modelo de requisito de software

Modelo para Documento de
Especificação de Requisitos de Software
Prof. Dr. Juliano Lopes de Oliveira
(Baseado na norma IEEE Std 830-1993 - Recommended Practice for Software Requirements Specifications)

A boa organização lógica do documento e a sua redação correta são condições essenciais para que ele se torne útil na prática. Algumas recomendações neste sentido, antes de examinarmos o conteúdo da especificação de requisitos:
•

•

Os pontos básicos que devem ser definidos no documento são: funcionalidade, interfaces externas, restrições, critérios de qualidade e de desempenho. O documento deve definir quais funções são executadas sobre que dados para produzir quais resultados em qual local e para quem.
◊

Toda a equipe de desenvolvimento (usuários, técnicos e gerentes) deve participar da elaboração do documento, que deve definir corretamente todos os requisitos do software, mas sem descrever detalhes de projeto ou de implementação (a menos que seja realmente uma restrição a ser considerada). O documento descreve as necessidades do produto de software, e não o processo de produção.

◊

Gráficos e diagramas podem ajudar bastante na especificação. Porém, não se trata de um documento de projeto: não se faz particionamento de módulos internos, escolha de estruturas de dados, e outras atividades de projeto.
Tampouco se faz atividades de planejamento de software, tais como cálculo de custos, cronograma de entrega, critérios de validação, etc.

É preciso garantir que o documento define estes pontos de maneira correta, não ambígua, completa, consistente, classificada de acordo com a importância dos requisitos, verificável, modificável e rastreável.
◊

Um requisito correto é um requisito que o software deve atender. Um requisito não ambíguo permite somente uma interpretação.

◊

Uma especificação de requisitos é completa se contém todos os requisitos importantes, definindo todas as definições de respostas do software para todas as