Gerenciamento e controle de mudanças de requisitos

Prévia do material em texto

www.devmedia.com.br 
[versão para impressão]
 Link original: https://www.devmedia.com.br/gerenciamento-e-controle-de-mudancas-de-requisitos/32278
Gerenciamento e controle de mudanças de requisitos
Este artigo apresenta como podemos proceder para gerenciar e controlar mudanças em requisitos
de software, considerando as definições e benefícios das estratégias apresentadas.
Por que eu devo ler este artigo:Os projetos de desenvolvimento de software caracterizam-se por apresentar alto grau de incerteza durante a fase de
levantamento de requisitos. Mesmo após os requisitos terem sido levantados e o projeto já estar em desenvolvimento, mudanças nos requisitos
podem ocorrer. Conhecer maneiras de lidar com os requisitos que mais sofrem alterações é primordial para garantir o sucesso do projeto. Este
artigo apresenta diversas formas de gerenciar e controlar as mudanças nos requisitos, principalmente os requisitos voláteis. Para cada forma é
apresentada a sua definição e seus benefícios para o gerenciamento dos 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 levantamentodos 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;
Figura 1. Gerenciamento de Mudança de Requisitos.
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.
Figura 2. Matriz de Rastreabilidade de Requisitos.
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 errosde 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.
Características Definição
Correto É correto se, e somente se, cada requisito
expresso for encontrado também no software.
Não ambíguo É não ambíguo se, e somente sem, cada
requisito declarado seja suscetível a apenas
uma interpretação.
Completo É completo se, e somente se, conter toda e
apenas a informação necessária para que o
software correspondente seja produzido.
Consistente É consistente se, e somente se, nenhum dos
requisitos do documento, tornando
individualmente, está em conflito com qualquer
outro requisito do mesmo documento.
Classificado por importância / estabilidade Se existe indicações no documento quanto à
importância ou estabilidade do requisito.
Verificável É verificável se, e somente se, para cada um
dos requisitos contidos no documento, existe
um processo finito e economicamente viável
através do qual uma pessoa ou máquina possa
assegurar que o produto de software atende ao
requisito.
Modificável É modificável se, e somente se, modificações
possam ser agregadas ao documento de forma
fácil, completa e consistente, com relação a sua
estrutura e estilo.
Rastreável É Rastreável se, e somente se, a origem de
cada um de seus requisitos é clara e a
referência de cada um deles pé facilitada nos
documentos subsequentes do processo ou em
uma melhoria da documentação do sistema.
Tabela 1. Características dos requisitos a serem avaliadas.
A Tabela 2 mostra questões a serem respondidas para cada uma das características mostradas na Tabela 1.
ITEM ITEM PARA VERIFICAÇÃO SIM NÃO
Não ambíguo: É não ambíguo se, e somente se, cada requisito declarado seja suscetível a apenas uma interpretação.
1 Cada requisito está descrito com clareza, concisão e sem ambiguidade? C 
Consistente: É consistente se, e somente se, nenhum dos requisitos do documento, tomado individualmente, está em conflito
com qualquer outro requisito do mesmo documento.
2 Existem requisitos conflitantes? 
Completo: É completo se, e somente se, conter toda e apenas a informação necessária para que o software correspondente seja
produzido.
3 Existem requisitos implícitos? 
4 Os requisitos exibem a distinção clara entre funções, dados e restrições? 
5 As restrições e dependências foram claramente descritas? 
6 Existem requisitos que contêm algum nível desnecessário de detalhe do projeto? 
7 Os requisitos definem todas as informações a serem apresentadas ao usuário? 
8 S requisitos descrevem as respostas do sistema ao usuário devido às condições de erro? 
9 Existem situações não tratada pelos requisitos que precisam ser consideradas? 
10 O documento contém realmente toda a informação prometida em sua introdução? 
Tabela 2. Exemplo de checklist para avaliação de requisitos
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.
Referências
AGILE ALLIANCE, Manifesto for agile software development
 http://www.agilemanifesto.org
ENGHOLM, Hélio, Engenharia de Software na Prática, 1 ª. ed , São Paulo, Novatec, 2010.
MACEDO, P. C., Sbrocco, T. C., Henrique, J., Metodologias Ágeis: Engenharia de Software Sob Medida, 1 ª. ed, Érica, São Paulo,
2012.
PRESSMAN, Roger S., Engenharia de Software, 6 ª. ed, São Paulo, McGrawHill, 2006.
SOMMERVILLE, Ian, Engenharia de Software, 8ª. ed, São Paulo, Addison-Wesley, 2007.