No livro "Métodos modernos para descrever os requisitos funcionais para sistemas", Alistair Coburn descreveu um método para escrever uma parte da declaração do problema, a saber, o método de caso de uso.
O que é isso Esta é uma descrição de um cenário de interação do usuário com um sistema (ou empresa). O sistema funciona ao mesmo tempo como uma caixa preta (e isso possibilita dividir a complexa tarefa de design no design da interação e em garantir essa interação). Ao mesmo tempo, são introduzidos padrões de notação, o que garante facilidade de leitura, inclusive para não participantes, e permite que você faça algumas verificações quanto à integridade e conformidade com os objetivos da parte interessada.
Um exemplo de caso de utilização
Como é o cenário, usando o exemplo de autorização no site por email:
(Sistema) Faça login no site para acessar sua conta pessoal. ~~ (nível do mar)
Contexto: um cliente não autorizado é autorizado no site para que o site o reconheça e exiba informações pessoais para ele: histórico de navegação, compras, número atual de pontos de bônus, etc., usando o email como login.
Nível: Objetivo do Usuário
Ator principal: cliente (visitante da nossa loja online)
Escopo: interação do cliente com o site da loja online
Interessados e interesses:
- o profissional de marketing deseja que o número máximo de visitantes do site seja identificado para alcançar melhor os boletins pessoais,
- um especialista em segurança deseja impedir o acesso não autorizado aos dados pessoais do visitante, incluindo tentativas de selecionar uma senha para uma conta ou procurar uma conta com uma senha fraca,
- um invasor deseja obter acesso aos bônus das vítimas,
- os concorrentes querem deixar um feedback negativo sobre os produtos,
- a botnet deseja obter a base de clientes da loja e usar o ataque para tornar o site inoperante.
Condições prévias: o visitante não deve estar logado.
Garantias mínimas: o visitante descobrirá o fato de uma tentativa de login bem-sucedida ou malsucedida.
Garantias de sucesso: o visitante está autorizado.
O cenário principal:
- O cliente inicia a autorização.
- O sistema confirma que o cliente não está autorizado e não excede o número de tentativas malsucedidas de login desta sessão (procurando uma senha fraca para muitas contas) sob a Regra de Segurança No. 23.
- O sistema aumenta o contador do número de tentativas de autorização.
- O sistema exibe um formulário de autorização para o cliente.
- O cliente insere email e senha.
- O sistema confirma a presença de um cliente com esse e-mail no sistema e a senha corresponde e não excede o número de tentativas de entrada nesta conta de acordo com a Regra de Segurança Nº 24.
- O sistema autoriza o cliente, adiciona o histórico de navegação e a cesta desta sessão à última sessão desta conta do cliente.
- O sistema exibe uma mensagem de êxito da autorização e prossegue para a etapa do script a partir da qual o cliente interrompeu para autorização. Nesse caso, os dados na página estão sobrecarregados, levando em consideração os dados pessoais da conta.
Extensões:
2.a. O cliente já está autorizado:
2.a.1 O sistema notifica o cliente do fato da autorização feita anteriormente e sugere a interrupção do script ou a etapa 4, enquanto que a etapa 6 foi concluída com êxito, a etapa 7 é executada com o esclarecimento:
2.a.7 O sistema desativa o cliente na conta antiga, autoriza o cliente na nova conta, enquanto o histórico de navegação e a cesta dessa sessão de interação permanecem na conta antiga, não entram na nova. Em seguida, vá para a etapa 8.
2.b O número de tentativas de autorização excedeu o limite em "Regra de Segurança No. 23":
2.b.1 Vá para a etapa 4, o captcha é exibido adicionalmente no formulário de autorização
2.b.6 O sistema confirma a entrada correta do captcha
2.b.6.1 Captcha digitado incorretamente:
2.b.6.1.1 o sistema também aumenta o contador de tentativas malsucedidas de login para esta conta
2.b.6.1.2 o sistema exibe uma mensagem de falha e retorna à etapa 2
6.a. Nenhuma conta com este email foi encontrada:
6.a.1 O sistema exibe uma mensagem sobre a falha e oferece a opção de transição para a etapa 2 ou transição para o script "Registro do usuário", salvando o e-mail inserido,
6.b. A senha da conta com este email não corresponde à digitada:
6.b.1 O sistema aumenta o contador de tentativas malsucedidas de entrar nesta conta.
6.b.2 O sistema exibe uma mensagem de falha e oferece uma opção para a transição para o cenário “Recuperação de senha” ou para a etapa 2.
6.c: O contador de tentativas de entrada nesta conta excedeu o limite em "Regra de Segurança No. 24".
6.v.1 O sistema exibe uma mensagem sobre o bloqueio da entrada na conta por X minutos e prossegue para a etapa 2.
O que é ótimo
Verifica a integridade e a conformidade com as metas, ou seja, você pode fornecer os requisitos para verificação a outro analista, permitindo menos erros no estágio de definição da tarefa.
Trabalhar com um sistema como uma caixa preta permite compartilhar o desenvolvimento e a coordenação com o cliente do que será automatizado a partir dos métodos de implementação.
Faz parte do caminho do analista, uma das principais partes da usabilidade. O script do usuário define os principais caminhos para seu movimento, o que reduz bastante a liberdade de escolha para o designer e o cliente e ajuda a aumentar a velocidade do desenvolvimento do design.
É muito agradável na descrição do local onde as exceções de cada etapa da interação são reveladas. Um sistema de TI holístico deve fornecer um ou outro tratamento de exceção, parte no modo manual, parte no automático (como no exemplo acima).
A experiência mostrou que o tratamento de exceções mal pensado pode facilmente transformar um sistema em um sistema terrivelmente inconveniente. Lembro-me de uma história em que, nos tempos soviéticos, foram necessárias várias aprovações de diferentes serviços para tomar uma decisão, e dói quando o último serviço diz - e você tem um nome errado ou algum outro erro na pontuação, refaz tudo e reconcilia tudo.
Muitas vezes me deparo com situações em que uma lógica do sistema que não foi pensada para exceções exigia uma alteração significativa desse sistema. Por esse motivo, a maior parte do trabalho do analista é gasta no tratamento de exceções.
A notação de texto, diferentemente dos diagramas, permite identificar e cobrir mais exceções.
Adição ao método de prática
O caso de uso não é uma parte da produção com prioridade independente, diferente da história do usuário.
Nesse cenário, considere a exceção “6.a. Nenhuma conta foi encontrada com este e-mail. ” e a próxima etapa "6.a.1. O sistema exibe uma mensagem de falha e prossegue para a etapa 2". Qual o negativo permanece nos bastidores? Para o cliente, qualquer retorno é equivalente ao fato de que todo o trabalho que ele fez ao inserir os dados é jogado no aterro. (Isso simplesmente não é visível no script!) O que pode ser feito? Recrie o script para que isso não ocorra. Isso pode ser feito? Você pode - por exemplo, ver o script de autorização no Google.
Otimização de cenário
O livro fala sobre formalização, mas fala pouco sobre métodos de otimização para esses cenários.
Mas é possível fortalecer o método otimizando scripts, e o método de formalização de casos de uso permite isso. Especificamente, para cada exceção que ocorre, você precisa pensar sobre ela, determinar a causa e reconstruir o script para se livrar da exceção ou minimizar o caminho do cliente.
Ao fazer o pedido da loja on-line, você precisa entrar na cidade de entrega. Pode acontecer que, para uma cidade escolhida pelo cliente, a loja não possa entregar a mercadoria porque ela não entrega lá, devido a restrições gerais ou devido à falta de mercadorias no armazém correspondente.
Se você simplesmente descrever o cenário de interação no estágio de design, poderá escrever "informar o cliente sobre a impossibilidade de entrega e oferecer a mudança da cidade ou da composição da cesta" (e muitos analistas iniciantes param por aí). Mas se houver muitos desses casos, você poderá otimizar o cenário.
A primeira coisa a fazer é dar apenas a cidade onde podemos fazer a entrega. Quando fazer isso? Antes do momento de escolher um produto no site (detecção automática da cidade via ip com especificação).
Segundo - você precisa escolher apenas os produtos que podemos entregar ao cliente. Quando fazer isso? No momento da seleção - no ladrilho de mercadorias e no cartão do produto.
Essas duas alterações eliminam significativamente essa exceção.
Medição e requisitos métricos
Considerando a tarefa de minimizar o tratamento de exceções, é possível colocar a tarefa no relatório (o caso de uso não é descrito). Quantas exceções foram, em que casos ocorreram, além de quantos cenários foram bem-sucedidos dos de entrada.
Mas infelizmente. A experiência mostrou que os requisitos de relatório para cenários neste formulário não são suficientes; você precisa considerar os requisitos de relatório para processos descritos principalmente não na forma de um caso de uso.
Acesso à usabilidade
Em nossa prática, expandimos a descrição da descrição do caso de uso com a descrição de atributos específicos de entidades e dados para tomada de decisão pelo cliente, o que aprimora a usabilidade subsequente.
Para o design da usabilidade, adicionamos uma seção de entrada - os dados exibidos.
Em um cenário de autorização, esse é um fato da autorização do cliente no sistema. Se o cliente estiver pré-autorizado, exiba um aviso sobre como alternar o histórico de navegação e a cesta para a nova conta após uma autorização bem-sucedida.
No caso geral, este é um mapeamento das informações necessárias para o cliente, para que ele possa tomar uma decisão sobre suas ações adicionais de acordo com o cenário (pode-se perguntar se o cliente possui dados suficientes, o que mais é necessário, quais informações são necessárias para que o cliente tome decisões).
Também vale a pena dividir as informações de entrada nos campos de entrada se o processamento ocorrer separadamente e com a formação de várias exceções.
No exemplo com autorização do cliente, se você destacar as informações inseridas com um nome de usuário e senha, altere o script de autorização com as etapas separadas para inserir um login e senha separados (e isso é feito no Yandex, Google, mas não na maioria das lojas online).
Acesso às conversões de dados necessárias
Os requisitos para algoritmos de transformação de dados também podem ser extraídos do script.
Exemplos:
- Para tomar uma decisão de comprar um produto em uma loja online, o cliente precisa saber no cartão do produto a possibilidade, o custo e as condições de entrega deste produto em sua cidade (calculadas pelo algoritmo sobre o fato da disponibilidade de mercadorias nos armazéns e nos parâmetros da cadeia de suprimentos).
- Quando uma frase é inserida na cadeia de pesquisa, o cliente recebe as dicas de pesquisa pelo algoritmo (formado pelo algoritmo ...).
Total
Em geral, depois de ler o livro, infelizmente, não está claro como percorrer todo o caminho, desde o analista até os problemas de negócios, até o TK formalizado para o desenvolvedor. O livro conta apenas parte do processo, com a entrada de palavras pouco claras e as próximas etapas. Por si só, o caso de uso geralmente não é uma declaração completa para o desenvolvedor.
No entanto, essa é uma maneira muito boa de formalizar e processar cenários da interação de um objeto e um sujeito, quando a interação causa uma alteração em algo no sujeito. É um dos poucos métodos de gravação que permitem requisitos verificáveis com pontos de pesquisa explícitos de exceção.
É necessário que o livro seja lido pelos analistas para que eles comecem a escrever produções verificáveis.