Guia de Especificao de Requisitos Funcionais

Verso 6
Este guia operacional tem como objetivo determinar a forma de estruturao dos requisitos funcionais. Visa facilitar a forma de escrita e o entendimento em relao ao modo como especificar os requisitos funcionais Leonardo Siqueira de Arajo 8/9/2008

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

SUMRIO
1. ESTRUTURA DO CASO DE USO ............................................................................................ 7 1.1. Melhores prticas ............................................................................................................... 7 1.2. Nome do caso de uso ........................................................................................................ 7 1.3. Descrio do caso de uso .................................................................................................. 7 1.4. Atores ................................................................................................................................. 7 1.4.1. Dicas para Identificao............................................................................................... 7 1.4.2. Nomenclatura e Descrio de Atores .......................................................................... 8 1.5. Pr-condies .................................................................................................................... 8 1.6. Ps-condio...................................................................................................................... 9 1.7. Cenrio do caso de uso ..................................................................................................... 9 1.8. Utilizao de palavras-chaves............................................................................................ 9 1.9. Fluxo bsico ..................................................................................................................... 11 1.10. Fluxo alternativo ............................................................................................................. 11 1.11. Subnvel dos passos ...................................................................................................... 13 1.12. Estilos dos fluxos bsico e alternativos.......................................................................... 13 1.13. Referncia ao ator .......................................................................................................... 14 1.14. Passos a serem descritos .............................................................................................. 14 1.15. Validao dos campos ................................................................................................... 15 2. RELACIONAMENTOS ENTRE CASOS DE USO .................................................................. 15 2.1. Include (incluso) ............................................................................................................. 15 2.2. Extend (extenso) ............................................................................................................ 16 3. REGRAS DE NEGCIO ......................................................................................................... 18 3.1. Conceito ........................................................................................................................... 18 3.2. Melhores prticas ............................................................................................................. 18 4. MENSAGENS DO SISTEMA .................................................................................................. 19 5. SEPARAO DOS PASSOS DE UM CRUD ......................................................................... 20 6. PRTICAS NO RECOMENDADAS...................................................................................... 20 7. REQUISITOS ESPECIAIS ...................................................................................................... 21 8. REFERNCIAS ....................................................................................................................... 21

Verso 6

Pgina 2/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

Histrico de revises
Data 8/9/2008 18/9/2008 Descrio Criao do documento. Excluso do uso dos fluxos de excees, conforme orientao da analista de processo Renata Sousa. 1/10/2008 Incluso do item 7 pr-condio de fluxo alternativo; Alterao do exemplo do item 8. 4 Leonardo Siqueira de Arajo Verso 1 2 Responsvel Leonardo Siqueira de Arajo Leonardo Siqueira de Arajo

19/9/2008

Leonardo Siqueira de Arajo

Incluso de orientaes de escrita dos fluxos bsicos e alternativos e RN. Incluso dos itens 1, 3, 5 e 7; Incluso de exemplos no item 6; Excluso do item Chamadas aos fluxos alternativos Alterao do item 1.2; Alterao do item 1.3; Alterao do item 1.4; Alterao do item 1.5; Alterao do item 1.6; Alterao do item 1.8; Alterao do item 1.10; Alterao do item 1.13; Alterao do item 1.16; Alterao do item 2.1; Alterao do item 2.2; Incluso do item Requisitos especiais; Incluso do item Prticas no recomendadas.

6/10/2008

Leonardo Siqueira de Arajo

12/11/2008

Leonardo Siqueira de Arajo

14/11/2008

Alterao do termo Descrio da interface do caso de uso para Especificao de Tela no item 6.

Leonardo Siqueira de Arajo

Verso 6

Pgina 3/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

17/11/2008

Incluso dos exemplos em quadros.

Leonardo Siqueira de Arajo

Verso 6

Pgina 4/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

GUIA DE ESPECIFICAO DE CASO DE USO

