O Documento de Requisitos de Software

Em alguns casos, os requisitos de usuário e de sistema são integrados em uma única descrição. Em outros, os requisitos de usuário são definidos com uma introdução à especificação de requisitos de sistema. Se houver um grande número de requisitos, os requisitos detalhados de sistema podem ser apresentados em um documento separado. SOMMERVILLE, pág. 63

Há um grande número de usuário deste documento, desde clientes passando por desenvolvedores e testadores, até engenheiros de manutenção do sistema. Sendo assim, o compromisso deste documento é maior.

O número detalhamento depende do tipo de sistema que será desenvolvido e do processo que será usado. Por exemplo, para os métodos ágeis, os requisitos mudam tão rapidamente que, quando o documento chega a ser concluído, já está ultrapassado, então, esses processos de desenvolvimento escrevem um pequeno documento de apoio, sem um grande número de detalhes.

O documento de requisitos não deve conter detalhes da arquitetura ou projeto do sistema, pois não devem se preocupar com a forma como o sistema deve ser projetado ou implementado. No entanto, apesar de não entrar em um requisito, um projeto inicial as vezes é importante para ajudar a estruturar as especificações de requisitos e, até mesmo em alguns casos, restrições do projeto na interoperação entre sistemas geram novos requisitos.

Crie um formato padrão para todo os requisitos
Use idioma consistentes.
Use “deve” para obrigação e “deveria” ou “pode” para recomendações.
Use termos característicos do problema e não jargões da computação.
Organize os requisitos logicamente
Use sentenças diretas, objetivas (evite vocabulário vago) e com vocabulário limitado (evite com, e, também, ou)
Evite ambiguidade

Notações para Escrever os Requisitos

Sentenças em Linguagem Natural

Os requisitos são escritos em frases numeradas em linguagem natural. Para esse tipo de notação, há muito grandes riscos de mal-entendidos, por isso, para minimizar tal situação, invente um formato-padrão e garanta que as definições sigam ele, use linguagem consistente para distinguir requisitos obrigatórios (‘deve’) de requisitos desejáveis (‘pode’), não use linguagem técnica da engenharia de software e descreva uma justificativa para a existência do requisito que auxilie nas futuras alterações.

Linguagem Natural Estruturada

Os requisitos são escritos em uma linguagem natural em um formulário padrão ou template, onde cada campo fornece informação sobre um aspecto do requisito, como por exemplo, descrição da função, descrição das entradas, descrição das saídas,informação sobre a ação a ser tomada, pré-condições e pós-condições, e até mesmo efeitos colaterais.

Linguagem de Descrição de Projeto

Uso de uma espécie de linguagem de programação, porém com características mais abstratas para especificar os requisitos. É uma notação pouco utilizada atualmente.

Notações Gráficas

Uso de modelos gráficos, suplementados por anotações de texto. Nesse tipo de notação, diagramas UML são comumente usados.

Especificações Matemáticas

Uso de conceitos matemáticos, como máquinas de estado finito ou conjuntos. Apesar de reduzir as possibilidades de ambiguidade, a maioria dos clientes não compreende essa notação.

Gestão das Mudanças

As seguintes atividades são parte da gestão de mudanças:

Avaliar o impacto nos requisitos
Validar com o cliente
Notificar os envolvidos
Atualizar as especificações de requisitos
Garantir a rastreabilidade nos requisitos.

Processo

Solicitação de mudanças

Um cliente solicita a mudança de alguma funcionalidade do sistema.

Análise de Impacto

Análise da mudança onde é identificado o seu impacto em todo o projeto em termos de recursos e tempo.

Segue algumas perguntas que podem ser feitas nessa etapa:

Qual o impacto sobre o hardware?
Qual o impacto sobre o desempenho?
Como a mudança modificará a percepção que o cliente tem sobre o software?
A mudança afetará a qualidade e confiabilidade do software?
Quantos requisitos foram recusados até o momento?
É o momento certo de fazer a alteração?
A alteração contraria as expectativas do cliente e da empresa desenvolvedora?

Preparação da Proposta de Modificação

Um documento contendo toda a análise e descrição da mudança é criado.

Avaliação da Proposta

A proposta de mudança é avaliada pela equipe através do documento de proposta.

Aprovação?

Se não aprovada, a proposta é arquivada para fins de documentação. Caso seja aprovada, então, ela será implementada e incorporada ao projeto.

Gerência de Configurações

Cada mudança realizada gera um nova versão dos artefatos do processo. Quando um artefato é modificado para acomodar alguma alteração, isso é gerência através de uma nova versão desse artefato que é gerada. Várias versões de um artefato podem estar relacionadas a várias versões de um requisito simultaneamente.

Rastreabilidade de Requisitos

É uma atividade importante em termos de requisitos, pois um simples requisitos pode estar sendo referenciado em n artefatos e alterá-lo obriga que todos esses artefatos sejam alterados também. Porém, sabe em quais artefatos um requisito está sendo referencia exige um rastreamento ou um controle de suas referências.

Segue abaixo um rastreamento que pode acontecer em uma simples tabela: