Hélio Engholm Jr

Especializado em Engenharia de Software

Este artigo trata do levantamento e gerenciamento de requisitos e apresenta um template de especificação de Caso de Uso, que pode ser utilizado em projetos que usam o Paradigma Orientado a Objetos.

Levantamento e Gerenciamento de Requisitos

Responsabilidade e Autoridade

Papéis Responsabilidades
Coordenador de Projetos
  •   Definir Estratégias de   Gerenciamento
  •   Identificar   Fornecedores de Requisitos
  •   Identificar restrições
  •   Aprovar Escopo do   Sistema
  •   Consolidar Requisitos
  •   Validar   Requisitos com Fornecedores de Requisitos
  •   Manter Rastreabilidade   de Requisitos
Analista de Requisitos
  •   Definir Estrutura de   Requisitos
  •   Definir Estratégias de   Gerenciamento
  •   Estabelecer ambiente   de requisitos
  •   Identificar   Fornecedores de Requisitos
  •   Obter Entendimento do   Problema
  •   Identificar Usuários
  •   Identificar   Necessidades
  •   Identificar Restrições
  •   Capturar Vocabulário   Comum
  •   Levantar   Características do Produto
  •   Levantar Requisitos de   Software
  • Validar Escopo do   Sistema
  •   Especificar   Requisitos Funcionais e Não Funcionais
  •   Especificar Cenários   Operacionais
  •   Criar Protótipos
  •   Consolidar Requisitos
  •   Elaborar Pacote para   Validação
  •   Validar   Requisitos com Fornecedores de Requisitos
  •   Manter Rastreabilidade   de Requisitos
Arquiteto de Software
  •   Identificar Restrições
  •   Consolidar Requisitos
Analista de Testes
  •   Consolidar Requisitos
Fornecedor de Requisitos
  •   Fornecer requisitos
  •   Aprovar Escopo do   Sistema
  •   Validar Requisitos
  •   Aceitar Requisitos

Quebra de página

Identificar Fornecedores de Requisitos

São exemplos de Fornecedores de Requisitos:

  • Cliente patrocinador;
  • Usuário Final;
  • Áreas Técnicas do Cliente (Qualidade, Produção, Banco de Dados, Tecnologias); entre outros
  • Gestores do negócio;
  • Usuários finais, que são os fornecedores de requisitos preferenciais;
  • Pessoas com alçada para tomada de decisão.
  • Pessoas ou áreas que avaliarão e aprovarão os produtos gerados
  • Patrocinador ou Cliente do Projeto

Atributos Mínimos dos Requisitos

Benefício: Indica o grau de benefício ou prioridade dos requisitos em relação às expectativas dos Fornecedores de Requisitos.

Valor

Descrição

Crítico Requisitos essenciais   cujo fracasso em sua implementação significa que o sistema não irá atender as   Necessidades dos interessados. Imprescindível que seja atendido pelo sistema,   condição fundamental para o sucesso do projeto.
Importante Requisitos importantes   para a eficácia ou eficiência do sistema. Sua não implementação afeta a   satisfação do usuário e/ou o valor agregado do produto e o não atendimento   não determina o fracasso do projeto.
Útil Requisitos úteis,   porém menos críticos, sendo usados menos freqüentemente. Não possui muito   significado para a satisfação do usuário e pode deixar de ser atendida.

Estabilidade: Indica o grau de maturidade e confiabilidade em relação ao entendimento e comprometimento de um requisito entre os envolvidos do projeto.

Valor

Descrição

Alta Deve indicar   requisitos que possuem alto grau de estabilidade. O entendimento pela Equipe   de Projeto e pelos Fornecedores de Requisitos é evidente e a probabilidade de   ocorrência de mudanças é baixa.
Média Requisitos cuja   probabilidade de ocorrência de mudanças é considerável. Alguns fatores que   determinam esse valor são: requisitos ainda não entendidos completamente pela   equipe de projeto ou com algumas pendências de definições por parte do   Fornecedor do Requisito.
Baixa Requisitos cuja   mudança é certa, devido à baixa maturidade do mesmo. Requisitos altamente   complexos, requisitos com muitas pendências de definição, requisitos com   histórico de mudanças elevadas e requisitos com influências externas (Leis,   outros sistemas) são alguns fatores que influenciam para esse valor.

