Soluções Concretas para Problemas Práticos da Engenharia de Requisitos

Atualmente muitas empresas estão se movimentando no sentido de definir detalhadamente seus processos para apoiar suas atividades de desenvolvimento. O cenário da crescente adoção de modelos de maturidade como MPS (SOFTEX, 2007a) e CMMI (SEI, 2006) é um indicador de que as empresas nacionais estão se preocupando com a qualidade dos serviços que oferecem, conseguindo, dessa forma, uma inserção maior no mercado internacional de desenvolvimento de software. Adicionalmente, pesquisas como a encomendada pela SOFTEX (Travassos e Kalinowski, 2008) apontam diversos benefícios obtidos por empresas que investiram na melhoria de seus processos.

Os modelos de maturidade exigem a implementação de diversos processos e boas práticas da engenharia de software. Uma das atividades fundamentais da engenharia de software exigidas desde os níveis iniciais dos modelos é a engenharia de requisitos (Campos et al., 2008 – artigo publicado na edição 7 da Engenharia de Software Magazine). A importância dos requisitos e alguns conceitos iniciais relacionados à engenharia de requisitos do software são destacados em (Ávila e Spínola, 2008 – artigo publicado na edição 1 da Engenharia de Software Magazine).

Existem diferentes maneiras de estruturar um processo com atividades relacionadas à engenharia de requisitos em empresas desenvolvedoras de software. Acreditamos que modelos de maturidade, como o MPS, possam servir como um arcabouço para a definição deste processo. As exigências relacionadas à engenharia de requisitos no modelo MPS podem ser encontradas em (SOFTEX, 2007a) e maneiras de implementar estas exigências podem ser encontradas em (SOFTEX, 2007b). Além disso, consideramos de fundamental importância para um processo de engenharia de requisitos que ele seja capaz de lidar com dificuldades e problemas relacionados a requisitos que possam surgir durante o desenvolvimento de software na prática. Uma iniciativa rumo ao levantamento destas dificuldades e problemas e de maneiras de estruturar um processo para lidar com estes problemas encontra-se neste artigo.

O restante deste artigo está organizado da seguinte maneira. A seção 2 define a engenharia de requisitos e descreve suas principais atividades. A seção 3 representa um levantamento de dificuldades e problemas por atividade do processo de engenharia de requisitos, além da descrição de possíveis soluções. Por fim, a seção 4 apresenta as considerações finais deste artigo.

Engenharia de Requisitos

Podemos entender requisitos como sendo o conjunto de necessidades explicitadas pelo cliente que deverão ser atendidas para solucionar um determinado problema do negócio no qual o cliente faz parte. De forma genérica, requisitos podem ser dos seguintes tipos:

• Requisitos funcionais - São requisitos diretamente ligados a funcionalidade do software, descrevem as funções que o software deve executar.
• Requisitos não funcionais - São requisitos que expressam condições que o software deve atender ou qualidades específicas que o software deve ter. Em vez de informar o que o sistema fará, os requisitos não-funcionais colocam restrições no sistema.
• Requisitos de domínio - São requisitos derivados do domínio da aplicação e descrevem características do sistema e qualidades que refletem o domínio. Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas.

O refinamento funcional dos requisitos é freqüentemente realizado utilizando a notação de casos de uso, que descrevem a interação entre entidades externas e o sistema. Mais informações sobre casos de uso podem ser encontradas em (Cockburn, 2007).

A engenharia de requisitos compreende as atividades relacionadas à produção (levantamento, registro, validação e verificação) e gerência (controle de mudanças, gerência de configuração, rastreabilidade, gerência de qualidade dos requisitos) de requisitos. A Figura 1 representa estas atividades. Maiores detalhes sobre estas atividades podem ser obtidos em (Ávila e Spínola, 2008).