Este guia tem como objetivo apresentar padres mnimos, conceitos e boas prticas que devem ser seguidas na especificao de requisitos para os sistemas que j se encontram em produo e no possuem documentao adequada e para o desenvolvimento de novos sistemas. Sero considerados os seguintes artefatos: Casos de Uso, Regras de Negcio. No inteno deste guia apresentar solues para todas as situaes que sero vivenciadas durante a especificao de requisitos, o que se pretende garantir uma maior conformidade nas especificaes que so elaboradas por diferentes analistas. A seguir, alguns trechos extrados do RUP v7.0: caso de uso (classe) Descrio de comportamento do sistema em termos de seqncias de aes. Um caso de uso deve produzir um resultado de valor observvel para um agente. Um caso de uso contm todos os fluxos de eventos relacionados produo do "resultado de valor observvel", incluindo fluxos de exceo e alternativos. De uma maneira mais formal, um caso de uso define um conjunto de instncias de caso de uso ou cenrios. (Fonte: Glossrio do RUP v7.0) caso de uso de negcio (classe) Um caso de uso define um conjunto de instncias de casos de uso, no qual cada instncia uma seqncia de aes realizada por um negcio que produz um resultado de valor observvel para um determinado agente de negcios(ator). Uma classe de casos de uso de negcio contm todos os fluxos de trabalho, principais e alternativos, relacionados produo do "resultado observvel do valor". (Fonte: Glossrio do RUP v7.0) Uma Especificao de Caso de Uso pode ter as seguintes propriedades: Nome: O nome do caso de uso; Descries Resumidas: Uma descrio resumida da funo e da finalidade do caso de uso; Fluxo de Eventos: Uma descrio textual do que o sistema faz com o caso de uso (no como os problemas especficos so solucionados pelo sistema). A descrio deve ser compreendida pelo cliente; Requisitos Especiais: Uma descrio textual que coleta todos os requisitos, como requisitos no funcionais, no caso de uso, que no so considerados no modelo de caso de uso, mas que precisam de ateno durante a fase de design ou Desenvolvimento; pr-condies: Uma descrio textual que define uma restrio (alterao no estado inicial) no sistema quando o caso de uso pode ser iniciado; ps-condies: Uma descrio textual que define uma restrio (alterao no estado final) no sistema quando os casos de uso devem ser encerrados;

Verso 6

Pgina 5/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

Pontos de Extenso: Uma lista de locais contidos no fluxo de eventos do caso de uso, nos quais pode ser inserido um comportamento adicional utilizando o relacionamento de extenso; Relacionamentos: Os relacionamentos, como associaes de comunicao, relacionamentos de incluso, generalizao e extenso, nos quais o caso de uso participa; Instncia do caso de uso: A seqncia citada na definio realmente um fluxo de eventos especfico do sistema ou uma instncia. Muitos fluxos de eventos so possveis e muitos podem ser bem parecidos. Para tornar um modelo de casos de uso compreensvel, voc deve agrupar os fluxos de eventos semelhantes em um caso de uso. Identificar e descrever um caso de uso realmente significa identificar e descrever um grupo de fluxos de eventos relacionados; O sistema executa: Isso significa que o sistema fornece o caso de uso. Um agente se comunica com a instncia de casos de uso do sistema; Um resultado observvel de valor: Voc pode colocar um valor em um caso de uso executado com xito. Um caso de uso deve verificar se um agente pode realizar uma tarefa que tem um valor identificvel. Isso muito importante na determinao do nvel correto ou da granularidade de um caso de uso. Nvel correto significa alcanar os casos de uso que no so muito pequenos. Em determinadas circunstncias, voc pode utilizar um caso de uso como uma unidade de planejamento em uma organizao que contm indivduos que so agentes no sistema; Aes: Uma ao um procedimento computacional ou algortmico. Ela disparada quando o agente fornece um sinal ao sistema ou quando o sistema obtm um evento de tempo. Uma ao pode implicar transmisses de sinais para o agente chamado ou outros atores. Uma ao atmica, o que significa que realizada integralmente ou no; Um agente especfico: O agente importante para encontrar o caso de uso correto, especialmente porque ele ajuda voc a evitar casos de uso muito grandes. Como exemplo, considere uma ferramenta de modelagem visual. H realmente dois agentes para esse aplicativo: um desenvolvedor - algum que desenvolve sistemas utilizando a ferramenta como suporte e um administrador do sistema - algum que gerencia a ferramenta. Cada um desses agentes tem suas prprias demandas no sistema e, portanto, precisa do seu prprio conjunto de casos de uso;

Verso 6

Pgina 6/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

1. ESTRUTURA DO CASO DE USO

1.1. Melhores prticas
Formatao A formatao a ser utilizada : fonte arial, tamanho 10 e cor preta. NO UTILIZAR ITLICO E SUBLINHADO. Negrito pode ser usado para destacar informaes e os ttulos.

1.2. Nome do caso de uso

O nome do caso de uso deve ser nico e intuitivo, e deve identificar com clareza o resultado de valor que ele produz para algum ator do sistema. Talvez o nome precise ter vrias palavras para ser entendido. Dois casos de uso no podem ter o mesmo nome. Deve seguir a forma: Verbo Infinitivo + Substantivo ou Sentena. Seguem algumas consideraes para nomear os casos de uso: No usar nomes extensos; No usar nome de atores ou siglas de sistemas externos; No usar plural; Buscar termos que reflitam o objetivo do caso de uso na totalidade; No usar nomenclatura que tenha conjuno e, pois poder retratar dois objetivos distintos em um mesmo caso de uso.

1.3. Descrio do caso de uso

A breve descrio deve consistir de um texto claro o suficiente para permitir o entendimento do objetivo do caso de uso e para refletir a proposta central do caso de uso . A breve descrio pode ser mantida tanto na Especificao de Caso de Uso como no diagrama de caso de uso.

