Uma descrição de caso de uso explica como um ator alcança um objetivo interagindo com um sistema. Ela complementa um diagrama de casos de uso:

• Diagrama de casos de uso:Mostra atores, escopo do sistema e relacionamentos.

• Descrição de caso de uso:Explica o comportamento detalhado, condições, regras e resultados.

Um diagrama fornece o mapa; a descrição fornece a rota.

1. O que é um Caso de Uso?

Um caso de uso representa um objetivo valioso que um ator externo alcança por meio de um sistema.

Exemplos:

• Cliente faz um pedido

• Funcionário apresenta uma solicitação de reembolso

• Paciente agenda uma consulta

• Administrador cria uma conta de usuário

• Cliente redefine uma senha

Um bom caso de uso é:

• Orientado a objetivos

• Valioso para um ator

• Descrito da perspectiva do usuário

• Independente de layouts específicos de tela

• Focado no comportamento observável do sistema

Nomes de casos de uso ruins e melhorados

Use uma frase curta verbo–substantivo, como Enviar Solicitação de Reembolso, Rastrear Remessa, ou Aprovar Solicitação de Empréstimo.

2. Conceitos-Chave

2.1 Ator

Um ator é um papel externo que interage com o sistema.

Um ator pode ser:

• Uma pessoa

• Uma organização

• Outro sistema de software

• Um dispositivo de hardware

• Um gatilho agendado ou baseado em tempo

Exemplos:

• Cliente

• Agente de Suporte

• Auxiliar de Armazém

• Gateway de Pagamento

• Serviço de E-mail

• Administrador

Um ator é um papel, não necessariamente um indivíduo específico. Por exemplo, “Cliente” geralmente é melhor do que “Jane Smith.”

Atores principais e de suporte

O ator principal inicia o caso de uso para alcançar um objetivo.

O ator de suporte auxilia o sistema durante a execução.

Exemplo:

• Ator principal: Cliente

• Ator de suporte: Gateway de Pagamento

• Caso de uso: Fazer Pedido

O cliente inicia o pedido, enquanto o gateway de pagamento autoriza o pagamento.

2.2 Limite do Sistema

O limite do sistema define o que está dentro do sistema que está sendo modelado.

Para uma loja online, o limite pode conter:

• Navegar pelos Produtos

• Adicionar Produto ao Carrinho

• Fazer Pedido

• Realizar Pagamento

• Rastrear Pedido

Os seguintes estão fora do limite:

• Cliente

• Gateway de Pagamento

• Empresa de Entrega

• Provedor de E-mail

O limite evita confusão sobre a responsabilidade do sistema.

2.3 Caso de Uso

Um caso de uso deve descrever uma interação completa que produz um resultado significativo.

Por exemplo:

Realizar Pedido:Um cliente seleciona produtos, fornece informações de entrega, paga pelo pedido e recebe uma confirmação de pedido.

“Validar número de cartão de crédito” pode ser uma função do sistema, mas geralmente é muito pequena para ser um objetivo de usuário independente. Em vez disso, pode fazer parte de Realizar Pedido ou Realizar Pagamento.

2.4 Pré-condições

Uma pré-condição declara o que já deve ser verdadeiro antes que o caso de uso comece.

Exemplos:

• O cliente possui uma conta ativa.

• O produto está disponível para venda.

• O funcionário está autenticado.

• O horário da consulta existe.

• O carrinho de compras contém pelo menos um item.

Uma pré-condição não é uma ação realizada pelo caso de uso.

Pré-condição inadequada:

O cliente faz login.

Pré-condição melhor:

O cliente está autenticado.

2.5 Pós-condições

Uma pós-condição declara o que é verdadeiro após o término do caso de uso.

Exemplos:

• O pedido foi registrado.

• O pagamento foi autorizado.

• Um e-mail de confirmação é enviado.

• A solicitação de reembolso tem status de enviada.

• A conta de usuário está marcada como ativa.

