Introdução à Engenharia de Requisitos Orlando da Silva Jr.

A Engenharia de Requisitos cria uma ponte para o design e a construção do software, ajudando o engenheiro de software a compreender o problema que será resolvido. É uma ação que começa durante a atividade de comunicação e continua até a atividade de modelagem. A Engenharia de Requisitos consiste em um conjunto de tarefas que colaboram na compreensão:

Do impacto do negócio sobre o software;

Do que o cliente quer; e

De como os usuários finais irão interagir com o software. A intenção da Engenharia de Requisitos é fornecer a todas as partes envolvidas uma compreensão escrita do problema, que pode ser alcançada por meio dos seguintesprodutos:

Cenários de usuário;

Listas de funções e atributos;

Modelos de análises; ou

Especificação. A Engenharia de Requisitos compreende as seguintes etapas:

1. Concepção:define o escopo e a natureza do problema; 2. Elicitação:ajuda o cliente a definir o que é requerido; 3. Elaboração: os requisitos básicos são redefinidos e modificados; 4. Negociação: quais são as prioridades? O que é essencial? Para quando é

requerido? 5. Especificação: o problema é especificado; e 6. Validação: garante que a compreensão do problema entre o engenheiro e o

cliente coincide.

1ª Etapa –Concepção

Concepção Elicitação Elaboração Negociação Especificação Validação

A maior parte dos projetos começa quando uma necessidade de negócio é identificada ou um potencial novo produto ou serviço é descoberto;

Nesta etapa, os engenheiros de software realizam uma série de perguntas na intenção de estabelecer uma compreensão básica do problema, das pessoas que querem a solução, da natureza da solução que é desejada e da eficácia da comunicação preliminar e da colaboração entre o cliente e o desenvolvedor.

2ª Etapa – Elicitação

Pergunta aos envolvidos quais são os objetivos do sistema, o que ele deve realizar, como o sistema se ajusta às necessidades do negócio e, finalmente, como o sistema será usado no dia-a-dia;

Problemas de escopo: os limites do sistema foram mal definidos ou os usuários/clientes especificaram detalhes técnicos desnecessários que confundem em vez de clarear os objetivos gerais do sistema;

Problemas de compreensão:os usuários/clientes não estão completamente certos daquilo que precisam, têm uma fraca compreensão das capacidades e limitações da computação, não têm uma completa compreensão do domínio do problema, têm problemas de comunicação com o engenheiro, omitiram informações que acreditam ser óbvias, especificam requisitos que entram em conflito com as necessidades dos usuários/cliente ou especificam requisito que são ambíguos ou não-testáveis;

Problemas de volatilidade:os requisitos mudam constantemente. 3ª Etapa – Elaboração

Expande e refine a informação recebida das etapas anteriores;

Foca-se no desenvolvimento de um modelo técnico de funções, atributos e restrições de software;

É uma ação da modelagem de análise que é composta por um número de tarefas de modelagem e refinamento;

É dirigida pela criação e refinamento dos cenários de usuário que descrevem como o usuário final irá interagir no sistema;

Produz classes e diagramas UML;

O resultado final é um modelo de análise que define o domínio informacional, funcional e comportamental do problema.

4ª – Negociação

Consiste na resolução de conflitos entre requisitos;

Os envolvidos ranqueiam os requisitos e discutem conflitos em prioridade;

Riscos associados com cada requisito são identificados e analisados;

“Chutes” de esforço de desenvolvimento são feitos e usados para avaliar o impacto de cada requisito no custo do projeto e no tempo de entrega.

5ª Etapa – Especificação

Consiste na elaboração de um documento que transmita de maneira comum a todos os envolvidos o que será desenvolvido;

É o produto final da engenharia de requisitos e serve como o fundamento das atividades de engenharia de software subsequentes.

Descreve a função e o desempenho do sistema e as restrições que governarão seu desenvolvimento.

6ª Etapa – Validação

Consiste na avaliação do produto produzido pela especificação;

Examina a especificação para garantir que nenhum requisito é ambíguio;

Examina ainda as inconsistências, omissões e erros, que devem ser corrigidos;

Verifica se a especificação está de acordo com os padrões estabelecidos para o processo, o projeto e o produto;

O mecanismo primário é a revisão técnica formal, que visa avaliar os requisitos por meio do exame da especificação, buscando erros de conteúdo ou interpretação e clareando as informações apresentadas, se necessário.

O Gerenciamento de Requisitosé um conjunto de atividades que ajuda a equipe de projeto a identificar, controlar e rastrear requisitos e mudanças de requisitos em qualquer momento. A gestão dos requisitos começa pela identificação: a cada requisito é atribuído um identificado único. Em seguida são criadas tabelas de rastreamento(Figura 1), que relacionam os requisitos a um ou mais aspectos do sistema ou ao seu desenvolvimento.

Figura 1 - Exemplo de Tabela de Rastreamento

Existem diferentes tabelas de rastreamento:

Tabela de rastreamento de fontes: indica a origem de cada requisito;

Tabela de rastreamento de subsistema:categoriza requisitos por subsistema governado;

Tabela de rastreamento de interfaces:apresenta como os requisitos se relacionam com as interfaces internas e externas do sistema.