Gerenciamento e controle de mudanças de requisitos

Desenvolver softwares não é uma tarefa fácil, tão pouco trivial. Vários fatores de risco estão associados ao desenvolvimento do produto a ser entregue, sejam eles conhecidos ou não. Essa dificuldade vem desde os primórdios da computação, onde era grande a dificuldade em entregar os sistemas. Naquela época não existiam processos de desenvolvimento de software bem definidos, ou simplesmente não havia nenhum. Com o passar do tempo surgiu a engenharia de software, a qual se ocupou em encontrar soluções para resolver os problemas que levavam ao fracasso dos projetos. Processos de desenvolvimento de software e modelos de desenvolvimento de software foram criados e se tornaram excelentes ferramentas para construir sistemas.

Muitas soluções foram propostas ao longo dos anos, de forma que os problemas relacionados aos requisitos considerados instáveis fossem minimizados. Uma das soluções propostas foi o congelamento dos requisitos, através de métodos formais, os quais se utilizavam de notações matemáticas para realizar a especificação de requisitos de software. Entretanto, a prática mostrou que o congelamento de requisitos não era uma boa solução, uma vez que o engessamento do processo acabava atrapalhando. Com o passar do tempo chegou-se à conclusão de que o projeto precisava ficar em constante refinamento, objetivando a estabilidade dos requisitos.

A adoção da prototipação tornou-se uma ótima ferramenta, uma vez que ajuda o cliente a entender melhor as suas necessidades e validar os requisitos que foram coletados. A validação dos protótipos, por parte do cliente, refina os requisitos e direciona o desenvolvimento para um caminho ideal. Com o tempo, foram criados novos processos de desenvolvimento de software, os quais se tornaram mais dinâmicos e propuseram soluções para lidar com requisitos voláteis.

Embora a engenharia de software tenha criado processos que ajudaram a resolver os grandes atrasos e fracassos dos projetos, desenvolver softwares continuou a ser uma tarefa difícil. Ainda é muito comum que os usuários não conheçam totalmente suas necessidades. Além disso, os requisitos não permanecem imutáveis ao longo do ciclo de vida do desenvolvimento do software, por isso é preciso estar bem atento a esse detalhe. A essa mudança dos requisitos dá-se o nome de volatilidade. Quanto mais volátil for um requisito, maior será o risco de não entregar o projeto no prazo estipulado e dentro dos custos previstos. A volatilidade dos requisitos torna praticamente impossível criar uma arquitetura que seja imune a isso, uma vez que na fase inicial do projeto os requisitos ainda não estão bem definidos e na maioria das vezes alguns detalhes da especificação só são conhecidos durante a implementação do sistema.

Requisitos voláteis, estimativas pobres e muito otimistas se constituem nas principais causas dos projetos de software saírem do controle, tornando-se difícil de serem gerenciados. Os problemas relacionados às estimativas são derivados diretamente da gerência, a qual não fez uma estimativa correta. Já os problemas decorrentes da volatilidade dos requisitos estão intimamente relacionados ao desenvolvimento do software, sendo bem mais complexos de serem resolvidos.

Dependendo do cenário que ocasiona a volatilidade dos requisitos, torna-se necessário considerar a utilização de metodologias ágeis, pois elas proporcionam um feedback contínuo ao cliente e a equipe, através de curtas iterações e pequenos releases, objetivando entregar uma solução que atenda às necessidades do cliente e com qualidade. Além de utilizar metodologias ágeis, também é necessário que o projeto seja dividido em módulos, cada um com “vida própria” e com pequenos ciclos de desenvolvimento. Dessa forma, um módulo não depende funcionalmente de outro módulo e se acontecer alguma mudança nos requisitos não haverá um grande impacto no sistema como um todo, apenas no módulo onde ocorreu a mudança dos requisitos.

Requisitos estáveis e requisitos voláteis

Mudanças nos requisitos de um sistema podem acontecer em qualquer fase do ciclo de desenvolvimento do software. Alguns requisitos são mais susceptíveis a mudanças do que outros, o que os torna muito mais instáveis. A mudança nos requisitos não implica em dizer que o processo de desenvolvimento adotado não é eficiente, afinal as mudanças são inevitáveis. Nesta situação é fundamental saber controlar essas mudanças de forma que a implementação do software seja possível.