Situação: Indica a situação atual de um requisito.

Valor

Descrição

Proposto Indica requisitos que   foram solicitados pelos Fornecedores de Requisitos, mas ainda estão em   análise pela Equipe de Projeto ou pelo Cliente.
Aprovado Requisito aprovado e   incorporado ao escopo do sistema.
Cancelado Requisito que foi   cancelado. Para ser cancelado o requisito pode estar Aprovado, e neste caso   será retirado do escopo do sistema, ou pode estar simplesmente Proposto.

Risco: Indica grau de risco de implementação de um determinado requisito na visão da Equipe de Projeto.

Valor

Descrição

Alta Requisitos cujo risco   de implementação é alto devido aos seguintes fatores: requisitos com baixa   estabilidade, requisitos com alta complexidade, inovações tecnológicas e   dependências externas e alto custo de implementação.
Média Seguir os mesmos   critérios anteriores, passível de análise dos níveis de influência exercidos   pelos fatores.
Baixa Idem

Responsável: Indica o nome do responsável na Equipe de Projeto pelo requisito.

Valor

Descrição

Membro da Equipe Estabelece o membro da   equipe responsável no momento pelo requisito. Pode   ser alterado durante o tempo.

Observações: Atributo livre para registro de observações como pendências ou problemas que atualmente está ocorrendo com o requisito.

Valor

Descrição

Texto Livre Importante recurso   para que o Analista de Requisitos ou o Coordenador de Projetos registre   pendências encontradas no desenvolvimento do requisito.

 

Levantar Características do Produto

Exemplos:

O sistema deve ser compatível com Windows XP

O sistema deve distinguir perfis de usuários

O sistema deve ser capaz de anexar arquivos com tamanho de até 2MB

O sistema deve ser capaz de enviar mensagens eletrônicas às pessoas convocadas para as reuniões.

O sistema deve reportar o inventário de todos os itens, atualizados na data e hora da emissão.

O sistema deve controlar acesso de usuários

O sistema deve ser capaz de armazenar o histórico de operações

Esse tipo de requisito deve ser rastreável. Dessa maneira, os Atributos de Requisitos e Matrizes de Rastreabilidade definidas na estratégia de gerenciamento devem ser criadas ou mantidas, conforme subprocesso Manter Rastreabilidade.

Levantar Requisitos de Software

Os Requisitos de Software são divididos em dois tipos: Requisitos Funcionais e Requisitos não Funcionais. Desse modo, o objetivo desta atividade é identificar e registrar os Requisitos Funcionais e Requisitos não Funcionais do sistema. O Analista de Requisitos registra as informações na Lista de Requisitos Funcionais e na Lista de Requisitos não Funcionais.

Requisitos Funcionais são aqueles que definem as funções ou ações que o sistema deve fornecer. São tipos de Requisitos Funcionais:

  • Casos de uso;
  • Funções;
  • Regras de negócio;
  • Interfaces Internas;
  • Interfaces Externas.

Requisitos não funcionais descrevem atributos do sistema ou do ambiente do sistema. São tipos de Requisitos não Funcionais:

  • Usabilidade;
  • Confiabilidade;
  • Desempenho;
  • Suportabilidade;
  • Restrições de projeto;
  • Requisitos de Implementação;
  • Requisitos de Interface;
  • Requisitos Físicos.

Descrição das Atividades

Especificar Requisitos Funcionais

Esta atividade tem o objetivo de gerar a Especificação de Requisitos Funcionais a partir da Lista de Requisitos Funcionais, Solicitações dos Envolvidos, Visão e Glossário de maneira que esses requisitos sejam suficientes para retratar todo o comportamento funcional do sistema.

Nesta atividade, o Analista de Requisitos deve documentar os detalhes dos Requisitos Funcionais, especificando os seguintes itens:

  • Pré-condições e pós-condições
  • Fluxos de operação;
  • Entradas e saídas;
  • Interação do sistema com as Interfaces Externas e Usuários;
  • Interfaces internas;
  • Restrições de segurança e permissões;
  • Exceções; e
  • Regras de negócio.