1.4. Atores
1.4.1. Dicas para Identificao Para identificao dos atores deve-se tentar identificar: Quem dever suprir, utilizar ou remover informaes do sistema. Quem dever utilizar cada funcionalidade do sistema. Quem o interessado no requisito definido. Na organizao, onde o sistema ser utilizado. Quem realizar a manuteno do sistema. Quais os recursos externos do sistema. Os sistemas com os quais o produto a ser desenvolvido dever interagir. Os dispositivos de hardware que devero prover alguma informao ao sistema (Ex.: sensores de temperatura, dispositivos criptogrficos, cartes inteligentes.) Pgina 7/21

Verso 6

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

Os dispositivos de hardware que devero obter alguma informao do sistema ( Ex.: dispositivo de abertura/trancamento de portas de segurana) O ator denominado Temporizador dever ser utilizado caso existam casos de uso que representem funcionalidades cuja execuo est condicionada ao fator tempo, como por exemplo, casos de uso referentes ao processamento de informaes em um determinado perodo do dia. Nestes casos, tambm possvel denominar os atores como Gerenciadores, Administradores, ou Iniciadores de tarefa. Os atores devem representar os papis assumidos pelos usurios do sistema, e no os usurios do sistema. Ex.: em um sistema de recolhimento de FGTS, um ator denominado Contribuinte pode ser tanto um escritrio de contabilidade, como uma prefeitura ou uma empresa privada. Se a modelagem fosse de usurios, teramos 3 atores ao invs de um nico ator. No recomendvel a existncia de 2 (dois) atores de um mesmo tipo (humano, hardware, software ou temporizador) iniciando o mesmo caso de uso. Duas instncias de atores do mesmo tipo no devem interagir com a mesma instncia do caso de uso. Nos casos em que haja esta situao, deve-se aplicar generalizao para representar dois ou mais atores (do mesmo tipo) relacionados ao caso de uso. 1.4.2. Nomenclatura e Descrio de Atores Na definio da nomenclatura dos atores deve-se: Definir nomes que tenham significado claro e objetivo para o cliente e para a equipe tcnica do projeto. Evitar o uso de siglas e abreviaturas. O nome do ator deve representar a sua funo em relao ao caso de uso.

Na especificao do caso de uso de extenso abstrato, inserir na seo de Atores do template, o seguinte texto: Este caso de uso possui os mesmos atores dos casos de uso que o estendem. Na especificao do caso de uso de extenso concreto, inserir na seo de Atores do template, o seguinte texto: Este caso de uso possui os atores abaixo citados e os mesmos atores dos casos de uso que o estendem. Na especificao do caso de uso de incluso abstrato, inserir na seo de Atores do template, o seguinte texto: Este caso de uso possui os mesmos atores dos casos de uso que o incluem.

1.5. Pr-condies
Uma pr-condio de um caso de uso explica o estado do sistema para que o caso de uso possa comear. As pr-condies somente devem ser especificadas se agregarem valor para o caso de uso. Uma informao adicionada como pr-condio deve ser considerada como verdadeira em todos os cenrios do caso de uso. Portanto, no devem ser validadas. Exemplo 1: Caso de Uso: Manter Documento Pr-Condio: Login O Sistema deve ter autorizado a pessoa que realizar a manuteno do Documento. Verso 6 Pgina 8/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

1.6. Ps-condio
Uma ps-condio de um caso de uso lista os possveis estados do sistema no fim do caso de uso. O sistema deve estar em um desses estados no fim da execuo do caso de uso. Tambm importante informar aes que o sistema executa no fim do caso de uso, independentemente do que tenha ocorrido no caso de uso. No descreva como ps-condio o objetivo do caso de uso. Lembre-se que o caso de uso deve possuir apenas informaes que agregam valor para os interessados. As ps-condies podem ser usadas para reduzir a complexidade e melhorar a compreenso do fluxo de eventos do caso de uso. Deve ficar claro que a ps-condio tem que estar de acordo com o objetivo do caso de uso. Exemplo 1: Caso de Uso: Efetuar Saque Ps-Condio: Ao final do caso de uso, o terminal torna-se disponvel para a execuo de qualquer outra transao.

1.7. Cenrio do caso de uso

O cenrio deve ser descrito fora do item 4.1 - fluxo bsico, aps o item 4 fluxo de eventos definido no template do caso de uso (MF SEFAZ sigla do sistema UC Nome do caso de uso.doc).

A descrio pode seguir o padro: O caso de uso acionado quando.... Exemplo 1: 1 O caso de uso se inicia quando o ator aciona a opo de manuteno de clientes; 2 O caso de uso se inicia em horrio pr-determinado...; 3 O caso de uso se inicia quando o sistema identifica a solicitao de gerao de informaes para o sistema SITAF; 4 O caso de uso se inicia quando o sistema verifica que est no horrio de iniciar a rotina de execuo.

1.8. Utilizao de palavras-chaves

Para facilitar a comunicao entre todos os clientes do caso de uso, sero sugeridas algumas palavras-chaves, ou seja, verbos para indicar aes do ator e do sistema. Segue relao das palavras-chaves definidas:

