Autores: Edna Pacheco Zanlorenci -GPS

     Robert Carlisle Burnett - PUC-PR

Resumo

Engenharia de Requisitos é um amplo campo de pesquisa para a Engenharia de Software. Como área específica de atuação, apresenta avanços tecnológicos e meios próprios voltados para pesquisa em terminologia, métodos, linguagens e ferramentas que compõem o esforço de pôr em prática o campo de conhecimento gerado [ZJ97].

Descobrimento, documentação e gerenciamento de requisitos caracterizam as etapas fundamentais do processo de engenharia de requisitos.

Requisitos, referem-se aos fenômenos que ocorrem no ambiente ou domínio da aplicação.

Especificações, referem-se às definições de interface entre o ambiente e o software utilizado para solução do problema.

Palavras-chave: ambiente, domínio da aplicação, engenharia, especificação, requisito.

Introdução

O objetivo do trabalho sobre o tema engenharia de requisitos é de divulgar informações oriundas de pesquisa e estudos de trabalhos e publicações disponibilizados em eventos oficiais, na literatura específica e atual em desenvolvimento de software. Pretende-se que este artigo seja o primeiro de uma série, com o compromisso de publicar o que se está discutindo nos meios acadêmicos e profissionais na área de requisitos.

Conceitos Fundamentais de RE (Requirements Engineering)

No contexto da Engenharia de Requisitos serão apresentados os conceitos e fundamentos de forma genérica, sobre a engenharia e o ambiente do processo, os requisitos e as especificações do produto.

1. Engenharia de Requisitos

O termo "Requirements Engineering" é traduzido para o português, como "Engenharia de Requisitos". Entende-se engenharia como aplicação de princípios matemáticos e científicos às construções, como técnica de construções. Entende-se requisito como condição que se precisa para conseguir certo fim, como exigência legal necessária para certos efeitos.

Engenharia de Requisitos [SS97 e KS98], é um termo relativamente novo que foi inventado para cobrir todas as atividades envolvidas em descobrimento, documentação e manutenção de um conjunto de requisitos para um sistema baseado em computador. O uso do termo engenharia implica em técnicas sistemáticas e repetitíveis a serem usadas para assegurar que os requisitos do sistema sejam completos, consistentes, relevantes,... O termo engenharia de requisitos vem da antecedente engenharia de sistemas, correspondendo à fase de análise de sistemas.

Engenharia de Requisitos [LM96] pode ser definida como o processo sistemático de desenvolvimento de requisitos através de um processo iterativo de análise de problema, documentação de observações resultantes em uma variedade de formatos de representação e checagem de precisão do entendimento obtido. Pode ser considerado como o processo através do qual o documento de requisitos é preenchido.

2. Processo de Engenharia de Requisitos

Desenvolvimento de software [MJ95] é engenharia num segundo sentido: é a engenharia de estruturas complexas de descrições. Um engenheiro civil confronta-se com o problema, por exemplo, de projetar ponte sobre um rio e construir uma estrutura de partes, usando concreto e metal como materiais brutos. Um desenvolvedor de software confronta-se com o problema de criação de um projeto de sistema e constrói uma estrutura de descrições, usando linguagens e notações como materiais brutos.

Desenvolvimento [GW89] é o processo de transformação de desejos de alguém em um produto que satisfaça aqueles desejos. O processo de requisitos é a parte do desenvolvimento em que o problema é as pessoas tentarem descobrir o que é desejado. Um problema [GW90] é uma diferença entre coisas como desejadas e coisas como percebidas. Para entender este processo [GW89] é necessário o foco sobre cinco palavras críticas: desejo, produto, pessoas, tentar e descobrir:

• desejo e não necessidade, por quê? Porque pessoas nem sempre compram o que necessitam, mas sempre desejam o que compram, mesmo que o desejo seja somente transitório;
• produto é algo que tenta satisfazer um conjunto complexo de desejos. A complexidade é proporcional à quantidade e diversidade de objetivos das pessoas requisitantes;
• pessoas podem agregar muitas diferenças de requisitos, e descobrir quem são as pessoas é a parte mais extensa do processo de descoberta;
• tentar é procurar garantir que o resultado do desenvolvimento vá ao encontro do desejado. Se pessoas não conhecem o que desejam, nenhum processo de desenvolvimento e nenhuma disciplina exata, hábil e eficiente, irão satisfazê-las;
• descobrir é a palavra mais crítica. É extrair o que realmente é equivalente ao fazer.

