Autores: Edna Pacheco Zanlorenci -  GPS

                Roberto Carlise Burnett - PUC-PR

Apresentação

A IEEE Computer Society Technical Council on Software Engineering, com o suporte da indústria Fujitsu, Incose e MCI, realizou a 3ª.Conferência Internacional sobre Engenharia de Requisitos (ICRE’98) de 06 a 10 de abril de 1998, em Colorado Springs, Colorado, U.S.A.

A IEEE iniciou em 1992 a realização de eventos sobre Engenharia de Requisitos, conferência e simpósio, alternadamente. A conferência (ICRE) é realizada a cada dois anos, em ano par, intercalando também a cada dois anos, em ano ímpar, o simpósio (ISRE). A diferença de enfoque destes eventos anuais é que a conferência congrega, além da parte técnica, a divulgação comercial e da indústria, enquanto que o simpósio é um evento destinado a apresentações técnicas.

O próximo evento será o 4º.Simpósio Internacional sobre Engenharia de Requisitos, ISRE’99, de 07 a 11 de junho de 1999, em Limerick, na Irlanda.

1. Introdução

Daniel M.Berry e Brian Lawrence em sua introdução à programação técnica da conferência fizeram considerações sobre a evolução ocorrida entre o ICRE’96 e o ICRE’98, particularmente no sentido de estreitamento da distância entre a pesquisa e a prática em engenharia de requisitos.

Há mais de uma década [BL98], Fred Brooks escreveu: "A única parte mais difícil de construção de um sistema de software é decidir precisamente o que construir. Nenhuma outra parte do trabalho conceitual é tão difícil como estabelecer os requisitos técnicos detalhadamente. Logo, nenhuma outra parte do trabalho danifica o sistema resultante se feito de forma errada. Nenhuma parte é mais difícil para retificar depois". Através da história da indústria, tem-se deparado com esta verdade. Definir e aplicar requisitos bons e completos é trabalho difícil e o sucesso nestas tentativas tem se esquivado de muitos desenvolvedores. Mas tem havido progresso. Em muitos campos, pesquisadores propõem novos métodos para tratar o problema e, eventualmente, são adotados alguns deles. A falta de completa adoção é conhecida como a distância entre a pesquisa e a prática.

A distância é grande ainda, mas tem-se um pouco mais de métodos validados na prática e de ferramentas disponíveis. Neste sentido, o comitê do programa ICRE’98 estabeleceu um critério importante para aceitação de artigos, ou seja, cada qual deveria conter estudo de caso, relato das lições aprendidas, relato do trabalho e ligação com trabalho futuro. As sessões de subdivisão dos artigos (ICRE’98) selecionados refletem a crescente preocupação com o esforço em ligar a pesquisa à prática:

- segurança, sobrevivência e tolerância a falhas;

- gerenciamento de mudança e rastreamento histórico de requisitos;

- extração de requisitos;

- modelagem e requisitos;

- cenários;

- intenções;

- requisitos e reuso de software;

- pesquisas em progresso.

2. Aspectos dos Artigos Apresentados de RE (Requirements Engineering)

Na sessão sobre segurança, sobrevivência e tolerância a falhas:

- validação de requisitos para sistemas tolerantes a falhas, usando modelo de checagem na validação do comportamento de tolerância a falha de um controlador de nave espacial;

- definição de requisitos para sobrevivência de sistemas de rede, avaliando riscos de acesso por intrusos;

- análise de garantia de requisitos, com um check-list para uma família de produtos de instrumentos de vôo.

Na sessão sobre gerenciamento de mudança e rastreamento histórico de requisitos:

- gerenciamento automático de requisitos e o cuidado de como usar ferramentas sobre múltiplas versões de projeto;

- lições aprendidas da construção de um sistema de rastreamento de requisitos baseados Web;

- reestruturando especificações de requisitos para gerenciamento de inconsistência e mudança, a fim de identificar e analisar inconsistências e gerenciar mudança.

Na sessão de extração de requisitos, foram apresentadas várias técnicas de abordagem:

- uso de técnicas desenvolvidas para extrair requisitos de crianças, com adultos, para desenvolvimento de trabalho inovativo e futurístico;

- uso da técnica de captura de requisitos por comportamento (etnografia), suportada por vídeo, ou seja, captar os requisitos a partir de observação de imagens e sons documentados;