Os requisitos são considerados estáveis ou permanentes quando são derivados da atividade principal da organização, isto é, são derivados do modelo de domínio da organização. Como exemplo de requisitos estáveis, podemos considerar os requisitos de uma faculdade, onde sempre haverá requisitos relativos aos alunos, aos professores, as turmas, notas dos alunos e as aulas.

Os requisitos são considerados voláteis quando mudam à medida que o sistema está em desenvolvimento ou já em uso. Podemos citar com exemplos de requisitos voláteis os requisitos resultantes de políticas governamentais, os quais mudam de acordo com a aprovação de uma legislação ou decreto, requisitos que não podem ser completamente definidos antes da implementação do sistema, entre outros.

Os requisitos voláteis são classificados como:

1. Requisitos mutáveis se modificam de acordo com as mudanças do ambiente ao qual a organização está operando;
2. Requisitos emergentes: são requisitos que vão surgindo à medida que a compreensão do cliente se desenvolve durante o desenvolvimento do sistema. Ao longo do ciclo de desenvolvimento poderão surgir novos requisitos emergentes;
3. Requisitos consequentes: são requisitos que resultam da introdução do sistema no ambiente do usuário. Essa introdução faz com que o cliente perceba a necessidade de outros requisitos em consequência do uso do sistema que foi introduzido no meio de trabalho;
4. Requisitos de compatibilidade: dependem de outros elementos e mudam sempre que estes mesmos elementos também mudam.

A seguir serão apresentadas algumas estratégias para lidar com os requisitos voláteis.

Gerenciamento de mudanças de requisitos

Como citado anteriormente, inevitavelmente, os requisitos vão mudar ao longo do ciclo de desenvolvimento do sistema e quanto mais voláteis forem os requisitos, maiores as probabilidades de haver mudanças. Gerenciar essas mudanças torna-se crucial para poder ter um controle sobre os requisitos do sistema. Utilizar um processo formal de gerenciamento de mudança de requisitos faz com que todas as propostas de mudança sejam tratadas de modo consistente, contribuindo para que as mudanças nos documentos sejam feitas de forma controlada.

Vários fatores ocasionam mudança nos requisitos, tais como:

• Requisitos que não são claramente definidos e/ou escritos de forma ambígua;
• Os requisitos foram obtidos de vários usuários diferentes;
• Mudança de usuários chave durante o levantamento dos requisitos;
• Dificuldade em expressar os requisitos utilizando a linguagem natural;
• Diferentes tipos de requisitos em diferentes níveis de detalhe;
• Dependência entre os requisitos;
• Alterações constantes nos requisitos em decorrência do entendimento sobre o negócio evoluir apenas durante a fase de desenvolvimento.

Os sistemas devem ser desenvolvidos de forma a controlar as alterações sofridas, fazendo com que seu desenvolvimento seja impactado o mínimo possível com tais mudanças. A mudança dos requisitos deve ser um processo controlado, visando garantir a qualidade do sistema. Toda mudança deve ser analisada e avaliada, visando buscar maneiras de ser implementada de forma eficiente e com o mínimo possível de custo, quer seja custo financeiro ou de esforço.

O gerenciamento de mudança de requisitos pode ser organizado nos seguintes estágios (ver Figura 1):

1. Análise do problema e especificação da mudança – nesse estágio é identificado um problema com os requisitos ou com a proposta de mudança requerida. Em seguida é feita uma análise sobre a validade dessa mudança, podendo ser feita uma proposta mais específica de mudança nos requisitos;
2. Análise e custo da mudança – nesse estágio o efeito da mudança é avaliado junto a outros requisitos. Estima-se o custo da mudança em termos de modificação no documento de requisitos. Após ser estimado o custo, será decidido se a alteração será realizada ou não;
3. Implementação de mudanças – nesse estágio são feitas as atualizações nos documentos de requisitos de forma a refletir as mudanças que foram solicitas;

As principais preocupações do gerenciamento dos requisitos são:

• Gerenciar as mudanças nos requisitos;
• Manter a rastreabilidade entre os requisitos;
• Gerenciar os demais documentos que se relacionam aos documentos de requisitos ao longo do ciclo de vida do projeto.

