UNIDADE 3 - Gerenciamento de Requisitos Ampli

Prévia do material em texto

Introdução
Por décadas, acreditava-se que o escopo de um sistema seria o único norte para o sucesso no desenvolvimento de software. Compreendia-se por escopo todas as funcionalidades mapeadas de um sistema e que não sofressem alterações até que o projeto fosse concluído e entregue.  
Atualmente, a lista de funções de um software faz parte de requisitos de sistema, junto a outras especificações, que podem alterar inúmeras vezes ao longo da vida útil do sistema. 
Você perceberá que nesse cenário volátil é que se faz tão necessário o gerenciamento, o controle de mudança e a revisão de requisitos para manter a disponibilidade de um software que atenda aos negócios de uma organização, da sociedade ou de um indivíduo.
Conforme Reinehr (2020, p. 33), “a velocidade do mercado exige que novos produtos ou funcionalidades sejam lançados cada vez mais rápido”.
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática.  
Bons estudos!
Processos de qualidade na engenharia de requisitos
Estar com o sistema sempre em funcionamento, sendo útil aos negócios e aos usuários, com uma boa qualidade, seria considerado um bom nível de satisfação para muitos. Porém, ainda pode ter alguém que diria que não ficou da forma que havia sido combinado. Afinal, o desafio é enorme para quem quer gerenciar um projeto de desenvolvimento de software e atender a todos os critérios ou a todas as pessoas envolvidas.   
Processos de qualidade na Engenharia de Requisitos 
Adotar atividades adequadamente ajustadas ao nível de conhecimento do time de desenvolvimento favorece obter requisitos com qualidade. Para tanto, é importante conhecer processos de qualidade na Engenharia de Requisitos. As principais atividades para obter a qualidade dos requisitos, segundo MPS.BR (2021), é definir, gerenciar e manter atualizados os requisitos das partes interessadas e do produto, conforme ilustrado na Figura 1
Fonte: elaborada pelo autor.
Ao definir um requisito, deve-se concebê-lo visando à clareza necessária para a compreensão de todos os envolvidos, em especial, o usuário final e os responsáveis pelo desenvolvimento do software. O uso de técnicas adequadas para elicitar requisitos é fundamental nesta fase do projeto, tanto para garantir que uma regra de negócio será implementada por uma funcionalidade quanto para a validação na etapa da entrega do aplicativo.  
Ao gerenciar requisitos, o responsável deverá ter a certeza de que suas funções previstas estão planejadas para serem incorporadas no aplicativo; ao longo do ciclo de desenvolvimento, monitorar para que o requisito seja fielmente implementado e que, ao final, o produto contenha integralmente o requisito com a qualidade desejada pelo cliente ou usuário, validando a efetividade de uso em operação. No curso do desenvolvimento, caso tenha sido necessária a implementação parcial, outro requisito deverá ser descrito com o devido vínculo para garantir que será complementado em outra versão futura do aplicativo. 
Sabe-se que o requisito poderá sofrer modificações naturalmente pela demanda dos negócios, portanto as funcionalidades do aplicativo devem sofrer modificações, o que corresponde à fase de manter o requisito.  
Controle de mudanças de requisitos 
As mudanças de requisitos requerem um cuidado especial para que o software seja devidamente alterado mesmo após inúmeras manutenções terem sido aplicadas em outras funcionalidades relacionadas. Portanto, o controle de mudanças de requisitos se faz necessário para analisar o impacto antes mesmo da implementação da alteração no software.  
Partindo do princípio de que as regras de negócio sofrem alterações constantes, os princípios do DevOps (Desenvolvimento e Operações) têm sido aplicados com sucesso em organizações que adotam o CI/CD (Continuous Integration/Continuous Delivery) para entregar as funcionalidades requeridas pela operação do sistema com maior brevidade possível. Neste caso, segundo Pressman e Maxim (2021), praticando uma abordagem com ciclos contínuo, foco em qualidade no processo de construção e entrega de software. Dentre as soluções do DevOps, constata-se o TDD (Test Driven Development) e XP (eXtreme Programming).  
Revisão de requisitos 
Para que uma equipe possa aumentar a qualidade de requisitos, deve-se efetuar a revisão de requisitos. Para tanto, conheça a proposta de Verificação & Validação, segundo Hirama (2012, p. 105):  
[...] determinar se os requisitos de um sistema ou componente estão completos e corretos, os produtos de cada fase de desenvolvimento atendem aos requisitos e às condições impostas pela fase anterior e o sistema ou componente final está aderente com os requisitos especificados. (HIRAMA, 2012, p. 105) 
Você percebeu que com atenção e a metodologia adequada é possível gerenciar as mudanças constantes de requisitos, então continue aprofundando e colocando em prática o que conheceu por aqui.  
Bons estudos!
Controle de mudanças de requisitos
Ao se deparar com uma dúvida de como os processos da Engenharia de Requisitos poderão aprimorar a qualidade dos requisitos e, consequentemente, a qualidade do software, lembre-se de que a melhor maneira de obter o máximo em qualidade nos requisitos de software é conhecer as diversas características que eles possuem, compreender o que pode influenciar na criação ou na mudança de um requisito de sistema e ter habilidade em processos e ferramentas que auxiliarão no gerenciamento de todas essas variáveis. Em seguida, colocar em prática os processos, usando ou não ferramentas que contribuirão na gestão de mudanças de requisitos.  
Se o usuário de um sistema está solicitando um novo requisito, por exemplo, “ao alterar o horário da agenda da consulta para o paciente, o médico ou o laboratório deve receber uma mensagem e um e-mail com a nova informação, bem como o paciente também receberá um comunicado pelo sistema de mensagem”, deverá proceder a definição dele de forma completa e obter a comprovação do entendimento por parte de quem solicitou o novo requisito. 
Sentindo a necessidade de conhecer melhor a solicitação do usuário, deve-se marcar um encontro presencial com a participação de especialista para elicitar os detalhes técnicos ou métodos adequados ao processo a ser implementado, conforme ilustrado na Figura 2. 
Fonte: elaborada pelo autor.
Através desta providência, amplia-se o grau de confiabilidade do time de desenvolvimento para implementar o novo requisito funcional. Assim, colocará em prática a sua evolução em competência e habilidade, com base no conhecimento vivenciado de pesquisadores experientes em diversos setores da economia e da sociedade.  
Pressman e Maxim (2021, p. 312) destacam fatores relevantes sobre processos de desenvolvimento de software, em que a
“gestão de qualidade efetiva estabelece a infraestrutura que dá suporte a qualquer tentativa de construir um produto de software de alta qualidade”.
Os autores ainda complementam sobre o requisito:
“ele satisfaz a um conjunto de requisitos implícitos que se espera de todo software de alta qualidade”.
E por consequência, dentre os pontos da qualidade,
“permite que os engenheiros de software despendam mais tempo criando aplicações novas e menos tempo em manutenções”. 
Quando se obtém o requisito detalhado, torna-se mais apropriado e seguro para a elaboração dos cenários de teste quanto na massa de dados que utilizará para validar o aplicativo, dando continuidade ao processo do desenvolvimento, assim que o código-fonte estiver liberado para a fase de Continuous Deployment e revisão de requisitos. 
Durante a revisão do requisito, deve-se convocar o especialista que auxiliou na complementação do requisito para a devida validação da funcionalidade implementada e que será entregue ao cliente. Com essa providência, evidenciará que a correlação entre a qualidade de um software é diretamente associada às funcionalidades. Para Pressman e Maxim (2021, p. 311), as funções especificadas no modelo de requisitos são essenciais para elevar a qualidade do projeto de software. Os autores ainda complementamque a qualidade de software depende da conformidade entre os requisitos do produto e a satisfação do cliente. 
Chegando ao final deste bloco, você viu que vale a pena manter o foco na qualidade e no detalhamento do requisito, então coloque esses conhecimentos em prática em suas atividades. 
Bons estudos! 
Revisão de requisitos
Você deve estar pensando em como manter as boas práticas dos processos da qualidade, do controle de mudanças de requisitos e da revisão de requisitos. Então, analisaremos como aplicar os conceitos conhecidos. 
Na clínica médica CLINIREQ, os dados são controlados por um aplicativo, instalado em nuvem, sendo possível acessar pelos funcionários, médicos associados e clientes/pacientes com login. O sistema possui grandes vantagens reconhecidas pelos usuários pela confiança, pela assistência, pelo poder de decisão e pela simplicidade, sendo que os fatores de qualidade foram conquistados ao longo de décadas no segmento de negócios. Dentre esses fatores para o time de desenvolvimento, estão: equilíbrio da documentação, proporcionando a localização de requisitos e módulos, a facilidade de manutenção das funcionalidades e o conforto para refatoração dos itens de software. Por outro lado, para a equipe de operação (usuários e time da infraestrutura), aponta-se a rapidez na implantação, a fácil assimilação, a confiança na utilização e a evolução constante, conforme exige o negócio da saúde, entre outras. 
O desafio dos times de desenvolvimento e de operações está em escolher as melhores alternativas durante a execução das novas demandas, corrigir bugs que nunca pararam de ser encontrados pelos usuários e atender ao exigente segmento de médicos e pacientes em clínicas que dependem de aplicações de alto valor agregado. 
Imagine-se aceitando a implementação de novas funcionalidades e as mudanças em outras com metas de curtíssimo prazo. Dentre os novos requisitos, estão: RF (requisito funcional), inserção de fotografia e reconhecimento por impressão digital do paciente e controle de confirmações de consultas através de e-mails e sistema de mensagens. Pelas modificações, solicitaram nos RFs agenda de compromissos e exames e procedimentos na Sala Virtual de Espera (SVE).  
Faça uma demonstração da funcionalidade durante a validação da aplicação utilizando dados reais acessando um cadastro já existente, agora incluindo uma fotografia diretamente da webcam, validando a operação de acordo com o requisito funcional descrito. Para complementar a validação da nova implementação, deve-se repetir o processo, porém, durante a inclusão de um novo paciente, associar a fotografia dele.  
A implementação da nova funcionalidade é relativamente pequena para um sistema que gerencia todos os departamentos de uma clínica, e não foram percebidas dificuldades técnicas para a codificação e a integração dos métodos e/ou das funções. Contudo, a análise de impacto deve ser realizada antes do início da efetiva construção. Como exemplo, pode-se analisar o aspecto do design, se existe implementação com tratamento de imagem e que poderia ser reutilizada, assim aumentaria a qualidade dos artefatos ao final do processo. Outro exemplo que se poderia analisar é o impacto em espaço a ser ocupado pelas imagens das fotografias em função da quantidade de pacientes existentes e os novos esperados nos próximos meses, inclusive, seria o caso de conferir qual a resolução/qualidade da imagem a ser armazenada.   
Através dessa análise de pouco esforço, sem perder os propósitos da Engenharia de Requisitos, pode-se evitar chances de futuros riscos, principalmente se tratando do procedimento CI/CD, no qual a participação de desenvolvedores e de responsáveis da infraestrutura de operações está atuando ao longo do ciclo de vida nas atividades do projeto. 
Com isso, encerramos esse terceiro bloco, no qual você verificou que é importante estar preparado para se comunicar com os responsáveis pela operação do sistema, conhecer as regras de negócio e acompanhar as mudanças de requisitos. Sendo assim, continue se dedicando nas competências e colocando suas habilidades em prática no gerenciamento de requisitos. 
Bons estudos! 
Saiba mais
As validações das implementações entre requisito e funcionalidade no software estão cada vez mais eficientes com o ambiente de desenvolvimento em nuvem, o que facilitou também o gerenciamento da integração e entrega contínua. O processo de validação acrescentará mais valor ao software, pois é uma oportunidade para um feedback dos usuários em tempo real.  
Visite e leia o artigo sobre este assunto: itens 7.8, 12.5 e 12.7 do livro de Pressman e Maxim (2021). 
Referências
HIRAMA, Kechi. Engenharia de Software. Rio de Janeiro, RJ: Elsevier Editora, 2012. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788595155404/. Acesso em: 28 maio 2022.  
MPS.BR. Melhoria de Processo do Software Brasileiro Guia Geral MPS de Software. Softex, 2021. Disponível em: https://softex.br/download/guia-geral-de-software-2021/. Acesso em: 28 maio 2022.  
PAULA FILHO, W. de P. Engenharia de Software – Produtos – Vol. 1. Rio de Janeiro, RJ: LTC, 2019. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788521636724/. Acesso em: 28 maio 2022.  
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Porto Alegre, RS: AMGH Editora, 2021. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em: 26 maio 2022.  
REINEHR, S. Engenharia de Requisitos. Porto Alegre, RS: SAGAH, 2020. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786556900674/. Acesso em: 26 maio 2022. 
Introdução
Havia um entendimento de que requisito era apenas usado para documentar o que seria desenvolvido no aplicativo e que esta documentação seria a única fonte ao longo do projeto de software, da análise à validação do sistema. 
Com o envolvimento de muitas pessoas e inserido em um ambiente altamente competitivo, em que as necessidades mudam diariamente, nesse mundo moderno e interconectado, ter o requisito devidamente documentado ao modelo tradicional já não atende à realidade tão dinâmica. 
Para tanto, um padrão tem sido praticado na gestão de requisitos concomitante aos processos da engenharia de software visando estar com requisitos constantemente aderentes aos negócios do ambiente onde ocorre as operações do sistema. 
Assim, é possível garantir aos usuários a manutenção do sistema através do gerenciamento dos relacionamentos entre os requisitos e da organização dos requisitos.  
Compreenderemos melhor e aprenderemos a aplicar esses conceitos. Bons estudos!
Padronização de processos na gestão de requisitos
Visando manter os requisitos com bom nível de qualidade para o uso pelos desenvolvedores, algumas atividades devem partir da gestão de requisitos. Neste caso, o time de desenvolvedores, com a participação direta dos usuários responsáveis pela operação, deve adotar processos padronizados para a correta especificação e finalidade. Para Vazquez (2016), os processos que intercalam atividades da Engenharia de Requisitos na exploração da profundidade do produto, detalhando o seu comportamento esperado, alcançam maior aderência das funcionalidades do software aos negócios da organização operadora do sistema.  
A cada iteração do ciclo do desenvolvimento de um software, é fundamental que aconteça a interação entre os responsáveis pela operação e o time de desenvolvimento, a fim de explorar com profundidade o comportamento esperado do sistema, para requisitos novos ou em mudanças, conforme ilustra a Figura 1. 
Fonte: elaborada pelo autor.
Com foco na eficiência da gestão de requisitos, é imprescindível implantar um processo padronizado para o devido tratamento dos requisitos, sendo que a metodologia para especificação do requisito é menos importante para Vasquez (2016), seja por descrição da história do usuário ou por diagrama de caso de uso, mas que tenha o aprofundamento necessário para compreender o relacionamento que existe entre eles.  
A atividade de organização dos requisitos é de grandeimportância para que os interessados se localizem entre os requisitos relacionados e sua prioridade de implementação, entendendo que o mapeamento completo entre requisitos e seus relacionamentos deve preceder o estabelecimento da priorização para escolha na ordem de implementação. Previsto também em processos de padrão de qualidade.
Conforme MPS.BR (2021, p. 27), “atividades e produtos de trabalho relacionados são revisados visando identificar e tratar inconsistência em relação aos requisitos”. 
O que não pode ficar de fora deste detalhamento é a percepção quanto aos requisitos ditos não funcionais, tendo em vista que estes podem proporcionar aumento em segurança, produtividade e escala para muitos negócios superconectados. Hirama (2012, p. 170) entende que deve ter um entendimento claro do relacionamento entre os requisitos e que
“os interesses podem ser divididos em interesses centrais (requisitos funcionais) e interesses transversais (requisitos não funcionais). Os interesses transversais causam o espalhamento, enquanto o entrelaçamento é uma consequência desse espalhamento”.  
Para melhor compreender algumas das atividades, a Figura 2 ilustra um processo padrão para a gestão de requisitos de qualidade. 
Fonte: elaborada pelo autor.
Assim, considera-se que, quanto maior a profundidade dos requisitos e dos relacionamentos entre eles, maior é a necessidade de procedimentos adequados para revisão e organização dos requisitos para submeter ao desenvolvimento de software. O relacionamento entre requisitos pode ser pela dependência funcional em função dos resultados em que determinará a priorização no desenvolvimento das funcionalidades. Para tanto, a classificação dos requisitos é fundamental para que eles possam ser identificados corretamente quanto à volatilidade, ao impacto sobre a arquitetura e ao risco.  
Você chegou ao final do primeiro bloco e viu que, através da adequada classificação, se torna possível a tão desejada organização dos requisitos para facilitar o acesso, a compreensão e a implementação, bem como mantê-lo atualizado ao longo do projeto e da vida útil do sistema. Agora, comece colocar em prática essa competência. Bons estudos!
Gerenciar os relacionamentos entre os requisitos
Partindo do princípio de que você está em contato direto com as pessoas interessadas no sistema, essa será a base para manter os requisitos atualizados e as organizações competitivas. Você perceberá que é possível manter os requisitos como fonte segura no desenvolvimento de software, desde que se executem procedimentos que colaboram com a manutenção deles: padrões, organização e gerenciamento dos relacionamentos entre os requisitos. 
Se um requisito implementa uma regra que altera quando um fator externo impõe mudanças, por exemplo, alteração de taxas do governo (municipal, estadual, federal ou internacional) tem impacto direto na aplicação que se utiliza desta regra para desempenhar os seus negócios, reflita sobre mudanças no processo tarifário da importação de produtos em que a sua organização atua. 
Numa situação em que se recebe a comunicação de que a alteração será realizada e há um prazo para realizar a adaptação, as primeiras atividades devem estar associadas ao entendimento da nova regra, a fim de compreender se haverá impacto na aplicação e qual a extensão dela. Assim, entenda como proceder as atividades padronizadas para manter os requisitos devidamente organizados, com os relacionamentos entre eles, conforme ilustra a Figura 3. 
Fonte: elaborada pelo autor.
Se é uma mudança de requisito, deve-se executar a atividade “Definir”, conferindo se realmente essa nova regra de negócio não fere as existentes, ou talvez necessite criar um requisito relacionado a outro existente. Enquanto “Explorar com aprofundamento” é considerada uma atividade altamente importante em função do detalhamento necessário em impacto às necessidades reais para o funcionamento dos negócios. Muitas vezes, é recomendável a participação de especialistas no assunto (podendo ser das áreas de contabilidade, economia, analista de comércio exterior, relações internacionais, entre outras).   
Tratando-se de um requisito complexo, este poderá ter de alto risco em sua implementação. Conforme declarado por Reinehr (2020, p. 27),
“é importante lembrar que a extensão da análise de requisitos vai variar de acordo com a criticidade do software e qual o seu papel dentro do contexto no qual está inserido”.  
Portanto, identificar as reais características do requisito durante essa etapa é imprescindível, inclusive para efetuar a correta classificação dele, o que tornará muito favorável na execução da atividade “Revisar relacionamentos” entre os demais requisitos que podem ou não estar em operação. 
As opiniões e considerações feitas pelos especialistas são fundamentais para determinar o relacionamento entre os requisitos, bem como entender e determinar a prioridade dele para a implementação quando estiver executando a atividade “Organizar”, em que estará com os requisitos prontos para serem utilizados pelos interessados para cumprir as próximas fases da construção ou integração do software.  
Uma característica bastante marcante que os líderes e gestores priorizam está relacionada aos requisitos (funcional ou não funcional) que agregam valor aos negócios, ou seja, esta é uma das classificações que se deve considerar ao priorizar e organizar.
Segundo Pressman e Maxim (2021, p. 40), a “abordagem iterativa capacita o cliente a avaliar o incremento de software regularmente, fornecer o feedback necessário para a equipe de software”
facilitando desenvolvedores e responsáveis pela operação do sistema na organização adequada dos requisitos. 
Muito bom saber que você concluiu o segundo bloco e percebeu que é fácil organizar os requisitos. Agora, “mãos à obra”, pratique e amplie suas habilidades com esses conhecimentos. 
Bons estudos!
Procedimentos de organização de requisitos
Na agricultura, cada vez mais a Tecnologia da Informação (TI) tem dado um tom diferente e moderno, principalmente no que se refere ao mapeamento e ao manejo de lavouras de grande escala. Você está participando de uma realidade no campo, em que será implementada uma função especializada para informar a situação do solo durante os dois próximos anos. 
Com o foco em praticar a organização, o gerenciamento do relacionamento entre requisitos e os processos da gestão de requisitos, compreenda como as atividades poderão ser executadas neste desafio de uma situação da realidade no campo. Para saber mais sobre o assunto, leia um artigo sobre "Tecnologia no campo: 5 tecnologias no campo para facilitar a vida do agricultor".
A empresa REQAgro inicia a transição do processo manual para o automatizado via IoT (Internet of Things) para a nova funcionalidade do seu sistema: a leitura e o registro da situação do solo em vários pontos ao longo de sete mil hectares (7.000 ha). Os pontos foram estrategicamente escolhidos em função de um histórico de medições (até então feitas manualmente), mas que sofrerá uma ampliação em função dessa facilidade que a TI proporciona. Esta funcionalidade tem o objetivo de aumentar consideravelmente a quantidade de pontos de coleta.  
Fonte: Unspash.
Numa rápida projeção com a nova funcionalidade, hipoteticamente, os agrônomos estão prevendo aumentar em 10% a produção agrícola e gastar cerca de 12% a menos em insumos, especificamente para correção do solo. Esse é um excelente panorama para classificação do requisito quanto ao valor que agregará aos negócios. 
Ao se aprofundar no requisito, poderá perceber se o equipamento (hardware e software) a ser instalado na captura dos dados tem acesso à internet e qual será o protocolo de comunicação, frequência e dados a serem transmitidos, entre outros detalhes. Conforme comentado por Reinehr (2020), sistemas complexos, envolvendo hardware e software, precisam de uma etapa de análise de requisitos mais aprofundada. 
Quanto ao relacionamento entre outros requisitos funcionais (em operação e outros planejados para serem implementados),você verificará que tem relação com o plano de aplicação de insumos para correção do solo e o plano de plantios, o qual, por sua vez, poderá se diferenciar pela cultura (milho, soja, trigo ou milheto) a ser desenvolvida na próxima safra.  
Agora que está vencendo o desafio para a organização do novo requisito através de processos da gestão de requisitos, compreende-se que a participação dos gestores e dos agrônomos foi fundamental para se aprofundar no requisito e identificar os principais requisitos relacionados. Aqui, fica claro que as partes interessadas devem ser convocadas na fase do gerenciamento das relações entre requisitos. 
Fonte: elaborado pelo autor.
No Quadro 1, percebe-se que o #3 Apuração dos insumos para correção do solo e #4 Geração da produtividade da safra deverão sofrer modificações (manutenção evolutiva) para atender à nova funcionalidade a ser desenvolvida. Enquanto o requisito #5 Geração da qualidade da safra requer atenção em função de estar planejado para ser implementado.  
O resultado esperado pela organização dos requisitos pode variar de acordo com a metodologia ou as restrições que o projeto poderá impor, porém é imprescindível que obtenha a segurança dos dados analisados até o presente momento e do próximo passo no desenvolvimento de um software. 
Com isso, encerramos o terceiro bloco, mas você pode continuar se atualizando sobre a gestão de requisitos e colocar em prática as habilidades na definição, exploração, revisão e organização de requisitos.  
Bons estudos! 
Saiba mais
Compreender como explorar com aprofundamento os requisitos de um sistema estudando os itens 7.2.1 (Identificação de envolvidos), 7.2.3 (Trabalho em busca da colaboração) e 7.2.5 (Requisitos não funcionais), publicados em Pressman e Maxim (2021, p. 107-109). 
Referências
HIRAMA, Kechi. Engenharia de Software. Rio de Janeiro, RJ: Elsevier Editora, 2012. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788595155404/. Acesso em: 28 maio 2022.  
MPS.BR. Melhoria de Processo do Software Brasileiro. Guia Geral MPS de Software. Softex, 2021. Disponível em: https://softex.br/download/guia-geral-de-software-2021/. Acesso em: 28 maio 2022.  
PAULA FILHO, W. de P. Engenharia de Software - Produtos - Vol. 1. Rio de Janeiro, RJ: LTC, 2019. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788521636724/. Acesso em: 28 maio 2022.  
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Porto Alegre, RS: AMGH Editora, 2021. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em: 26 maio 2022.  
REINEHR, S. Engenharia de Requisitos. Porto Alegre, RS: SAGAH, 2020. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786556900674/. Acesso em: 26 maio 2022.  
VAZQUEZ, C. E.; SIMÕES, G. S. Engenharia de Requisitos. Rio de Janeiro, RJ: Brasport, 2016. Disponível em: https://plataforma.bvirtual.com.br/Leitor/Publicacao/160193/epub/0. Acesso em: 08 jun. 2022.
Introdução
Sabe-se que os requisitos são condições com as quais o sistema deve estar de acordo. Ao falarmos de gerenciamento de requisitos, referimo-nos a uma abordagem sistemática, da qual se extraem, organizam e documentam-se requisitos de um sistema. Estes requisitos podem sofrer alterações durante o desenvolvimento, portanto eles devem ser mantidos em um processo controlado, visando garantir a qualidade do sistema. 
Toda mudança deve ser analisada e avaliada dentro de um processo de monitoramento dos requisitos, em que a evolução deles segue tipicamente gerenciada por modelos de natureza incremental.  
Segundo Pressman e Maxim (2021, p. 122), "o desenvolvimento incremental implica a necessidade de validação incremental. O monitoramento de requisitos dá suporte à validação contínua por analisar modelos de meta do usuário em relação ao sistema em uso"
ou seja, além de outros diversos fatores agentes de alterações, podemos citar a avaliação contínua da satisfação do usuário utilizada como feedback para aprimoramentos de requisito. 
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática. Bons estudos!
Processos de monitoramento de requisitos
Por mais que você seja acurado durante a definição e especificação dos seus requisitos, sempre haverá mudanças neles. A mudança dos requisitos é inerente ao processo de gerenciamento deles, mas toda e qualquer alteração deve sempre ser analisada, avaliada e justificada, procurando encontrar formas de implementação eficientes e que acarretem o mínimo de custo, impacto e esforço possível.  
Processo de monitoramento de requisitos 
Durante o processo de monitoramento de requisitos, deve-se estar capacitado a refinar as características do sistema identificando a ordem de prioridade de suas funcionalidades, bem como o caráter de urgência e a volatilidade de cada uma delas. O gerenciamento dos requisitos, principalmente aqueles que tendem à volatilidade, é uma tarefa complexa: um requisito alterado não implicará somente mais ou menos tempo gasto na implementação da funcionalidade de um determinado recurso, mas também poderá impactar outros requisitos. Fatos importantes no monitoramento é saber as causas que motivam a mudança do requisito, sendo uma tarefa que poderá auxiliar no seu monitoramento e nas decisões das ações. Como citado por Reinehr (2020, p. 261), podendo ser
“um erro, ele terá, obrigatoriamente, que ser corrigido antes que prossiga para a implementação”
de novos requisitos; ou ainda
“quando se tratar de uma melhoria ou de um novo requisito, pode ser que a opção seja pela não implementação ou pelo adiamento da alteração para versões posteriores do produto”. 
 Gerenciamento de mudanças de requisitos 
