Escrever casos de uso parece coisa simples, mas ao não se concentrar nos princípios fundamentais que orientam a elaboração de um bom caso de uso, acaba-se cometendo erros. Conheça os sete erros mais comuns:
1. Escrever requisitos funcionais em vez de cenários de utilização
Os casos de uso são escritos em termos sobre o que o sistema deve fazer. Cenários de uso descrevem ações dos usuários e as respostas obtidas do sistema.
É importante que o texto do caso de uso permita claramente identificar como o sistema realizará um determinado comportamento. Deve-se manter uma clara distinção entre as descrições das ações (voz ativa) e os requisitos funcionais (voz passiva)
Exemplos:
Caso de uso: Editar conteúdo do carrinho de compras
(incorreto) – Fluxo Básico – Se o cliente modificar a quantidade de um item no carrinho de compras, e pressionar o botão de atualização, o sistema irá armazenar a nova quantidade, e exibir a novo custo para o item selecionado.
(correto) – Fluxo Básico – Na página do carrinho de compras, o cliente modifica a quantidade de um item e então pressiona o botão atualizar. O sistema armazena a nova quantidade e exibe o novo custo para o item selecionado.
2. Descrever atributos e métodos em vez de cenários de uso
Os casos de uso não devem conter muitos detalhes de telas e também estar livres de detalhes de campos de telas. Se você, por exemplo, estiver escrevendo um caso de uso e estiver relacionando vários campos da tela no texto de caso de uso, pare! O objetivo aqui é descrever o que o sistema deverá fazer, e não como será feito.
Exemplos:
Caso de uso: Processar Pedido
(incorreto) O operador do estoque certifica-se que os itens relacionados no pedido conferem com o itens físicos. O operador passa o código de barras na leitora da estação. O sistema executa o método mudança de estado do pedido, para mudar o pedido para o estado de atendido, e então chama o método alterar quantidade em estoque, para cada um dos itens do pedido
(correto) O operador do estoque certifica-se que os itens relacionados no pedido conferem com o itens físicos. O operador passa o código de barras na leitora da estação. O sistema muda o estado do pedido, para atendido, e então atualiza a quantidade em estoque, para cada um dos itens do pedido
3. Escrever casos de uso de forma muito resumida
O objetivo de um caso de uso é descrever todos os detalhes da ação do usuário e da resposta do sistema. É melhor que o texto seja o mais completo possível, do que ser um texto muito resumido que omite esses detalhes
Deve-se lembrar também que os casos de uso servirão para a elaboração do manual do usuário. Assim é melhor pecar por excesso do que por falta de detalhes no manual do usuário.
Exemplos:
Caso de uso: Criar conta do cliente
(incorreto) O cliente entra com a informação solicitada. O sistema valida as informações e cria uma nova conta para o usuário
(correto) O cliente entra com o seu nome, e-mail, e a senha (duas vezes) e então pressiona o botão criar conta. O sistema certifica que o cliente forneceu dados válidos e então cria uma nova conta usando esses dados. O sistema conduz o cliente à página principal do sistema.
4. Desconectar-se completamente da interface do usuário
Um dos fundamentos da notação de casos de uso, é que os desenvolvedores concordem em desenhar o sistema sob o ponto de vista dos usuários. Não é possível praticar isso, sem ser especifico as quais ações serão realizadas pelos usuários nas respectivas telas.
Entretanto não é necessário entrar em detalhes de campos ou detalhes cosméticos sobre a tela (trabalho do protótipo). O importante é citar pontos da interface que permite ao usuário dizer para o sistema fazer algo.
Exemplos:
Caso de uso: Procurar item
(incorreto) O cliente digita o nome do animal e então submete uma requisição de pesquisa. O sistema recupera detalhes importantes sobre cada animal e então exibe uma lista de animais.
(correto) O cliente digita o nome do animal na página de pesquisa e então pressiona o botão procurar. O sistema recupera detalhes importantes sobre cada animal, então o sistema exibe uma lista de animais em página de resultados da pesquisa.
5. Evitar explicitar o nome dos objetos de fronteira
Objetos de fronteira são objetos que os atores irão interagir. Exemplos – janelas, caixa de diálogos, menus, etc. Na diretriz de detalhar a navegação do usuário, é necessário dar nomes aos objetos de fronteira no texto do caso de uso
Os nomes desses objetos serão posteriormente úteis nas próximas fases do desenho do sistema
Exemplos:
Caso de uso: Acompanhar pedidos recentes
(incorreto) O sistema recupera e exibe os pedidos que o cliente solicitou nos últimos 30 dias. O cliente solicita detalhamento de um pedido. O sistema recupera e exibe o conteúdo do pedido, apenas no modo de leitura. O cliente retorna para a lista de pedidos, quando ele finalizou a leitura dos detalhes do seu pedido.
(correto) O sistema recupera e exibe os pedidos que o cliente solicitou nos últimos 30 dias, e exibe esses pedidos na página de acompanhamento de pedidos. Cada registro possui um numero de pedido (em forma de link) O cliente seleciona um link. O sistema recupera e exibe o conteúdo do pedido, apenas no modo de leitura na página de detalhamento do pedido. O cliente pressiona OK e retorna para a página de acompanhamento de pedido.
6. Descrever apenas as interações do usuário e esquecer as respostas do sistema
A narrativa de um caso de uso deve ser orientada por respostas a eventos, ou seja, “O sistema faz isto quando o usuário faz aquilo” O caso de uso deve capturar o que ocorre em decorrência a ação do ator: criação de registros em tabelas, validação de entrada de dados do usuário, mensagens de erros, etc.
O texto do caso de uso deve descrever os dois lados do diálogo entre o ator e o sistema, e todo o comportamento que se está buscando descobrir, ocorre do lado do sistema neste diálogo. Deixar a resposta do sistema de fora, significa ignorar o comportamento do sistema
Exemplos:
Caso de uso: Editar conteúdo do carrinho de compras
(incorreto) Na página do carrinho de compras, o cliente modifica a quantidade de um item do carrinho de compras, e então pressiona o botão de atualização. Então o cliente pressiona o botão de continuar comprando
(correto) Na página do carrinho de compras, o cliente modifica a quantidade de um item do carrinho de compras, e então pressiona o botão de atualização. O sistema armazena a nova quantidade, calcula e exibe o novo custo para tal item. Então o cliente pressiona o botão de continuar comprando.
7.Omitir texto para os fluxos alternativos
Apesar dos fluxos básico serem mais fáceis de se identificar, não significa que se deva deixar de fora os fluxos alternativos. Geralmente os fluxos alternativos importantes só são descobertos na fase de codificação e depuração.
Nesta ocasião, o programador tende a encontrar uma solução que lhe seja mais conveniente, o que não é saudável para o projeto
Exemplos:
Caso de uso: efetuar logon
(incorreto) O cliente entra com a sua identificação e senha, e então o cliente pressiona o botão de log-in. O sistema conduz o cliente para a página inicial.
(correto) O cliente entra com a sua identificação e senha, e então o cliente pressiona o botão de log-in. O sistema valida as informações contra os dados da conta do usuário e então conduz o cliente para a página inicial