Os requisitos devem ser documentados e controlados, de forma a minimizar o impacto e as dificuldades que possam vir a acontecer com as mudanças. O gerenciamento de requisitos ajuda também a evitar que funcionalidades menos importantes sejam implementadas antes daquelas com maior urgência, minimizando o impacto de alterações que possam vir a ser desenvolvidas sem a devida aprovação. Devemos também ter o cuidado com as mudanças de requisitos solicitadas com urgência, pois em muitos casos são realizadas as mudanças no sistema, deixando para fazer a mudança nos requisitos posteriormente, o que em muitas situações acabam não acontecendo por falta de tempo ou esquecimento.

Uma boa prática é antecipar as mudanças de requisitos, classificando-os para identificar quais deles são os mais voláteis e prever possíveis mudanças. Estas informações são úteis para projetar o sistema de forma que os requisitos sejam implementados com independência de componentes, minimizando assim a influência das mudanças no sistema. A utilização de métricas de software, como a APF (Análise de Ponto de Função) por exemplo, torna possível medir uma funcionalidade e determinar o tamanho das mudanças de requisitos, bem como a evolução do tamanho do sistema.

Note que o gerenciamento de mudança de requisitos se constitui numa excelente ferramenta para lidar com os requisitos voláteis, uma vez que é um processo controlado, orientado a mudanças e que possui as ferramentas necessárias para esse controle.

Rastreabilidade de Requisitos

A rastreabilidade é uma ferramenta bastante útil, pois nos ajuda a entender o relacionamento entre produtos de trabalho, sejam eles especificações de requisitos, código fonte, arquitetura do sistema, testes de softwares, entre outros, nos ajudando a garantir a integridade entre estes elementos. Em gerenciamento de requisitos, a rastreabilidade nos ajuda a entender a relação entre os requisitos definidos pelo cliente e os produtos resultantes destes requisitos como especificações, protótipos e testes.

A rastreabilidade ajuda a gerenciar os requisitos de forma mais eficaz. Diz-se que um requisito é rastreável quando é possível identificar quem solicitou o requisito, porque o requisito existe, quais os requisitos que estão relacionados com ele e como esses requisitos se relacionam entre si e com outros elementos do produto do trabalho. Todas essas informações são utilizadas para identificar quais requisitos são afetados por possíveis propostas de mudanças.

A rastreabilidade tem como principais objetivos:

• Compreender a origem dos requisitos;
• Gerenciar mudanças nos requisitos;
• Avaliar o impacto da mudança de um requisito no projeto;
• Avaliar o impacto da falha de um teste nos requisitos;
• Verificar se todos os requisitos do sistema foram implementados.

Quando um requisito muda, seus relacionamentos com outros requisitos podem ser afetados. Assim, todos os vínculos desse requisito são considerados como “vínculo de rastreabilidade suspeito”. Isso ajuda a analisar a mudança e determinar se os itens associados também precisarão ser mudados, contribuindo para uma melhor análise de mudanças que poderão vir a impactar no projeto.

Uma ferramenta bastante útil para fazer a rastreabilidade de requisitos é a matriz de rastreabilidade (ver Figura 2). Ela contém informações sobre os requisitos e a sua origem, sendo bastante útil para identificar a importância de cada um dos requisitos descritos nos documentos de requisitos e consequentemente avaliar o grau de compatibilidade das entregas com o planejado.

A rastreabilidade dos requisitos é uma forma bastante eficaz para lidar com requisitos voláteis, uma vez que dá uma visão macro do impacto desses requisitos no projeto. O mais importante é fazer com que outros requisitos tenham o mínimo possível de dependência dos requisitos voláteis, diminuindo assim o custo, retrabalho e atrasos.

Validação dos Requisitos

A validação dos requisitos se encarrega de verificar se os requisitos realmente atendem as necessidades do cliente. Durante a validação dos requisitos, a decisão sobre se um requisito possui o nível necessário de qualidade é tomada, e também, se os requisitos podem ser aprovados para uso nas demais atividades de desenvolvimento. Essa decisão deve ser tomada com base em critérios de aceitação previamente definidos. Assim, o objeto da validação de requisitos é descobrir erros nos requisitos documentados.

