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
• Os principais problemas no desenvolvimento de um sistema de software decorrem:
• do entendimento errado entre engenheiro de software (produtor), responsável em
apresentar o documento de requisitos, e usuário (consumidor).
• Um documento de requisitos de software precisa ser claro, consistente e completo,
porque esse documento servirá de referência aos desenvolvedores, gerente de projeto,
engenheiros de software (responsáveis pelos testes e manutenção do sistema), além de
servir de base para definir o escopo das funcionalidades a serem registradas num
contrato.
• Os requisitos compreendem o cerne de qualquer produto e mudanças sobre eles
podem ocorrer ao longo do ciclo de vida de um software.
4. 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.
5. 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.
• Considera-se ainda que a elicitação de requisitos objetiva definir características do
sistema sob a perspectiva do cliente, enquanto que a análise de requisitos visa obter a
especificação de requisitos, do ponto de vista técnico, conforme entendimento dos
desenvolvedores.
6. 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.
7. Engenharia de Requisitos – Documentação
• É importante ressaltar a necessidade de definir o ‘limite’, ou também denominado
escopo do sistema, a fim de tratar os requisitos funcionais e não funcionais do sistema.
• Além disso, quando da elaboração do documento de requisitos, o engenheiro de
software deve levar em consideração os diferentes pontos de vistas
dos stakeholders de modo que o documento resultante possa comunicar
adequadamente o conjunto de requisitos do sistema a ser construído.
8. 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.
9. Engenharia de Requisitos – Documentação
• É elaborado pelo engenheiro de software e compreende o conjunto de requisitos do
sistema a ser desenvolvido;
• Deve ser analisado e confirmado pelos stakeholders;
• Integra e relaciona um conjunto de perspectivas dos interessados do projeto;
• Serve como mecanismo de comunicação para os stakeholders (i.e. as partes
interessadas do projeto);
• Captura e documenta os requisitos do projeto e serve de referência para testes,
manutenção e evolução do sistema.
10. 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
11. 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.
12. 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.
13. 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.
14. 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.
15. 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.
