Como descrever casos de uso – Parte 4

Durante a modelagem de casos de uso uma das coisas mais importantes é descrever o comportamento de cada caso de uso. Essa descrição é também chamada de Especificação de Caso de Uso.

O RUP define um template que indica os itens que devem compor a especificação. Esse template é bastante extenso, mas eu sempre o uso como base para sugerir um template mais simples e ágil.

Seu conteúdo deve ter:

  • Nome do caso de uso,
  • Breve descrição,
  • Fluxos de eventos (fluxo básico e fluxos alternativos),
  • Pré e pós condição,
  • Requisitos especiais (descrever os requisitos específicos para o caso de uso em foco. É uma espécie de complementação do evento – do fluxo de eventos).
  • Especificações suplementares (somente a referência dos requisitos que são realizados pelo caso de uso em foco e também por outros casos de uso, ou aqueles que têm abrangência ampla no nível do sistema. A descrição do requisito está no artefato Especificação Suplementar).
  • Regras de negócio envolvidas (somente as referências das regras de negócio realizadas pelo caso de uso. Se quiser saber o detalhe da regra, é necessário acessar o artefato Regra de Negócio).

Nos próximos posts prometo que irei detalhar cada um desses itens que compõem a Especificação de Caso de Uso.

A literatura especializada apresenta uma grande quantidade de formatos de templates. Uma das formas mais populares é aquela que possui duas raias. Uma para o Ator e outra para o Sistema. Esse modelo é bem interessante porque permite uma melhor visualização da interação Ator X Sistema.

Em uma ocasião anterior eu fiz uma experiência usando o Diagrama de Atividades (da UML) no lugar de uma descrição textual. Distribuímos as atividades em duas raias (Ator e Sistema). O resultado foi excelente, porque foi facilmente entendido pelo usuário e foi de grande valor para os desenvolvedores, os quais alegaram que o diagrama eliminou ambiguidades e ofereceu precisão e facilidade na abstração dos serviços/operações que deverão ser implementados. O resultado final foi um considerável ganho de agilidade.

Infelizmente as empresas tendem a eternizar os templates em uso, muitas vezes proibindo mudanças. Essas coisas precisam ser constantemente revisadas para medir o quanto está contribuindo para a qualidade e produtividade da equipe.

Sugiro experimentar o diagrama de atividades como uma forma simples, precisa, solucionadora de problemas de ambiguidade e ágil de descrever os fluxos de eventos dos casos de uso.

Mas cuidado. Quando estiver montando o diagrama de atividades, concentre-se somente em duas grandes coisas:

  • A intenção do Ator.
  • As responsabilidades do sistema na produção do resultado de valor do ponto de vista do Ator.

Evite sempre modelar a navegabilidade. Isso não é responsabilidade de caso de uso e sim de Modelagem da Interface do Usuário.

 

Leitura adicional:

·         Casos de Uso – Embora seja uma técnica muito utilizada, ainda é mal compreendida – Parte 1

·         Que é Caso de Uso? – Parte 2

·         Como elicitar casos de uso? Parte 3.

·         Uso de Templates

·         Regra de Negócio Não é Requisito de Software

·         O RUP não é uma metodologia