Este artigo é baseado no padrão IEEE Std 830-1998 (IEEE Recommended Practice for Software Requirements Specifications).

Esta prática recomendada tem como objetivo a especificação de requisitos de software a ser desenvolvido, mas também pode ser usada na escolha de produtos comerciais de software. No entanto, a sua aplicação a software já
desenvolvido pode ser contra-producente.

Quando o software está embebido em sistemas de grande escala, como sejam equipamentos médicos, então tudo o que está fora do âmbito deste documento deve ser visto em particular.

Esta recomendação prática descreve o processo da criação de um produto e o conteúdo desse mesmo produto. O produto é um Documento de Requisitos de Software (DRS). Estas recomendações práticas podem ser usadas para criar um DRS ou podem ser usadas como modelo para um padrão mais específico.

Esta recomendação prática não identifica nenhum método, nomenclatura ou ferramenta específica para a preparação de um DRS.

 

1. Natureza do DRS

O DRS é uma especificação particular de um software, produto, programa ou conjunto de programas que executam certas funções num ambiente específico. O DRS pode ser escrito por um ou mais representantes do fornecedor, um ou mais representantes do cliente, ou por ambos.

Quem escreve um documento de EES deve sempre ter em conta os seguintes pontos base:

1. Funcionalidade. O que deve fazer o software?
2. Interfaces externas. Como interage o software com as pessoas, com o hardware do sistema, com outro hardware, e com outro software?
3. Performance. Qual é a velocidade, disponibilidade, tempo de resposta, tempo de recuperação das várias funções do software, etc.?
4. Atributos. Quais as considerações relativas à portabilidade, correcção, mantenabilidade, segurança, etc.?
5. Restrições de desenho impostas numa implementação. Existem exigências padrão, linguagem de implementação, políticas para integridade da base de dados, limites de recursos, ambientes operacionais, etc.?

Quem escreve deve evitar introduzir exigências de desenho ou de projeto no DRS.

 

2. Características de um bom DRS

Um DRS deve ser:

1. Correto. Um DRS está correto se, e só se, todas as exigências expressas nele serão correspondidas pelo software.
2. Não ambíguo. Um DRS é não ambíguo se, e só se, todas as exigências expressas nele têm apenas uma única interpretação. Como mínimo, isto requer que cada característica do produto final seja descrita usando termos simples e únicos.
3. Completo. Um DRS é considerado completo se, e só se, inclui os seguintes elementos: Todas as exigências significantes, quer se prendam com a funcionalidade, o desempenho, restrições de desenho,
   atributos, ou interfaces externas (em particular, quaisquer exigências externas impostas por especificações de sistemas) estão reconhecidas e tratadas. Estão definidas as respostas do software a todas as classes realizáveis de entradas de dados em todas as classes de situações. Legendas e referências completas para todas as figuras, tabelas e diagramas do documento de EES bem como a definição de todos os termos e unidades de medida.
4. Consistente. Consistência refere-se à consistência interna. Se um DRS não está de acordo com um documento de mais alto nível, tal como seja uma especificação de exigências de sistema, então ele não está correto.
5. Classificável por importância e/ou estabilidade. Um DRS encontra-se classificado por importância e/ou estabilidade se cada exigência nele contido tem associada um identificador de estabilidade e/ou importância.
6. Verificável. Um DRS diz-se verificável se, e só se, cada exigência especificada é verificável. Uma exigência é verificável se, e só se, existe um processo finito e de custo aceitável através do qual uma pessoa ou uma máquina pode verificar que o produto de software cumpre essa exigência. Em geral uma exigência ambígua não é verificável.
7. Modificável. Um DRS diz-se modificável se, e só se, a sua estrutura e estilo são tais que mudanças a exigências podem ser efetuadas de forma fácil, completa e consistente, preservando simultaneamente estrutura e estilo.
8. Rastreável. Um DRS diz-se rastreável se cada uma das suas exigências é clara e facilitadora da identificação da mesma exigência em versões futuras do desenvolvimento ou da documentação.

 

3. Modelo de estrutura de um DRS

O modelo apresentado aqui apenas sugere uma estrutura, entretanto não é obrigatório usar os mesmos nomes dos seus componentes.

1. Introdução
   1. Propósito
   2. Âmbito
   3. Definições, acrónimos e abreviaturas
   4. Referências
   5. Organização
2. Descrição geral
   1. Perspectiva do produto
   2. Funcionalidades do produto
   3. Características do usuário
   4. Restrições
   5. Assunções e dependências
3. Requisitos específicos
   1. Requisitos de Interface Externos
      1. Interfaces de Usuário
      2. Interfaces de Hardware
      3. Interfaces de Software
         1. Interfaces de Comunicação
   2. Características de sistema
      1. Característica de sistema 1
         1. Introdução/Objectivo da característica
         2. Estímulo/Sequência de resposta
         1. Requisitos Funcionais Associados
            1. Requisito Funcional 1
            2. Requisito Funcional n
      2. Característica de sistema 2
      3. Característica de sistema m
   3. Requisitos de Performance
   4. Restrições de Desenho
   5. Atributos do Sistema de Software
   6. Outros Requisitos
4. Tabela de conteúdos
5. Apêndices
6. Índice remissivo