<Nome do Projeto>

Especificao de Caso de Uso: <Nome do Caso de Uso> Verso <nmero da verso>

Pgina 5 de 6


<Nome do Projeto>
Especificao de Caso de Uso: <Nome do Caso de
Uso>

Verso <nmero da verso>



Os textos que aparecem em azul e entre colchetes so explicaes para ajudar no preenchimento de
cada seo e devem ser apagados no documento final.



Histrico de Reviso


Data Verso Descrio Autor





[Na coluna Autor, deve-se especificar o nome dos autores e sua equipe, responsveis pelas alteraes.
Na coluna descrio, deve-se especificar exatamente o que foi mudado. No devem ser colocadas informaes
vagas como, por exemplo, "Alteraes realizadas depois da reunio x".]

<Nome do Projeto>

Especificao de Caso de Uso: <Nome do Caso de Uso> Verso <nmero da verso>



Pgina 5 de 6


Sumrio
1. Descrio 4
2. Pr-condies 4
3. Fluxo de Eventos 4
3.1 Fluxo Bsico 4
3.2 Subfluxos 4
3.2.1 (S01) <Nome do Subfluxo> 4
3.3 Fluxos Alternativos 5
3.3.1 (A01) <Nome do Fluxo Alternativo> 5
3.4 Excees 5
3.4.1 (E01) <Nome do Fluxo de Exceo> 5
4. Ps-condies 5
5. Requisitos Especiais 5
5.1 (RE01) - <Nome do Requisito Especial> 5
6. Regras de negcio especficas 6
6.1 (RN01) - <Nome da Regra de Negcio > 6
7. Detalhamento das Interfaces com Usurios 6
7.1 (I01) - <Nome da Interface com Usurio> 6
7.1.1 Imagem 6
7.1.2 Campos 6
7.1.3 Comandos 6
8. Demais Interfaces 7
8.1 Interfaces de Software 7
8.2 Interfaces de Hardware 7
9. Observaes 7



<Nome do Projeto>

Especificao de Caso de Uso: <Nome do Caso de Uso> Verso <nmero da verso>



Pgina 5 de 6


Especificao de Caso de Uso: <Nome do Caso de
Uso>

1. Descrio
[A descrio deve resumir o papel e finalidade do caso de uso. Um nico pargrafo deve bastar para
esta descrio.]

2. Pr-condies
[A pr-condio de um caso de uso o estado que o sistema deve apresentar antes do caso de uso ser
executado.]

3. Fluxo de Eventos
1. Fluxo Bsico
[Este caso de uso comea quando o ator faz algo. Um ator sempre inicia o caso de uso. O caso de uso
deve descrever o que o ator faz e o que o sistema faz como resposta. Deve ter o formato de um dilogo
entre o ator e o sistema.
O caso de uso deve descrever o que acontece dentro do sistema, mas no como ou porque. Se h troca
de informao, seja especfico sobre o que passado para o sistema e vice-versa. Por exemplo, no
muito esclarecedor dizer que o ator digita a informao do cliente; melhor dizer que o ator informa
o nome e o endereo do cliente.
As alternativas simples podem ser apresentadas dentro do texto do caso de uso. Se forem necessrias
somente algumas sentenas para descrever o que acontece quando h uma alternativa, faa-o
diretamente dentro do fluxo dos eventos. Se os fluxos alternativos forem mais complexos, use uma
seo separada para descrev-los.
Uma imagem , s vezes, melhor que mil palavras. Se melhorar a clareza, use vontade grficos de
interface de usurio, fluxo de processo, ou outras figuras no caso de uso. Se um diagrama de fluxo for
til para apresentar um processo de deciso complexo, use-o. Similarmente para um comportamento
dependente de estado, um diagrama de transio de estados freqentemente esclarece o
comportamento do sistema melhor do que pginas e pginas de texto. Use a melhor forma para
representar seu problema, mas cuidado para no usar terminologia, notao ou figura que sua
audincia no possa compreender. Lembre-se que sua finalidade esclarecer, no confundir.]
1.
1.
2.

2. Subfluxos
1. (S01) <Nome do Subfluxo>
[O fluxo bsico pode ser quebrado em subsees, para aumentar a clareza. Os subfluxos descrevem
geralmente detalhes de iteraes ou de condies executadas com maior freqncia. Os subfluxos so
referenciados dentro dos passos do fluxo principal, de outros subfluxos ou de fluxos alternativos.
Quando um subfluxo termina, os eventos do fluxo original so recomeados, ou seja, o fluxo retorna
ao ponto em que estava quando o subfluxo havia sido chamado, a menos que indicado de outra
maneira.]
1.
1.

<Nome do Projeto>

Especificao de Caso de Uso: <Nome do Caso de Uso> Verso <nmero da verso>



Pgina 5 de 6


2.
3.