"The discovery is nothing; the discovering (the exploring) is everything" [GW89].

A descoberta é nada; o descobrimento (a exploração) é tudo.

Isto estende o pensamento do autor a dizer "O produto é nada; o processo é tudo". Concluindo que o processo de desenvolvimento de requisitos é um processo de desenvolvimento com uma equipe de pessoas que:

• entendem os requisitos;
• trabalham juntos sobre o projeto;
• sabem como trabalhar efetivamente como uma equipe.

O processo de engenharia de requisitos[LM96] apresenta dois tipos básicos de atividades:

• primeiro, a análise do problema, onde desenvolvedores gastam seu tempo em "brainstorming", entrevistas com pessoas que têm mais conhecimento acerca do problema e identificam as possíveis restrições sobre a solução do problema;
• segundo, a descrição do produto, onde é tempo de escrever, tomar algumas decisões difíceis e preparar um documento que descreva o comportamento externo esperado do produto.

A primeira atividade é caracterizada pela incerteza, uma expansão da informação e do conhecimento; a segunda, é caracterizada pela organização de idéias, resolução de conflitos de pontos de vista e intenções dos clientes, da variedade de cenários e eliminação de inconsistências e de ambigüidades. Não existe um modelo único de processo, mas muitos.

Um processo de engenharia de requisitos [SS97] é um conjunto estruturado de atividades para extrair, validar e manter um documento de requisitos. Uma completa descrição do processo poderá incluir quais atividades são realizadas, a estruturação ou particionamento destas atividades, quem é responsável pela atividade, as entradas e saídas de/para atividade e as ferramentas usadas para suportar a engenharia de requisitos.

3. Domínio da Aplicação ou Ambiente

O primeiro passo em análise de problemas é estruturar e analisar o domínio da aplicação. O princípio de relevância do domínio, declara que: "Tudo o que é relevante para os requisitos, deve aparecer em alguma parte do domínio da aplicação". Existe uma importante conseqüência deste princípio. O domínio da aplicação não é limitado a partes do mundo que estão diretamente ligados ao sistema de software, é mais abrangente, refere-se ao negócio[MJ95].

O domínio da aplicação é onde os requisitos particulares dos clientes são encontrados. Se o domínio da aplicação não for identificado corretamente não se está apto para focalizar os requisitos dos clientes.

Em cada atividade de desenvolvimento de software, o contexto do problema tem, ao menos, dois domínios distintos: o domínio da aplicação (o ambiente ou o mundo real ou matéria julgada) e o sistema de software. O domínio da aplicação é onde os requisitos do cliente existem; o software sustenta uma solução para o problema por interação em alguns caminhos com o domínio da aplicação. Pode-se pensar do domínio da aplicação como o que é dado e do domínio do software como o que será construído[MJ95].

Requisitos são exclusivamente todos os fenômenos do ambiente, isto é, os fenômenos externos ao software.

Programas são, exclusivamente, todos os fenômenos de software, isto é, os fenômenos internos à máquina. Programas são sobre o comportamento da máquina (software).

Especificações são, exclusivamente, todos os fenômenos compartilhados (estados e eventos), que formam a interface entre o ambiente e o software.

4. Requisitos

Requisito [LM96], simplesmente, pode ser definido como "algo que um cliente necessita". Entretanto, do ponto de vista de um desenvolvedor, requisito pode também ser definido como "algo que necessita ser projetado".

Existem inúmeras definições do termo requisitos [LM96]. As mais notáveis reportam-se a IEEE(1990), aplicável, a nível geral, também a situações que não as específicas de software:

1. uma condição ou capacidade necessária para um cliente resolver um problema ou realizar um objetivo;
2. uma condição ou capacidade que deve ser encontrada ou possuída por um sistema ou componente de sistema, para satisfazer um contrato, padrão, especificação ou outro documento imposto formalmente;
3. uma representação documentada de uma condição ou capacidade, como em 1 ou 2 acima.

