Modelagem de Sistemas de Informação 05

Modelagem de Sistemas de Informação

Aula 05 – 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.


• 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.


• 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.


• 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.


• 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


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.


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.


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.


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.

Technology

Modelagem de Sistemas de Informação 05