Verso 6

Pgina 9/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

Apresenta: aps uma operao, o sistema apresenta uma mensagem para o usurio (sucesso ou erro) ou informaes de formulrio. Ao realizada pelo sistema; Confirma: o ator solicita um servio do sistema ou confirma um servio solicitado; Exclui: indica a excluso fsica ou lgica de um registro em um arquivo lgico (banco de dados, arquivo,...) do sistema. Ao realizada pelo sistema; Informa: indica o preenchimento de informaes no sistema realizado pelo ator; Registra: indica o registro (incluso/alterao) de uma informao em um arquivo lgico (banco de dados, arquivo,...) do sistema. Ao realizada pelo sistema; Recupera: indica que a informao recuperada de um arquivo lgico (banco de dados, arquivo,...) e est disponvel para o usurio. Ao realizada pelo sistema; Seleciona: o ator seleciona um objeto de uma lista recuperada pelo sistema; Valida: validao de um objeto ou regra de negcio aps uma operao executada pelo usurio. Em um passo de validao geralmente existe uma exceo associada. Ao realizada pelo sistema; Verifica: verificao da ocorrncia de um comportamento no esperado, utilizada para iniciar uma exceo do sistema (geralmente primeiro passo de um fluxo de exceo). Ao realizada pelo sistema. Calcula: indica que o sistema realizou um clculo; Subtrai: indica que o sistema subtraiu um valor de outro valor; Soma: indica que o sistema somou um valor a um outro valor; Divide: indica que o sistema dividiu um valor por outro valor; Multiplica: indica que o sistema multiplicou um valor por outro; Exibe: aps uma operao, o sistema apresenta uma mensagem para o usurio (sucesso ou erro) ou informaes de formulrio. Ao realizada pelo sistema; Preenche: indica o preenchimento de informaes no sistema realizado pelo ator; Gera: indica que o sistema gerou algumas informaes, tipo relatrio, entre outros; Armazena: indica o registro (incluso/alterao) de uma informao em um arquivo lgico (banco de dados, arquivo,...) do sistema. Ao realizada pelo sistema.

Observaes: 1. As palavras apresentadas acima so sugestes, os analistas podero definir novas palavras conforme a necessidade. 2. A palavra-chave Verifica pode ser utilizada tambm para a verificao de uma situao particular (regra de negcio) no fluxo principal ou fluxos alternativos.

Verso 6

Pgina 10/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

1.9. Fluxo bsico

O fluxo bsico descreve o comportamento principal ou o mais comum da funcionalidade. O cenrio ser descrito por uma seqncia de passos de interao entre o ator e o sistema para que o objetivo do caso de uso seja atingido. A especificao de caso de uso deve ser voltada ao negcio, no devendo conter detalhes de interface ou a utilizao de termos que remetem s atividades de projeto e desenvolvimento, tais como: tabela, objeto, etc.

1.10. Fluxo alternativo

Os fluxos alternativos podem ser divididos em dois grupos: Os que tratam excees (ou erros); Os que disponibilizam comportamentos adicionais que podero ser acionados tanto pelo sistema quanto pelo ator.

Os fluxos de eventos alternativos abordam o comportamento de carter opcional ou excepcional em relao ao comportamento normal e tambm as variaes do comportamento normal. Voc pode pensar nos fluxos de eventos alternativos como "desvios" do fluxo de eventos bsico, alguns dos quais retornaro para o fluxo de eventos bsico, alguns dos quais terminaro a execuo do caso de uso e outros podem acionar outro fluxo alternativo. As excees devem tratar problemas relacionados execuo, incluindo situaes que interrompam a execuo do caso de uso. As excees no necessariamente encerram o caso de uso, mas elas devem impedir a continuidade do fluxo. Cada fluxo de exceo dever conter um ttulo que o descreva de forma objetiva e represente claramente a exceo. Devem seguir a seguinte regra de nomenclatura: FA + Seqencial + Sentena que descreve o objetivo do fluxo. Dever ter um ttulo no infinitivo, quando possvel, e completo o suficiente para descrever o objetivo ou a ao que leva a sua execuo. Exemplo 1: 1 FA1 Executar rotina de atualizao; 2 FA2 Alterar cliente; 3 FA3 Erro na rotina de atualizao; 4 FA4 Campo obrigatrio. Cada fluxo alternativo dever conter um ttulo que o descreva de forma objetiva e que represente claramente o desvio. Para descrever o incio do fluxo alternativo ou o retorno ao fluxo que o iniciou, usar a palavra PASSO e no item ou outro termo. Verso 6 Pgina 11/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