Pós-condições devem descrever resultados, não detalhes de implementação.

Pós-condição ruim:

A pedidos tabela é atualizada.

Pós-condição melhor:

O pedido é armazenado e disponível para atendimento.

2.6 Cenário Principal de Sucesso

O cenário principal de sucesso, também chamado de fluxo básico ou caminho feliz, descreve a interação normal bem-sucedida.

Cada passo deve descrever:

1. Uma interação entre ator e sistema

2. Uma resposta do sistema

3. Uma ação de negócios significativa

Exemplo:

1. O cliente seleciona os produtos.

2. O sistema exibe o carrinho atual.

3. O cliente insere as informações de entrega.

4. O sistema valida as informações de entrega.

5. O cliente envia o pedido.

6. O sistema solicita autorização de pagamento.

7. A gateway de pagamento autoriza o pagamento.

8. O sistema registra o pedido.

9. O sistema exibe a confirmação do pedido.

Evite detalhes específicos da interface, a menos que sejam essenciais para o requisito.

Passo inadequado:

O cliente clica no botão azul no canto inferior direito.

Passo melhor:

O cliente envia o pedido.

2.7 Fluxos Alternativos

Um fluxo alternativo descreve uma variação válida do cenário principal.

Exemplos:

• O cliente escolhe a retirada na loja em vez da entrega.

• O cliente paga com um método de pagamento salvo.

• O administrador aprova uma reivindicação com condições.

• O usuário se autentica usando um código de uso único.

Fluxos alternativos podem se reconectar ao fluxo principal.

Exemplo:

A1. O cliente usa um método de pagamento salvo
No Passo 6, o cliente seleciona um método de pagamento salvo. O sistema solicita autorização usando esse método e, em seguida, continua no Passo 7.

2.8 Fluxos de Exceção

Um fluxo de exceção descreve uma condição malsucedida ou anormal.

Exemplos:

• O pagamento é recusado.

• O produto está sem estoque.

• A autenticação falha.

• O serviço externo está indisponível.

• Os dados obrigatórios são inválidos.

Um fluxo de exceção deve explicar:

• Onde o problema ocorre

• O que o sistema faz

• O que o ator vê

• Se o caso de uso termina ou retoma

Exemplo:

E1. Pagamento recusado
No Passo 7, a Gateway de Pagamento rejeita a transação. O sistema exibe o motivo, marca o pedido como não pago e permite que o cliente selecione outro método de pagamento.

2.9 Relações de Include e Extend

include

Use include quando um caso de uso sempre invoca outro comportamento reutilizável.

Exemplo:

• Place Order inclui Calculate Total

• Place Order inclui Authenticate Customer

• Withdraw Cash inclui Verify PIN

O comportamento incluído é obrigatório.

Place Order <<include>> Calculate Total

extend

Use extend quando um comportamento opcional ou condicional complementa um caso de uso base.

Exemplo:

• Place Order pode ser estendido por Apply Discount Code

• Checkout pode ser estendido por Add Gift Message

O comportamento de extensão nem sempre é executado.

Apply Discount Code <<extend>> Place Order

Uma regra útil:

• Include: “Isso sempre ocorre como parte do caso de uso.”

• Extend: “Isso pode acontecer sob certas condições.”

Não use include e estender simplesmente para dividir cada fluxo em pequenas partes. Uma decomposição excessiva torna o modelo difícil de entender.

2.10 Generalização

A generalização representa herança entre atores ou casos de uso.

Exemplo:

• Funcionário é um ator geral.

• Gerente é um ator especializado que herda o comportamento do Funcionário.

Gerente --|> Funcionário

Use generalização quando o elemento especializado for genuinamente um tipo do elemento generalizado, e não apenas porque dois elementos compartilham alguns passos.

3. Modelo Padrão de Descrição de Caso de Uso

O modelo a seguir funciona bem para documentos de requisitos, especificações de projeto e modelos de análise.

