O livro descreve um método para escrever parte de uma declaração de problema, ou seja, o método de caso de uso.
O que é isso? Esta é uma descrição do cenário de interação do usuário com o sistema (ou com o negócio). Nesse caso, o sistema atua como uma caixa preta (e isso permite dividir a complexa tarefa de design em projetar a interação e 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 algumas verificações de completude e conformidade com os objetivos da parte interessada.
Exemplo de caso de uso
Como fica o cenário, usando o exemplo de autorização no site via email:
(Sistema) Faça login no site para acessar sua conta pessoal. ~~ (nível do mar)
Contexto: Um cliente não autorizado faz login no site para que o site o reconheça e mostre suas informações pessoais: histórico de navegação, histórico de compras, número atual de pontos de bônus, etc., usando o e-mail como login.
Nível: meta do usuário
Personagem principal: cliente (visitante da nossa loja online)
Escopo: Interação do cliente com o site da loja online
Partes interessadas e interesses:
- o profissional de marketing deseja que o número máximo de visitantes do site seja identificado para maior cobertura de correspondências pessoais,
- o especialista em segurança deseja garantir que não haja casos de acesso não autorizado aos dados pessoais do visitante, incluindo tentativas de adivinhar a senha de uma conta ou procurar uma conta com senha fraca,
- o invasor deseja obter acesso aos bônus da vítima,
- os concorrentes querem deixar comentários negativos sobre os produtos,
- A botnet quer obter a base de clientes da loja e usar um ataque para tornar o site inoperante.
Pré-condições: o visitante não deve ser autorizado.
Garantias mínimas: o visitante saberá se a tentativa de autorização foi bem-sucedida ou malsucedida.
Garantias de sucesso: o visitante está autorizado.
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 de autorização malsucedidas de uma determinada sessão (busca de uma senha fraca para múltiplas contas) de acordo com a “Regra de Segurança nº 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 digita seu e-mail e senha.
- O sistema confirma a presença de um cliente com tal e-mail no sistema e que a senha corresponde e o número de tentativas de login nesta conta não é excedido de acordo com a “Regra de Segurança nº 24”.
- O sistema autoriza o cliente, adiciona o histórico de navegação e o cesto desta sessão com a última sessão desta conta de cliente.
- O sistema exibe uma mensagem de sucesso de autorização e passa para a etapa de script a partir da qual o cliente foi interrompido para autorização. Neste caso, os dados da página são recarregados levando em consideração os dados da conta pessoal.
Extensões:
2.a. O cliente já está autorizado:
2.a.1. O sistema notifica o cliente sobre o fato da autorização realizada anteriormente e se oferece para interromper o script ou ir para a etapa 4, e se a etapa 6 for concluída com sucesso, a etapa 7 é executada com esclarecimentos:
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 o carrinho desta sessão de interação permanecem na conta antiga e não são transferidos para a nova. Em seguida, vá para a etapa 8.
2.b O número de tentativas de autorização excedeu o limite de acordo com a “Regra de Segurança No. 23”:
2.b.1 Vá para a etapa 4, um 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 de autorização malsucedidas para esta conta
2.b.6.1.2. o sistema exibe uma mensagem de falha e retorna para a etapa 2
6.a. Nenhuma conta com este e-mail foi encontrada:
6.a.1 O sistema exibe uma mensagem de falha e oferece a opção de ir para a etapa 2 ou ir para o cenário “Cadastro de Usuário” e salvar o e-mail inserido,
6.b. A senha da conta com este e-mail não corresponde à digitada:
6.b.1 O sistema aumenta o contador de tentativas de login malsucedidas nesta conta.
6.b.2 O sistema exibe uma mensagem sobre falha e oferece a opção de ir para o cenário “Recuperação de senha” ou ir para a etapa 2.
6.c: O contador de tentativas de login para esta conta excedeu o limite da “Regra de segurança nº 24”.
6.c.1 O sistema exibe mensagem sobre bloqueio de login da conta por X minutos e segue para o passo 2.
O que é ótimo
Verifica a completude e o cumprimento das metas, ou seja, você pode entregar os requisitos a outro analista para verificação, cometendo menos erros na fase de formulação do problema.
Trabalhar com um sistema caixa preta permite separar o desenvolvimento e a coordenação com o cliente do que será automatizado dos métodos de implementação.
Faz parte da trajetória do analista, uma das principais partes da usabilidade. O cenário do usuário define os principais caminhos de seu movimento, o que reduz muito a liberdade de escolha do designer e do cliente e ajuda a aumentar a velocidade de desenvolvimento do projeto.
Estou muito satisfeito com o local na descrição onde são identificadas exceções para cada etapa da interação. Um sistema de TI completo deve fornecer algum tipo de tratamento de exceções, algumas manualmente, outras automaticamente (como no exemplo acima).
A experiência mostra que o tratamento de exceções mal pensado pode facilmente transformar um sistema em um sistema terrivelmente inconveniente. Lembro-me da história de quando, nos tempos soviéticos, para tomar uma decisão, era necessário obter várias aprovações de diferentes serviços, e como é doloroso quando o último serviço diz - mas a sua candidatura está com o nome errado ou algum outro erro no pontuação, refazer tudo e recoordenar tudo.
Muitas vezes me deparo com situações em que a lógica de funcionamento de um sistema que não foi pensada para exceções exigiu um retrabalho significativo do sistema. Por causa disso, a maior parte do trabalho do analista é gasta no tratamento de exceções.
A notação de texto, ao contrário dos diagramas, permite que mais exceções sejam identificadas e cobertas.
Adição ao método da prática
O caso de uso não é uma parte da declaração com prioridade independente, ao contrário da história do usuário.
No cenário acima, considere a exceção “6.a. Nenhuma conta com este e-mail foi encontrada.” e a próxima etapa “6.a.1 O sistema exibe uma mensagem de falha e segue para a etapa 2.” Que coisas negativas ficaram nos bastidores? Para o cliente, qualquer retorno equivale ao fato de todo o trabalho que ele fez de inserção de dados ser jogado em aterro. (Simplesmente não está visível no script!) O que pode ser feito? Reconstrua o script para que isso não aconteça. É possível fazer isso? Você pode - por exemplo, consultar o script de autorização do Google.
Otimização de cenário
O livro fala sobre formalização, mas diz pouco sobre métodos para otimizar tais cenários.
Mas é possível fortalecer o método otimizando cenários, e o método de formalização de casos de uso permite que isso seja feito. Especificamente, você precisa pensar em cada exceção que ocorre, determinar a causa e reconstruir o script para se livrar da exceção ou minimizar a jornada do cliente.
Ao fazer um pedido em uma loja online, você deve inserir a cidade de entrega. Pode acontecer que a loja não consiga entregar a mercadoria na cidade escolhida pelo cliente por não entregar aí, por restrições de tamanho, ou por falta de mercadoria no armazém correspondente.
Se simplesmente descrevermos o cenário de interação na fase de cadastro, podemos escrever “informar ao cliente que a entrega é impossível e oferecer a mudança de cidade ou conteúdo do carrinho” (e muitos analistas novatos param por aí). Mas se houver muitos casos assim, o cenário poderá ser otimizado.
A primeira coisa que você precisa fazer é escolher apenas a cidade onde podemos entregar. Quando fazer isso? Antes de selecionar um produto no site (autodetecção da cidade via IP com esclarecimento).
Em segundo lugar, precisamos de poder escolher apenas as mercadorias que podemos entregar ao cliente. Quando fazer isso? No momento da seleção - no bloco do produto e no cartão do produto.
Essas duas mudanças contribuem bastante para eliminar essa exceção.
Requisitos para medições e métricas
Ao considerar a tarefa de minimizar o tratamento de exceções, você pode definir uma tarefa de relatório (o caso de uso não é descrito). Quantas exceções houve, em que casos ocorreram, além de quantos cenários de entrada foram aprovados com êxito.
Mas, infelizmente. A experiência tem mostrado que os requisitos de relatórios para cenários neste formato não são suficientes; é necessário considerar os requisitos de relatórios para processos que são descritos principalmente não na forma de um caso de uso.
Acesso à Usabilidade
Em nossa prática, ampliamos o formulário de descrição de casos de uso com uma descrição de atributos específicos de entidades e dados para o cliente tomar uma decisão, o que aprimora a usabilidade posterior.
Para design de usabilidade, adicionamos uma seção de entrada - exibir dados.
Num cenário com autorização, é o fato do cliente estar autorizado no sistema. Se o cliente for pré-autorizado, exiba um aviso sobre a mudança do histórico de navegação e do carrinho para a nova conta após a autorização bem-sucedida.
Em geral, trata-se de uma exibição das informações necessárias ao cliente para que ele possa tomar uma decisão sobre suas futuras ações de acordo com o cenário (você pode perguntar se esses dados são suficientes para o cliente, o que mais é necessário, quais informações não o cliente precisa tomar decisões).
Também vale a pena dividir as informações inseridas em campos de entrada caso sejam processados separadamente e com formação de diferentes exceções.
No exemplo com autorização do cliente, se você separar as informações inseridas em login e senha, vale a pena alterar o script de autorização para destacar as etapas de inserção de um login separado e uma senha separada (e isso é feito no Yandex, Google, mas não é feito na maioria das lojas online).
Alcançando as transformações de dados necessárias
Você também pode extrair requisitos para algoritmos de conversão de dados do script.
Примеры:
- Para tomar a decisão de adquirir um produto em uma loja online, o cliente precisa saber na ficha do produto a possibilidade, custo, prazo de entrega deste produto em sua cidade (que são calculados pelo algoritmo com base na disponibilidade do produto em armazéns e parâmetros da cadeia de abastecimento).
- Ao inserir uma frase na linha de pesquisa, o cliente recebe sugestões de pesquisa de acordo com o algoritmo (que são geradas pelo algoritmo...).
No total
Em geral, depois de ler o livro, infelizmente, não fica claro como passar de um analista a problemas de negócios até uma especificação técnica formalizada para um desenvolvedor. O livro conta apenas parte do processo, com as etapas de entrada pouco claras e as próximas etapas pouco claras. O caso de uso em si geralmente não é uma declaração completa para o desenvolvedor.
No entanto, esta é uma forma muito boa de formalizar e processar cenários de interação entre um objeto e um sujeito, quando a interação provoca uma mudança em algo no sujeito. É um dos poucos métodos de escrita que permite requisitos verificáveis com pontos de busca de exceção explícitos.
O livro é uma leitura obrigatória para os analistas começarem a escrever peças testáveis.
Fonte: habr.com