Exemplo 2: no passo 4.1.4 do fluxo bsico, caso no haja empregados domsticos cadastrados para o Empregador informado, o sistema informa que no h empregados domsticos cadastrados e retorna ao FB4. Os fluxos alternativos que ocorrem a partir dos fluxos de eventos devem ser descritos utilizando a seguinte estrutura: No(s) passo(s) <nmero do(s) passo(s) do fluxo bsico ou do fluxo alternativo onde existe a possibilidade de ocorrncia de um fluxo alternativo > do <fluxo bsico ou fluxo alternativo>, caso <descrio da condio de ocorrncia do fluxo alternativo>, o sistema dever <descrio da ao a ser tomada pelo sistema>. <Descrio do fechamento do fluxo alternativo>. Exemplo 3: Nos passos 4.1.4 do fluxo bsico, FA1.4 do fluxo alternativo FA1 ou FA2.4 do fluxo alternativo FA2, caso o Empregador no confirme a transao, o sistema informa que a transao ser cancelada e finaliza caso de uso. Caso exista a necessidade de incluir passos no contexto do fluxo alternativo que ocorrem a partir dos fluxos de eventos, utilizar a seguinte estrutura: No(s) passo(s) <nmero do(s) passo(s) do fluxo bsico ou do fluxo alternativo onde existe a possibilidade de ocorrncia de um fluxo alternativo> do <fluxo bsico ou fluxo alternativo>, caso <descrio da condio de ocorrncia do fluxo alternativo>, o sistema deve executar os seguintes passos: 1. <Descrio do passo do fluxo alternativo>. <Explicao do passo, caso necessrio>. 2. <Descrio do passo do fluxo alternativo>. <Explicao do passo, caso necessrio>. 3. Finaliza caso de uso. <ou Retorna ao <referncia cruzada do nmero do passo> do <fluxo bsico, fluxo alternativo ou fluxo de exceo>.> Para descrever os fluxos alternativos que no so iniciados a partir dos fluxos de eventos e que no possuem passos, deve-se utilizar a estrutura abaixo: Caso <descrio da condio de ocorrncia do fluxo alternativo>, o sistema dever <descrio da ao a ser tomada pelo sistema>. <Descrio do fechamento do fluxo alternativo>. Para descrever os fluxos alternativos que no so iniciados a partir dos fluxos de evento e que possuem passos, deve-se utilizar a estrutura abaixo: Caso <descrio da condio de ocorrncia do fluxo alternativo>, o sistema deve executar os seguintes passos: 1. <Descrio do passo do fluxo alternativo>. <Explicao do passo, caso necessrio>. 2. <Descrio do passo do fluxo alternativo>. <Explicao do passo, caso necessrio>. 3. Finaliza caso de uso. <ou Retorna ao <referncia cruzada do nmero do passo> do <fluxo bsico, fluxo alternativo ou fluxo de exceo>.>

Verso 6

Pgina 12/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

As descries dos passos do fluxo alternativo so opcionais e podero ser feitas sempre que houver a necessidade de um maior detalhamento. Caso o fluxo alternativo seja finalizado no prprio fluxo, deve-se utilizar a expresso Finaliza caso de uso. para descrever o seu fechamento e caso no seja, tendo que retornar a um determinado passo do fluxo bsico, alternativo ou de exceo, deve-se utilizar na hiptese, a referncia cruzada para o retorno, com a seguinte expresso: Retorna ao <referncia cruzada do passo> do fluxo bsico <ou fluxo alternativo ou de exceo>.

1.11. Subnvel dos passos

Os fluxos alternativos que cuidam de excees e de alternativas tero apenas dois subnveis: a numerao do ttulo e a dos respectivos passos. Exemplo 1: FA1 Incluir usurio FA1.1 o sistema verifica que a opo para incluir usurio foi selecionada; FA1.2 o sistema apresenta as seguintes informaes...; FA1.3 o ator informa os seguintes dados...; FA1.4 o ator aciona opo...; ...

FA2 Campo obrigatrio FA2.1 ... FA2.2 ...

1.12. Estilos dos fluxos bsico e alternativos

O estilo dos fluxos bsico e alternativo dever ter a numerao automtica iniciando com as abreviaes FB e FA, respectivamente. Exemplo 1: 1 - Fluxo bsico: FB1, FB2; 2 - Fluxo alternativo FA1: FA1.1, FA1.2. Ao retornar ao fluxo que originou a chamada, dever ser feita referncia ao passo FB e FA sem especificar o fluxo. Para casos onde o fluxo alternativo retorna para outro fluxo alternativo, informar o passo e o fluxo alternativo. Exemplo 2: 1 Chamada realizada no passo FB3; Retorno: FA1.4 O sistema retorna ao FB4;

Verso 6

Pgina 13/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

2 Chamada realizada no passo FA1.4; Retorno: FA2.3 O sistema retorna ao FA1.5. Observaes: As chamadas devem fazer uso do recurso referncia cruzada do Microsoft Word. Devero sempre estar em negrito, entre parnteses ou colchetes e no final da linha do passo.

1.13. Referncia ao ator

