ENGENHARIA RÁPIDA DE REQUISITOS

Pessoal,

devido as necessidades cada vez maiores dos usuários, e o tempo cada vez menor de levantamento e análise de requisitos (bem como sua construção em si) vemos agora uma nova revolução na Engenharia de Requisitos: a Engenharia Rápida de Requisitos.


Visão Atual de Levantamento e Análise de Requisitos:

Veja na imagem abaixo de uma visão comum de procedimentos em um projeto (ex: fases essênciais), quando construímos um novo sistema baseado na experiência ou visão de um outro sistema já existente dentro da empresa:

Como podemos ver, os requisitos são poucos trabalhados pois em geral pois apenas se acrescenta o que se deseja no novo tomando a experiência positiva do antigo. É o chamado desenvolvimento a partir de decisões pré-concebidas, ou decisões gerenciais chaves. Exemplo: o sistema novo terá uma tela nova de cadastro de usuário. O que muda internamente no sistema novo é baseado na experiência do desenvolvedor com o antigo sistema. Apenas tenta-se evitar armadilhas já conhecidas.

Como podemos acelarar o projeto de requisitos de maneira sem perder qualidade?

A solução está em pre-definir questões genéricas chaves que ajudem a filtrar e organizar o levantamente dos requsitos. É como se tivessemos um check-list geral de apoio para tomar como base ou "v-zero" no levantamento dos requisitos. Isso é uma estratégia de engenharia. Veja na imagem abaixo a idéia:


O desenvolvimento passa a ter no processo de análise de requisitos um enfoque mais metódico, porém existem alguns pontos chaves:

• A documentação dso requisitos deve ser criada desde o início de maneira objetiva e eficiente (ex: o texto deve ser útil e objetivo ao máximo e validado de forma clara por todos);
• A estrutura da documentação dos requisitos deve ser feita organizadamente e clara e simples para todos.

A partir daí podemos definir as tais "perguntas chaves" que ajudarão na criação e mostagem dos requisitos. Alguns exemplos clássico seriam: Como os requisitos da função "núcleo" do sistemas estão definidos? Como os requisitos não-funcinais estão descritos? A rastreabilidade entre os requisitos está documentada, validada e clara? Quem são as pessoas de contado do sistema antigo?

Quais os passos essenciais no levantamento e análise de requisitos, se considerarmos um ciclo básico de desenvolvimento (ou iteração)?

São 4 passos essenciais:

• Identificar as funções que precisam ser consideradas;
• Determinar os aspectos críticos do sistema anterior (ou antigo);
• Analisar os conceitos do sistema anterior;
• Documentar os resultados da análise e levantamento, tais como decisões tomadas e fatores de influência.

Quais os Ganhos?

Vejamos alguns dos principais ganhos:

• Sinergia com benefícios para a documentação do sistema;
• Alta produtividade pois a análise e construção dos requisitos passa a ser objetiva (tudo que é feito, em geral, de forma objetiva ao máximo tem ganho de tempo significativo);
• Permitirá reuso dos requisitos já criados (faz sentido);
• Os pré-requisitos do projeto ficam claros (este é um dos maiores entraves iniciais num projeto);
• Material gerado pela documentação passa a ter benefícios em futuros projetos baseados no antigo.Com isto tudo passamos a ter uma engenharia objetiva de análise e levantamento de requisitos, também conhecida como "Rapid Requirements Engineering".
  

Abraços,

Leonardo Molinari
=================

Fontes

• MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software, Editora Visual Books, 2007, Florianópolis, 85-7502-210-5.
  


• ___________. Gerência de Projetos - Técnicas e Práticas com Ênfase em Web, Editora Érica, 2004, São Paulo, 85-7194-0050.
  


• ___________. BTO - Otimização da Tecnologia de Negócio, Editora Érica, 2003, São Paulo, 85-7194-9506.
  


• ___________. Testes de Software - Produzindo Sistemas Melhores e Mais Confiáveis, Editora Érica, 2006, 3a Edição, São Paulo, 85-7194-959X.
  


• STICKYMINDS. Endereço: http://www.stickyminds.com/. Acesso em julho de 2007.