Estudando Engenharia de Requisitos para Concursos – Parte 2

Olá, meu querido aluno e minha querida aluna! Na postagem anterior, vimos o que eram os requisitos e as diversas classificações de requisitos. Na publicação de hoje, estudaremos os diversos processos de Engenharia de Requisitos que encontramos na literatura cobrada em prova de concursos.

Sommerville divide a engenharia de requisitos inicialmente em quatro etapas:

• Estudo de viabilidade (o software é útil ao negócio?).
• Descoberta de requisitos (elicitação e análise).
• Especificação (conversão dos requisitos para um padrão).
• Validação (Checar se o conjunto de requisitos especificados realmente faz aquilo que o cliente quer).

Porém, a engenharia de requisitos é um processo iterativo, onde estas atividades muitas vezes se sobrepõem. Sommerville, então, foge um pouco dessa versão linear da engenharia de requisitos e nos traz uma versão em espiral, como pode ser vista na figura a seguir.

Observem que, sobre essa nova ótica, passamos a ter três atividades que são desenvolvidas em espiral. O processo se inicia no interior da espiral com uma especificação dos requisitos de negócio (o que o software agregará de valor ao negócio) e a validação desta especificação se dá por um estudo de viabilidade. Na sequência, os requisitos dos usuários são elicitados e especificados e protótipos são criados para validação destes requisitos.

Agora que já se sabe o que o cliente quer, requisitos do sistema são elicitados e especificados. Atividades de revisão são realizadas para validação dos requisitos do sistema e o término da espiral é o documento de requisitos do sistema.

Como vimos, a primeira etapa de Sommerville é a Elicitação e Análise de Requisitos, atividade onde os engenheiros de software trabalham com o cliente e com usuários finais do sistema para descobrir o domínio do software, os serviços que serão oferecidos, a performance esperada do sistema, restrições de hardware etc. Nessa etapa, os requisitos descobertos são classificados e priorizados.

Depois, temos a Especificação de Requisitos, onde são escritos os requisitos do usuário e do sistema em um documento. Os requisitos devem estar claros, sem ambiguidade, fáceis de entender, completos e consistentes.

Na sequência, temos a Validação de Requisitos, momento em que os requisitos levantados são validados junto ao cliente, em busca de erros. É uma atividade fundamental porque erros no documento de requisitos levam a um trabalho extenso quando são descobertos na fase de desenvolvimento ou depois do sistema entregue.

Fim do Sommerville, agora vamos ver o processo de Pressman! Este autor cita uma sequência linear de sete etapas para a engenharia de requisitos. A Concepção é o início do entendimento do software. O objetivo dessa etapa é entender o problema, quais os envolvidos, a natureza da solução e iniciar o processo de comunicação entre clientes e colaboradores.

Depois temos o Levantamento, momento em que se pergunta aos envolvidos no projeto: Qual o objetivo do produto, como o produto se enquadra nas necessidades do negócio e como o produto será utilizado? Entretanto, existem diversos problemas nesse ponto do projeto, em especial:

• Problemas de escopo: Não se identifica corretamente os limites do que o Software deve ou não fazer, pois muitas vezes requisitos técnicos desnecessários confundem o entendimento da solução esperada.
• Problemas de entendimento: O cliente não tem domínio suficiente do problema, não conhece o potencial de uma solução computacional, omite informações óbvias, entre outras coisinhas a mais.
• Problemas de volatividade: Os requisitos mudam ao longo do tempo.

Fim do levantamento, temos a Elaboração, onde ocorre o refinamento das informações obtidas na etapa anterior com a inclusão de um modelo técnico das funções, características e restrições do software. Depois, vem a negociação. É frequente que, após a etapa de elaboração, muitos requisitos não estejam de acordo com a disponibilidade de recursos disponíveis ou, ainda, sejam conflitantes entre si. Nesse ponto, os requisitos são avaliados junto ao cliente e podem ser excluídos, combinados ou ainda serem acrescentados novos requisitos.

Negociação finalizada, vamos especificar os requisitos. A Especificação é a apresentação formal dos dados obtidos até o momento, podendo incluir gráficos, textos em linguagem natural, modelagem de cenários ou protótipos. O principal aqui é que a especificação possa guiar o desenvolvimento futuro, indicando os limites e possibilidades do software.

Depois dos requisitos especificados, fazemos a Validação. Nesse ponto, todos os envolvidos (clientes, colaboradores e usuários) avaliam os requisitos em busca de erros de interpretação, ambiguidade e omissões.

A sétima etapa de Pressman ocorre ao longo de todo o processo de Engenharia de Requisitos. Estamos falando da Gestão de Requisitos, processo que visa identificar, controlar e rastrear requisitos e modificações nos requisitos ao longo de um projeto. Em projetos de grande porte, com centenas de requisitos, é essencial um modelo formal, muitas vezes baseado em tabelas que cruzam os requisitos com os aspectos do sistema, como interfaces e dependências. Para projetos menores, esse processo pode ser feito de forma mais informal.

E assim, terminamos nossos estudos por hoje. Aprendemos o processo de Engenharia de Requisitos na visão dos dois maiores autores de Engenharia de Software: Pressman e Sommerville. Na próxima postagem, iremos avaliar as etapas da Engenharia de Requisitos em detalhe. Um abraço, pessoal!