Em contraste ao padrão IEEE [LM96], o padrão BSI (British Standards Institution) enfatiza os requisitos de software. Em BS 6719 guia padrão 1986 para especificação de requisitos de usuários para sistemas baseados em computador, provê uma base para descrição das necessidades e prioridades do cliente, ou seja, específico para software.

Requisitos [SS97 e KS98], são descrições de como o sistema poderá comportar-se, informações do domínio da aplicação, condições sobre operação de sistema ou, especificações de uma propriedade ou atributo de sistema. Requisitos são definidos durante os estágios iniciais de um desenvolvimento de sistema como uma especificação do que poderá ser implementado. Requisitos, invariavelmente contêm uma mistura de informação do problema, declarações de comportamento e propriedades do sistema, e condições de projeto e de construção. Esta abordagem de definição é exclusiva para sistema de software, notadamente voltada para o sistema como solução para o problema.

Requisitos [MJ95 e ZJ97] são fenômenos do domínio da aplicação. São exclusivamente todos os fenômenos do ambiente. É uma propriedade do domínio da aplicação, que o sistema de software deve executar. Para descrevê-los exatamente, descrevemos os relacionamentos acerca dos fenômenos do contexto do problema. Muitos projetos falham porque seus requisitos estão inadequadamente explorados e descritos.

Particularmente, esta última definição dá ênfase ao domínio do conhecimento sobre o problema, tendo como referência os fenômenos que ocorrem no ambiente de negócio do cliente, onde residem os problemas a serem resolvidos, seja com o uso de computador ou não.

Consolidando as idéias, requisito é uma declaração descritiva de fenômenos, envolvendo o cliente e os usuários, para os quais deverá ser provida tecnologia da informação e compartilhamento de recursos na solução de problemas. Fato inegável da importância da descrição do requisito é a abordagem de tratamento da informação, cujo enfoque está nos acontecimentos dinâmicos e na necessidade de tratá-los de forma estruturada.

5. Especificações

Os requisitos [SS97] caracterizam-se sob duas formas fundamentais: os funcionais e os não-funcionais ou especificações:

• por requisitos funcionais, entendem-se os fenômenos ambientais referentes ao negócio e domínio da aplicação que se queira conhecer e estudar, ou seja, o que fazer. São escritos do ponto de vista do cliente. Normalmente são expressos em linguagem natural, diagrama informal ou usando alguma notação que é apropriada para o entendimento do problema.
• por requisitos não-funcionais ou especificações, entendem-se as especificações técnicas de como melhor adequar a solução do problema para responder ao cliente. São especificações que podem ser expressas como um modelo abstrato do sistema. Pode ser um modelo matemático ou baseado em notações gráficas, tais como diagrama de fluxo de dados, hierarquia de classes de objetos e, de preferência em linguagens de representação formal, que podem gerar código fonte e objeto diretamente, por exemplo a linguagem de especificação "Z".

A terminologia de desenvolvimento de software não é padronizada e o conceito de especificação é um dos elementos que fazem parte do universo do contexto da engenharia de software. Dentre eles [MJ95] a que mais se aproxima e restringe a forma de pensar, referência a de Carlo Ghezzi, em Fundamentos de Engenharia de Software:

"Em geral, pode-se ver uma especificação como uma declaração de acordo entre um produtor e um consumidor de serviço ou entre um implantador e um usuário".

Especificações são coisas difíceis. Embora sejam um tipo de requisito, podem não ser vistas para fazer sentido no ambiente do negócio. Isto porque são derivadas dos requisitos do cliente por uma série de passos de raciocínio.

As especificações dos fenômenos de interface entre o domínio da aplicação e o sistema de software referem-se aos procedimentos de entrada de informações para o software e aos resultados processados pelo software.

O estado da arte

A variedade de tópicos de discussão e divergências sobre o tema Engenharia de Requisitos é caracterizada pela falta de uma terminologia padrão e de conceitos da tecnologia em desenvolvimento. Entretanto, o resultado destas discussões tem contribuído para o surgimento de ferramentas para automação de extração, documentação e gerenciamento de mudança de requisitos. A diversidade de fontes de estudo e de pesquisa é evidenciada pela qualidade dos eventos, das publicações em livros e em revistas técnicas, e do material disponível na Internet.

1. Eventos

Os eventos internacionais representativos promovidos pela IEEE [BL98], ocorrem anualmente, de forma alternada, com publicação de anais, disponibilizados para aquisição:

