Análise de Sistemas Orientada a Objetos

Aula 03 – Documentação de Requisitos

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 registraradequadamente o documento de requisitos.

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.

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.

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.

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.

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 comunicaradequadamente o conjunto de requisitos do sistema a ser construído.

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.

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.

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

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.

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.

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.

Engenharia de Requisitos – Documentação3. 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.

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.