Especificar Requisitos Não Funcionais

 

Especificar Cenários Operacionais

Nesta atividade, o Analista de Requisitos deve gerar, com base nas Especificações dos Requisitos Funcionais e no Visão, as Especificações de Cenários Operacionais.

Criar Protótipos

Prototipação é uma técnica muito importante para obter o entendimento dos requisitos funcionais do sistema. Quanto maior o grau de dinamismo de um protótipo, mais poderoso ele se torna para alcançar esse objetivo. No entanto, deve-se tomar cuidado para que os usuários entendam que o protótipo não materializa, neste momento, a solução final para o sistema.

Consolidar requisitos

Esta análise deve assegurar que os Requisitos são:

  • Completos: possuem todas as informações necessárias para o seu desenvolvimento
  • Viáveis: a implementação é viável quanto às restrições da solução técnica
  • Executáveis: contém todos os passos e regras que possibilitem a sua execução
  • Verificáveis: é possível verificar se o que foi implementado corresponde com o Requisito especificado.
  • Rastreáveis: estão representados as origens e associações entre os requisitos

Analisar o problema

Critérios para validação e aceitação de requisitos incluem:

  • Claros: os requisitos devem estar escritos de maneira clara, qualquer integrante da equipe deve ser capaz de entender o requisito.
  • Completos: nenhum detalhe importante deve ser omitido, tais como dados de entrada e saída, regras de validação ou interação do usuário com o sistema.
  • Consistentes: um requisito não pode contradizer um outro requisito.
  • Únicos: evitar duplicidade de requisitos.
  • Viáveis: alguns requisitos de sistema não são requisitos de software, portanto não são implementáveis.
  • Testáveis: requisitos possíveis de serem testados quando implementados
  • Rastreáveis: requisitos que derivam de algum outro requisito ou darão origem a outros requisitos.
  • Claros: os requisitos devem estar escritos de maneira clara, qualquer integrante da equipe deve ser capaz de entender o requisito.
  • Completos: nenhum detalhe importante deve ser omitido, tais como dados de entrada e saída, regras de validação ou interação do usuário com o sistema.
  • Consistentes: um requisito não pode contradizer um outro requisito.
  • Únicos: evitar duplicidade de requisitos.
  • Viáveis: alguns requisitos de sistema não são requisitos de software, portanto não são implementáveis.
  • Testáveis: requisitos possíveis de serem testados quando implementados
  • Rastreáveis: requisitos que derivam de algum outro requisito ou darão origem a outros requisitos.

Template de ESPECIFICAÇÃO DE CASO DE USO

REF005 – Descrição do Caso de Uso

Nome do Caso de Uso: Cadastrar cliente

Descrição do Caso de Uso: Ao selecionar a opção adicionar cliente, o sistema deverá solicitar ao usuário a entrada dos dados obrigatórios nome e CPF do mesmo. Após o usuário preencher os dados solicitados e confirmar a operação de …..

Atores e casos de uso

Apresentamos abaixo, o diagrama de caso de uso relacionado.

INSERIR O DIAGRAMA DE CASOS DE USO RELACIONADO

Fluxo Básico

Descrição: Preenchimento de todos os dados corretamente com valor de depósito em conta corrente superior a R$5,00.

Inserir Diagrama UML de Atividades

Fluxo alternativo

Descrição: Depósito com valor menor que R$50,00.

Inserir Diagrama UML de Atividades

Regras de negócio

• Para uma pessoa ser cliente do banco é necessário que a mesma possua pelo menos uma conta corrente.

• Para o cadastramento de novo cliente, o sistema deverá exigir o cadastramento de conta corrente, logo após o fornecimento dos dados do novo cliente.

• Nenhuma conta corrente pode ser cadastrada através de depósito menor que R$5,00.

Pré condições

Não se aplica.

Pós condições

• Cliente cadastrado no sistema com pelo menos uma conta corrente cadastrada com depósito realizado superior a R$5,00.

 

Veja exemplo completo a partir de estudo de Caso no Livro:

ES na prática

 




+ Artigos