ID do Caso de Uso:
Nome do Caso de Uso:
Objetivo:
Escopo:
Nível:
Ator Primário:
Atores de Suporte:
Partes Interessadas e Interesses:

Gatilho:

Pré-condições:

Garantias Mínimas:

Garantias de Sucesso:

Cenário Principal de Sucesso:
1.
2.
3.

Fluxos Alternativos:
A1.
A2.

Fluxos de Exceção:
E1.
E2.

Requisitos Especiais:
- Desempenho
- Segurança
- Usabilidade
- Disponibilidade
- Conformidade

Regras de Negócio:

Requisitos de Dados:

Frequência e Volume:

Pressupostos:

Questões em Aberto:

Casos de Uso Relacionados:

Explicação dos campos

4. Exemplo: Realizar Pedido

UC-001 — Realizar Pedido

Objetivo:
Permitir que um cliente compre um ou mais produtos.

Escopo:
Loja Online

Nível:
Objetivo do usuário

Ator principal:
Cliente

Atores de suporte:

• Gateway de Pagamento

• Serviço de Inventário

• Serviço de E-mail

• Serviço de Entrega

Partes interessadas e interesses:

• Cliente: Deseja comprar produtos com sucesso e receber confirmação.

• Loja: Deseja registrar um pedido válido e receber o pagamento.

• Armazém: Precisa de informações precisas de atendimento.

• Gateway de Pagamento: Precisa de uma solicitação de pagamento válida.

• Serviço de Entrega: Precisa de um endereço de entrega completo.

Gatilho:
O cliente submete o carrinho de compras para finalização da compra.

Pré-condições:

• O cliente tem pelo menos um item no carrinho.

• Os produtos estão disponíveis para compra.

• O cliente fornece um endereço de entrega válido.

• O sistema pode se comunicar com o serviço de pagamento.

Garantias mínimas:

• Nenhum pedido não pago é tratado como confirmado.

• O cliente é informado se o pedido não puder ser concluído.

• O inventário reservado é liberado se o pagamento falhar.

Garantias de sucesso:

• O pagamento é autorizado.

• O pedido é registrado.

• O estoque é reservado.

• O cliente recebe a confirmação.

• As informações de atendimento são disponibilizadas ao armazém.

Cenário principal de sucesso

1. O cliente revisa o carrinho de compras.

2. O sistema exibe os produtos, quantidades, preços, impostos, custo de frete e total.

3. O cliente fornece as informações de entrega.

4. O sistema valida as informações de entrega.

5. O cliente seleciona um método de pagamento.

6. O cliente envia o pedido.

7. O sistema verifica a disponibilidade dos produtos.

8. O sistema solicita a autorização de pagamento ao Gateway de Pagamento.

9. O Gateway de Pagamento autoriza o pagamento.

10. O sistema cria o pedido.

11. O sistema reserva os produtos solicitados.

12. O sistema envia uma confirmação de pedido ao cliente.

13. O sistema exibe o número do pedido e a data estimada de entrega.

Fluxos alternativos

A1. O cliente usa um endereço salvo

No Passo 3, o cliente seleciona um endereço previamente salvo. O sistema exibe o endereço e continua no Passo 4.

A2. O cliente usa um método de pagamento salvo

No Passo 5, o cliente seleciona um método de pagamento salvo. O sistema utiliza esse método e continua no Passo 6.

A3. O cliente escolhe a retirada na loja

No Passo 3, o cliente seleciona a retirada na loja em vez da entrega. O sistema exibe as lojas disponíveis e as datas de retirada, em seguida continua no Passo 5.

Fluxos de exceção

E1. Produto indisponível

No Passo 7, o sistema determina que um produto está indisponível. O sistema identifica o produto indisponível, atualiza o carrinho e solicita ao cliente que revise o pedido.

E2. Pagamento recusado

No Passo 9, a Gateway de Pagamento recusa o pagamento. O sistema não confirma o pedido, libera as reservas de estoque, exibe a mensagem de falha e permite que o cliente selecione outro método de pagamento.