3. Fluxos Alternativos
1. (A01) <Nome do Fluxo Alternativo>
[Alternativas opcionais executadas com menor freqncia so descritas em uma seo separada como
fluxo alternativo. Os fluxos alternativos no so referenciados dentro de outros fluxos; suas prprias
pr-condies definem quando eles so ativados. Diferente do subfluxo, quando o fluxo alternativo
termina,nem sempre os eventos do fluxo original so retomados no mesmo ponto em que estava
quando o fluxo alternativo havia sido ativado. Sendo assim necessrio indicar o ponto de retomada
do fluxo.
Pode haver, e normalmente haver, um certo nmero de fluxos alternativos em um caso de uso.
Mantenha cada um separado para melhorar a clareza. O uso de fluxos alternativos melhora a
legibilidade do caso de uso e previne que os casos de uso sejam decompostos em hierarquias.]
1. Pr-condies
[Para cada fluxo alternativo preciso levantar as suas pr-condies, ou seja, as condies que se
supem estejam satisfeitas ao iniciar a execuo do fluxo. As pr-condies indicam em que condies
este fluxo alternativo chamado, ou seja, o que preciso acontecer para ele ser chamado.]
2. Passos
1.
2.
3.

4. Excees
1. (E01) <Nome do Fluxo de Exceo>
[Existem fluxos alternativos que representam na verdade situaes de exceo do caso de uso. Nesse
caso, interessante documentar separadamente para identific-las de forma mais clara e rpida.]
1. Pr-condies
[As pr-condies de um fluxo de Exceo o estado do sistema que permitiu identificar a exceo.]
2. Passos
1.
2.
3.

4. Ps-condies
[A ps-condio de um caso uso uma lista de estados possveis que o sistema pode apresentar
imediatamente aps o trmino do caso de uso.]
5. Requisitos Especiais
[O requisito especial tipicamente um requisito no funcional especfico do caso de uso ou que o
influencie. Deve ser descrito aqui quando no puder ser especificado facilmente ou naturalmente no
texto do fluxo de eventos do caso de uso. Os exemplos de requisitos especiais incluem requisitos legais,
padres da aplicao, atributos da qualidade do sistema a ser construdo como usabilidade,
confiabilidade, desempenho.
Requisitos relativos a ambiente e arquitetura como sistemas operacionais, ambientes, exigncias
relativas a compatibilidade, restries de desenho, devem ser tambm descritos.]
1. (RE01) - <Nome do Requisito Especial>

<Nome do Projeto>

Especificao de Caso de Uso: <Nome do Caso de Uso> Verso <nmero da verso>



Pgina 5 de 6




6. Regras de negcio especficas
[Registrar aqui as regras de negcio que so levantadas no detalhamento do caso de uso, evitando
assim registr-las ao longo dos fluxos, visando aumentar a legibilidade e clareza. Alm disso, regras
complexas devem ser subdividas em mais de uma. Toda regra de negcio deve ser referenciada ao
longo dos fluxos do caso de uso.]
1. (RN01) - <Nome da Regra de Negcio >

7. Detalhamento das Interfaces com Usurios
[Inserir nesta seo os esboos das interfaces vinculadas ao caso de uso em questo. O esboo das
interfaces auxilia na validao dos casos de uso com os usurios, pois estes conseguem visualizar
melhor o sistema ao verem algo mais concreto.]
1. (I01) - <Nome da Interface com Usurio>
1. Imagem
[Inserir a imagem do esboo da interface.]
2. Campos
[Preencher a tabela com os campos presentes na interface e sua descrio. Por exemplo:
Nome: Login, Senha, Endereo, etc
Descrio: Descrio completa do endereo do usurio incluindo rua, nmero, cidade,
cep e pais, etc.
Valores Vlidos: Maior que zero,Entre 5 e 10, etc. .
Tipo: Moeda, Inteiro, Texto, Data, etc.
Restries: Valor default 001, Obrigatrio / Altervel; Calculado pelo sistema / No
Altervel, Formato at 50 caracteres, at 5 dgitos, 10 dgitos e duas casas decimais,
DD/MM/AAAA, etc.]
No. Nome Descrio Valores
Vlidos
Tipo Restries
1.
2.
3.
4.

3. Comandos
[Preencher a tabela com os comandos presentes na interface e sua descrio. Por exemplo:
Nome: Ok, Pesquisar, Consultar, Excluir, etc.
Ao: Localiza e exibe os dados de um usurio j cadastrado, Exclui um usurio do
sistema, etc.
Restries: Sempre habilitado, Habilitado se algum registro estiver selecionado, etc.]
No. Nome Ao Restries
1.
2.
3.
4.

8. Demais Interfaces

<Nome do Projeto>

Especificao de Caso de Uso: <Nome do Caso de Uso> Verso <nmero da verso>



Pgina 5 de 6


[Esta seo define as interfaces que devem ser suportadas pela aplicao.]
1. Interfaces de Software
[Descreve interfaces de software para outros componentes de negcio do sistema. Podem ser
componentes comprados, componentes reusados e/ou componentes desenvolvidos para subsistemas
fora do escopo mas, que interagem com o sistema. No incluir aqui interfaces com componentes de
infra-estrutura. Esses devem ser referenciados no Documento de Arquitetura.]
No. Nome Ator Descrio
1.
2.
2. Interfaces de Hardware
[Descreve quaisquer interfaces de hardware que so suportadas pelo software, incluindo estrutura
lgica endereo fsico, comportamento esperado, etc.]
No. Nome Hardware Descrio
1.
2.

9. Observaes
[Seo de preenchimento livre, onde podem ser colocadas informaes importantes no registradas
nas outras sees. Pode-se registrar, por exemplo:
lembretes e informaes que sero necessrias, mas que ainda no esto sendo utilizadas, para
que no sejam perdidas informaes j levantadas,
pessoas ou documentos que serviram de fonte para a especificao do caso de uso,
etc.]