Gerenciamento de requisitos

formal deve ser iniciado para identificar, controlar e reportar mudanças no projeto, as mudanças aceitas devem ser incorporadas a ERS. (ibidem).

2.2.3.5 Validação de requisitos

Como etapa final do processo de engenharia de requisitos, a validação permite verificar se os requisitos não possuem problemas e atendem as definições propostas pelo usuário. O custo de correção dos requisitos pode ser muito inferior e diminuir o retrabalho se identificados nesta fase, já que isto normalmente significa mudanças no projeto, na implementação e na realização de novos testes para avaliar os requisitos necessários.

Algumas das verificações que devem ser realizadas segundo SOMMERVILLE (2007) incluem:

• Validade: Avaliar se o sistema fornece as funções necessárias para desempenhar os requisitos propostos pelos stakeholders, isto se torna necessário devido à existência de diversos pontos de vista.

• Consistência: Responsável por verificar se os requisitos possuem conflitos ou estão em contradição para a realização de uma tarefa.

• Completeza: Avaliar se os requisitos necessários estão incluídos e definidos para a realização dos objetivos.

• Realismo: Responsável por verificar se os requisitos propostos estão de acordo com as tecnologias existentes, orçamentos e prazos propostos.

• Facilidade de verificação: Com o objetivo de testar e validar o sistema é necessário que os requisitos possam ser testados, verificando sua confiabilidade e demonstrando seu real funcionamento.

Utilizando um ciclo iterativo é possível que o software seja organizado por um conjunto de mini projetos que representam funcionalidades presentes no mesmo. Normalmente possuem duração fixa e objetivos definidos denominados de iterações, cada qual formada por um conjunto de atividades de análise de requisitos, projeto e implementação, que permitem testar, integrar e executar o módulo após sua conclusão (LARMAN, 2004).

Segundo Martins (2001) o gerenciamento de requisitos é uma atividade que ocorre em paralelo durante as etapas presentes na engenharia de requisitos até a entrega da documentação (Figura 19).

Figura 19. Cobertura do gerenciamento de requisitos nas etapas da engenharia de requisitos.

Fonte: Martins (2001).

Em um projeto é necessário realizar um acompanhamento constante para permitir a evolução e refletir as necessidades da organização, já que a compreensão dos problemas a serem solucionados nem sempre é fácil, tornando os requisitos incompletos (SOMMERVILLE, 2007). A existência de mudanças após a implantação torna-se quase que inevitável dentro da organização devido a basicamente dois fatores:

• Em sistemas grandes geralmente os usuários acabam adquirindo mais experiência e descobrindo novas necessidades com o passar do tempo, podendo causar conflitos e contradições com os diferentes requisitos propostos; e

• Nem sempre dentro das organizações os responsáveis por negociar o sistema são os verdadeiros usuários devido a restrições organizacionais e políticas presentes, o que de certa forma acaba interferindo na definição do escopo, onde após a instalação, novas mudanças e regras de negócio são introduzidas para refletir as reais necessidades do negócio.

A utilização de uma ferramenta de apoio, seja ela uma ferramenta CASE ou uma planilha, torna-se necessária e essencial como fonte de gerenciamento, controle e consulta aos envolvidos no

projeto, onde para cada requisito é armazenado sua identificação, descrição textual, data e origem de obtenção (MARTINS, 2001).

Para Cappelli e Santoro (2005) os seguintes benefícios são adquiridos ao realizar o armazenamento e identificação dos requisitos:

• Controle de alterações para permitir avaliar as modificações realizadas bem como os responsáveis pelas mesmas;

• Facilidade na geração de documentos de requisitos em forma de versão;

• Facilidade no acesso e visualização dos requisitos de forma única e centralizada.

2.2.4.1 Mudanças

Além de um processo de gerenciamento para realizar o acompanhamento dos requisitos, é necessário estabelecer e planejar políticas em toda e qualquer mudanças para avaliar os impactos causados pela evolução do sistema de forma controlada (SOMMERVILLE, 2007).

Para Castro (2000), o gerenciamento de mudanças é formado por um conjunto de políticas, procedimentos e padrões utilizados para controlar as mudanças de requisitos que ocorram dentro de um sistema, com o objetivo de identificar problemas, validar e testar as mudanças para garantir a qualidade.

Existem basicamente duas razões responsáveis por interferir e modificar os requisitos: (i) Os fatores externos correspondem a toda e qualquer característica relacionada a mudanças no problema a ser resolvido; e (ii) os fatores internos relacionados às questões de projeto não identificados nas fases iniciais e na dificuldade de gerenciar os requisitos e suas mudanças (Cappelli; Santoro, 2005).