E3. Gateway de Pagamento indisponível

No Passo 8, o Gateway de Pagamento não responde dentro do tempo limite configurado. O sistema marca a tentativa de pagamento como pendente, informa o cliente e impede o envio duplicado do pedido.

Regras de negócio

• Um pedido deve conter pelo menos um produto.

• A quantidade do produto deve ser maior que zero.

• Um produto não pode ser pedido quando o estoque disponível for insuficiente.

• O pagamento deve ser autorizado antes que o pedido seja confirmado.

• Preços e impostos são calculados usando as regras de precificação vigentes.

• Um cliente pode cancelar um pedido apenas antes do início da execução.

Requisitos especiais

• O resumo do pedido deve ser exibido em até dois segundos sob carga normal.

• As informações de pagamento não devem ser armazenadas em texto puro.

• Envios duplicados não devem criar pedidos duplicados.

• O sistema deve registrar um rastro de auditoria para alterações de status de pagamento e de pedido.

5. Níveis de Casos de Uso

As descrições dos casos de uso podem ser escritas em diferentes níveis de detalhe.

Caso de uso de nível de resumo

Um caso de uso de resumo descreve um processo de negócio amplo.

Exemplo:

Atender Pedido do Cliente

Isso pode incluir:

• Receber pedido

• Selecionar produtos

• Embalagem do pedido

• Despachar pedido

Caso de uso de nível de objetivo do usuário

Este é geralmente o nível mais útil para análise de requisitos.

Exemplo:

Registrar Pedido

Descreve um objetivo que um ator principal pode alcançar em uma única sessão.

Caso de uso de nível de subfunção

Isso descreve um comportamento de sistema menor e reutilizável.

Exemplos:

• Calcular o Total do Pedido

• Validar Pagamento

• Gerar Fatura

Casos de uso de nível de subfunção são úteis quando o comportamento é reutilizado ou tecnicamente complexo, mas não devem substituir os casos de uso de objetivo do usuário.

6. Escrevendo Descrições de Casos de Uso de Alta Qualidade

Use linguagem centrada no ator

Escreva da perspectiva do ator:

O cliente submete um pedido.

Evite terminologia centrada na implementação:

O OrderController invoca o serviço de pedidos.

O último pertence à documentação de design, não a um caso de uso de negócios.

Mantenha cada passo atômico

Evite combinar muitas ações:

O cliente insere os detalhes, seleciona o pagamento, confirma o pedido e recebe um e-mail.

Melhore separando a interação:

1. O cliente insere as informações de entrega.

2. O sistema valida as informações.

3. O cliente seleciona um método de pagamento.

4. O cliente confirma o pedido.

5. O sistema envia uma confirmação.

Descreva comportamento observável

Um leitor deve ser capaz de determinar se o requisito foi implementado.

Fraco:

O sistema processa a solicitação.

Mais forte:

O sistema valida a solicitação, registra a reivindicação, atribui a ela um número de reivindicação e exibe o status de submissão.

Evite o design de interface do usuário prematuro

Use:

O cliente fornece as informações de entrega.

Em vez de:

O cliente insere o endereço na caixa de texto e clica no botão verde Continuar.

A segunda versão restringe desnecessariamente a interface.

Mantenha o fluxo principal bem-sucedido

Não preencha o fluxo básico com todos os erros possíveis. Coloque os erros em fluxos de exceção.

Identifique as regras de negócio separadamente

Regras de negócio frequentemente se aplicam a múltiplos casos de uso. Mantê-las separadas evita texto repetido e inconsistente.

Torne o comportamento de falha explícito

Para cada falha importante, especifique:

• Se os dados são salvos

• Se uma transação é revertida

• Se o ator pode tentar novamente

• Se um administrador é notificado

• Se o caso de uso termina ou retoma

7. De Requisitos para Casos de Uso

Um fluxo de trabalho prático é:

1. Identifique o sistema que está sendo modelado.

2. Liste os atores externos.

