Artigos Banco de Dados Especificação de Casos de Uso na Prática

De que se trata o artigo:

Este artigo apresenta inicialmente algumas definições associadas à engenharia de requisitos e à especificação de requisitos através de casos de uso. Em seguida, são apresentados alguns exemplos reais de especificação utilizando casos de uso.

Para que serve:

O objetivo do artigo é explicitar de forma prática como a especificação dos requisitos do software através de casos de uso podem ser efetuadas em um nível de detalhe tal que informações importantes para outras etapas do desenvolvimento como planejamento de testes, projeto e desenvolvimento não sejam omitidas.

Em que situação o tema é útil:

O assunto abordado é útil no dia a dia do analista de requisitos na realização de suas atividades.

A engenharia de requisitos é um termo usado para descrever as atividades relacionadas à produção (levantamento, registro, validação e verificação) e gerência (controle de mudanças, gerência de configuração, rastreabilidade, gerência de qualidade dos requisitos) de requisitos. A Figura 1 representa essa definição.

Figura 1. Engenharia de Requisitos.

Mas o que podemos entender por requisitos? Existem diferentes definições encontradas na literatura técnica:

· Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir os seus objetivos;

· As descrições das funções e restrições são os requisitos do sistema;

· Um requisito é uma propriedade que o software deve exibir para resolver algum problema no mundo real;

· Uma condição ou uma capacidade que deve ser alcançada ou estar presente em um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto...

Assim, podemos entender requisitos como sendo o conjunto de necessidades explicitadas pelo cliente que deverão ser atendidas para solucionar um determinado problema do negócio no qual o cliente faz parte. É importante estar atento para esta definição: embora o requisito seja definido pelo cliente, nem sempre o que o cliente quer é o que o negócio precisa. Cabe à equipe de consultores identificar a real necessidade do negócio.

Neste contexto, requisitos são importantes para:

· Estabelecer uma base de concordância entre o cliente e o fornecedor sobre o que o software fará;

· Fornecer uma referência para a validação do produto final;

· Reduzir o custo de desenvolvimento (como vimos anteriormente, requisitos mal definidos causam retrabalho).

A atividade de identificação e especificação de requisitos do software é uma atividade bastante desafiadora. É complexo:

· Identificar as reais necessidades do cliente;

· Lidar com clientes;

· Formalizar as necessidades do cliente através da especificação de requisitos de forma que esta seja de fácil entendimento para o cliente e forneça as informações requeridas pela equipe de desenvolvimento;

· Lidar com domínios desconhecidos. Entende-se por domínio o contexto para o qual o software está sendo desenvolvido. Por exemplo: contabilidade, medicina, controle de estoque. Para ilustrar esta dificuldade, imagine-se elaborando a especificação dos requisitos de um módulo estatístico para um sistema do mercado financeiro;

· Definir as necessidades do usuário em termos de especificações.

O objetivo deste artigo não é apresentar um referencial teórico sobre como lidar com cada questão envolvida nas atividades diárias de um analista de requisitos. Focaremos aqui apenas no último tópico da lista apresentada acima: “Definir as necessidades do usuário em termos de especificações”. Faremos isto de forma totalmente prática através da apresentação de um conjunto de casos de uso especificados que poderão servir de base para suas atividades como analista de requisitos.

Contextualização dos Exemplos

As especificações de casos de uso apresentadas neste artigo são fruto da experiência prática do autor. Eles não servem de gabarito para futuras atividades de especificação, ao invés disso, podem ser considerados um ponto de partida para que possamos ver na prática como podemos escrever casos de uso.

É importante estar atento também ao fato de que os casos de uso apresentados neste artigo refletem as características de escrita dos autores. Estas características que envolvem itens como nível de detalhamento, informações contidas nos casos de uso, dentre outras, costumam mudar também de organização para organização.

Tendo isto em mente, para este artigo iremos considerar o conjunto de definições apresentado na Tabela 1 como sendo importantes na descrição de um caso de uso.

Objetivo:

Contém uma breve descrição do objetivo do caso de uso.

Requisitos:

Neste campo indicamos a qual requisito funcional o caso de uso em questão está associado.

Atores:

Neste campo definimos a lista de atores associados ao caso de uso. Ator é qualquer entidade externa que interage com o sistema (neste caso, com o caso de uso em questão).

Prioridade:

Informação identificada junto ao usuário que auxilia na definição dos casos de uso que serão contemplados em cada iteração do desenvolvimento do software.

Pré-condições:

Neste campo devemos informar as condições que devem ser atendidas para que o caso de uso possa ser executado.

Freqüência de uso:

Informação identificada junto ao usuário que auxilia na definição dos casos de uso que serão contemplados em cada iteração do desenvolvimento do software.

Criticalidade:

Informação identificada junto ao usuário que auxilia na definição dos casos de uso que serão contemplados em cada iteração do desenvolvimento do software.

Condição de Entrada:

Neste campo definimos qual ação do ator dará início à interação com o caso de uso em questão.

Fluxo Principal:

Esta é uma das seções principais do caso de uso. É onde descrevemos os passos entre o ator e o sistema. O fluxo principal é o cenário que maisacontece no caso de uso e/ou o mais importante.

Fluxo Alternativo:

Fluxo alternativo é o caminho alternativo tomado pelo caso de uso a partir do fluxo principal, ou seja, dada uma condição de negócio o caso de uso seguirá por outro cenário que não o principal caso essa condição seja verdadeira.

Pós-condições:

Neste campo devemos informar o estado em que o sistema (ou entidade manipulada no caso de uso) estará depois que o caso de uso for executado.

Regras de negócio:

Nesta seção descrevemos todas as regras funcionais que o caso de uso deve cumprir durante sua execução.

Tabela 1. Conceitos envolvidos na descrição de um caso de uso.

A partir de agora apresentaremos dois exemplos de casos de uso. Procuramos utilizar como exemplo situações corriqueiras no dia a dia do desenvolvimento de software.

[subtítulo]Exemplos de Casos de Uso[/subtítulo]

Inicialmente vamos apresentar um caso de uso contendo a descrição de um cenário de cadastro básico para a entidade Pessoa Física. Este cadastro possui as operações de consulta, inclusão, exclusão e alteração. Sua especificação está apresenta na Tabela 2.

UC1 – Manter Pessoa Física

Objetivo:

Permitir que funcionários adicionem, consultem, removam ou alterem dados de pessoas físicas.

Requisitos:

-

Atores:

Funcionário

Prioridade:

Baixa

Pré-condições:

Freqüência de uso:

Eventual

Criticalidade:

Baixa

Condição de Entrada:

O Funcionário seleciona a opção Manter Pessoa Física.

Fluxo Principal:

1. O sistema apresenta formulário de busca de pessoas físicas contendo as informações:

- CPF (campo editável)

- Nome (campo editável)

- Estado (lista dos Estados brasileiros)

- As opções Buscar e Cancelar

- A opção Incluir Nova Pessoa Física

2. O ator escolhe a opção Incluir Nova Pessoa Física [A1][A2]

3. O sistema apresenta formulário de cadastro de Pessoas Físicas contendo os seguintes campos a serem preenchidos:

(Informações Gerais)

- CPF (campo editável)

- RG (campo editável)

- Nome (campo editável)

(Endereços)

- Tabela com os endereços cadastrados para a pessoa física que está sendo criada (cada endereço adicionado possui as seguintes informações: Logradouro, Bairro, Complemento, CEP, Município, Estado e País) e a opção de Excluir Endereço ...

Quer ler esse conteúdo completo? Tenha acesso completo