A Engenharia de Requisitos

A área de Engenharia de Requisitos vem a muito tempo mostrando ser um problema complexo de se lidar, sendo muitas vezes elencada como a responsável por falhas e problemas em projetos de software em decorrência de erros como a falta de participação dos envolvidos, requisitos incompletos e objetivos confusos. Para buscar melhorias no campo, a engenharia de requisitos procurou nos últimos 25 anos evoluir com pesquisas sobre processos e técnicas para ampliar o apoio e suporte a disciplina.

Primeiros 25 anos: Os vários marcos de pesquisa

Desde o início as Técnicas de Modelagem foram vistas como elementos centrais no processo de engenharia de requisitos, tendo a maioria das pesquisas dedicado boa parte de seus esforços neste tema.

Os estudos iniciais de Ross e Schoman explicavam detalhadamente o escopo da engenharia de requisitos e determinou diversos elementos potenciais da disciplina e a SADT como técnica de modelagem específica. Esta técnica apoiou outros modelos vinculados por regras de consistência, assim que estejam abrangendo dados, operações e dados-operações. Bubenko também introduziu técnicas de modelagem que capturavam entidades e eventos, já reconhecendo que deviam participar do processo do futuro software. Outras técnicas semi-formais foram desenvolvidas no final dos anos 70 como a RML, primeira linguagem de modelagem a ter uma semântica comum definida.

Logo os agentes também começaram a ter a sua importância reconhecida a partir da percepção de que os sistemas eram compostos por estes componentes ativos, atribuindo responsabilidades de objetivos e restrições a estes dentro do software e do ambiente como importante resultado no processo de ER. E dentre as pesquisas ao perceber que os requisitos não podiam responder se eram suficientes, Yue agregou o estabelecimento de metas baseadas nos requisitos quando completos e suficientemente refinados.

Se dividindo em duas estruturas complementares para metas e refinamentos de metas, o quadro formal e o quadro qualitativo foram introduzidos, dando origem a metodologias como KAOS no formal e NFR no qualitativo além de outros procedimentos posteriores que trabalham com pontos conflito em requisitos e diferenças em nível de metas, elicitação baseada em cenários incluindo deficiências, reutilização de requisitos e a essencial documentação dos mesmos.

De Modelagem Orientada a Objetos para Orientada a Metas/Objetivos

Já as técnicas de análise orientada a objetos, combinam várias técnicas de modelagem semi-formais para perceber as características do sistema, entretanto conceitos, estruturação, mecanismos e análise estruturada tiveram como base técnicas e o campo da programação. O “Porquê” do essencial da engenharia de requisitos não são abordados. Porém mostra-se os benefícios de realizar uma orientação a metas, refinando metas e estruturar a especificação e derivar vários modelos como modelo de metas, de objeto, de responsabilidade do agente e de operação. Assim foi proposta a especificação formal com estudo de caso do “Sistema BART”.

 Inicialmente identificando as metas, objetivos e “soft-goals” com base no documento inicial, relatando em um gráfico/diagrama de metas e incluindo detalhes como conflitos, palavras-chave e símbolos de refinamento. Passa também por fases de levantar os objetivos formais e identificação de objetos, elicitação de novas metas através das questões “Porquê” e “Como”, identificação de potenciais atribuições de responsabilidades, interfaces do agente de derivação, identificação de operações e Objetivos de operacionalização. Por fim utilizando um misto de técnicas formais e informais para elaboração de requisitos orientados a metas, foi possível chegar a um bom nível de técnicas de especificações.

Vivendo com conflitos

Os conflitos são comuns na abordagem orientada a metas, devendo ser detectados e resolvidos, com possibilidade de utilidade temporária para extração de informação. Objetivos divergentes podem ter de serem enfraquecidos para manter um objetivo maior para remover a divergência.

Já o apoio para a construção da arquitetura de software não evoluiu tanto quanto a encontrar técnicas para derivar sistematicamente a arquitetura das especificações de requisitos. Propostas para linguagem de descrição e técnicas construtivas foram propostas mas não houve muito trabalho realizado na derivação. Uma abordagem viável é utilizar metas funcionais e agentes de software derivando a abstração de fluxo de dados e metas não funcionais para refinar os fluxos de dados.

De requisitos para Arquitetura/Mais trabalho para os próximos 25 anos

Portanto as próximas pesquisas devem se dedicar a preencher a lacuna entre a pesquisa de Engenharia de Requisitos e as pesquisas em arquitetura de software. Cada vez mais softwares estão personalizáveis e complexos com grande aceitação do mercado e com carência na ligação entre essas áreas para a entrega de um produto final com grande nível de maturidade e satisfação. Assim como as pesquisas de ER e especificações formais, agentes de modelagem, reengenharia de requisitos que necessitam de aprofundamento técnico para evoluírem a disciplina em conjunto com a engenharia de software.

Opinião Critica Pessoal do Autor do Resumo

Os estudos realizados e citados no artigos baseiam a engenharia de requisitos e estruturam com técnicas e métodos padronizados e consolidados, com anos de pesquisas e evolução no processo de engenharia de requisitos, buscando uma integridade na construção de software desde o mais importante nível inicial que é a levantamento, elicitação, refinação e análise de requisitos, agora traz como interessante sugestão a busca pelos próximos 25 anos de pesquisa por pontes e soluções para problemas que ainda estão sem respostas claras e lacunas entre inter-disciplinas da engenharia e desenvolvimento de software focando nas partes relacionáveis entre a engenharia de requisitos e arquitetura de software.

Esta interdisciplinaridade é de grande importância tendo em vista a diferença de ambiente e área de conhecimentos entre o engenheiro e o arquiteto/desenvolvedor, trazendo dificuldades na comunicação e entendimento entre membros da equipe por estarem experienciando “universos” diferentes. Para isto, uma formalização simplificada e objetiva de uma metodologia que ligue as áreas pode agregar muito na evolução do processo de software na ponta final.

Síntese do Artigo de Axel van Lamsweerde, disponível em: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.585.2878&rep=rep1&type=pdf