Quando houver apenas um ator que executa um caso de uso, a palavra ator ser utilizada nos passos de interao com o sistema; quando houver mais de uma especializao, ser citada a palavra que identifica a especializao, conforme observao do item 1.3. Ao identificar o ator no caso de uso, acrescentar sua descrio, mesmo que essa informao se repita em outros casos de uso. Exemplo 1: Para um ator: Definio de ator: gestor; Citao do ator no passo: o ator informa os seguintes dados... (no se informa a palavra gestor, pois s temos um ator); Exemplo 2: Para mais de um ator: Definio de ator: a) gestor; b) analista (ambos so especializao de funcionrio); Citao do ator no passo: o gestor/analista informa... (informe a generalizao funcionrio caso no seja necessrio especificar o que cada especializao realiza no caso de uso, conforme descrito acima).

1.14. Passos a serem descritos

Os passos a serem descritos em uma especificao de caso de uso (seqncia a ser seguida), seja no fluxo bsico, seja nos fluxos alternativos, so: 1 - o sistema apresenta as seguintes informaes...; 2 - o ator informa os seguintes dados...; 3 - o ator aciona opo...; 4 - o sistema verifica/pesquisa...; 5 - o sistema apresenta...; 6 - fim de caso de uso.

Verso 6

Pgina 14/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

Em todos os passos, o verbo principal dever ser escrito sempre no presente do indicativo: O sistema identifica que o ator digitou... ; O ator aciona a opo... ; O sistema verifica que o ator cadastrou... .

Observaes: Como boa prtica, cada passo descrito dever ter apenas um (1) verbo principal.

1.15. Validao dos campos

Nos passos onde o sistema realizar verificao/pesquisa, princpio, apenas os campos que levam em considerao alguma regra de negcio sero verificados. Informaes invlidas, como letras em campos numricos e CPF/CNPJ invlidos no sero verificados. Exemplo 1: FA1 Data invlida: NO SER VERIFICADO! Esse tipo de validao ser tratada no Guia de Desenvolvimento. FA2 Data menor que data atual: SER VERIFICADO, POIS ATENDE ALGUMA REGRA DE NEGCIO. Observaes: para fins de produtividade, permitido criar fluxos alternativos que tratam validaes diferentes para o mesmo campo. Exemplo 2: FA1 Gesto inativa FA1.1 - O sistema verifica que a gesto est inativa ou invlida; FA1.2 - O sistema exibe a mensagem (MN1 ou MN2); FA1.3 - O sistema retorna ao FB1, mantendo os campos preenchidos.

2. RELACIONAMENTOS ENTRE CASOS DE USO 2.1. Include (incluso)

O relacionamento de incluso conecta um caso de uso base a um caso de uso de incluso. O caso de uso de incluso descreve um segmento de comportamento que ser inserido em local determinado do caso de uso base. O caso de uso base controla o relacionamento com o caso de uso de incluso e pode depender do resultado da execuo da incluso. O relacionamento de incluso deve ser explicito, ou seja, necessrio definir em qual passo do caso de uso base ocorrer a incluso. O relacionamento de incluso pode ser usado para:

Verso 6

Pgina 15/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

Separar o comportamento do caso de uso base que no seja necessrio para compreender a finalidade principal do caso de uso; apenas o resultado importante;

Separar o comportamento que seja comum a dois ou mais casos de uso. Conforme descrito por Booch, Jacobson e Rumbaugh em UML Guia do Usurio [5], a forma de descrever a incluso a seguinte: Include: nome do caso de uso.

Dicas de como especificar relacionamentos com esteretipo <<incluso>> Na especificao do caso de uso base, indicar a existncia do relacionamento de incluso na estrutura dos fluxos de eventos do caso de uso. Deve-se utilizar o texto padro: O sistema aciona/executa o caso de uso <nome do caso de uso> para <objetivo geral da incluso realizada.

Na especificao do caso de uso de incluso, substituir o texto Este caso de uso inicia quando <descrever o incio do caso de uso> (definido na seo de Fluxo de Eventos do template) pelo texto padro: Este caso de uso uma incluso de outros casos de uso. Na especificao do caso de uso de incluso, inserir na seo de Atores do template, o seguinte texto: Este caso de uso possui os mesmos atores dos casos de uso que o incluem.

2.2. Extend (extenso)

Se um caso de uso possui segmentos de comportamento opcional ou excepcional e isso no acrescenta nada compreenso da finalidade principal do caso de uso, aconselhvel dividi-lo para criar um caso de uso de extenso. O caso de uso original se tornar um caso de uso base, com o qual o caso de uso de extenso manter um relacionamento de extenso. comum o caso de uso de extenso ser abstrato, mas no necessrio que seja. As extenses podem ser usadas para diversas finalidades: Mostrar que uma parte de um caso de uso um comportamento opcional (ou possivelmente opcional) do sistema. Isso faz a diferenciao entre comportamento opcional e comportamento obrigatrio em um modelo; Mostrar que um subfluxo s executado em determinadas condies (algumas vezes excepcionais), como o disparo de um alarme; Inserir comportamentos adicionais em pontos determinados do caso de uso base. Os segmentos de comportamento que so inseridos (e a ordem na qual so inseridos) dependero da interao com os atores durante a execuo do caso de uso base.