3. Pergunte o que cada ator deseja realizar.

4. Converta cada objetivo em um nome de caso de uso.

5. Defina o limite do sistema.

6. Escreva o cenário principal de sucesso.

7. Adicione fluxos alternativos e de exceção.

8. Adicione regras de negócio e requisitos especiais.

9. Desenhe o diagrama de casos de uso.

10. Revise o modelo com as partes interessadas.

11. Relacione casos de uso a requisitos, testes e artefatos de design.

Análise ator-meta

Uma pergunta útil é:

Qual resultado de negócio este ator precisa do sistema?

8. Notação de Diagrama de Casos de Uso

Os elementos mais comuns são:

• Ator:Papel externo

• Caso de uso: Capacidade do sistema ou objetivo do ator

• Limite do sistema: Escopo do sistema

• Associação: O ator participa de um caso de uso

• Incluir: Comportamento reutilizável obrigatório

• Estender: Comportamento opcional ou condicional

• Generalização: Ator ou caso de uso especializado

Um diagrama de casos de uso não deve tentar mostrar:

• Cada etapa do fluxo de trabalho

• Tabelas de banco de dados

• Atributos de classe

• Regras de negócio detalhadas

• Layouts de tela

• Algoritmos internos

Esses elementos pertencem a diagramas de atividade, diagramas de classe, diagramas de sequência ou requisitos escritos.

9. Exemplo de Diagrama PlantUML

O exemplo a seguir modela o Registrar Pedido caso de uso e comportamento relacionado.

@startuml
direção da esquerda para a direita

skinparam packageStyle retângulo
skinparam sombreamento false
skinparam usecase {
    BackgroundColor #F8FBFF
    BorderColor #2F5597
    ArrowColor #555555
}

ator Cliente
ator "Gateway de Pagamento" as Pagamento
ator "Serviço de Estoque" as Estoque
ator "Serviço de E-mail" as Email
ator "Serviço de Entrega" as Entrega

retângulo "Loja Online" {
    usecase "Navegar Produtos" as Navegar
    usecase "Gerenciar Carrinho" as Carrinho
    usecase "Registrar Pedido" as RegistrarPedido
    usecase "Calcular Total do Pedido" as CalcularTotal
    usecase "Verificar Disponibilidade do Produto" as VerificarEstoque
    usecase "Autorizar Pagamento" as AutorizarPagamento
    usecase "Reservar Estoque" as ReservarEstoque
    usecase "Enviar Confirmação do Pedido" as EnviarConfirmacao
    usecase "Rastrear Pedido" as RastrearPedido
    usecase "Aplicar Código de Desconto" as AplicarDesconto
}

Cliente --> Navegar
Cliente --> Carrinho
Cliente --> RegistrarPedido
Cliente --> RastrearPedido

Pagamento --> AutorizarPagamento
Estoque --> VerificarEstoque
Estoque --> ReservarEstoque
Email --> EnviarConfirmacao
Entrega --> RastrearPedido

RegistrarPedido ..> CalcularTotal : <<include>>
RegistrarPedido ..> VerificarEstoque : <<include>>
RegistrarPedido ..> AutorizarPagamento : <<include>>
RegistrarPedido ..> ReservarEstoque : <<include>>
RegistrarPedido ..> EnviarConfirmacao : <<include>>

AplicarDesconto ..> RegistrarPedido : <<extend>>

@enduml

Interpretação

• O Cliente inicia Finalizar Pedido.

• Finalizar Pedido sempre inclui cálculo, verificação de estoque, autorização de pagamento, reserva de inventário e confirmação.

• Aplicar Código de Desconto é opcional, portanto estende Finalizar Pedido.

• Serviços externos participam de comportamentos específicos do sistema.

• O limite do sistema é o Loja Online retângulo.

A posição exata dos elementos é controlada pelo mecanismo de renderização. As decisões de modelagem importantes são os atores, casos de uso, limites e relacionamentos.

