Gestão de Requisitos

A gestão de requisitos é uma prática fundamental em várias áreas da engenharia de requisitos e já foi explicitamente referida (pontos 2.4.1.3 Comunicação de Requisitos e

2.4.1.5 Evolução de Requisitos).

Define-se como o processo de levantar, documentar, organizar e rastrear os requisitos em mudança (alterações de requisitos) e comunicar esta informação a toda a equipa de projecto (Davis e Leffingwell, 1999), permitindo a evolução dos requisitos, ao longo do tempo. Gumus e Ertas (2004) apresentam os três principais objectivos da gestão de requisitos:

1. Captar e documentar correcta e explicitamente os requisitos.

 depende da estrutura e eficácia do levantamento e validação dos requisitos; 2. Alinhar as actividades do ciclo de desenvolvimento do sistema com os

requisitos, para assegurar o cumprimento dos mesmos.  depende da existência de rastreabilidade dos requisitos; 3. Gerir requisitos em mudança

 depende de uma gestão de alterações efectiva (já referida no ponto 2.4.1.5 Evolução de Requisitos).

LEVANTAMENTO E VALIDAÇÃO DOS REQUISITOS

Esta é a primeira fase da gestão de requisitos e pretende capturar, representar, analisar e documentar os requisitos num documento de especificação de requisitos, como base de partida para o desenvolvimento do sistema (Gumus e Ertas, 2004). Rzepka (1989) decompôs este processo nas seguintes actividades:

Identificar as relevantes fontes de requisitos, entre: utilizadores finais, sistemas de comunicação com o Cliente ou factores ambientais;

Recolher a lista do que se quer relativamente a cada uma dessas fontes, ainda possivelmente com ambiguidades, inconsistências, requisitos inviáveis ou não testáveis e até incompleta;

Documentar e refinar essa lista para cada fonte, sendo tipicamente de alto nível, específica de cada domínio, relevante do problema e com termos específicos do utilizador;

Integrar as várias listas, resolvendo os conflitos entre os vários pontos de vista e verificando a viabilidade;

Determinar os RNF (como questões de desempenho e confiabilidade) e declará- los num documento de requisitos.

RASTREABILIDADE DOS REQUISITOS

A rastreabilidade é a capacidade de estabelecer e manter uma ligação entre as necessidades do Cliente, requisitos e constrangimentos decorrentes dessas necessidades, e o resultado da concretização desses requisitos. Pretende permitir alcançar o segundo objectivo da gestão de requisitos, isto é, controlar e garantir, ao longo de todo o projecto, o cumprimento de todos os requisitos (Gumus e Ertas, 2004).

Muitas organizações consideram a rastreabilidade uma obrigação, um requisito contratual a satisfazer, outras vêem-na como um importante componente de um PDSI com qualidade e uma necessidade para a sobrevivência. As várias perspectivas sobre a rastreabilidade, dependem também do ponto de vista de cada stakeholder: para o Cliente, significa poder determinar que estão satisfeitos os requisitos do sistema; para quem desenvolve, a preocupação é a de saber como uma alteração num requisito vai afectar o sistema, que módulos afecta, directa e indirectamente; para quem testa, significa assegurar que cada requisito está a ser testado, garantindo a completude dos testes (Davis e Leffingwell, 1999).

De acordo com uma definição genericamente aceite, rastreabilidade é a capacidade de descrever e acompanhar a vida de um requisito, em qualquer um dos sentidos (Gotel e Finkelstein, 1994):

Rastreabilidade para a frente: da sua origem, ao longo do seu desenvolvimento e especificação, até à sua instalação e utilização;

Rastreabilidade para trás: em períodos de refinamentos contínuos e repetidos, em qualquer uma dessas fases.

Relativamente à documentação do requisito, pode ainda dividir-se nas duas seguintes (Gumus e Ertas, 2004):

Pré-rastreabilidade: é a capacidade de descrever e acompanhar esses aspectos da vida de um requisito (em ambos os sentidos), até à sua inclusão no documento de especificação de requisitos;

Pós-rastreabilidade: é a mesma capacidade, mas após incluído no documento. Nuseibeh e Easterbrook (2000) defendem que a rastreabilidade é o “coração” da prática da gestão de requisitos, fornecendo uma base para os requisitos e sendo a própria base para as ferramentas que analisam as consequências e impactos de possíveis alterações. Garantir a rastreabilidade na documentação de requisitos permite alcançar integridade e completude da mesma, desempenhando um importante papel na gestão de alterações.

GESTÃO DE ALTERAÇÕES

As alterações à documentação de requisitos têm de ser geridas, o que, no mínimo implica a utilização de técnicas e ferramentas para a gestão de configurações e controlo de versões (Estublier, 2000) e a exploração das ligações de rastreabilidade para monitorizar e controlar o impacto das alterações nas diferentes componentes da documentação. As alterações típicas às especificações de requisitos são (Nuseibeh e Easterbrook, 2000):

Acrescentar requisitos - são acrescentados requisitos quando se alteram as necessidades dos stakeholders, ou quando simplesmente não foram descobertos na análise inicial;

Retirar requisitos - são retirados requisitos, geralmente, apenas durante o desenvolvimento, para evitar que o custo e o prazo sejam excedidos, prática conhecida como expurgo de requisitos;

Corrigir erros.

Gerir as alterações dos requisitos não é apenas um processo de gestão de documentação, mas também de reconhecimento da alteração ao longo do levantamento contínuo de requisitos, de reavaliação de risco, e de avaliação dos sistemas no seu contexto operacional. Na engenharia de software foi demonstrado que concentrar as alterações na

codificação do programa leva à perda de estrutura e facilidade de manutenção (Bennett e Rajlich, 2000). Assim, cada alteração proposta tem de ser avaliada no âmbito dos requisitos e arquitectura existente, para que a relação custo/benefício possa ser ponderada.

Um exemplo óbvio da necessidade de estabilidade e controlo é o desenvolvimento de famílias de produtos aplicacionais, o qual se tornou um tipo de actividade de desenvolvimento cada vez mais importante (Nuseibeh e Easterbrook, 2000). Neste caso, é necessário desenvolver um conjunto de produtos aplicacionais que partilhem requisitos e características arquitecturais similares, mesmo que com diferentes requisitos chave. Assim, uma das principais questões de investigação na engenharia de software prende-se com o processo de identificar os requisitos nucleares para que se desenvolvam arquitecturas, estáveis face a alterações, e flexíveis o suficiente para poderem ser parametrizadas e adaptadas a requisitos alterados (Garlan, 2000).