• ISRE - Internacional Symposium on Requirements Engineering, em anos ímpares, com foco sobre debates conceituais.
• ICRE - Internacional Conference on Requirements Engineering, em anos pares, com foco além da tendência evolutiva de conceitos, inclui ferramentas e fornecedores.
• Sessões de Engenharia de Requisitos são realizadas em várias reuniões sobre Engenharia de Software, ICSE - International Conference on Software Engineering (ACM), ESEC - European Software Engineering Conference e, no Brasil, SBES - Simpósio Brasileiro de Engenharia de Software.

Outras conferências: IWSSD - International Workshop on Software Specification and Design e REFSQ - Requirements Engineering: Foundation for Software Quality.

2. Publicações

Além de algumas referenciadas na bibliografia ao final, fazem-se presente periódicos da IEEE (Transactions on Software Engineering) e da ACM (Transactions on Software Engineering and Methodology).

Em 1996, a Spring-Verlag iniciou seu novo jornal Engenharia de Requisitos.

3. Web e Sites Ftp

O jornal Spring-Verlag, referenciado em: http://www.mac.co.umist.ac.uk/RE/Journal.html.

Renoir - Requirements Engineering Network of Excellence, da União Européia, referenciado em: http://www.cs.ucl.ac.uk/research/renoir.

Requirements Engineering Newsletter, ftp://ftp.cs.city.ac.uk/pub/requirements.

Informação acerca de Engenharia de Requisitos, lista:

http://www/jrcase.mq.edu.au/~didar/seweb/groups.html.

Tema para Continuação

O próximo tema será discorrido sobre a estruturação dos tópicos de estudo de engenharia de requisitos, na 3ª Conferência Internacional sobre Engenharia de Requisitos, realizada em abril.98 pela IEEE.

Conclusão

O objeto de pesquisa foi centrado no conhecimento dos fundamentos conceituais da Engenharia de Requisitos onde a terminologia e a aplicabilidade compõem uma primeira fase de estudo sobre o tema.

Do assunto pesquisado, percebem-se duas tendências básicas na abordagem de tratamento de requisitos:

• uma, enfocando a fase inicial de descobrimento de requisitos no conceito exclusivo de ambiente do negócio do cliente e, de forma independente, as especificações técnicas como extensão dos requisitos, para implementação. É voltada para o entendimento dos problemas, com mais clareza didática;
• outra, enfocando a fase de requisitos integrada a projeto, embutindo como requisitos, além dos requisitos do negócio, ou seja funcionais, também as especificações técnicas, entendidas como requisitos não funcionais. É voltada para a aplicação de métodos e técnicas de engenharia de requisitos com maior foco na solução dos problemas.

Referências Bibliográficas

[BL98] BERRY, Daniel M.; LAWRENCE, Brian. Requirements engineering. 1. ed. USA : IEEE Software, Mar./Apr. 1998. p. 26-29.

[GW89] GAUSE, Donald C.; WEINBERG, Gerald M. Exploring requirements (quality before design). 1. ed. USA : Dorset House Publishing Co. Inc., 1989. p. 300.

[GW90] GAUSE, Donald C.; WEINBERG, Gerald M. Are your lights on? 1. ed. USA: Dorset House Publishing Co. Inc., 1990. p. 157.

[MJ95] JACKSON, Michael. Software requirements and specifications: a lexicon of practice, principles and prejudices. 1. ed. Massachusstes : Addison-Wesley, 1995. p. 228.

[KS98] KOTONYA, Gerald; SOMMERVILLE, Ian. Requirements engineering (Processes and techniques). 1. ed. England : J. Wiley & Sons, 1998. p. 282.

[LM96] MACAULAY, Linda A. Requirements engineering. 1. ed. Great Britain : Springer-Verlag London, 1996. p. 202.

[SS97] SOMMERVILLE, Ian; SAWYER, Pete. Requirements engineering (A good practice guide). 1. ed. England : J. Wiley & Sons, 1997. p. 391.

[ZJ97] ZAVE, Pamela; JACKSON, Michael. Four dark corners of requirements engineering. Transactions on software engineering and methodology, USA, v. 6, n.1, p. 1-30, Jan. 1997.