Área do Caso de Uso[editar | editar código-fonte]

Cada caso de uso foca-se numa característica do sistema. Para a maioria dos projetos de
software isto significa que múltiplos, talvez dezenas, de casos de uso são necessários
para especificar completamente um novo sistema.
O grau de conformidade de um projeto de software em particular pode influenciar o nível
de detalhe requerido em cada caso de uso. É geralmente aceite que cada caso de uso
seja curto o suficiente para ser implementado por um desenvolvedor de software
num lançamento.
A engenharia de requisitos consiste num processo onde são identificados todos os
diferentes requisitos que um sistema de software deverá satisfazer quando se encontrar
funcional. Este processo recorre a diferentes técnicas, algumas delas complementares
entre si. O objectivo final é obter todos os requisitos idealizados para o sistema,
possivelmente classificados por ordem de importância, descritos o mais claramente
possível e devidamente validados pelos interessados ou stakeholders do sistema.
A clareza com que os requisitos são descritos e a sua abrangência que é idealizada
pelos stakeholders é a máxima prioridade do processo tendo em vista não só a
necessidade de transição do conhecimento dos requisitos do sistema tanto para os
programadores que o irão implementar quanto para os utilizadores que dele farão uso,
mas também para garantir que todo o conteúdo pretendido esteja identificado antes do
processo de implementação começar, de modo a facilitar a arquitetura e planejamento de
implementação da solução, evitando retrabalho.
Entre as várias técnicas auxiliares à tarefa de levantamento de requisitos, as mais
reconhecidas e aconselhadas são:

 Identificação de stakeholders: Determinação clara de quem irá usar o sistema e de

quem o projetou, discernindo quais os objectivos iniciais por detrás da ideia, de modo
a poder entender o que esperam que o sistema cumpra.
 Entrevistas com stakeholders do sistema: Consiste em efetuar entrevistas com os
utilizadores e visionários do sistema tentando obter uma ideia das várias necessidades
que o sistema deve satisfazer.
 Workshops de requisitos: Sessões de grupo com os utilizadores e visionários do
sistema promovendo o debate e discussão de ideias sobre o sistema a desenvolver.
 Listagem contratual de requisitos: Consiste em elaborar uma listagem contendo todas
as necessidades que o sistema deverá satisfazer.
 Prototipagem: Criação, apresentação e debate de modelos de interacção não
funcionais que ajudem a ilustrar como o sistema deverá se comportar, permitindo
assim obter feedback mais detalhado dos stakeholders sobre o sistema.
 Diagrama de Caso de Uso: Descreve a funcionalidade proposta para o novo sistema.
 Expansão de Diagrama de Casos de uso: Consiste na explicitação de todas as
diferentes funcionalidades do sistema, que permitirá inferir e identificar mais
claramente outras necessidades.
Diagramas de casos de uso[editar | editar código-fonte]
Ver artigo principal: Diagrama de caso de uso
Muitas pessoas introduziram os casos de uso via UML, que define uma notação gráfica
para representar os casos de uso. O UML não define padrões para o formato escrito
objetivando descrever casos de uso, e assim muitas pessoas compreendem erroneamente
que a notação gráfica define a natureza do caso de uso; contudo a notação gráfica pode
dar a visão geral mais simples de um caso de uso ou de um conjunto destes casos.
O diagrama de casos de uso fornece um modo de descrever a visão externa do sistema e
suas interações com o mundo exterior, representando uma visão de alto nível da
funcionalidade.

Seções habituais nos Casos de Uso[editar | editar código-fonte]

Há alguns cuidados a ter para ter a certeza que um caso de uso está correctamente
compreendido. Habitualmente é adoptado um standard que requer o preenchimento de
alguns campos relativos ao caso de uso de modo a facilitar o trabalho em grupo e a
clareza do relacionamento entre vários casos de uso, e do caso de uso em relação aos
actores e ao próprio sistema.
Algumas das secções habitualmente utilizadas incluem:

 Nome: Identificador inequívoco do caso de uso, deve ser escrito em formato

de verbo/substantivo e ser suficiente para o utilizador perceber a que se refere o caso
de uso.
 Iteração ou estado de desenvolvimento: Descrição do estado actual do caso de uso à
medida que este vai evoluindo.
 Sumário: Curto resumo do caso de uso.
 Pré-condições: Listagem das condições que se devem verificar quando o utilizador
inicia este caso de uso. Não incluem triggers.
 Triggers: Eventos que ocorrem dando início ao caso de uso. Podem ser externos,
temporais ou internos.
 Linha de Eventos: Esta secção descreve o curso de eventos ou cenário que se realiza.
Usualmente é descrito através de uma sequência de eventos numerados.
 Percursos Alternativos: Descrição de percursos alternativos à linha de eventos básica.
 Pós-condições: Descrição do estado do sistema após a execução do caso de uso
 Regras de negócio: Secção reservada para informação adicional relativa à política da
empresa ou restrições impostas pelo tipo de negócio.
 Notas: Informação adicional relativamente ao caso de uso, não coberta pelas secções
anteriores.
 Autor e data: Listagem dos autores e datas das várias versões revistas.

Benefícios e Vantagens do Caso de Uso[editar | editar código-

fonte]
A utilização de casos de uso é uma técnica relativamente recente, mais flexível, apoiada
num formato novo e mais ágil para capturar requisitos de software que contrasta com a
documentação extensiva e "monolítica" que tenta, mas falha em registrar todos os
requisitos possíveis de um sistema antes deste começar a ser construído.
Os casos de uso podem ser facilmente adicionados e removidos do projeto de software
assim que as prioridades mudam. Os casos de uso podem também servir como base para
estimar, escalonar e validar esforços. Uma razão porque os casos de uso se tornaram
populares é que são fáceis de entender por pessoas da área de negócio, e assim
provaram ser uma excelente ponte entre quem desenvolve o software e os usuários finais.
Entre as vantagens da utilização no processo de engenharia de requisitos incluem-se:

 A modelagem de um caso de uso (incluindo a sua especificação) é geralmente aceita

como uma excelente técnica para a captura dos requisitos funcionais de um sistema.
 Desencorajam o design prematuro.
 Podem ser usados a base para o esforço de estimação, planeamento e validação.
 São reutilizáveis dentro de um projecto. O caso de uso pode evoluir com cada
interação, desde um método de levantamento de requisitos, para linhas gerais de
desenvolvimento aos programadores, de um caso de teste, até a documentação.
 Caminhos alternativos de um caso de uso registram comportamentos adicionais que
podem melhorar a robustez do sistema.
 São úteis para sondar o verdadeiro âmbito do sistema. Podem ser facilmente
adicionados ou removidos consoante a mudança de prioridades no desenvolvimento
do projecto do sistema.
 São facilmente entendidos por todos os tipos de utilizadores, criando uma ponte entre
os que desenvolvem o software e os stakeholders do sistema.
 As especificações de um caso de uso não requerem a utilização de uma
dada linguagem, podem ser escritas nos mais diversos estilos para encaixar com as
necessidades do projecto.
 Permite descrever um requisito como se contasse uma história. Torna-se mais fácil
descrever requisitos sob a forma de uma história ou cenário.
 Estão ligados directamente com a interação do sistema, isto permite aos designers da
interface um maior envolvimento no processo de desenvolvimento do projecto quer
antes ou em paralelo com os programadores de software.
 Colocam os requisitos em contexto, são claramente descritos em relação às tarefas do
negócio.
 Os diagramas de caso de uso ajudam os stakeholders a entender a natureza e escopo
da área de negócio ou sistema em desenvolvimento.
 Diagramas de caso de uso podem ser gravados usando a notação UML e mantidos
usando diferentes ferramentas CASE.
 Casos de uso e diagramas de caso de uso podem ser completamente integrados com
outras deliverables de análise e design criadas usando uma ferramenta CASE para
produzir requisitos, design e repositório de implementação mais completos.

Cenário principal[editar | editar código-fonte]

No mínimo, cada caso de uso deveria ter um "cenário principal", ou o curso típico de
eventos. O cenário principal é normalmente um conjunto de passos, por exemplo:

 O sistema pede para o usuário se identificar.

 O usuário digita o seu nome e palavra-chave.
 O sistema verifica a informação de identificação.
O caso de uso representa uma atividade genérica que define um escopo (limite) de uma
declaração de problema (texto que explica o que o sistema necessita). Exemplo: pagar
faturas.

Cenários alternativos[editar | editar código-fonte]

Os casos de uso podem conter cenários alternativos ou secundários que contêm variações
do tema principal. Exceções, ou o que acontece quando as coisas não correm bem,
podem também ser descritas.

Outras partes de um caso de uso[editar | editar código-fonte]

Há também outros formatos, ou templates para documentos de casos de uso.
Normalmente, os casos de uso têm uma secção de "sumário" que pode ser escrita
preliminarmente durante o projeto de software para capturar a essência do cenário antes
do corpo principal estar completo. Uma secção de "precondições" pode ser usada para
conter as condições iniciais que foram assumidas antes do cenário ter começado.

Conceitos[editar | editar código-fonte]

 Ator: Agente externo (uma pessoa ou um sistema) que interage com o sistema,
dividindo-se em primário que interage diretamente e secundário que somente faz um
serviço.
 Interação: Comunicação dos atores com o sistema.
 Associação entre casos de uso:
 Inclusão (Include): Um caso de uso pode ser aproveitado no contexto de outros
casos de uso. Exemplo: "calcular o DV do CNPJ" é um comportamento que pode
ser utilizado como mecanismo para validar a inclusão de um objeto cliente
("cadastrar cliente"), como pode ser utilizado para validar a inclusão de um
objeto fornecedor ("cadastrar fornecedor"). Compartilhamento de uma ação por
outras ações (reutilização).
 Extensão (Extend): Um caso de uso pode ter seu comportamento requerido por
outro caso de uso (e somente por este outro caso de uso). Dois motivos para a
utilização do Extend: melhorar a estabilidade do modelo (i.e. redução do impacto
de eventuais mudanças de comportamento) e diminuir a complexidade das
operações (i.e. isolar os elementos que apresentem comportamentos mais
complexos). Exemplo: "cadastrar funcionário" requer a chamada de uma operação
para "cadastrar dependente do funcionário". O comportamento de "cadastrar
dependente do funcionário" servirá apenas aos propósitos de "cadastrar
funcionário" (i.e. não será compartilhado com outras ações). Modularização.
Menor acoplamento e maior coesão.