Dicas para especificações de casos de uso

Seguem algumas dicas sobre especificações de casos de uso:

1. Não use detalhes de implementação ou de determinada tecnologia em

suas especificações.
a. A tecnologia ficará obsoleta, e seu caso de uso terá que ser
revisto.
b. Exemplos: imagine um sistema de autoatendimento bancário, em
caixas eletrônicos. Ao descrever a ação do usuário “informar seus
dados de acesso”, evite descrever como, por exemplo: “Usuário
insere o seu cartão”. Em vez disso, use: “Usuário informa dados da
agência, conta e senha de acesso”.
c. Amanhá a tecnologia muda e a identificação passa a ser, por
exemplo, pela leitura da digital, e o caso de uso precisará ser
escrito novamente. Fazendo como o proposto, estará adequado a
qualquer tecnologia.

2. Procure não associar casos de uso a telas de sistemas.

a. Muitos autores sugerem que listemos esboços de telas nas
especificações de casos de uso. Geralmente os autores são
favoráveis e os processos de desenvolvimentos são ágeis, visando
entregar o código o mais rápido possível.
b. Procure evitar essa prática, pois no momento em que estamos
especificando os casos de uso, ainda é cedo para pensarmos em
interface, que será objeto da fase de projeto do sistema.
c. Resista a essa tentação, pois sabemos que os usuários adoram
telas.

3. Existe um formato de especificação de que muitos gostam, pois fica mais

claro o diálogo que acontece entre ator e caso de uso. O modelo tem
 duas colunas. Na primeira, descrevemos as ações do ator, e na segunda as
ações do sistema.

4. Os casos de uso incluídos (chamados de <include>) ou estendidos

(chamados por <extends>) também devem ter descrição textual, podendo
estar no formato resumido ou informal.

5. Perguntas que podem ajudar no detalhamento dos cenários principal e

alternativos:

a. Quando tudo ocorre na normalidade (com sucesso), qual o

comportamento do sistema? – Esse será o passo a passo do cenário
principal;
b. Algo pode acontecer de forma diferenciada nesse passo? – Indica
um cenário alternativo (relacionado a esse passo);
c. O que pode dar errado nesse passo? – Da mesma forma que a
pergunta anterior, esta conduz à identificação de um cenário
alternativo.

6. Quando um passo for muito complicado, ele pode vir a ser um novo caso
de uso, que se relacionará com o caso original pelo estereótipo
<include>.

7. Faça casos de uso enxutos, pois casos longos podem não ser lidos em sua
totalidade.