Para isto é necessário planejar minuciosamente a forma de gerenciamento das mudanças, seguindo uma referência das modificações e estabelecendo um canal único de controle.

2.2.4.2 Rastreabilidade

Durante o ciclo de vida de um projeto de software, é necessário manter o controle dos impactos que poderão ser ocasionados durante a ocorrência de mudanças. Garantir o relacionamento entre os casos de uso, requisitos e demais artefatos, permite que seja avaliado a

A rastreabilidade é definida como uma atividade responsável por permitir rastrear a ligação de um requisito a outros elementos do projeto, fornecendo informações para acompanhar seu ciclo de vida e assim avaliar possíveis impactos que possam ser causados no projeto (KRUCHTEN, 2003).

Sommerville (2007) aponta três tipos de informações disponíveis que podem ser utilizadas através da rastreabilidade:

• Informações de rastreabilidade da origem: Permitem relacionar os requisitos aos documentos e stakeholders, que na ocorrência de mudanças, facilitam encontrar e consultar sobre a mudança;

• Informações de rastreabilidade de requisitos: São responsáveis por interligar um requisito aos demais requisitos presentes na documentação. Isto permite avaliar quais requisitos serão afetados diretamente na ocorrência de uma mudança; e

• Informações de rastreabilidade de projeto: Permitem avaliar toda e qualquer parte da implementação do projeto que possa ser afetada pela alteração do requisito.

Para facilitar a avaliação do relacionamento dos requisitos com os demais componentes do projeto, a utilização de matrizes de rastreabilidade permite uma melhor visualização entre as dependências existentes. É possível identificar anormalidades quanto à realização de um determinado requisito por um caso de uso, principalmente em sistemas com grande complexidade envolvida no desenvolvimento, servindo como base para o gerenciamento de requisitos e no suporte a identificação de incompatibilidades gerada. (KOTONYA; SOMMERVILLE, 1997 apud QUIRINO, 2005).

A matriz a ser utilizada é relativa à dependência existente entre os elementos. Normalmente as principais matrizes são formadas entre requisitos funcionais e casos de uso, devido ao seu forte acoplamento (SANTOS; VARGAS; ABREU, 2004).

Uma forma alternativa apontada por (KOTONYA, SOMMERVILLE, 1997 apud QUIRINO, 2005) são as listas de relacionamento, formada por requisitos e dependências, porém sua utilização não permite uma avaliação inversa dificultando a visualização.

O gerenciamento e avaliação dos impactos causados por alterações no projeto são divididos em níveis, dependendo de quando e em que parte do projeto foram realizadas. Se a mudança ocorrer durante a fase de especificação, deve ser avaliado como esta alteração afetará o restante dos requisitos (SANTOS; VARGAS; ABREU, 2004). Já para uma alteração durante a fase de implementação deve-se avaliar tanto os impactos causados entre os requisitos, quanto no funcionamento geral do sistema e por fim, caso uma modificação seja feita após o sistema estar concluído, além das etapas de verificação de requisitos e sistema, deve ser feito uma avaliação adicional para verificar como os stakeholders do negócio serão afetados.

Quando se trata de um número pequeno de requisitos (i.e., aproximadamente 250), as tabelas ou matrizes de rastreabilidade podem ser utilizadas através de uma simples planilha, porém se utilizadas sobre uma grande quantidade de informações as tabelas acabam tornando-se problemáticas, pois impedem uma fácil leitura e compreensão (CASTRO, 2000).

Para permitir controle durante o rastreamento, é necessário definir políticas sobre como e quais informações estarão disponíveis. A Figura 20 representa um exemplo do impacto que pode ser causado por uma alteração nos requisitos. Está matriz de rastreabilidade realiza o cruzamento entre RF x RF. A primeira coluna e a primeira linha são responsáveis por relacionar e nomear cada requisito com um identificador único. Avaliando o requisito R1, é possível verificar a sua dependência com os requisitos R3 e R4. No caso de realizar uma alteração no requisito R4, é necessário fazer uma avaliação nos impactos que serão gerados aos requisitos R1 e R3, pois na coluna R4 e possível visualizar a dependência de R1 e R3 com R4 (SANTOS; VARGAS; ABREU, 2004).

Figura 20. Exemplo de matriz de rastreabilidade entre requisitos.

Fonte: SANTOS; VARGAS; ABREU (2004).