10. Criando o Diagrama no Visual Paradigm VPasCode

VPasCode é uma plataforma baseada em navegador para texto-para-diagrama que suporta PlantUML, Mermaid, Graphviz e outros formatos de diagrama. Oferece edição de código-fonte e renderização em tempo real, permitindo que o diagrama seja atualizado conforme o código muda.

Fluxo de trabalho básico

1. Abra o editor VPasCode.

2. Crie um novo diagrama PlantUML.

3. Cole a fonte PlantUML.

4. Confirme que o editor reconhece a sintaxe PlantUML.

5. Revise a visualização em tempo real.

6. Edite atores, casos de uso, relacionamentos e estilos no painel de código-fonte.

7. Exporte ou copie o diagrama renderizado.

8. Adicione o diagrama à documentação do projeto.

VPasCode suporta diagramas de casos de uso PlantUML e oferece renderização em tempo real no navegador. Também fornece exemplos e opções de estilo para diagramas PlantUML.

Exemplo de prompt para geração assistida por IA

Se estiver usando um recurso de geração de diagramas por IA, um prompt útil é:

Crie um diagrama de casos de uso PlantUML para uma loja online.

Ator principal:
- Cliente

Atores de suporte:
- Gateway de Pagamento
- Serviço de Inventário
- Serviço de E-mail
- Serviço de Entrega

Principais casos de uso:
- Navegar pelos Produtos
- Gerenciar Carrinho
- Finalizar Pedido
- Rastrear Pedido

Finalizar Pedido deve incluir:
- Calcular Total do Pedido
- Verificar Disponibilidade do Produto
- Autorizar Pagamento
- Reservar Inventário
- Enviar Confirmação do Pedido

Aplicar Código de Desconto deve estender Finalizar Pedido.

Use um limite de sistema chamado Loja Online.

Trate o código gerado como um ponto de partida. Revise se:

• Os atores são genuinamente externos

• Os casos de uso representam os objetivos do usuário

• inclui e estende são usados corretamente

• A fronteira do sistema está correta

• As relações refletem o comportamento real do negócio

O VPasCode também suporta a alternância entre a edição de diagramas baseada em texto e as ferramentas de modelagem gráfica do Visual Paradigm, o que pode ser útil quando as equipes desejam edição baseada em fonte para versionamento e edição visual para refinamento de layout.

11. Manutenção de Diagramas de Casos de Uso PlantUML

Use apelidos significativos

Os apelidos facilitam a manutenção das relações:

usecase "Place Order" as PlaceOrder
Customer --> PlaceOrder

Adicione comentários

' Transação principal do cliente
usecase "Place Order" as PlaceOrder

Os comentários ajudam outros membros da equipe a entender a fonte e manter o diagrama.

Mantenha o diagrama focado

Se um diagrama contém muitos casos de uso:

• Crie um diagrama de contexto

• Crie diagramas separados por área de negócio

• Use agrupamentos de pacotes

• Conecte diagramas relacionados por meio da documentação

• Evite mostrar todas as subfunções no nível mais alto

Use nomenclatura consistente

Escolha uma convenção e aplique-a consistentemente:

• Registrar Pedido

• Cancelar Pedido

• Rastrear Pedido

Evite misturar estilos como:

• Registrar Pedido

• CancelamentoDePedido

• funcao_rastreamento

Armazene a fonte junto com o projeto

Uma estrutura típica de repositório pode ser:

docs/
  use-cases/
    UC-001-registrar-pedido.md
    UC-002-rastrear-pedido.md
  diagrams/
    use-cases-loja-online.puml

Manter o .puml fonte sob controle de versão torna as alterações revisáveis e reproduzíveis.

12. Rastreabilidade

Um processo maduro de requisitos conecta casos de uso a outros artefatos do projeto.

A Rastreabilidade ajuda a responder:

• Quais requisitos estão cobertos?

• Quais casos de uso não foram testados?

• Quais componentes de design suportam um objetivo de negócio?