- uso de uma abordagem prática de extração de requisitos baseada em pontos de vista;

- rotas de interações de requisitos a partir de documentos de requisitos, para detectar erros e pontos críticos para análise;

- reestruturação para análise de inconsistências e negociação de requisitos sob a abordagem de ponto de vista;

- pré-design conceitual, preenchendo a distância entre requisitos e projeto conceitual;

- uma abordagem de construção de especificações centrada em intenções de pessoas, na fase de captura de requisitos;

- uma experiência com frame SCRAM, método de análise de requisitos para cenários.

Na sessão de modelagem e requisitos, apresenta:

- uma perspectiva através da teoria da construção, que muda a ênfase de uma visão tecnocêntrica do processo, onde requisitos são codificados em forma inicial de um sistema, para um foco sobre o entendimento humano dos sistemas;

- experiência de integração entre engenharia de requisitos e análise de negócio;

- usando um framework modelo de qualidade para reforçar a ponte de requisitos (teoria e prática).

Na sessão de cenários:

- protótipo de ferramenta de software, sistemática para geração e uso de cenários;

- estudo de caso de decomposição funcional de requisitos, usando cenários;

- experiência com SCRAM, um método de análise de requisitos em cenários.

Na sessão intenções:

- especificações de intenções - uma abordagem para construir especificações centradas em pessoas, baseada em teoria de sistemas, psicologia cognitiva e interação homem-máquina;

- framework para evolução de cenário - para entendimento da evolução de cenário e ajuda ao tratamento e identificação das ações pertencentes ao ambiente e aqueles que compartilham o software;

- uso de cenário em desenvolvimento de sistemas: forma, conteúdo, propósito e ciclo de vida.

Na sessão de requisitos e reuso de software:

- a engenharia de requisitos em projetos de centros de controle de rede;

- transferência de tecnologia para reuso, um modelo de gerenciamento a processo de aperfeiçoamento de framework, reuso de modelo e benefícios;

- adquirindo COTS para seleção de requisitos de software, de uma variedade de clientes;

Na sessão de pesquisas em progresso:

- formulação sistemática de características de software não-funcionais ou de qualidade, orientado a processos e a produtos;

- uma abordagem para cruzamento das disciplinas de engenharia de requisitos e padrões de processos, através de um framework;

- framework para extração de requisitos através da mixagem iniciativa de diálogo, através da linguagem natural.

O estado da arte

O debate continua[BL98]. Um diz respeito à distinção entre requisitos funcionais e não-funcionais. Os pesquisadores insistem nesta distinção, muito embora a prática aceite que em muitos casos a distinção não é clara. Outro debate diz respeito à natureza dos sistemas em desenvolvimento e seus requisitos. A maioria dos trabalhos de engenharia de requisitos é grande; sistemas de um conjunto de coisas, desenvolvidos para um cliente específico sob um contrato que inclui requisitos, com a idéia que implementando menos que o conjunto completo de requisitos equivale a falha de implementação do sistema contratado. No entanto, na prática tem-se várias realidades:

- hoje, o desenvolvimento de software é mais dirigido à comercialização, para satisfazer clientes anônimos e para condicioná-los ao retorno para compra de novas versões;

- não existem recursos suficientes para construir software que possa satisfazer os desejos de cada cliente. Isto é essencial para priorizar requisitos, então face à pressão para executar rapidamente, os mais importantes requisitos podem ser implementados por primeiro;

- requisitos são incompletos por natureza, principalmente porque eles mudam como resultado da aplicação do sistema.

Finalmente, na prática têm sido apontadas duas necessidades particulares, que métodos e ferramentas devem preencher:

- primeiro, a parte do projeto arquitetural necessária para efetivar a engenharia de requisitos, deve ser integrada aos requisitos;

- segundo, os métodos e ferramentas devem ser mais acessíveis, técnica e financeiramente.

Referências Bibliográficas

[BL98] BERRY, Daniel M., LAWRENCE, Brian. Requirements engineering. IEEE SOFTWARE, Los Alamitos, p. 26-29, mar./apr. 1998.

[IC98] INTERNATIONAL CONFERENCE ON REQUIREMENTS ENGINEERING, 3., 1998, Los Alamitos. Anais... Los Alamitos : IEEE, 1998. 250 p.