A validação dos requisitos é de fundamental importância para o desenvolvimento de um sistema, uma vez que é uma forma de reduzir os riscos de um requisito errado ser propagado para as demais fases do ciclo de desenvolvimento, ajudando assim a melhorar a qualidade do produto que está sendo desenvolvido. Resolver erros nos requisitos quando o sistema já está em operação implica no aumento de custos, esforço e tempo para corrigi-los.

Diferentes tipos de verificação devem ser feitos durante a validação dos requisitos. As principais são:

1. Verificações de validade;
2. Verificações de consistência;
3. Verificações de completeza;
4. Verificações de realismo;
5. Facilidade de verificação.

As principais técnicas utilizadas para validar os requisitos são:

1. Revisões de requisitos;
2. Prototipação;
3. Casos de testes;
4. Análise automatizada da consistência dos requisitos.

A validação dos requisitos é muito importante e no caso dos requisitos voláteis se torna uma ferramenta bastante eficiente, uma vez que são verificadas as consistências e validade desses requisitos. Isso faz com que os requisitos sejam priorizados de acordo com a sua criticidade, evitando desenvolver funcionalidades instáveis demais e que geram muito retrabalho.

Revisão de requisitos

A revisão de requisitos é um processo manual, onde os documentos de requisitos são examinados e lidos por alguém da equipe ou pelo próprio cliente. A revisão ajuda na validação dos requisitos, uma vez que possíveis erros de conteúdo ou interpretação são esclarecidos, a fim de evitar requisitos mal definidos, perda de informações, inconsistências, requisitos conflitantes ou requisitos irreais.

Para validar os requisitos, torna-se importante ter um roteiro. Um checklist (lista de verificação) com critérios a serem avaliados deve ser seguido. O checklist contém perguntas ou afirmações sobre uma determinada circunstância, sendo aplicado sempre que vários aspectos tenham que ser considerados em ambientes complexos, em que nenhum aspecto possa vir a ser omitido.

A aplicabilidade de um checklist e seu sucesso depende da complexidade dele mesmo. Um número muito grande de perguntas pode acabar dificultando o seu uso, já que nem sempre o avaliador tem uma visão aprofundada sobre as perguntas. É extremamente recomendável que o checklist tenha um número de perguntas que não venham a atrapalhar a sua própria utilização, e que essas perguntas não sejam demasiadamente genéricas, mas sim coesas e precisas.

Os principais objetivos de um checklist são:

• Descobrir erros de lógica ou implementação;
• Verificar que o sistema atende aos requisitos especificados;
• Garantir que o sistema seja desenvolvido de maneira uniforme;
• Desenvolver projetos mais gerenciáveis.

As questões elaboradas para o checklist de requisitos devem apontar problemas e defeitos que possam aparecer nos documentos de requisitos. A Tabela 1 lista as principais características para uma boa especificação de requisitos.

A Tabela 2 mostra questões a serem respondidas para cada uma das características mostradas na Tabela 1.

Conflitos, contradições, erros e omissões que por ventura foram encontrados, deverão ser destacados na revisão e serem formalmente registrados. A partir daí, fica a cargo dos usuários e da equipe de desenvolvimento propor e negociar soluções para os problemas identificados.

Note que o checklist para a validação dos requisitos fornece estratégias para lidar com os requisitos voláteis, ajudando no processo de gerenciamento dos requisitos.

Metodologias ágeis e requisitos voláteis

Pressões cada vez maiores por um desenvolvimento de software que se encaixe dentro do custo estipulado, com prazos cada vez menores, aliados a regras de negócio cada vez mais complexas, fez com que houvesse a necessidade de buscar um processo de desenvolvimento de software que pudesse suportar as pressões e desenvolver sistemas com qualidade e dentro dos prazos previstos.

Em 2001, um grupo de especialistas se reuniu e publicou um manifesto com uma série de princípios comuns, visando acelerar o desenvolvimento de software através da melhoria contínua do processo, gerando benefícios como o aumento da comunicação e colaboração contínua do cliente, evitando falhas na elaboração, respostas rápidas às mudanças e aumento significativo da produtividade. O manifesto recebeu o nome de “manifesto ágil”.

