O documento de requisitos de software, também conhecido como requisitos de especificação de software, é uma especificação que serve como norte para que os desenvolvedores do sistema implementem corretamente. SOMMERVILLE (2011) afirma que se faz necessário incluir tanto os requisitos de quem vai utilizar o sistema, como uma especificação dos requisitos do sistema. Às vezes, os requisitos do usuário e do sistema são correlacionados e uma única descrição. Em outros casos, os requisitos do usuário são definidos numa introdução à especificação de requisitos do sistema. Se houver um grande número de requisitos, os requisitos detalhados do sistema podem ser um documento diferente.
Os documentos de requisitos são essenciais quando é contratado desenvolvimento externo. No entanto, os métodos de desenvolvimento ágeis caem no risco de se alterarem tão rapidamente que um documento de requisitos está desatualizado assim que ele é escrito, de modo que o trabalho é profundamente inutilizado. (BATISTA, 2003), (PRESSMAN, 2002).
Para SOMMERVILLE (2011) sistemas onde os requisitos são inconstantes, a abordagem de documento de requisito é um bom negócio. No entanto, autor pensa que
ainda é útil escrever um breve documento de apoio que defina os requisitos de negócios e de confiabilidade para o sistema.
O documento de requisitos tem um conjunto diversificado de usuários, que vão desde gerenciamento da organização que está pagando pelo sistema, aos engenheiros responsáveis pelo desenvolvimento do software. A Figura 04, tirada do livro com Gerald Kotonya sobre engenharia de requisitos (KOTONYA e SOMMERVILLE, 1998) mostra possíveis usuários do documento de requisitos.
Figura 04 – Usuários de um documento de requisitos. Fonte: (SOMMERVILLE, 2011).
Editada pelo autor
Pela diversidade de usuários, o documento de requisitos tem que ser um compromisso de transparência entre a comunicação dos requisitos aos clientes, afirmam BEZERRA, (2015) e SOMMERVILLE (2011), a definição dos requisitos detalhados para os desenvolvedores e testadores, sem ficarem de fora as informações sobre as possíveis
evoluções do sistema. As informações sobre alterações antecipadas podem evitam decisões de design e ajudam os engenheiros de manutenção do sistema que têm que adaptar o sistema as novas exigências.
Como relata CERA, (2012) e SOMMERVILLE (2011), o nível de detalhamento que se deve incluir em um documento de requisitos, depende do tipo de sistema que está sendo desenvolvido e o processo de desenvolvimento utilizado. Sistemas crítico devem ter requisitos bem detalhados, dado que a segurança deve ser bem analisada. Quando o sistema tem que ser desenvolvido através de terceirização, as especificações do sistema precisam ser detalhadas e precisas para mitigar possíveis más interpretações. Se for utilizado um processo de desenvolvimento iterativo, o documento de requisitos pode ser menos detalhado e quaisquer dúvidas podem ser resolvidas durante o desenvolvimento do sistema.
O Quadro 02 mostra uma possível organização de um documento baseado em um padrão IEEE para documentos de requisitos (IEEE, 1998). Esta norma é genérica que pode ser ajustada de acordo com cada especificidade.
Quadro 02 – Estrutura de um documento de requisitos.
Capítulo Descrição
Prefácio Definir o público esperado do documento e descrever as versões, incluindo uma justificativa para a criação de uma versão e resumo das alterações feitas em cada versão.
Introdução Descrever a necessidade do sistema. Descrever detalhadamente as funções do sistema e explicar como ele funcionará com outros sistemas. Também, descrever como o sistema se encaixa no negócio global ou estratégico da organização.
Glossário Definir os termos usados no documento. Não fazer suposições sobre experiências ou conhecimentos.
Definição dos requisitos do usuário
Descrever os serviços fornecidos para o usuário. Os requisitos não funcionais do sistema também devem ser descritos nesta seção. Nessa descrição pode usar linguagem natural, diagramas ou outras notações que sejam compreensíveis para os clientes. Padrões de produtos e processos que devem ser especificados.
Arquitetura do sistema
Este capítulo deve apresentar uma visão geral de alto nível do sistema, mostrando a distribuição de funções entre os módulos do sistema. Os componentes de arquitetura que são reutilizados devem ser destacados.
Especificação dos requisitos do sistema
Descrever os requisitos funcionais e não-funcionais. Se necessário, pode incluir mais detalhes nos requisitos não-funcionais.
Modelos de sistemas
Incluir modelos gráficos mostrando os componentes do sistema, modelos de objetos, fluxos de dados ou modelos de dados semânticos.
Evolução do
sistema
Descrever as hipóteses fundamentais sobre o sistema e quaisquer alterações previstas, alterando-se a necessidades do usuário e assim por diante. Esta seção é útil para ajudar os projetistas de sistemas a evitar decisões de projeto que restringiriam as prováveis mudanças futuras.
Apêndice Fornecer informações detalhadas e específicas relacionadas com a aplicação em desenvolvimento; Por exemplo, descrições de hardware e banco de dados. Os requisitos de hardware definem as configurações mínimas do sistema. Os requisitos de banco de dados definem a organização lógica dos dados pelo sistema e as relações entre os dados.
Índice Vários índices para o documento podem ser incluídos. Para além de um
Índice alfabético, pode haver um índice de diagramas, um índice de funções, e assim por diante.
Fonte: Padrão IEEE para documentos de requisitos (IEEE, 1998).
SOMMERVILLE (2011), chama a atenção para os problemas com o uso de linguagem natural para a especificação de requisitos. Ele ressalta que esse nível de linguagem deixa margem para possíveis interpretações equivocadas, e uma única sentença pode haver várias exigências.