Aps a criao de uma extenso, certifique-se de que o fluxo de eventos do caso de uso base ainda est com seu sentido completo e pode ser compreendido por si s, sem que seja necessria nenhuma referncia ao caso de uso de extenso. As extenses podem acontecer em dois momentos: Verso 6 Pgina 16/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

Quando casos de uso internos so chamados (extenses) pelos casos de usos bases; Quando casos de usos externos so chamados por casos de usos bases (internos).

Quando as chamadas forem internas (casos de uso base realizando extenses aos casos de uso internos), seguir o que est definido no exemplo 1, logo abaixo; quando as chamadas forem externas (casos de uso base acessando informaes de outros sistemas), seguir o que est definido no exemplo 2. Exemplo 1: Sistemas internos FB5 O sistema verifica... [PE7.1]; PONTO DE EXTENSO PE7.1 Recuperar CPF No FB5, informao CPF, estendido ao caso de uso Manter Cliente. Exemplo 2: Sistemas externos FB5 O sistema valida o CPF no sistema CPE. FB5 O sistema pesquisa/consulta o CPF no sistema CPE. FB5 O sistema recupera dados do cliente no sistema CPE. Dicas de como especificar relacionamentos com esteretipo <<extenso>> Na especificao do caso de uso base, indicar a existncia do relacionamento de extenso na seo definida como Pontos de Extenso, do template. Deve-se definir um nome para o ponto de extenso. As seguintes recomendaes devem ser seguidas: Para descrever o ponto de extenso que ocorre em algum passo do fluxo bsico ou do fluxo alternativo/exceo, utilizar o texto padro: No(s) passo(s) <nmero do(s) passo(s) do fluxo bsico ou do fluxo alternativo/exceo onde existe a possibilidade de ocorrncia de um ponto de extenso> do <nome do fluxo bsico ou fluxo alternativo/exceo>, caso <descrio da condio de ocorrncia do ponto de extenso>, o sistema deve estender o caso de uso <nome do caso de uso>. Exemplo 3: PE7.1, PE7.2

Abaixo seguem diretrizes para casos de uso de extenso. Os casos de uso de extenso podem ser abstratos ou no, pra isso seguem orientaes para os dois casos: Na especificao do caso de uso de extenso abstrato, substituir o texto Este caso de uso inicia quando <descrever o incio do caso de uso> (definido na seo Fluxo de Eventos do template.) pelo texto padro: Este caso de uso uma extenso de outros casos de uso.

Verso 6

Pgina 17/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

Na especificao do caso de uso de extenso abstrato, inserir na seo de Atores do template, o seguinte texto: Este caso de uso possui os mesmos atores dos casos de uso que o estendem. Na especificao do caso de uso de extenso concreto, inserir na seo de Atores do template, o seguinte texto: Este caso de uso possui os atores abaixo citados e os mesmos atores dos casos de uso que o estendem. E neste caso listar os atores que se relacionam com o caso de uso na condio de concreto. Na especificao do caso de uso de extenso concreto, substituir o texto Este caso de uso inicia quando <descrever o incio do caso de uso>. (definido na seo Fluxo de Eventos do template) pelo texto padro: Este caso de uso inicia quando <descrever o incio do caso de uso> ou quando uma extenso de outros casos de uso.

3. REGRAS DE NEGCIO
As regras de negcios so tipos de requisitos de como os negcios, incluindo suas ferramentas de negcios, devem operar. Elas podem ser leis e regulamentos impostos ao negcio, mas tambm expressam a arquitetura e o estilo de negcio escolhidos. As regras de negcios: Devem ser expressas rigorosa e formalmente para que sejam uma base para automao; Representam limitadores do comportamento; Definem polticas e prticas que determinam o que possvel, desejvel ou mesmo impossvel na operao do negcio; No so processos, e sim o direcionamento dos processos. Portanto, definem a direo que um fluxo dever seguir.

3.1. Conceito
As regras de negcio so declaraes de polticas (leis, normas corporativas, resolues...) ou condies que devem ser cumpridas. As regras de negcio esto fora da fronteira do sistema que est sendo desenvolvido, ou seja, so declaraes que pertencem ao domnio do negcio que se pretende resolver. No escopo do sistema, as regras de negcio sero atendidas por funcionalidades especficas.

3.2. Melhores prticas

Formatao

Verso 6

Pgina 18/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

A formatao a ser utilizada : fonte arial, tamanho 10 e cor preta. NO UTILIZAR ITLICO E SUBLINHADO. Negrito pode ser usado para destacar informaes e os ttulos. As regras de negcio devem ser especificadas em um documento prprio Documento de Regras de Negcio. Esta separao permite a reutilizao por diferentes requisitos (casos de uso) do sistema. Na documentao dos sistemas legados este documento prprio ser aplicado para sistemas crticos; As regras de negcio sero identificadas com um cdigo nico em todo o documento. Este cdigo ser utilizado como referncia nos outros artefatos; As regras de negcio so geralmente referenciadas nos passos do caso de uso onde ocorrem validaes de dados e nos passos onde ocorrem extenses (desvio para fluxos alternativos ou excees); Os casos de uso que referenciam regras de negcio devem citar o documento na seo Referncias.