O manifesto ágil acabou propiciando o aparecimento das metodologias ágeis, as quais têm o objetivo de acelerar o desenvolvimento de software e garantir a qualidade do mesmo. O manifesto ágil possui os seguintes valores:

• Indivíduos e interações são mais importantes do que processos e ferramentas;
• Software funcionando é mais importante do que uma documentação extensa;
• O relacionamento com o cliente é mais importante do que a negociação do contrato;
• Responder às mudanças é mais importante do que seguir o planejamento;

Além dos quatro valores citados, o manifesto ágil também publicou doze princípios, os quais são:

• Garantir a satisfação do cliente entregando rapidamente e continuamente softwares funcionais;
• Softwares funcionais são entregues frequentemente;
• Softwares funcionais são a principal medida de progresso do projeto;
• Mudanças são bem-vindas, mesmo que ocorram tardiamente no desenvolvimento;
• Cooperação constante entre o cliente e a equipe de desenvolvimento;
• Construa projetos em torno de indivíduos motivados, propiciando a eles ambiente e suporte necessário e confiando neles para fazer o trabalho;
• Design do software deve prezar pela excelência técnica;
• Simplicidade;
• Rápida adaptação às mudanças;
• Indivíduos e interações mais do que processos e ferramentas;
• Softwarefuncional mais do que documentação extensa;
• Colaboração com clientes mais do que negociação de contratos;
• Responder a mudanças mais do que seguir um plano.

A falta de informação e a falta de experiência na utilização das metodologias ágeis tem feito com que muitos profissionais negligenciem as técnicas tradicionais de levantamento e análise de requisitos. Isso se explica devido à confusão feita com o segundo valor do manifesto ágil, o qual diz que software funcionando é mais importante do que uma documentação extensa. Ao contrário do que se pensa, as metodologias ágeis não rejeitam os processos e ferramentas, documentação, negociação de contratos e o planejamento. Longe disso, as metodologias ágeis mostram que estes itens têm uma importância secundária quando comparados com os indivíduos e interações, um software funcional, a colaboração do cliente, respostas rápidas a mudanças e interações.

As metodologias ágeis têm como foco principal entregar software ao cliente, através de entregas frequentes em intervalos de tempo mais curtos. Devido ao curto intervalo de tempo para as entregas, a documentação deverá ser criada de forma a atender apenas ao que está sendo entregue. Assim, evita-se criar uma documentação extensa, a qual conterá requisitos e regras de negócios que não sejam implementadas ou então que sejam desatualizadas.

As metodologias ágeis possuem as seguintes vantagens:

• Entregas mais rápidas, frequentes e regulares;
• Foco no que é prioritário e traz mais valor para o cliente;
• Transparência e visibilidade do status do projeto;
• Flexibilidade para as mudanças nos requisitos, antecipação dos problemas e maior agilidade na tomada de decisões;
• Melhoria da qualidade final do produto;
• Produtividade;
• Equipes auto gerenciáveis, maior autonomia, disciplina e regularidade;
• Maior comprometimento por parte dos integrantes da equipe;
• Melhoria na comunicação.

Nos métodos tradicionais de desenvolvimento de software é definido, no início do projeto, um cronograma que contém as atividades a serem realizadas durante o andamento do projeto e o prazo de conclusão do mesmo. Na prática, os prazos podem sofrer atrasos e falhar por diversos motivos. Com as metodologias ágeis esse problema praticamente não ocorre, pois os prazos são dados para que sejam desenvolvidas pequenas partes do sistema, num curto prazo. Assim, são feitas entregas que agregam valor ao sistema e ao cliente, evitando criar documentação e funcionalidades desnecessárias.

A principal ideia das metodologias ágeis é que é impossível conhecer todos os requisitos antes de começar a codificar o sistema, por isso é um desperdício de esforço tentar. Assim, as metodologias ágeis prezam por determinar o mínimo necessário para começar a implementar o sistema e suprir a falta de documentação escrita trazendo a própria fonte das informações para próximo da equipe de desenvolvimento. As metodologias ágeis são baseadas em entregas iterativas e incrementais, ou seja, são baseadas em ciclos curtos, nos quais o sistema vai sendo entregue em pedaços funcionais para o cliente. Com isso, o retorno quanto à adequação do software é obtido de maneira mais rápida, sendo mais fácil fazer correções ou adaptações de requisito.

