Documento De Especificação De Requisitos

Documento de Especificação de Requisitos

Apesar da existência dos 3 tipos de especificação vistos nos itens anteriores, existe uma especificação que é a usada como declaração oficial dos requisitos do sistema.

Este documento, normalmente chamado de Documento de Especificação de Requisitos (Software Requirements Specification ou SRS) inclui uma combinação dos requisitos do utilizador e do sistema e tem diferentes utilidades para diferentes pessoas3 :

Clientes: confirmar a completude dos requisitos e propor alterações.

Gestores: orçamentar o sistema e planejar o processo de desenvolvimento.

Engenheiros: compreender o sistema a desenvolver.

Engenheiros (testes): desenvolver testes para validar o cumprimento dos requisitos.

Engenheiros (manutenção): compreender o sistema e a ligação entre as suas partes.

Existem diversos padrões para este documento, embora não se possa apontar nenhum como o "ideal". Uma estrutura proposta pelo IEEE que é talvez a mais usada é o IEEE/ANSI 830-19934 .

Validação

Nesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que o cliente pretende.

À semelhança do que sucede na análise dos requisitos, pretende-se encontrar problemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase lida com uma especificação completa dos requisitos.

A validação é especialmente importante em sistemas de grandes dimensões uma vez que erros encontrados demasiado tarde (durante o desenvolvimento ou já depois de o sistema estar a ser usado) no documento de requisitos têm repercussões proporcionais à dimensão do projeto. Uma vez que alterações em requisitos já consolidados têm um custo muito superior a alterações no código ou design, este tipo de erros traduz-se em elevados custos e necessidade de refazer muito do trabalho que se julgava já concluído.

Durante a fase de validação dos requisitos, devem ser verificados (através de checklists) os seguintes atributos dos requisitos:

Validade: a especificação resulta da análise dos requisitos identificados junto das diversas partes interessadas envolvidas. Como tal, requisitos identificados individualmente (isto é, junto de cada parte interessada) podem diferir da especificação final que se atinge após o cruzamento de informação e é necessário que cada cliente compreenda e aceite a especificação final obtida.

Consistência: não devem existir conflitos entre os requisitos identificados.

Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de forma inequívoca pelas partes interessadas.

Completude: todas as funcionalidades pretendidas devem fazer parte da especificação do sistema.

Realismo: dadas as restrições do projeto (tecnológicas, financeiras e temporais) o sistema especificado