Como criar um documento de Caso de Uso

A documentação de casos de uso é uma técnica amplamente utilizada na engenharia de software para descrever os requisitos funcionais de um sistema. É um documento que descreve como os atores externos interagem com o sistema em questão, detalhando as etapas que ocorrem durante essas interações. Embora haja grandes benefícios em usar um documento de caso de uso, ele também apresenta algumas desvantagens. A seguir estão as vantagens e desvantagens de usar a documentação de casos de uso em projetos de software:

Vantagens:

Compreensão clara dos requisitos: O documento fornece uma visão geral clara das interações entre os atores e o sistema, ajudando a identificar e entender os requisitos funcionais do sistema.

Rastreabilidade de requisitos: Cada caso de uso é uma unidade clara e independente de funcionalidade, o que facilita o rastreamento e a verificação dos requisitos. Isso ajuda a garantir que todos os requisitos sejam atendidos durante o desenvolvimento.

Comunicação efetiva: O documento de caso de uso serve como uma ferramenta de comunicação entre os stakeholders do projeto, permitindo que todos tenham uma compreensão comum dos requisitos e funcionalidades do sistema.

Desvantagens:

Limitações na descrição de requisitos não funcionais: O documento de caso de uso tende a se concentrar principalmente em requisitos funcionais, como interações e fluxos de trabalho, deixando lacunas na descrição de requisitos não funcionais, como desempenho, segurança e usabilidade.

Complexidade em grandes projetos: Em projetos de software complexos, especialmente aqueles com muitos atores e casos de uso, o documento de caso de uso pode se tornar volumoso e difícil de gerenciar. Isso pode resultar em dificuldades de manutenção e atualização.

Resistência à mudança: Uma vez que o documento de caso de uso é criado e aprovado, ele pode se tornar resistente a mudanças. Qualquer alteração nos requisitos pode exigir uma revisão extensiva e demorada.

Estudo de Caso:

Para isso usaremos o seguinte exemplo como estudo de caso para criar o nosso template:

A pizzaria do Sr Genaro é reconhecida pela dedicação ao trabalho artesanal de fazer as pizzas. No entanto, seu negócio tomou grande proporção e não é possível crescer sem um sistema de informação. A pizzaria está dividida nas áreas de “Pedido”, “Produção” e “Entrega”. A área de “Pedido” contempla o atendimento ao cliente para registro da solicitação da pizza. O atendimento ocorre por call center. O atendente registra os dados do cliente, confirma o endereço e registra a solicitação. Ao finalizar a solicitação, o atendente envia para a área de “Produção”. Na “Produção”, a solicitação deve seguir uma fila. O cozinheiro prepara os produtos e separa as bebidas. Ao concluir, o produto é embalado e encaminhado para a “Entrega”. A entrega do produto deve ocorrer no máximo em 40 min após a solicitação do cliente. Ao receber o pagamento, quando retorna a pizzaria, o entregador conclui a solicitação do cliente no sistema(MAPA - ANÁLISE E PROJETO ORIENTADO A OBJETOS - 54/2021 - UNICESUMAR).

Do exemplo acima vamos extrair apenas 2 casos de uso para o nosso documento, que são: Solicitar pedido e Cadastrar cliente.

Quais as características que o documento deve ter?

Cabeçalho:

    1 - O número identificador do caso de uso.
    2 - O nome do caso de uso.
    3 - O nome do ator(s).

Precondição:

Na Precondição se lista as condições que devem ser atendidas para prosseguir com o caso de uso.

Fluxo Básico:

O Fluxo Básico é onde acontece o fluxo normal do nosso sistema, sem erros.

Pós-Condição:

A Pós-Condição exibe os objetivos ou estados que almejamos com o fim do caso de uso.

Fluxo Alternativo:

O Fluxo Alternativo é onde o usuário pode escolher por outra opção que se desvia do fluxo normal(Básico).

Fluxo de Exceção:

O Fluxo de Exceção é onde registramos os erros ou exceções possíveis do sistema.

O documento ficará com essa aparência:

Para o segundo caso de uso, teremos o seguinte resultado:

Baixe o exemplo no link a seguir: Documento

O documento de caso de uso é um excelente aliado no seu projeto de engenharia de software, porém trata-lo como um documento inquestionável e inflexível pode ser que traga mais problemas que soluções. E se tratando de software é um documento que nunca estará "pronto" devido a fase de manutenção do sistema.