Nas metodologias ágeis, a principal característica é a aceitação de mudança nos requisitos, planejamento do escopo e nas prioridades do projeto. Assim, deve-se focar na simplicidade e na rapidez, buscando reduzir custos e tempo quando mudanças surgirem e decidir quais providências deverão ser tomadas nessas situações. O gerenciamento dos projetos que utilizam as metodologias ágeis se preocupa em definir o escopo em um alto nível, permitindo o entendimento do trabalho. Uma vez que o escopo está definido, os requisitos são priorizados e definidos com a participação de toda a equipe do projeto e o cliente, os quais discutem e definem as funcionalidades durante cada iteração do ciclo de desenvolvimento. Essa abordagem é importante, pois reduz o efeito gold plating, ou seja, adicionar ao sistema, de forma arbitrária, funcionalidades que não foram solicitadas pelo cliente, apenas porque os desenvolvedores consideraram que o sistema necessitava da funcionalidade e que ela iria agregar algum valor ao sistema, ao invés de agregar valor ao negócio do cliente.

Assim como os processos tradicionais, os processos focados nas metodologias ágeis também precisam lidar com as mudanças que surgem ao longo do ciclo de desenvolvimento, especialmente os requisitos voláteis. Desta forma, torna-se necessário um modelo eficiente e capaz de gerenciar as mudanças e a utilização das versões dos artefatos que são geradas a cada nova funcionalidade ou mudança. A engenharia de software possui uma área que tem como objetivo controlar e gerenciar as mudanças, a qual é chamada de Gestão de Configuração de Software (GCS). Ela é capaz de atender tanto os processos formais, quanto as metodologias ágeis, propiciando o controle do processo de desenvolvimento e as mudanças do produto durante todo o ciclo de vida, permitindo que elas ocorram sem causar impacto no ambiente de desenvolvimento. O objetivo da GCS é manter a integridade dos produtos de trabalho, realizando identificação de todos os itens de configuração do software desenvolvidos, mantendo rastreabilidade das mudanças, disponibilizando informações sobre o estágio do desenvolvimento e realizando auditorias nos processos de GCS.

A adoção da GCS em ambientes ágeis é extremamente eficiente, uma vez que o software evolui de maneira segura e ordenada, disponibilizando informações sobre o estágio do desenvolvimento e auxiliando a melhoria contínua do processo de produção. Tudo isso é fundamental em um ambiente ágil, onde são feitas liberações constantes de novas versões e a absorção contínua de novos requisitos. As práticas tradicionais e o planejamento da GCS devem ser adaptados, de forma a controlar as mudanças sem comprometer a filosofia das metodologias ágeis. Para isso, deve-se adotar ferramentas que automatizem as atividades da GCS, como as ferramentas de controle de versão e mudança, uma vez que oferecem funcionalidades úteis como o versionamento automático dos itens de configuração, integração contínua e rastreabilidade das mudanças.

As metodologias ágeis contribuem significativamente para desenvolver sistemas que apresentam requisitos voláteis, uma vez que elas priorizam os requisitos que são melhor compreendidos e mais estáveis. Além disso, elas possuem uma boa aceitação em relação às mudanças, buscando resolvê-las da forma mais rápida possível, evitando implementar o sistema com erros e atrasos.

Desenvolver sistemas sem que haja mudança nos requisitos seria ideal para qualquer time de desenvolvimento. Entretanto, mudanças sempre irão ocorrer e é preciso estar preparado para recebê-las e, principalmente, como solucioná-las de forma a cumprir com o escopo e o prazo que foram acordados. A volatilidade dos requisitos influencia muito no gerenciamento dos requisitos, mas isso não é o fim do mundo. É preciso estar muito atento em relação às mudanças e se utilizar das melhores práticas da engenharia de software, de forma a contornar os problemas quando eles aparecerem e garantir o sucesso do projeto.

Confira também

Histórias de Levantamento de Requisitos

Vídeo

Por que eu preciso da UML?

Vídeo

Levantamento de requisitos

Curso