Classificação de Requisitos

 

Classificação dos Requisitos

Os requisitos podem ser classificados de várias formas a a finalidade desta classificação é melhor compreender a relação entre objetos, tarefas e as próprias funções do sistema. Uma forma bastante aceitável entre analista é que a classificação seja entre requisitos funcionais e não-funcionais.

 

1. Requisitos funcionais

Os requisitos funcionais são aqueles que fazem parte do sistema, como um relatório específico, um campo a mais em um cadastro, declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações, etc. Eles normalmente têm a finalidade de agregar valor ao usuário ou facilitar o trabalho que ele desenvolve. Requisitos funcionais serão implementados no próprio sistema e da junção desses requisitos o corpo do sistema será montado.

1.1. Porque os requisitos devem ser completos e consistentes?

Completos =>  porque devem incluir descrições de todos os recursos requeridos.
Consistentes => Não deve haver conflitos ou contradições nas descrições dos recursos de sistema.

 

Na prática, é impossível produzir um documento de requisitos completo e consistente.

1.2. Exemplos de requisitos funcionais

• O usuário deve ser capaz de pesquisar em todo o conjunto inicial de banco de dados ou selecionar um subconjunto a partir dele.

• O sistema deve fornecer telas apropriadas para o usuário ler os documentos no repositório de documentos.

• O sistema deve ser capaz de armazenar todas as informações sobre seus clientes(RG, CPF, Nome, data de nascimento e endereço) no banco de dados.

• O sistema deverá atribuir um identificador único (código) para cada pedido de produtos.

• O sistema deverá cancelar automaticamente um orçamento que tenha sido feito há mais de 30 dias e não tenha sido transformado em venda.

1.3. Imprecisão de requisitos

• Problemas surgem quando os requisitos não são precisamente definidos. 

• Requisitos ambíguos podem ser interpretados de maneiras diferentes pelos desenvolvedores e usuários.

• Considere o termo ‘telas apropriadas’:

          Intenção do usuário – tela de propósito especial para cada tipo diferente de documento;
          Interpretação do desenvolvedor – fornece uma tela de texto que mostra o conteúdo do documento.

2. Requisitos não-funcionais

Requisitos não-funcionais são aqueles relacionados ao ambiente onde o sistema está inserido. Um servidor mais robusto, um firewall, ou um usuário especializado em determinado procedimento pode ser visto como requisitos não-funcionais.  Eles não devem ser ignorados por não fazerem parte diretamente do sistemas, mas devem ser considerados por compor o ambiente onde o software irá rodar. 

Os requisitos podem ser classificados também pelo seu tipo: 

• Requisitos de produto

          Requisitos que especificam que o produto entregue deve se comportar de uma maneira particular, por exemplo, velocidade de execução, confiabilidade, etc.

• Requisitos organizacionais

          Requisitos que são uma conseqüência de políticas e procedimentos da organização, por exemplo, padrões de processo usados, requisitos de implementação, etc.
 

• Requisitos externos

          Requisitos que surgem a partir de fatores externos ao sistema e seu processo de desenvolvimento, por exemplo, requisitos de interoperabilidade, requisitos legais, etc.
 

2.1. Tipos de requisitos não-funcionais

  

2.2. Exemplos de requisitos não-funcionais

  

3. Requisitos de domínio

Requisitos que vêm do domínio de aplicação do sistema e que refletem as características desse domínio.

• Derivados do domínio de aplicação e descrevem características de sistema que refletem o domínio.

• Podem restringir os requisitos funcionais existentes ou estabelecer como cálculos específicos devem ser realizados.

• Se os requisitos de domínio não forem satisfeitos, o sistema pode não funcionar.

3.1. Problemas de requisitos de domínio

• Facilidade de entendimento

• Requisitos são expressos na linguagem do domínio de aplicação;

• Isso não é, frequentemente, compreendido pelos engenheiros de software que estão desenvolvendo o sistema.

• Implícito

• Especialistas em domínio compreendem a area tão bem que não pensam em tornar os requisitos de domínio explícitos.