<Nome do Projeto>
Especificação de Caso de Uso: <Nome do Caso de Uso>
Versão <1.0>
[Observação: O template a seguir é fornecido para ser usado no Rational Unified Process. O texto entre colchetes e exibido em itálico, em azul (estilo=InfoBlue), é fornecido para orientar o autor e deverá ser excluído antes da publicação do documento. Qualquer parágrafo inserido após esse estilo será definido automaticamente como normal (estilo=BodyText).]
Histórico da Revisão
|
Data |
Versão |
Descrição |
Autor |
|
<dd/mmm/aa> |
<x.x> |
<detalhes> |
<nome> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Índice Analítico
2.2.1 < Primeiro Fluxo Alternativo >
2.2.2 < Segundo Fluxo Alternativo >
3.1 < Primeiro Requisito Especial >
6.1 <Nome do Ponto de Extensão>
Especificação de Caso de Uso <Nome do Caso de Uso>
[O template a seguir é fornecido para uma Especificação de Caso de Uso, que contém as propriedades de texto do caso de uso. Este documento é usado com uma ferramenta de gerenciamento de requisitos, como o Rational RequisitePro, para especificar e marcar os requisitos contidos nas propriedades do caso de uso.
Os diagramas do 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 mais informações, consulte os mentores de ferramentas do Rational Unified Process.]
[A descrição relata brevemente a finalidade do caso de uso. Para tanto, será suficiente um único parágrafo.]
[Este caso de uso é iniciado quando o ator faz algo. Um ator sempre inicia os casos de uso. O caso de uso descreve o que o ator faz e o que o sistema faz em resposta. Ele deve ser elaborado como um diálogo entre o ator e o sistema.
O caso de uso descreve o que acontece dentro do sistema, mas não o porquê nem como. Se forem trocadas informações, seja específico no que diz respeito ao conteúdo que é passado e retornado. Por exemplo, não é muito esclarecedor dizer que o ator fornece informações do cliente. É melhor dizer que ele fornece o nome e o endereço do cliente. Freqüentemente é útil fazer uso de um Glossário de Termos para manter a complexidade do caso de uso sob controle — poderá ser conveniente definir termos como, por exemplo, informações do cliente nesse glossário, a fim de evitar que o caso de uso fique repleto de detalhes.
As alternativas simples poderão ser apresentadas no texto do caso de uso. Se forem necessárias apenas algumas frases para descrever o que acontece quando há uma alternativa, faça essa descrição diretamente na seção Fluxo de Eventos. Se o fluxo alternativo for mais complexo, use uma seção separada para descrevê-lo. Por exemplo, uma subseção Fluxo Alternativo explica como descrever alternativas mais complexas.
Às vezes, uma figura vale por mil palavras, embora não haja nada que possa substituir uma redação clara e organizada. Se for mais esclarecedor, sinta-se à vontade para colar representações gráficas de interfaces do usuário, fluxos de processo ou outras imagens no caso de uso. Se um fluxograma for útil para apresentar um processo complexo de decisões, utilize-o sem nenhuma dúvida! Semelhantemente no que diz respeito a comportamentos dependentes de estado, um diagrama de transição de estado geralmente esclarece o comportamento de um sistema muito mais do que páginas e páginas de texto. Use o meio de apresentação certo para o problema, mas procure evitar o uso de terminologia, notações ou imagens que o público possa deixar de compreender. Lembre-se de que sua finalidade é esclarecer e não obscurecer.]
[As alternativas mais complexas são descritas em uma seção separada, a que é feita referência na subseção Fluxo Básico da seção Fluxo de Eventos. Pense nas subseções Fluxo Alternativo como comportamentos alternativos — cada fluxo alternativo representa um comportamento alternativo geralmente devido a exceções que ocorrem no fluxo principal. O tamanho desses fluxos poderá ser tão extenso quanto o necessário para descrever os eventos associados ao comportamento alternativo. Quando um fluxo alternativo termina, os eventos do fluxo principal de eventos são retomados a menos que seja especificado de outra maneira.]
[Os subfluxos alternativos, por sua vez, poderão ser divididos em subseções para aprimorar a clareza.]
[Poderá haver, e muito provavelmente haverá, uma série de fluxos alternativos em um caso de uso. Mantenha cada fluxo alternativo separado para aprimorar a clareza. O uso de fluxos alternativos melhora a legibilidade do caso de uso e também evita que os casos de uso sejam decompostos em hierarquias de casos de uso. Lembre-se de que os casos de uso são apenas descrições textuais e que sua finalidade principal é documentar o comportamento de um sistema de maneira clara, concisa e compreensível.]
[Normalmente um requisito especial é um requisito não funcional que é específico de um caso de uso, mas que não é especificado, de maneira fácil ou natural, no texto do fluxo de eventos do caso de uso. Entre os exemplos de requisitos especiais estão incluídos requisitos legais e reguladores, padrões de aplicativo e atributos de qualidade do sistema a ser criado incluindo requisitos de usabilidade, confiabilidade, desempenho ou suportabilidade. Além disso, outros requisitos — como sistemas operacionais e ambientes, requisitos de compatibilidade e restrições de design — deverão ser capturados nesta seção.]
[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 realizado.]
[Uma condição posterior de um caso de uso é uma lista dos possíveis estados em que o sistema poderá se encontrar imediatamente depois do término de um caso de uso.]
[Pontos de extensão do caso de uso.]
[Definição da localização do ponto de extensão no fluxo de eventos.]