Dentro da metodologia ágil, em particular o Scrum (um framework da metodologia ágil), as mudanças de requisitos são discutidas e priorizadas para constituírem o Backlog da Sprint (lista principal de um projeto de desenvolvimento), dentro de uma Sprint ao invés, não são aceitas mudanças (HIRAMA, 2012, p. 54). É comum serem realizadas reuniões de demonstração das atividades realizadas e uma retrospectiva dos principais pontos a serem considerados no final de cada Sprint, seguidos de uma reunião de planejamento para a próxima Sprint, em que poderão ser consideradas as mudanças de requisitos, bem como seu impacto em posteriores características do sistema. Tais passos são realizados iterativamente, ou seja, são repetidos em ciclos de 1 a 4 semanas, como ilustrado na Figura 1. 
Fonte: elaborada pelo autor.
Segundo o IEEE (1998), a Engenharia de Requisitos, que comporta a atividade de gerenciamento de requisitos, integra a aquisição, o processo de refinamento e a verificação das exigências de negócio por meio de técnicas bem definidas, organizadas e de aspecto iterativo. Essas são usadas para assegurar que os requisitos sejam consistentes, substanciais e que atendam às necessidades do cliente em ordem de preeminência.   
Boas práticas de gerenciamento de requisitos 
É necessário constatar que a definição detalhada dos requisitos do sistema seja pouco propensa a alterações e que sejam utilizados links de rastreabilidade para caracterizar as dependências entre os requisitos e outras atividades presentes durante o processo de desenvolvimento. Pensando mais a longo prazo, a consolidação das estruturas nos obriga à análise das direções preferenciais no sentido do progresso. A nível organizacional, a determinação clara de objetivos causa impacto indireto na reavaliação dos métodos utilizados na avaliação de resultados. 
O gerenciamento de mudanças se torna, portanto, altamente recomendável e inclui atividades, como estabelecer uma linha de base do projeto, determinar quais dependências devem ser estabelecidas, determinar as relações entre os itens e, por fim, o controle de mudanças. Em todo surgimento de mudança, faz-se necessário avaliar o impacto causado por esta.  
Segundo Pressman e Maxim (2021, p. 442), a gestão do impacto envolve dois aspectos principais: garantir que sejam utilizadas estratégias que diminuam o impactode ações de outros desenvolvedores em seu próprio trabalho e utilizar técnicas que minimizem o impacto de suas atividades em trabalhos de outros colegas. Tais ações são fundamentais e se complementam, garantindo, assim, uma boa prática no gerenciamento de mudanças e na própria gestão dos requisitos em si. 
Concluindo o primeiro bloco, já foi possível ver que o monitoramento de requisitos é contínuo em qualquer metodologia, seja tradicional ou ágil, portanto, é imprescindível que faça bom uso do monitoramento para manter os requisitos prontos para o desenvolvimento.  
Bons estudos! 
Gerenciamento de mudanças de requisitos
São diversas as causas que contribuem para falhas em projetos de software, e todas estão inter-relacionadas, devendo-se dar igual importância, porém é nítido perceber que a má gestão dos requisitos está entre as motivações mais críticas de um projeto que apresentou defeito. A consequência de uma má gestão de requisitos implica a definição de funcionalidades ao sistema que não traduzem a real necessidade dos usuários ou dos negócios, gerando retrabalho, retardando as entregas e aumentando os custos e, principalmente, a insatisfação do usuário com a aplicação.  
Um bom gerenciamento de requisitos abrange as atividades e os processos de mudança de requisitos, controlando a evolução destes dentro de um sistema de informação. A alteração de um requisito se dá tanto pela constatação de uma nova necessidade quanto pela descoberta de falta de eficiência em um requisito já registrado. O gestor responsável pela definição do requisito deve ter em mente que a ligação entre os requisitos através da rastreabilidade desses é um fator crítico, e estes devem estar corretamente correlacionados.  
Supondo que um software, em desenvolvimento, recebe uma requisição para mudança de idioma do sistema, ou seja, inicialmente, esteja previsto num requisito que será disponibilizado nas línguas portuguesa e inglesa. Durante o seu desenvolvimento foi constatado que, para atender às necessidades de atuação no mercado italiano, além dos idiomas em implementação, será necessário incluir a tradução automática do conteúdo existente para a língua italiana também. 
Lembrando que a análise do impacto faz parte de uma boa prática para a gestão de requisitos voláteis, portanto se demonstra necessário fazer uma avaliação do impacto causado pela solicitação de tal mudança, conforme exemplificado no Quadro 1: 
Fonte: elaborado pelo autor
A adoção da boa prática de verificação do menor impacto incluída no processo formal de gerenciamento de mudanças faz com que todas as alterações propostas sejam tratadas de forma consistente e controlada. Todo sistema deve ser desenvolvido de modo que seja possível controlar as alterações, visando ao menor impacto resultante do processo de mudança.  
Sugerem-se, então, as seguintes etapas: 
· Análise do problema: identificação do problema, qual seu impacto em outros requisitos no projeto e detalhamento de suas características. 
· Análise do custo: estimativa do custo da mudança e viabilidade. 
· Atualização dos documentos necessários: atualizam-se os documentos de forma a refletir as mudanças que foram solicitadas. 
Em particular, no que se refere ao custo de uma alteração, Pressman e Maxim (2021) argumentam que, com a adoção de um processo ágil bem elaborado é possível reduzir os custos e esforços significativamente em um projeto de software, devido às entregas incrementais propostas nestes.   
Deve ficar atento ao que as metodologias ágeis propõem, não confundindo evitar documentações extensas com negligenciar as técnicas de levantamento e análise de requisitos por meio de ferramentas, processos, planejamentos e documentações. Estes, por sua vez, não são rejeitados, mas, sim, colocados em segundo plano no que diz respeito às interações com o cliente, a fim de entregar um software funcional com resposta rápida às mudanças. Em virtude do curto intervalo de tempo para as entregas, as documentações devem atender apenas ao que está sendo entregue, evitando documentações extensas e desatualizadas.  
Muito bom saber que concluiu o segundo bloco, agora já percebeu que é possível gerenciar os requisitos e quanto será útil para o desenvolvimento de software de qualidade. Se ainda não está aplicando na prática, está pronto para começar esta experiência. Bons estudos! 
Boas práticas de gerenciamento de requisitos
Vivencie nesse bloco uma dinâmica em mudanças de requisitos no ambiente de operações de sistemas de informações no setor de saúde, em especial, no departamento de pronto atendimento de uma unidade hospitalar. Assim, pode-se perceber o uso do gerenciamento das mudanças de requisitos e as boas práticas de processos de mudanças de requisitos, principalmente em sequência de constantes modificações. 
Ao receber a mudança de requisitos de uma regra de negócios do atendimento de pacientes na clínica ortopédica Orto EH, o Product Owner verifica que esse requisito foi alterado recentemente. Neste caso, verifica-se que é a quinta vez que está sendo modificado em um mês. O requisito trata da prioridade no atendimento em função da modalidade do paciente, do diagnóstico no pré-atendimento, na ocupação atual das posições do atendimento e da disponibilidade de profissionais na especialidade. 
Entenda aqui o que se passa na Orto EH, as mudanças na estrutura organizacional e as peculiaridades do setor, num cenário em que mais de 1.200 atendimentos são realizados diariamente, nada pode sair do controle e tudo deve estar bem ajustado aos operadores do sistema e aos pacientes. Inclusive, outros interessados, como a Agência Nacional da Saúde e os planos particulares de saúde, aos quais o estabelecimento deve apresentar relatórios rotineiros. 
As especificidades de cada atendimento são inerentes às dependências de cada parte interessada. Desde os tipos de atendimento, datas de histórico de atendimento, dados de acompanhantes, valores e dados dos procedimentos, entidades de regulamentação, entre outros. Sendo assim, num processo de atendimento a pacientes, podem existir inúmeras diferentes regras para serem operacionalizadas em um curto espaço de tempo (durante a recepção do paciente) e antes do início da consulta pelo médico.  
O monitoramento fica evidente quando se percebe a modificação de um requisito que foi desenvolvido e entregue (que esteja em plena operação), e até mesmo aquele que fora desenvolvido, mas que ainda não tenha sido entregue. Outra característica detectada no monitoramento é a identificação de que o mesmo requisito tenha sofrido outras modificações.  
No cenário apresentado, a modificação do requisito no atendimento do paciente está no registro de um tipo de diagnóstico que fora exigido por um convênio particular, o que pode levar a ter necessidade de adaptação em outros requisitos. As atividades de verificação dos requisitos relacionados são imprescindíveis para garantir que a modificação num requisito terá impacto a vários outros, o que pode ser percebido pela Figura 2.
Fonte: elaborada pelo autor.
A limitação na capacidade de desenvolvimento é natural em qualquer organização, pois os recursos são determinados por pessoas e pelo orçamento, o que leva à necessidade de escolher quais modificações (requisitos alterados) serão planejadas ao longo de um período, ou seja, apesar de terem sido identificados todos os requisitos que serão afetados, não são todos que serão modificados para a próxima entrega (próxima versão). 
Ao final do terceiro bloco, você percebeu a identificação das modificações dos requisitos e das relações entre eles e como o foco em monitoramento proporciona habilidades ao responsável pelo gerenciamento de requisitos para decidir, junto aos responsáveis pela operação, quais modificações são prioritárias. 
Bons estudos!
Saiba mais
Entre as principais causas de falha de projeto, é comum observar que a maioria dessas falhas estão relacionadas a aspectos diretamente ligados aos requisitos. Sendo assim, o gerenciamento dos requisitos constitui um fator de extrema importânciapara estabelecer o sucesso ou a falha de um projeto. 
Uma poderosa ferramenta que auxilia a gestão dos requisitos é a prototipação do software. Através dela, os envolvidos em um projeto podem verificar as funcionalidades de um software e conferir se todos os recursos estão atendendo aos requisitos estabelecidos. 
Visite e leia sobre este assunto no livro de "Reinehr" (2020, p. 17-18).
Referências
HIRAMA, K. Engenharia de Software. Rio de Janeiro, RJ: Elsevier, 2012. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788595155404/. Acesso em: 15 jun. 2022.  
IEEE. Recommended Practice for Software Requirements Specifications. [S. l.: s. n.], 1998.  
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Porto Alegre, RS: AMGH, 2021. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em: 14 jun. 2022.  
REINEHR, S. Engenharia de Requisitos. Porto Alegre, RS: SAGAH, 2020. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786556900674/. Acesso em: 19 jun. 2022. 
Introdução
Atualmente, há uma procura incansável por meios eficientes para a resolução de problemas relacionados às falhas de gestão em projetos de software, seja em termos de atrasos, alteração de requisitos ou acréscimo de custos. O responsável pelo projeto deve buscar otimizar o tempo de entrega baseando-se em diferentes variáveis, como qualidade, requisitos, esforço e custo. 
Por meio das metodologias ágeis, é possível ter alcance a uma gama de perspectivas que auxiliam os gestores na resolução de problemas corriqueiros, preservando o cronograma, evitando a má qualidade das entregas. A gestão das mudanças é imprescindível para garantir que o produto a ser entregue esteja de acordo com os objetivos de negócio do sistema.  
Desta forma, para atestar que ela ocorra de forma fluida e que seja possível avaliar todas as variáveis fundamentais para o sucesso do projeto, estabelece-se e monitora-se uma Matriz de Rastreabilidade, que estudaremos a seguir. 
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática. Bons estudos!
Finalidades do uso da matriz de rastreabilidade
Diante do cenário atual, é altamente recomendável que todo projeto de software tenha um plano de gerenciamento, em que se faz necessária a interação entre as diferentes equipes envolvidas, com foco principal na redução dos custos e esforços e na entrega contínua. Na prática, todos os projetos de software são agrupamentos de requisitos implementados, incluindo os mais diversos tipos.  
Com a crescente exploração dos métodos ágeis, é comum nos depararmos com projetos de grande porte que contêm ciclos de desenvolvimento mais curtos que os convencionais, fazendo com que o rastreamento de requisitos se torne um grande desafio atualmente. Através de um conjunto de requisitos bem definidos e um método confiável para o rastreamento destes é possível se assegurar que o projeto será bem-sucedido. Assim, a Matriz de Rastreabilidade (RTM – Requirement Traceability Matrix) se trata de um método bem estabelecido para este intuito.  
Finalidade e elaboração de uma RTM 
A rastreabilidade de requisitos consiste na manutenção de vínculos entre as propriedades dos requisitos e os requisitos propriamente ditos, podendo compreender também outros artefatos. Uma Matriz de Rastreabilidade de Requisitos pode ser vista como uma tabela onde as funcionalidades de um sistema (requisitos) são representadas de forma relacional. Tal matriz é utilizada com a finalidade de ter uma forma de rastrear as relações entre os requisitos do sistema, com o intuito de minimizar os riscos do projeto, aumentar a produtividade, identificar possíveis impedimentos e bloqueios e minimizar pontos de contingência.  
De fato, a rastreabilidade permite a elaboração de uma análise de impacto mais eficiente na progressão do sistema. Segundo Hirama (2012, p. 57), o rastreamento é fundamental para a análise de impactos quando os requisitos mudam. A elaboração da Matriz de Rastreabilidade de Requisitos compreende alguns pontos importantes que serão elencados a seguir. 
· Investigação inicial: este é o momento de diferenciar as principais necessidades e pormenores do projeto; tal análise é crucial para que os envolvidos saibam quais são as perspectivas com relação ao projeto e que possam assegurar que este seja homologado pelas partes interessadas. 
· Documentação de requisitos: etapa para fundamentar os requisitos. Tudo que é relativo aos requisitos deve ser bem documentado e definido, podendo fazer uso de ferramentas e meios já utilizados na empresa para facilitar o processo.  
· Especificação dos requisitos: este é o momento de fazer a junção das informações adquiridas nos pontos anteriores para agregar informação a esta etapa que essencialmente classifica os requisitos adequadamente. Estes podem ser funcionais ou não funcionais, por exemplo.  
· Composição da Matriz de Rastreabilidade de Requisitos: união das informações em uma matriz, especificando os requisitos que pertencerão a ela, seus respectivos detalhes e categorizações por ordem de precedência e prioridade. É importante também elencar os requisitos de acordo com o seu estado de implementação, ou seja, "em refinamento", "em desenvolvimento", "ativo" ou "cancelado".  
Tipos de Rastreabilidade (RTM) 
Segundo Paula Filho (2019), podem ser observados dois tipos de rastreabilidade: 
· Rastreabilidade para trás: permite que seja identificada a origem do requisito, a razão, quem e o que originou ele. Desta forma, é possível avaliar o impacto de uma possível mudança nele. 
· Rastreabilidade para a frente: permite localizar os pontos que serão afetados por este requisito. Este aspecto permite que os itens de análise, código e testes cubram todos os requisitos. 
Ao final desse bloco, foi possível perceber que a rastreabilidade produzirá muitos benefícios no gerenciamento das mudanças de requisitos, e você pode colocar em prática já o seu próximo projeto. Bons estudos! 
Elaboração da matriz de rastreabilidade
As matrizes de rastreabilidade (RTM) são a base para diversas atividades de desenvolvimento na engenharia de requisitos. Conforme apresentado em Pressman e Maxim (2021), a RTM pode propiciar continuidade para os desenvolvedores à medida que um projeto muda de fase, independentemente do modelo utilizado, podendo, inclusive, ser utilizada para certificar-se de que os itens do projeto estejam em conformidade com todos os requisitos e com o escopo do projeto. Ademais, uma RTM permite: 
· Gerenciar e avaliar o impacto das alterações no projeto. 
· Avaliar o impacto na falha de testes das funcionalidades relacionadas aos requisitos. 
· Avaliar o status em que se encontram os requisitos e determinar posteriores ações que devem ser realizadas. 
· Fornece a visibilidade de ponta a ponta para as atividades. 
· Validar se os requisitos do projeto foram atendidos. 
Como elaborar uma Matriz de Rastreabilidade de Requisitos (RTM)? 
Uma RTM é uma tabela, na qual as linhas são rotuladas com os nomes dos requisitos, e as colunas, com o nome de um artefato de engenharia (PRESSMAN; MAXIM, 2021). Suponhamos que devemos criar uma RTM (Quadro 1) com o artefato "objetivos de negócios" para uma loja de venda de produtos on-line. As linhas representarão os requisitos, e as colunas, os itens que compõem os objetivos de negócio daquele produto. 
Fonte: elaborado pelo autor.
Existem dois tipos de rastreamento de requisito, que estão relacionados à possibilidade de distinguir a origem e o destino de um requisito: 
· Rastreabilidade para trás. 
· Rastreabilidade para frente. 
A rastreabilidade para trás possibilita a identificação do contexto a partir do qual os requisitos foram originados, enquanto a rastreabilidade para frente permite identificar quais componentes implementam um determinado requisito. A Figura 1 representa um exemplo de elementos da rastreabilidade. 
Fonte: elaborada pelo autor.
Percebe-se, cada vez mais, que o entendimento das necessidades dos clientes é transformado em requisitos e, por fim, emartefatos de projeto, e deve estar devidamente relacionado e possibilitar a localização das regras de negócio.  
Se o patrocinador do projeto consultar o custo de um requisito modificado, ele pode obter os recursos usados na modificação de um determinado requisito em consequência das atividades realizadas. Além disso, ele pode ter a posse do montante dos esforços, compreendendo todos os artefatos modificados rastreados pela RTM.  
Pelo ponto de vista da tecnologia, é possível relacionar todos os demais recursos envolvidos na modificação realizada, tais como: módulos de integração (API) com terceiros, sistemas de banco de dados envolvidos, linguagem de programação, dados para a realização dos testes automatizados, entre outros 
Conclui-se, ao final do segundo bloco, que as instituições e empresas devem estabelecer as suas políticas de rastreabilidade com base nos processos de produção e gerência de requisitos. Tais políticas referenciam quais aspectos e informações de rastreabilidade podem ser sustentados e como devem ser mantidos. Que tal você também adotar a Matriz de Rastreabilidade no seu próximo projeto? Bons estudos! 
Tipos de matriz de rastreabilidade
Encare um desafio para a elaboração de uma Matriz de Rastreabilidade que seja extremamente útil aos interessados na administração do sistema que possui regras de negócio altamente complexo e crítico pelo impacto causado quando os resultados não são alcançados. Antes da elaboração da Matriz de Rastreabilidade, entenda alguns dos fatores que levaram a Orto EH a decidir pela informatização do sistema de atendimento no seu pronto-socorro.  
O grande volume de pacientes, um grau acima da média em rotatividade de funcionários, estava causando alguns problemas na operacionalização das atividades consideradas básicas, tais como: desorganização das fichas de pacientes, conflito na agenda de pacientes, consulta rápidas demais para tentar realizar todos os atendimentos, alto índice da relação quantidade de pacientes em espera e quantidade de atendentes da enfermagem. 
Você é o responsável pelo gerenciamento de requisitos do sistema de atendimento da Orto EH, fase em que se necessita analisar os requisitos e seus relacionamentos, contudo a organização resolveu adotar a matriz de rastreabilidade vertical para proporcionar maior segurança. Até a release (compõe uma versão parcial de um software) da semana anterior, os requisitos eram mapeados numa matriz horizontal, conforme o Quadro 2. Percebe-se que o preenchimento desse relacionamento entre requisitos e funcionalidades tem como base a análise do entendimento das operações realizadas pelo operador do sistema. 
Fonte: elaborado pelo autor.
Embora o quadro não reflita fielmente as funcionalidades do sistema de atendimento da Orto EH completamente, é possível perceber como se constrói uma Matriz de Rastreabilidade. Agora, deve dedicar esforços para a elaboração da Matriz de Rastreabilidade vertical, com a disponibilidade para usar nas duas maneiras de tipo de rastreabilidade: pré-rastreabilidade e pós-rastreabilidade. Pré-rastreabilidade é encontrar todos os artefatos identificados a partir do código-fonte até encontrar a sua origem quando foi definido pelo usuário do sistema, e pós-rastreabilidade é partir das definições do requisito (ou da história do usuário) e localizar todos os artefatos desenvolvidos até encontrar o código que implementa o requisito, conforme demonstrado no Quadro 3.
Fonte: elaborado pelo autor.
As representações nos quadros 2 e 3 são ilustrativas para uma explanação didática, pois, num processo real, é necessário elaborar as planilhas usando um software específico para otimizar o gerenciamento de requisitos de forma eficiente. Compreendendo melhor essas matrizes de rastreabilidade, é possível simular uma modificação na história do usuário H#03, quando se constata que serão alterados dois requisitos e que, por sua vez, é obrigatório analisar dois códigos-fonte (@cf_prog01 e @cf_prog03).  
Portanto, o gerenciamento indicará e analisará todos os itens envolvidos para elaborar o planejamento das atividades, a estimativa do esforço necessário e, consequentemente, os casos de testes, entre outros fatores desejáveis para o monitoramento do projeto. 
Agora que chegou ao final do terceiro bloco, você viu os benefícios da Matriz de Rastreabilidade, então é só começar a elaborar a sua matriz no seu próximo projeto. 
Bons estudos!
Saiba mais
A identificação das relações entre os requisitos é importante tanto para aspectos gerenciais quanto aspectos técnicos em um projeto. É comum verificar que a prática da rastreabilidade, utilizando casos de teste, permite identificar as ligações entre os requisitos, bem como identificar aqueles que não têm casos de teste. Quando a Matriz de Rastreabilidade (RTM) é bem elaborada, ela garante que o sistema seja seguro e que cumpra os níveis de qualidade adequados.  
Leia sobre processo de teste ligado à RTM no livro de Pressman e Maxim (2021, p. 383), no item 19.3.2 – Rastreabilidade.
Referências
HIRAMA, K. Engenharia de Software. Rio de Janeiro, RJ: Elsevier, 2012. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788595155404/. Acesso em: 15 jun. 2022.  
PAULA FILHO, W. de P. Engenharia de Software – Produtos – Vol.1. Rio de Janeiro, RJ: LTC, 2019. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788521636724/. Acesso em: 19 jun. 2022.  
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Porto Alegre, RS: AMGH, 2021. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em: 14 jun. 2022.  
REINEHR, S. Engenharia de Requisitos. Porto Alegre, RS: SAGAH, 2020. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786556900674/. Acesso em: 19 jun. 2022002E
Gerenciamento de requisitos
A cada dia, as necessidades de negócios se tornaram mais próximas do indivíduo, exigindo dos aplicativos maior flexibilidade para atender à particularidade pessoal. Se antes o processamento de dados estava voltado aos negócios institucionais de grande volume de dados com poucas variações de tarefas, atualmente as operações são extremamente específicas pela própria natureza e pelo desejo do indivíduo. 
Os primeiros sistemas de informações (SI) exigiam grande volume de entrada de dados com pouquíssima intervenção do operador. Aliada à economia previsível, não se exigiam mudanças constantes em software. 
Ao contrário, na virada do século XXI, as especificidades aumentaram rapidamente, e a necessidade de novas regras de negócios demandou mudanças constantes dos sistemas de informações, em busca de resultados inovadores, ainda com desafios de SI com maior flexibilidade ou bem próximos dos desejos individuais. Nesse cenário tão dinâmico e exigente é que se tornou mais e mais imprescindível preparar procedimentos ou padrões que possam aumentar a efetividade no monitoramento das mudanças e no gerenciamento de requisitos.  
A comunicação é um dos recursos exigidos para atender a essa tendência de atualização constante dos softwares, convocando os responsáveis pela operação do sistema. Chamado de partes interessadas, são elas que devem decidir os reais desejos para atingir as metas específicas de uma organização. 
Você percebeu que, para atingir os melhores resultados no gerenciamento de requisitos, foram apresentadas técnicas relacionadas ao manifesto ágil e aos processos de qualidade, dando foco em processos fundamentais para compreender, implementar, homologar e implantar sistemas de informações em curtíssimo espaço no tempo. E, para isso, viu-se a importância do CI/CD (Continuous Integration/Continuous Deployment), com o apoio de ferramentas (de design, gerenciamento de artefatos e versões e de testes).  
Quatro competências foram abordadas para que você possa compreender e estar habilitado a exercer o papel de gestor de requisitos de SI. Na primeira, foram abordadas o controle de mudanças de requisitos e a prática da revisão constante do requisito, inclusive desde a definição ou a redefinição do requisito. Ascontinuas revisões do requisito devem prever que ele possa sofrer mudanças entre a etapa da definição do requisito e da homologação, sendo avaliado pelo usuário ou pelo responsável pela operação, para decidir se prossegue ou se recomeça a implementação.  
A segunda se deu ao fato da necessidade de compreender e prever os relacionamentos entre os requisitos, o que leva à necessidade da organização eficiente dos requisitos. Saber classificar cada requisito de acordo com os objetivos para melhor priorizar e organizar, mantendo todos os envolvidos cientes de que nem todos os requisitos serão implementados no sistema simultaneamente. Mesmo que exista uma dependência entre os requisitos, é fato que a limitação de recursos passa a ser um fator importante e determinante para organizar os requisitos adequadamente. 
A sua habilidade em monitorar os requisitos é o que foi trabalhado na terceira parte, ou seja, mesmo que ainda não receba a notícia de que o requisito está sofrendo alteração, o gestor deve acompanhar o comportamento do requisito diretamente na sua origem, junto aos operadores, talvez se utilizando de técnicas investigativas.  
Por fim, um verdadeiro mapeamento dos requisitos, além do relacionamento entre eles, mas também com os demais artefatos gerados a partir de sua definição, permitindo que se possa rastrear pelos links construídos pela rastreabilidade, tanto da origem até os mais avançados artefatos, ou ao contrário. Assim, dando a segurança de qual seria o impacto quando um dos requisitos necessitar de mudanças, relacionando todos os artefatos a serem analisados e, talvez, modificados.  
Resumo visual
Referências
PAULA FILHO, W. de P. Engenharia de Software – Produtos – Vol.1. Rio de Janeiro, RJ: LTC, 2019. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788521636724/. Acesso em: 19 jun. 2022.  
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Porto Alegre, RS: AMGH, 2021. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em: 14 jun. 2022.  
REINEHR, S. Engenharia de Requisitos. Porto Alegre, RS: SAGAH, 2020. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786556900674/. Acesso em: 19 jun. 2022.