Forma mais eficiente de escrever casos de uso

Pelo fato dos casos de uso modelarem requisitos, eles são altamente dinâmicos por natureza. Quanto mais examinamos um cenário, mais aprendemos, e mais as coisas mudam. Para complicar ainda mais esta questão, as mudanças em um caso de uso podem levar a mudanças em outros. Portanto, queremos um método flexível e altamente eficiente para escrever casos de uso que maximize o valor aos Stakeholders, minimize os riscos no início do projeto e minimize o custoso re-trabalho tardio.

Uma abordagem iterativa de abranger antes de aprofundar é melhor. Essa abordagem de abranger-primeiro envolve dois aspectos: encontrar e descrever os casos de uso e detalhar os casos de uso individuais.

Encontrando e detalhando os casos de uso

Os casos de uso existem em conjuntos, e os relacionamentos entre os vários casos de uso e Atores são importantes. Conforme você aprende mais sobre os Atores, você também aprende mais sobre os limites e transações do sistema. Do mesmo modo, conforme você aprende mais sobre as transações do sistema, você aprende mais sobre seus Atores. Portanto, é mais eficiente capturar e descrever os principais casos de uso antes de detalhar os casos de uso individuais. Desta forma, você pode identificar e compreender a importância e os riscos associados a cada caso de uso antes de investir tempo para detalhá-los. Este aspecto da abordagem ampliar antes de aprofundar é incorporado no processo pela separação explícita de duas tarefas Encontrar e Descrever os Requisitos e Detalhar os Requisitos.

Detalhando cada caso de uso

De modo similar, faz sentido escrever cada caso de uso iterativamente. Comece detalhando o cenário principal. À medida que fizer isso, você poderá identificar vários fluxos alternativos e de erro que o caso de uso pode seguir e então avaliá-los, rearranjá-los, eliminá-los e prioriza-los antes de detalhar dos cenários sobreviventes, então você poderá focar seus esforços no lugar certo.

O nível de detalhes que você captura depende de vários fatores. Veja Guideline: Formatos de Casos de Uso para orientação sobre a seleção do formato correto para seus casos de uso.

Detalhe o fluxo básico de eventos (cenário principal)

Como ponto de partida, use a descrição passo-a-passo do cenário principal que você criou durante a Task: Encontrar e Descrever os Requisitos. Então, adicione detalhes a esse cenário gradualmente, descrevendo o que o caso de uso faz, e não como, para resolver os problemas internos ao sistema.

Uma descrição de fluxo de eventos cobre:

Como e quando o caso de uso se inicia
Quando o caso de uso interage com os Atores, e quais dados eles trocam
Quando o caso de uso usa dados armazenados no sistema ou armazena dados no sistema
Como e quando o caso de uso termina

Ele não descreve:

A interface com o usuário
Os detalhes técnicos de hardware ou software
Questões de design

Descreva o fluxo de eventos do cenário principal da seguinte forma:

O caso de uso inicia quando o <Nome do ator> <faz algo>.
O sistema <faz algo em resposta>.
O <Nome do ator> <faz algo a mais>.

Veja a seção 4 do Example: Especificação de Caso de Uso para um exemplo completo de um fluxo básico.

Detalhe os fluxos alternativos

Um caso de uso é formado por um conjunto de cenários, cada um representando instâncias específicas do caso de uso que correspondem a entradas específicas do Ator ou condições específicas do ambiente. Cada cenário descreve formas alternativas de comportamento do sistema, ou pode descrever falhas ou casos de exceção.

Revise a lista de fluxos alternativos que você capturou durante a Task: Encontrar e Descrever os Requisitos. À medida que você detalha o cenário principal, você pode identificar fluxos alternativos adicionais fazendo as seguintes perguntas:

Existem opções diferentes, dependendo da entrada do Ator? (Por exemplo, se o Ator entrar uma senha inválida enquanto usa um caixa eletrônico)
Que regras de negócio podem estar em jogo? (Por exemplo: O Ator requisita ao caixa eletrônico mais dinheiro do que está disponível na sua conta).
O que poderia dar errado? (Por exemplo: Não há conexão de rede disponível quando é necessária uma transação).

É melhor desenvolver estes cenários iterativamente, como o cenário principal.

Inicie identificando-os.
Examine cada cenário possível para determinar se ele é relevante, se pode realmente acontecer e se é distinto dos outros cenários.
Elimine cenários redundantes ou desnecessários.
Priorize os cenários restantes e comece a elaborar os mais importantes.

Além de detalhar o fluxo de eventos de cada fluxo alternativo na forma descrita acima, cada fluxo alternativo deve descrever:

Onde pode ser inserido o fluxo alternativo no fluxo básico de eventos.
A condição que deve ser atendida para que o comportamento alternativo inicie.
Como e onde o fluxo básico de eventos continua, ou como o caso de uso termina.

Veja a seção 5 do Example: Especificação de Caso de Uso para exemplos completos de fluxos alternativos.

Estruture o caso de uso

