O documento discute a importância da documentação de requisitos para engenheiros de software. Um bom documento de requisitos deve capturar claramente as necessidades dos usuários, o escopo do projeto e quais funcionalidades serão ou não implementadas para garantir que toda a equipe esteja alinhada.

1. Modelagem de Sistemas de
Informação
Aula 05 – Documentação de Requisitos

2. Engenharia de Requisitos – Documentação
• Um engenheiro de software é um profissional que deve ter a habilidade de antecipar e
gerenciar mudanças de requisitos de um produto de software.
• Ele precisa saber se expressar e comunicar-se bem a fim de capturar e registrar
adequadamente o documento de requisitos.

3. Engenharia de Requisitos – Documentação
• O engenheiro de software, desempenhando o papel de engenheiro de
requisitos, deve executar duas atividades essenciais para a elaboração do
documento de requisitos:
• Elicitação de requisitos – atividade na qual os requisitos do sistema a ser
desenvolvido são levantados;
• Análise de requisitos – atividade na qual os requisitos são analisados e confirmados
pelos principais interessados do projeto (isto é, os stakeholders) que incluem
cliente, usuário final e gerente de projetos, dentre outros.

4. Engenharia de Requisitos – Documentação
• O engenheiro de software está preocupado em levantar, entender, analisar e, por fim,
documentar os requisitos.
• Para tanto, ele deve concentrar-se nas características do sistema e atributos de
qualidade, e não em como obtê-los.
• É preciso identificar quais requisitos fazem parte ou não do escopo do sistema a ser
desenvolvido, ou em outras palavras, entender a interface do sistema considerado e o
ambiente externo.

5. Engenharia de Requisitos – Documentação
• O documento de requisitos delimita o escopo do conjunto de funcionalidades que um
sistema deve prover
• Descreve os atributos de qualidade que devem ser suportados.
• Este documento deve ser elaborado de maneira precisa, completa, consistente e,
principalmente, compreensível aos stakeholders (isto é, os principais interessados no
sistema).
• O documento de requisitos será lido por várias pessoas interessadas no projeto como,
por exemplo, cliente, gerente de projeto, engenheiro de testes e programadores, e,
portanto, precisa comunicar com clareza os requisitos do sistema.

6. Engenharia de Requisitos – Documentação
• O documento de requisitos de um projeto tem o objetivo de documentar o escopo do
sistema a ser desenvolvido. Nesse sentido, o documento de requisitos deve conter:
• Introdução e visão geral do documento
• Descrição de requisitos funcionais
• Descrição de requisitos não-funcionais
• Escopo não contemplado (de funcionalidades)
• Documentação de apoio

7. Engenharia de Requisitos – Documentação
A seguir, itens considerados imprescindíveis em um documento de requisitos:
• A relação de itens mencionados não pressupõe a intenção de ser completo, mas de
apontar os itens considerados como obrigatórios num documento de requisitos.
• Cabe destacar que os itens sugeridos para compor um documento de requisitos,
conforme nas próximas páginas, leva em consideração as recomendações de
documento padrão IEEE-Std 830-1998 recomendado pelo IEEE.

8. Engenharia de Requisitos – Documentação
1. Introdução Contém uma descrição dos objetivos do documento, o
público ao qual ele se destina e, em linhas gerais, o
propósito e escopo do projeto a ser desenvolvido. Pode
adicionalmente conter termos e abreviações usadas, tipos
de prioridades atribuídas aos requisitos, além de informar
como o documento deve evoluir.

9. Engenharia de Requisitos – Documentação
2. Requisitos Funcionais Esta seção descreve, de maneira sumarizada, as principais
funcionalidades que o sistema de software irá realizar. Por
exemplo, num sistema de biblioteca, esta seção deveria
conter uma descrição das funcionalidades de autenticação
de usuário e controle de acesso. Observe que o sumário
das funcionalidades de um sistema se faz necessário para
permitir o entendimento das funcionalidades do sistema
pelos diversos stakeholders. O engenheiro de software
deve organizar o conjunto de funcionalidades do sistema
de modo a torná-las mais compreensíveis aos clientes e
demais stakeholders. Vale ainda ressaltar que o
documento de requisitos pode ser complementado por
outro documento como, por exemplo, especificações de
casos de uso.

10. Engenharia de Requisitos – Documentação
3. Requisitos Não-Funcionais Apresenta-se uma descrição geral de outros
requisitos do produto que limitam opções de
desenvolvimento do sistema. Isto inclui a
descrição de requisitos de segurança,
confiabilidade, timeout de sessão de usuário,
usabilidade, dentre outros. Esta seção
considera os requisitos do produto, do
processo, da interface gráfica e da plataforma
tecnológica empregada.
4. Escopo Não-Contemplado Contém descrição das funcionalidades não
contempladas no escopo do sistema a ser
desenvolvido. Outra denominação dada a
esta seção é escopo negativo. Isto visa
garantir às partes interessadas no sistema
(isto é, cliente e equipe de desenvolvimento)
quais funcionalidades fazem parte ou não do
conjunto a ser implementado.

11. Engenharia de Requisitos – Documentação
5. Documentação Complementar Exemplos desses documentos compreendem atas
de reuniões nas quais ocorrerão levantamento e
validação de requisitos, bem como o plano de
projeto.
6. Apêndice Trata-se de uma seção que pode conter, por
exemplo, levantamento de perfil de usuários do
sistema a ser desenvolvido e descrição do
problema a ser automatizado pelo sistema de
software. É importante observar que o apêndice
não é parte do documento de requisitos e serve
apenas como informação de apoio para os leitores
do documento.