Documento de Regras e Casos de Uso

Agrupamento das Regras O documento pode ser divido em Grupos de Regras, o que permite uma separao por segmento de negcio. O agrupamento ajuda na localizao, bem como no entendimento do contexto da regra.

Especificao das Regras As regras de negcio devem ser atmicas, ou seja, auto-suficientes para o seu entendimento. Uma regra de negcio pode possuir vrios pargrafos de texto, e ainda sim ser uma nica regra; Utilize a forma afirmativa (sempre que possvel) na especificao das regras. A utilizao da forma negativa e, principalmente, a negativa de uma negativa geram dificuldades na interpretao; Evite textos extensos, quebrando o texto ou utilizando uma forma estruturada de para facilitar o entendimento; Para textos extensos, utilize palavras-chaves e uma forma estruturada para a composio das sentenas. Ver o item 2 Definies que se encontra no template de Regras de Negcio

4. MENSAGENS DO SISTEMA
As mensagens podem ser referentes ao negcio, apresentao ou para ajudar do usurio. Caso exista relacionamento direto das mensagens com as regras de negcio, o relacionamento pode ser realizado no caso de uso. Nos passos do caso de uso que descrevem a exibio de mensagem, ser utilizada referncia ao cdigo da mensagem descrita no documento Lista de Mensagens. Este deve ser citado na seo Referncias do Caso de Uso. Para mais informaes, ver o template de Lista de Mensagens.

Verso 6

Pgina 19/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

5. SEPARAO DOS PASSOS DE UM CRUD

Ficou definido que existiro (CreateReadUpdateDelete): duas formas para um caso de uso Manter

A consulta como fluxo principal, tendo os fluxos alternativos de incluso, alterao e excluso; A incluso como fluxo principal, tendo os fluxos alternativos de consulta, alterao e excluso, sendo que o fluxo de alterao ser chamado atravs do fluxo alternativo de consulta.

Observaes: importante verificar com o gestor do sistema qual das formas ser adotada na especificao desse tipo de caso de uso.

6. PRTICAS NO RECOMENDADAS
A descrio dos elementos de interface no deve ser feita nas especificaes de casos de uso. No utilizar termos tcnicos como boto, caixa de seleo ou links. Estas caractersticas devem ser definidas no documento Descrio da Interface do Caso de Uso em questo. Deve-se evitar a utilizao de termos que remetem s atividades de projeto e desenvolvimento, tais como: classe <nome da classe>, atributo <nome do atributo>; banco de dados; tabela <nome da tabela>; e Instrues como if else, switch case;

Estas informaes devem estar especificadas nos artefatos adequados, como Modelo de Anlise ou Modelo de Projeto. No se devem utilizar linguagens de navegao de tela mesmo quando no existir a presena de termos relacionados interface grfica (boto, caixa de seleo ou links). Exemplo 1: 4.1.5 O usurio aciona a confirmao da consulta. Neste exemplo, apesar de no existirem termos relacionados interface grfica, fica claro para o leitor que se trata de um boto de confirmao que acionado pelo usurio.

As especificaes de casos de uso no devem ter a estrutura de programas definidos em portugus estruturado. No deve existir a idia de loop nos passos do caso de uso. No devem ser usadas expresses que impliquem que os requisitos so opcionais ou indefinidos, como "deveria", "possivelmente" "etc.", outros, "talvez" ou "pode". Quando alguma seo do template da especificao no se aplicar ao caso de uso, deve-se utilizar o termo No se aplica.. Verso 6 Pgina 20/21

GUIA DE ESPECIFICAO DE REQUISITOS FUNCIONAIS

7. REQUISITOS ESPECIAIS
Neste item do documento devero ser explicitados os requisitos no-funcionais especficos do caso de uso, bem como informaes adicionais captadas durante o levantamento e que sejam relevantes apenas para o caso de uso especfico. Devem-se colocar informaes que permitam mensurar o requisito especial. Exemplos de requisitos especiais: - Formato de gerao de relatrios; - Tempo de Execuo da Transao, entre outros.

8. REFERNCIAS
[1] Rational Unified Process, Verso 2002.05.00, Portugus [2] Business Rules Applied, Barbara von Halle, Wiley Computer Publishing, 2002 [3] Escrevendo Casos de Uso Eficazes, Alistair Cockburn, Bookman, 2005 [4] More About Software Requirements, Karl E. Wiegers, 2006 [5] UML Guia do Usurio, Graddy Booch, James Rumbaugh, Ivar Jacobson, Campus, 2005 [6] Rational Unified Process Verso 7.0.1, Portugus

Verso 6

Pgina 21/21