É útil estruturar o caso de uso de acordo com os cenários. Isso ajuda a simplificar a comunicação e a manutenção e permite que os casos de uso sejam implementados iterativamente. Nomeie e descreva cada cenário principal, de forma que eles possam ser priorizados, atribuídos a uma iteração e a um indivíduo, e referenciados através da Lista de Itens de Trabalho para implementação.

Além de estruturar os casos de uso de acordo com os cenários, é útil estruturar os próprios cenários em sub-fluxos. Isso fornece um nível adicional de detalhe para o planejamento do trabalho e o acompanhamento do progresso. A menos que um sub-fluxo envolva somente uma parte menor do fluxo completo de eventos (que pode ser descrita no corpo do texto), é recomendado que você descreva cada sub-fluxo numa seção separada do Fluxo de Eventos. Seguem abaixo exemplos de sub-fluxos que devem ser separados numa seção:

Sub-fluxos que ocupam um grande segmento de um fluxo de eventos.
Fluxos de eventos excepcionais e alternativos. Isso ajuda a manter o fluxo básico de eventos do caso de uso mais claro.
Qualquer sub-fluxo que possa ser executado em vários pontos do mesmo fluxo de eventos.

Se existirem sub-fluxos identificados como sendo comuns para vários casos de uso, você pode re-fatorar seu modelo de caso de uso para incluí-los Veja Concept: Modelo de Caso de Uso para mais detalhes.

Para mais informações sobre estruturação de casos de uso, veja a seção "Fluxo de Eventos - Estrutura" em Concept: Caso de Uso.

O Template: Especificação de Caso de Uso fornece uma sugestão de estrutura para a especificação de caso de uso. Veja Example: Evolução do Modelo de Caso de Uso e Example: Especificação de Caso de Uso para exemplos de estruturação do modelo de caso de uso e da especificação de caso de uso, respectivamente.

Detalhe os requisitos especiais

Tenha certeza também de capturar qualquer requisito que esteja relacionado ao caso de uso, mas não seja levado em consideração no fluxo de eventos do caso de uso. Estes requisitos incluem as regras de negócio, restrições de design, requisitos de usabilidade, requisitos de desempenho, requisitos de confiabilidade, requisitos de suportabilidade e requisitos de interface. Todos esses requisitos influenciam a implementação e o custo associado tanto quanto o fluxo de eventos. Sendo assim, eles devem ser aprovados e priorizados.

Normalmente, os requisitos não-funcionais que se referem a um caso de uso específico são capturados na seção de Requisitos Especiais do caso de uso. Para mais informações, veja a seção "Requisitos Especiais" em Concept: Caso de Uso.

Se existirem requisitos não-funcionais que se aplicam a mais de um caso de uso, capture-os no Artifact: Especificação de Requisitos Suplementares. Para mais informações sobre requisitos suplementares, veja Concept: Requisitos Suplementares.

Para orientação em como escrever requisitos suplementares e especiais de forma clara, concisa e inequívoca, veja Escrevendo Bons Requisitos e Armadilhas dos Requisitos.

Veja a seção 8 do Example: Especificação de Caso de Uso para exemplos de requisitos especiais.

Descreva as precondições e pós-condições

Uma precondição de um caso de uso descreve o estado em que o sistema deve estar para que o caso de uso possa iniciar. Tome cuidado ao descrever o estado do sistema. Evite descrever detalhes de atividades incidentais que já podem ter acontecido.

Uma pós-condição de um caso de uso lista os possíveis estados que o sistema pode ficar ao término da execução do caso de uso. O sistema deve estar em um desses estados. Uma pós-condição também declara as ações que o sistema executa ao fim do caso de uso, independente do que ocorreu no caso de uso. As pós-condições podem ser categorizadas como Garantias Mínimas ou Garantias de Sucesso.

As Garantias Mínimas representam as condições que serão verdadeiras quando o caso de uso terminar, independente de como ele terminar.
As Garantias de Sucesso representam as condições que serão verdadeiras quando o caso de uso terminar com sucesso, independente de qual caminho ele seguiu.

Considere o seguinte ao especificar precondições e pós-condições:

Os estados descritos pelas pré ou pós-condições devem ser os estados que o usuário pode observar. "O usuário entrou no sistema" ou "o usuário abriu o documento" são exemplos de estados observáveis.
Uma precondição é uma restrição para que um caso de uso inicie. Não é o evento que faz o caso de uso iniciar.
Uma precondição para um caso de uso não é uma precondição para somente um sub-fluxo, embora você possa definir precondições e pós-condições no nível de sub-fluxos.
Uma pós-condição para um caso de uso deve ser verdadeira independente dos fluxos alternativos que foram executados; e não deve ser verdadeira somente para o fluxo principal. Se algo puder falhar, você pode identificar isso na pós-condição escrevendo "A ação está completa", ou se algo falhou, "A ação não foi executada", ao invés de "A ação está completa".

Para mais informações, veja a seção "Precondições e Pós-condições" em Concept: Caso de Uso.

Veja a seção 7 do Example: Especificação de Caso de Uso para exemplos de pré e pós-condições.