Documento de Requisitos

1. Introdução

É o principal produto da Engenharia de Requisitos, é uma declaração oficial do que será desenvolvido para o sistema.

Inclui os requisitos de usuário para o sistema e uma especificação detalhada dos requisitos de sistema.

É utilizado por:

• Clientes: analisam se o documento está de acordo com suas necessidades e solicitam mudanças;

• Gerentes: utilizam o documento para planejar o processo de desenvolvimento do projeto;

• Engenheiros: utilizam para entender melhor o sistema/problema que estão trabalhando, criar cenários de teste e gerenciar a manutenção do sistema;

• Desenvolvedores: consultam o documento como base para o seu trabalho.

Pode ser dividido em dois ou mais documentos que possuem visões diferentes (mais difícil de rastrear).

Normalmente, requisitos são documentados usando alguma combinação de linguagem natural,  modelos,  tabelas  e  outros artefatos técnicos, tais como: Matriz de Rastreabilidade, Diagrama de Casos de Uso, Descrições de Casos de Uso.

2. Modelo de Documento de Especificação de Requisitos da Disciplina

1. Introdução: breve introdução ao documento, descrevendo seu propósito e estrutura. 

2. Descrição do Propósito do Sistema: descreve o propósito geral do sistema (objetivo). 

3. Descrição  do Cenário:  apresenta,  em  um  texto  corrido,  uma  visão  geral  do domínio, do problema a ser resolvido e dos processos de negócio apoiados, bem como as principais ideias do cliente sobre o sistema a ser desenvolvido. 

4. Requisitos:  lista as regras de negócio, os requisitos funcionais e os requisitos não funcionais, com suas prioridades e dependências.

O Documento de Requisitos completo é recomendado para sistemas com requisitos mais estáveis, sendo importante investir em especificações de requisitos mais detalhadas. 

• • Tais especificações podem ser também requisitadas por certas empresas, que preferem contratar o desenvolvimento de um sistema apenas após conhecer todos os seus requisitos. 

  • Padrão ISO/IEC/IEEE  (29148-2018;830-1998) - Pode ser requisitado por organizações de certificação, principalmente no caso de sistemas que lidam com vidas humanas, como sistemas das áreas médica, de transporte ou militar. 

Quando os requisitos mudam frequentemente e o sistema não é de missão crítica, não vale a pena investir muito tempo na elaboração de um Documento de Requisitos detalhado. Corre-se o risco de quando ele ficar pronto, os requisitos já estarem obsoletos — ou um concorrente já ter construído um sistema equivalente e dominado o mercado.

3. Recomendações de Escrita

A  linguagem  natural  é  quase  sempre imprescindível, uma vez que é  a forma básica de comunicação  compreensível por todos os interessados.  

Contudo,  ela  geralmente  abre  espaços  para  ambiguidades  e  má  interpretação. É  interessante  procurar  estruturar  o  uso  da  linguagem  natural  e complementar  a descrição dos requisitos com outros elementos como modelos.

• O  sistema  deve/não deve  <verbo  indicando  ação,  seguido  de  complemento>:  use  o  verbo dever para designar uma função ou característica requerida para o sistema, ou seja, para  descrever  um  requisito  obrigatório.  

Exemplos:  O  sistema  deve  efetuar  o controle dos clientes da empresa. O sistema deve processar um pedido do cliente em um tempo inferior a cinco segundos, contado a partir da entrada de dados. 

• O sistema pode/não pode  <verbo  indicando ação, seguido de complemento>: use  o verbo poder para designar uma função ou característica desejável para o sistema, ou seja, para  descrever  um  requisito  desejável,  mas  não  essencial.  

Exemplos:  O  sistema pode  notificar  usuários  em  débito.  O  sistema  pode  sugerir  outros  produtos  para compra, com base em produtos colocados no carrinho de compras do usuário.

Orientações gerais para a escrita de requisitos:

• Escreva frases completas, com a gramática, ortografia e pontuação correta. 

• Procure manter frases e parágrafos curtos e diretos. 

• Use um glossário de termos se necessário. 

• Prefira a voz ativa (o sistema deve fazer alguma coisa) à voz passiva (alguma coisa deve ser feita). 

• Sempre que possível, identifique o tipo de usuário atrelado ao requisito. 

• Evite termos vagos, que conduzam a requisitos ambíguos e não testáveis, tais como “rápido”, “adequado”, “fácil de usar” etc. 

• Escreva requisitos individualmente testáveis.

Nível de Detalhamento dos Requisitos:

O nível de detalhamento da documentação de um requisito deve estar adequado ao projeto.

4. Matriz de Rastreabilidade

Chama-se de rastreabilidade (traceability) a capacidade de dado um trecho de código identificar os requisitos implementados por ele e vice-versa (isto é, dado um requisito, identificar os trechos de código que o implementam). 

Segundo o Guia PMBOK®, a matriz de rastreabilidade dos requisitos associa os requisitos às suas origens e os rastreia durante todo o ciclo de vida do projeto.

Seu uso ajuda a garantir que cada requisito adiciona valor de negócio através da sua ligação aos objetivos de negócio e aos objetivos do projeto, além de fornecer um meio de rastreamento do início ao fim do ciclo de vida do projeto, ajudando a garantir que os requisitos aprovados na documentação sejam entregues no final do projeto. Finalmente, fornece uma estrutura de gerenciamento das mudanças do escopo do produto.

Outros exemplos de tabela de rastreamento: fonte dos requisitos, dependências dos requisitos, interfaces do sistema.

5. Priorização de Requisitos

A priorização tem como função assegurar que os recursos do projeto sejam focados nos itens mais relevantes. Daí a importância de, na especificação, diferenciar cada requisito em termos de importância, dentre dezenas ou centenas de outros requisitos.

A responsabilidade por definir a prioridade do requisito deveria ser da parte interessada, facilitada pelo gerente de projetos. O analista de requisitos participa da discussão de priorização para ajudar no processo, mostrando eventuais impactos das decisões e esclarecendo melhor cada requisito, se necessário.

A grande dificuldade é ter as partes interessadas assumindo a responsabilidade da priorização. Muitos se omitem nessa questão, o que implica em delegar a terceiros (em geral, a equipe de desenvolvimento) a prioridade que será dada a cada requisito.

Outros não se omitem e deixam explícito que tudo é prioridade. Mas, na prática, isso não é priorizar.

A priorização é fundamental para a determinação da ordem de implementação dos requisitos.

Para esta disciplina, vamos utilizar a priorização de requisitos em 3 níveis, segundo a nomenclatura do Modelo de Documento de Requisitos da Disciplina, a saber:

• Alta: requisitos obrigatórios que não podem faltar na primeira versão do sistema

• Média: outros requisitos obrigatórios que não podem faltar no sistema e requisitos desejados para o sistema

• Baixa: requisitos desejados que podem ser implementados após avaliação futura caso não causem transtornos no processo de desenvolvimento