<Nome do Projeto>

Especificação de Caso de Uso: <Nome do Caso de Uso>

 

Versão <1.0>

 

[Nota: O gabarito a seguir é fornecido para utilização com o Rational Unified Process. O texto em azul exibido entre colchetes e em itálico (style=InfoBlue) foi incluído para orientar o autor e deve ser excluído antes da publicação do documento. Um parágrafo digitado após esse estilo será automaticamente definido como normal (style=Body Text).]

 

 

 


Histórico da Revisão

Data

Versão

Descrição

Autor

<dd/mmm/yy>

<x.x>

<details>

<name>

 

 

 

 

 

 

 

 

 

 

 

 

 


Índice

1.          Nome do Caso de Uso 

1.1      Breve Descrição     

2.          Fluxo de Eventos

2.1      Fluxo Básico     

2.2      Fluxos Alternativos     

2.2.1       < Primeiro Fluxo Alternativo >      

2.2.2       < Segundo Fluxo Alternativo >      

3.          Requisitos Especiais

3.1      < Primeiro Requisito Especial >     

4.          Condições Prévias    

4.1      < Condição Prévia Um >     

5.          Condições Posteriores    

5.1      < Condição Posterior Um >     

6.          Pontos de Extensão

6.1      <Nome do Ponto de Extensão>     


Especificação de Caso de Uso: <Nome do Caso de Uso>

1.                  Nome do Caso de Uso

[O gabarito a seguir é fornecido para uma Especificação de Caso de Uso, que contém as propriedades textuais do caso de uso.   Este documento é utilizado com uma ferramenta de gerenciamento de requisitos, como o Rational RequisitePro, para especificar e marcar os requisitos dentro das propriedades do caso de uso.

Os diagramas de caso de uso podem ser desenvolvidos em uma ferramenta de modelagem visual, como o Rational Rose.   Um relatório de caso de uso (com todas as propriedades) pode ser gerado com o Rational SoDA. Para obter informações adicionais, consulte os mentores de ferramenta no Rational Unified Process.]

1.1               Breve Descrição

[A descrição comunica brevemente o objetivo do caso de uso. Um único parágrafo será suficiente para esta descrição.]

2.                  Fluxo de Eventos

2.1               Fluxo Básico

[Este caso de uso é iniciado quando o agente faz alguma coisa. Um agente sempre inicia casos de uso.   O caso de uso descreve o que o agente faz e o que o sistema faz em resposta.  Ele precisa ser expresso na forma de um diálogo entre o agente e o sistema.

O caso de uso descreve o que acontece dentro do sistema, mas não como ou por que. Se informações forem trocadas, seja específico sobre o que é transmitido de um lado para outro. Por exemplo, não é muito ilustrativo dizer que o agente digita informações do cliente. É melhor dizer que o agente digita o nome e o endereço do cliente.  Um Glossário de Termos normalmente é útil para manter a complexidade do caso de uso gerenciável. Talvez seja necessário definir coisas como informações do cliente lá para evitar que o caso de uso seja suprimido nos detalhes.

Alternativas simples podem ser apresentadas no texto do caso de uso. Se forem necessárias apenas algumas sentenças para descrever o que acontece quando há uma alternativa, faça-o diretamente na seção Fluxo de Eventos.  Se o fluxo alternativo for mais complexo, utilize uma seção separada para descrevê-lo. Por exemplo, uma subseção Fluxo Alternativo explica como descrever alternativas mais complexas.

Algumas vezes, uma figura vale mais que mil palavras, embora não haja substituto para uma conversa limpa e clara.  Se isso melhorar a clareza, sinta-se livre para colar representações gráficas de interfaces do usuário, fluxos de processo ou outras figuras no caso de uso. Se um fluxograma for útil para apresentar um processo de decisão complexo, utilize-o sem dúvida!  Assim como para o comportamento dependente de estado, um diagrama de transição de estados normalmente esclarece melhor o comportamento de um sistema do que páginas e páginas de texto. Utilize o meio de apresentação correto para seu problema, mas seja prudente ao utilizar terminologia, anotações ou figuras que seu público possa não entender. Lembre-se de que o objetivo é esclarecer, não ocultar.]

2.2               Fluxos Alternativos

2.2.1          < Primeiro Fluxo Alternativo >

[Alternativas mais complexas são descritas em uma seção separada, referida na subseção Fluxo Básico da seção Fluxo de Eventos.  Pense nas subseções de Fluxo Alternativo como comportamentos alternativos - cada fluxo alternativo representa um comportamento alternativo normalmente devido a exceções que ocorrem no fluxo principal.  Eles podem ser necessários para descrever os eventos associados ao comportamento alternativo.  Quando um fluxo alternativo termina, os eventos do fluxo principal de eventos são retomados.]

2.2.1.1     < Um Subfluxo Alternativo >

[Os fluxos alternativos podem, por sua vez, ser divididos em subseções se isso aprimorar a clareza.]

2.2.2          < Segundo Fluxo Alternativo >

[Pode haver, e muito provavelmente haverá, vários fluxos alternativos em um caso de uso. Mantenha cada fluxo alternativo separado para melhorar a clareza. A utilização de fluxos alternativos melhora a legibilidade do caso de uso. Os fluxos alternativos também impedem que os casos de uso sejam decompostos em hierarquias de casos de uso. Tenha em mente que casos de uso são apenas descrições textuais e seu objetivo principal é documentar o comportamento de um sistema de uma maneira clara, concisa e compreensível.]

3.                  Requisitos Especiais

[Um requisito especial é, geralmente, um requisito não-funcional que é específico de um caso de uso, mas não é fácil ou naturalmente especificado no texto do fluxo de eventos do caso de uso. Exemplos de requisitos especiais incluem requisitos legais e reguladores, padrões de aplicativos e atributos de qualidade do sistema a ser construído incluindo requisitos de utilidade, confiabilidade, desempenho ou suportabilidade. Adicionalmente, outros requisitos - como sistemas e ambientes operacionais, requisitos de compatibilidade e restrições de design - devem ser capturados nesta seção.]

3.1               < Primeiro Requisito Especial >

 

4.                  Condições Prévias

[Uma condição prévia de um caso de uso é o estado do sistema que deve estar presente antes de um caso de uso ser executado.]

4.1               < Condição Prévia Um >

 

5.                  Condições Posteriores

[Uma pós-condição de um caso de uso é uma lista de estados possíveis que o sistema pode estar imediatamente após um caso de uso ter sido concluído.]

5.1               < Condição Posterior Um >

 

6.                  Pontos de Extensão

[Pontos de extensão do caso de uso.]

6.1               <Nome do Ponto de Extensão>

[Definição do local do ponto de extensão no fluxo de eventos.]