Um requisito é definido como "uma condição ou um recurso com o qual um sistema deve estar de acordo".

Existem vários tipos de requisitos. Uma maneira de categorizá-los é descrito como o modelo FURPS+ [GRA92], utilizando o acrônimo FURPS para descrever as principais categorias de requisitos com subcategorias, conforme mostrado a seguir.

O "+" em FURPS+ é para lembrá-lo de incluir requisitos como:

(Consulte também [IEEE Std 610.12.1990].)

Os requisitos funcionais especificam ações que um sistema deve ser capaz de executar, sem levar em consideração as restrições físicas. Eles são melhores descritos em um modelo de casos de uso e em casos de uso. Os requisitos funcionais especificam, portanto, o comportamento de entrada e saída de um sistema.

Os requisitos que não são funcionais, como os listados a seguir, às vezes são chamados de requisitos não funcionais. Vários requisitos não são funcionais e descrevem apenas atributos do sistema ou atributos do ambiente do sistema. Embora alguns deles possam ser capturados em casos de uso, aqueles que não puderem talvez estejam especificados em Especificações Suplementares. Os requisitos não funcionais são aqueles que dizem respeito a questões como as descritas abaixo.

Uma definição completa dos requisitos de software, dos casos de uso e das Especificações Suplementares pode ser empacotada junto para definir uma SRS (Especificação de Requisitos de Software) para um determinado "recurso" ou outro agrupamento de subsistemas.

Funcionalidade Para o início da página

Os requisitos funcionais podem incluir:

  • conjuntos de recursos
  • recursos
  • segurança

Utilização Para o início da página

Os requisitos de usabilidade podem incluir subcategorias como:

  • fatores humanos (consulte Conceitos: Design Centralizado no Usuário)
  • estética
  • consistência na interface com o usuário
  • ajuda on-line e sensível ao contexto
  • assistentes e agentes
  • documentação do usuário
  • materiais de treinamento

Confiabilidade Para o início da página

Os requisitos de confiabilidade a serem considerados são:

  • freqüência e gravidade de falha
  • possibilidade de recuperação
  • possibilidade de previsão
  • precisão
  • tempo médio entre falhas (MTBF)

Desempenho Para o início da página

Um requisito de desempenho impõe condições aos requisitos funcionais. Por exemplo, para uma determinada ação, ele pode especificar parâmetros de desempenho para:

  • velocidade
  • eficiência
  • disponibilidade
  • precisão
  • produtividade
  • tempo de resposta
  • tempo de recuperação
  • uso de recurso

Suportabilidade Para o início da página

Os requisitos de suporte podem incluir:

  • possibilidade de teste
  • extensibilidade
  • possibilidade de adaptação
  • possibilidade de manutenção
  • compatibilidade
  • possibilidade de configuração
  • possibilidade de serviço
  • possibilidade de instalação
  • possibilidade de localização (internacionalização)

Requisito de Design Para o início da página

Um requisito de design, freqüentemente chamado de uma restrição de design, especifica ou restringe o design de um sistema.

Requisito de Implementação Para o início da página

Um requisito de implementação especifica ou restringe o código ou a construção de um sistema. Como exemplos, podemos citar:

  • padrões obrigatórios
  • linguagens de implementação
  • políticas para integridade de banco de dados
  • limites de recursos
  • ambientes de operação

Requisito de Interface Para o início da página

Um requisito de interface especifica:

  • um item externo com o qual o sistema deve interagir
  • restrições de formatos, tempos ou outros fatores utilizados por tal interação

Requisito Físico Para o início da página

Um requisito físico especifica uma característica física que um sistema deve possuir, por exemplo:

  • material
  • forma
  • tamanho
  • peso

Esse tipo de requisito pode ser utilizado para representar requisitos de hardware, como as configurações físicas de rede obrigatórias.

Informações Adicionais

Informações adicionais sobre este tópico podem ser encontradas em:



Rational Unified Process   2003.06.15