• O que é afetado se um requisito mudar?

13. Erros Comuns

Modelar componentes internos como atores

Um banco de dados ou serviço interno geralmente não é um ator se estiver dentro dos limites do sistema.

Um ator deve ser externo ao sistema que está sendo modelado.

Tratar telas como casos de uso

Uma tela é um elemento de interface do usuário, não necessariamente um objetivo do usuário.

Use:

Enviar Reembolso de Despesas

Em vez de:

Tela de Reembolso de Despesas

Usar inclua para cada etapa compartilhada

Apenas a redação compartilhada não justifica um caso de uso incluído. Use inclua quando o comportamento é obrigatório e tem significado independente.

Usar estenda para etapas normais

Se um comportamento sempre ocorre, ele não deve ser modelado como uma extensão.

Escrever detalhes de implementação

Evite referências a:

• Controladores

• Tabelas de banco de dados

• Pontos de extremidade da API

• Classes

• Métodos internos

a menos que o documento seja especificamente um projeto técnico.

Omitir comportamento de falha

Um caso de uso está incompleto se explicar apenas o sucesso. Rejeição de pagamento, dados inválidos, expiração de tempo, falhas de autorização e recursos indisponíveis devem ser abordados.

Tornar os casos de uso muito amplos

“Gerenciar todo o negócio” não é acionável. Divida objetivos amplos em casos de uso no nível de objetivo do usuário.

Tornar os casos de uso muito pequenos

“Validar campo” e “Exibir mensagem” são geralmente etapas do sistema, não objetivos independentes do ator.

14. Lista de verificação de revisão

Antes de aprovar uma descrição de caso de uso, verifique:

Escopo e atores

• O limite do sistema está claro?

• Todos os atores externos foram identificados?

• Os atores são papéis e não nomes individuais?

• Os sistemas de suporte são modelados apenas quando são externos?

Qualidade do objetivo

• O caso de uso fornece valor ao ator principal?

• O nome é uma frase clara de verbo–substantivo?

• O caso de uso está em um nível apropriado?

Qualidade do fluxo

• O cenário principal descreve um resultado bem-sucedido?

• Cada etapa é atômica e observável?

• Os caminhos alternativos estão documentados?

• Os caminhos de exceção estão documentados?

• O comportamento de recuperação está claro?

Condições e resultados

• As pré-condições são testáveis?

• As garantias de sucesso são explícitas?

• As garantias mínimas estão definidas?

• As regras de negócio estão separadas das etapas procedimentais?

Qualidade do diagrama

• Todos os casos de uso estão dentro do limite correto?

• As associações dos atores são significativas?

• As incluem relações são obrigatórias?

• As estendem relações são opcionais ou condicionais?

• O diagrama é legível sem detalhes excessivos?

Qualidade dos requisitos

• Cada etapa importante pode ser testada?

• Os requisitos não funcionais estão incluídos?

• As questões não resolvidas foram registradas?

• O caso de uso está vinculado aos requisitos e aos casos de teste?

15. Estrutura Recomendada para Entregáveis

Para um pacote de projeto completo, utilize a seguinte estrutura:

1. Contexto do sistema
2. Catálogo de atores
3. Diagrama de casos de uso
4. Catálogo de casos de uso
5. Descrições detalhadas dos casos de uso
6. Regras de negócio
7. Requisitos não funcionais
8. Matriz de rastreabilidade
9. Questões em aberto e suposições
10. Arquivos fonte PlantUML

Uma descrição robusta de caso de uso é precisa o suficiente para analistas, compreensível para as partes interessadas e testável por uma equipe de garantia de qualidade. O melhor fluxo de trabalho é usar a descrição escrita para estabelecer o comportamento, o diagrama de casos de uso para comunicar o escopo e as relações, e o PlantUML no VPasCode para manter o modelo visual fácil de editar e manter.

Referência

This post is also available in Deutsch, English, Español, فارسی, Français, English, Bahasa Indonesia, Polski and Ру́сский.