A flexM4i apresenta algumas seções que tratam da gestão de requisitos, como ilustra a próxima figura.

Figura 1327: seções que tratam da gestão de requisitos (clique na figura para abrir o PDF em outra aba e assim baixar como um mapa de conteúdo da flexM4i com os links das seções)

Para conhecer a descrição completa dessa figura, acesse a descrição das seções na página principal sobre gestão de requisitos.

Recordamos a definição adotada pela flexM4i sobre práticas.

Prática é uma atividade profissional ou gerencial associada à aplicação de conhecimentos, habilidades, metodologias, métodos, ferramentas e técnicas para a execução de um processo.

As práticas foram sintetizadas das seguintes publicações:

• Gottesdiener, E. (2005). The software requirements memory jogger: A pocket guide to help software and business teams develop and manage requirements (5ª ed.). GOAL/QPC.
• Hood, C., Wiedemann, S., Fichtinger, S., & Pautz, U. (2008). Requirements management: The interface between requirements development and all other systems engineering processes. Springer Science & Business Media. 
• IIBA (2015). A guide to the business analysis body of knowledge – BABOK (3rd ed.). International Institute of Business Analysis. Toronto, Canada: IIBA.
• PMI (2015). Business analysis for practitioners: A practice guide. Project Management Institute Inc. Newtown Square, Pennsylvania. 
• PMI (2016). Requirements management: a practice guide. Project Management Institute, Inc. Newtown Square, Pennsylvania.
• PMI (2017). The PMI guide to business analysis. Project Management Institute, Inc. Newtown Square, Pennsylvania.

Por que consideramos as publicações de business analysis?

Segundo o IIBA (2015), a “BA (business analysis) é a prática de apoiar a mudança em uma empresa, definindo necessidades e recomendando soluções que agreguem valor aos stakeholders. Permite que uma empresa articule as necessidades e a razão para a mudança, assim como o desenvolvimento das soluções. A análise de negócios pode apoiar uma variedade de iniciativas estratégicas, táticas ou operacionais.

A gestão de requisitos é um dos pilares da BA para realizar mudanças e desenvolver soluções. 

Por essa razão, os BoKs (corpos de conhecimentos) da BA são considerados nesta seção.

A elicitação de requisitos é a primeira atividade formal da gestão de requisitos, cujo objetivo é compreender, estruturar e registrar requisitos a partir de necessidades previamente identificadas. Diferente de uma simples coleta de informações, essa atividade exige análise, facilitação e interação contínua com os stakeholders para garantir que os requisitos reflitam corretamente suas expectativas e estejam alinhados com os objetivos do projeto.

O processo começa com a análise das necessidades dos usuários, com o objetivo de definir um conjunto de requisitos que orientarão o desenvolvimento do produto. Para que essa etapa seja bem-sucedida, é essencial capturar essas necessidades de forma clara e traduzi-las em requisitos compreensíveis e utilizáveis. (Peruzzini, Marilungo & Germani, 2015).

Embora as necessidades normalmente tenham sido elicitadas anteriormente, ainda é necessário traduzir essas informações em requisitos concretos, compreensíveis e gerenciáveis. Isso inclui organizar requisitos por origem, complexidade, prioridade e função, aspectos fundamentais para uma gestão eficiente ao longo do ciclo de vida do projeto (IIBA, 2015). Segundo Pohl (2007), a elicitação envolve identificar e validar os requisitos com os stakeholders, garantindo que estejam consistentes com suas necessidades. 

Diferentes contextos – incertezas

A elicitação pode ocorrer em diferentes contextos. Em projetos bem definidos, onde as necessidades já foram claramente estabelecidas, esse processo tende a ser mais estruturado e focado na organização e formalização dos requisitos. No entanto, em ambientes de maior incerteza, como projetos inovadores ou desenvolvimento de produtos em estágio inicial, os stakeholders podem não ter uma visão clara do que precisam, exigindo técnicas mais exploratórias, como entrevistas abertas, observação contextual e prototipagem.

Processo iterativo – refinamento progressivo

Além disso, a elicitação é um processo iterativo, pois os requisitos iniciais podem ser imprecisos ou incompletos. O refinamento progressivo ocorre por meio de ciclos de validação e priorização, garantindo que os requisitos finais sejam bem definidos e viáveis. Técnicas como análise documental, workshops e modelagem podem ser utilizadas para consolidar os requisitos de forma estruturada.

Integração com outros processos / atividades

A elicitação deve estar integrada a outros processos (ou atividades) da gestão de requisitos, assegurando rastreabilidade e alinhamento com a estratégia do projeto. Essa conexão facilita a verificação e validação posteriores, garantindo que os requisitos definidos atendam às expectativas dos stakeholders e contribuam para os objetivos organizacionais. Essa “integração” é a execução dessas atividades em paralelo com transferência de informações entre elas, como ilustra a figura 1323 anterior. 

Listamos a seguir práticas  para realizar a elicitação de requisitos, cada uma adequada a diferentes contextos e objetivos.

• Benchmarking e Análise de Mercado, que permitem comparar práticas e soluções para identificar melhorias e oportunidades;
• Brainstorming, ideal para estimular ideias e reunir contribuições criativas de equipes;
• Análise das Regras do Negócio, para compreender os limites e diretrizes que influenciam os requisitos;
• Jogos Colaborativos, que promovem interação e engajamento das partes interessadas de forma dinâmica;
• Modelagem de Conceitos e Modelagem de Dados, úteis para representar visualmente informações e relacionamentos;
• Mineração de Dados, para extrair insights a partir de grandes volumes de informações;
• Context Diagram (Diagrama de Contexto) ou Mapa de sistema – Representação gráfica das fronteiras do sistema e suas interações externas, útil para delimitar o escopo dos requisitos.
• Análise de Documentos, que auxilia na revisão de materiais existentes para identificar requisitos;
• Grupos Focais, que reúnem um público específico para discutir necessidades e expectativas;
• Análise da Interface, para entender como os usuários interagem com sistemas ou produtos;
• Entrevistas, uma abordagem direta e personalizada para coletar informações;
• Mapas Mentais, que organizam ideias e requisitos de forma visual;
• Observação, para identificar requisitos por meio da análise de como as tarefas são realizadas no ambiente real;
• Análise e Modelagem de Processos, que detalham fluxos de trabalho e áreas de melhoria;
• Prototipagem, para criar representações preliminares do produto e validar requisitos;
• Pesquisas ou Questionários, que alcançam um grande número de pessoas de forma eficiente; e
• Oficinas, que promovem colaboração em sessões estruturadas de levantamento de requisitos.

A análise de requisitos envolve a organização, detalhamento e priorização dos requisitos levantados, garantindo que estejam bem definidos e documentados para orientar o desenvolvimento do projeto. Alguns autores utilizam o termo especificação, enquanto outros preferem documentação, mas ambos referem-se ao registro formal dos requisitos para facilitar seu acompanhamento ao longo do ciclo de vida do projeto (Jallow et al., 2014).

A documentação tem como objetivos amplos:

• estruturar os requisitos de forma clara, 
• representar em modelos e 
• validar as informações coletadas na elicitação.

As atividades relacionadas a cada objetivo são apresentadas a seguir.

Estruturar os requisitos:

• Organizar os requisitos de maneira sistemática e coerente.
• Identificar e implementar mudanças necessárias para atender às demandas da empresa.
• Manter os requisitos que já estão alinhados com as necessidades da empresa.
• Avaliar se existem lacunas ou elementos que podem ser descartados.
• Identificar premissas ou restrições que possam impactar os requisitos.

Representar em modelos:

• Utilizar modelos apropriados para documentar os requisitos.
• Refinar e detalhar requisitos complexos em componentes menores e mais gerenciáveis.

Validar as informações coletadas na elicitação:

• Analisar requisitos não funcionais, como desempenho, segurança e usabilidade.
• Verificar a consistência e completude das informações antes de consolidá-las na documentação.

Além de documentar os requisitos, é essencial organizá-los conforme sua importância para as partes interessadas do projeto (IIBA, 2015). A priorização permite que os requisitos mais críticos sejam atendidos primeiro, maximizando seu valor no contexto do projeto (Grady, 2014).

Karlsson, Wohlin e Regnell (1998) propõem um processo estruturado em três estágios para a priorização de requisitos, apoiando a tomada de decisão:

1. Preparação: Os requisitos são organizados conforme o método de priorização escolhido. Nessa etapa, uma equipe é formada e liderada por um responsável, que coleta e fornece as informações necessárias para o próximo estágio.
2. Execução: Com base nos dados obtidos na preparação, os tomadores de decisão realizam a priorização dos requisitos. Antes dessa etapa, é fundamental que os parâmetros de avaliação sejam definidos e acordados por todos os membros da equipe.
3. Apresentação: Os resultados da priorização são apresentados aos envolvidos, promovendo transparência e permitindo que as decisões sejam validadas ou ajustadas conforme necessário.

Lembre que consideramos aqui requisitos de produto, derivados dos requisitos e necessidades dos clientes, cuja definição é “Requisitos do produto é o termo em uma linguagem técnica interna de uma empresa para descrever as características do seu produto ou serviço (Ficalora & Cohen, 2010)”. Então ele se confunde com funcionalidades.

No entanto, as funcionalidades são a implementação prática dos requisitos.

Por exemplo, enquanto um requisito pode definir que um sistema deve permitir autenticação segura, a funcionalidade específica pode ser um login com reconhecimento facial ou integração com redes sociais.

Dessa forma, todas as funcionalidades são derivadas de requisitos, mas nem todo requisito se traduz diretamente em uma funcionalidade visível para o usuário.

 Como isso afeta a priorização?

A priorização pode ocorrer em diferentes níveis:

• Priorização dos requisitos (tema desta seção): ocorre nas fases iniciais do desenvolvimento, quando ainda se define o que deve ser atendido pela solução. Inclui tanto requisitos funcionais (o que o produto deve fazer) quanto não funcionais (como ele deve se comportar).
• Priorização das funcionalidades (features): Mais comum nas fases avançadas do desenvolvimento, quando já se sabe quais requisitos precisam ser atendidos e o foco está em como implementá-los.

A análise de requisitos, composta pela documentação e priorização, assegura que os requisitos estejam bem estruturados, compreendidos e alinhados com os objetivos do projeto, facilitando sua gestão ao longo do ciclo de vida do produto ou serviço.

No final da análise, devemos examinar:

• se os requisitos estão bem definidos, 
• se eles não se contradizem e 
• se não apresentam lacunas.

Assim, estamos preparados para as fases subsequentes de verificação e validação.

A partir deste ponto começamos a utilizar modelos, como citamos na visão geral das principais atividades e representamos na figura 1320 da visão geral. Porém, como descrevemos nas características da gestão de requisitos (seção principal), as atividades são iterativas. Por isso, já podemos começar a documentar durante a elicitação.

 Há uma grande variedade de modelos que podem ser utilizados.

Quanto mais crítica for a inovação do ponto de vista de riscos e incertezas, temos de formalizar os requisitos com mais cuidado.

Por exemplo, imagine os requisitos de um equipamento médico ou de uma aeronave.

Porém, lembre que requisitos estão no “final” dos artefatos iniciais da inovação. Isso significa que nas fases iniciais, principalmente em inovações mais radicais, tratamos as oportunidades, desafios e ideias sem o formalismo dos requisitos. 

Os requisitos são considerados quando já existir um conceito inicial do produto ou serviço.

No caso de desenvolvimentos incrementais, podemos documentar os requisitos desde o início. Isso porque o conceito do produto deve ser bem conhecido e dominado pela empresa.

Por exemplo, no desenvolvimento de um novo software de vendas pela web integrado com o controle de estoque, já conseguimos listar os requisitos desde o início do projeto.

Não vamos esgotar todas as possibilidades, mas seguem os modelos mais utilizados.:

• Lista de Requisitos – Registro estruturado dos requisitos em formato tabular, contendo atributos como identificador, descrição, prioridade, fonte e rastreabilidade.
• Casos de Uso (textual e/ou diagramático) – Representação das interações entre atores e o sistema. Pode ser descrito textualmente e complementado, se necessário, por um Diagrama de Casos de Uso (UML) para ilustrar visualmente as interações. Destaca-se que a UML é uma linguagem mais ampla, usada também no desenvolvimento e modelagem de bancos de dados e de atividades do desenvolvimento detalhado.
• Histórias de Usuário – Descrição breve e informal de um requisito sob a perspectiva do usuário final, geralmente no formato: “Como [tipo de usuário], quero [ação] para [objetivo]”.
• Modelos de Cenário – Estruturas narrativas detalhadas que descrevem como os usuários interagem com o sistema em diferentes situações, considerando variações e exceções.
• Tabela de Atores e Papéis – Lista de stakeholders e seus respectivos papéis na interação com os requisitos. Pode incluir Personas, quando necessário, para descrever perfis típicos de usuários.
• Context Diagram (Diagrama de Contexto) – Representação gráfica das fronteiras do sistema e suas interações externas, útil para delimitar o escopo dos requisitos.
• Modelos de Processos (BPMN ou Process Maps) – Diagramas que representam fluxos de processos de negócios, auxiliando na compreensão do contexto operacional dos requisitos.
• Matriz de Rastreabilidade – Estrutura que permite rastrear a origem e o impacto dos requisitos ao longo do desenvolvimento, facilitando mudanças e verificações de consistência.
• Catálogo de Regras de Negócio – Conjunto de diretrizes e restrições operacionais que afetam os requisitos do sistema ou produto.
• Glossário – Definição de termos-chave do domínio do projeto, reduzindo ambiguidades na interpretação dos requisitos.
• Tabelas de Eventos e Respostas (Event-Response Table) – Estruturam os eventos que desencadeiam ações no sistema, auxiliando na elicitação e definição de requisitos funcionais.
• Tabelas de Decisão ou Árvores de Decisão – Estruturas utilizadas para especificar regras de negócio complexas e representar a lógica de decisões com múltiplas condições.

Conforme discutimos anteriormente, as práticas citadas aqui podem ser utilizadas para a priorização de requisitos e/ou funcionalidades. Por isso, utilizamos a seguinte legenda no início de cada prática:

• R – apropriada para priorização de requisitos
• F – apropriada para priorização de funcionalidades (features)

Segundo Pierce (2025) os principais métodos e ferramentas para a priorização de requisitos e/ou funcionalidades são:

• (R&F) Método MoSCoW (MoSCoW Method): categoriza requisitos / funcionalidades em quatro níveis de prioridade: Must Have (Obrigatório), Should Have (Importante), Could Have (Desejável) e Won’t Have (Não necessário agora), facilitando a gestão de expectativas e entregas.
• (R&F) Método RICE (RICE Method): avalia  requisitos / funcionalidades considerando Alcance (Reach), Impacto (Impact), Confiança (Confidence) e Esforço (Effort), resultando em uma pontuação que auxilia na priorização.
• (R&F) Pontuação ponderada (Weighted Scoring): atribui pontuações a requisitos / funcionalidades com base em critérios predefinidos, como valor para o cliente, custo e esforço, permitindo uma priorização objetiva.
• (R&F) Valor vs esforço (Value vs Effort): compara o valor que um  requisito / funcionalidade agrega ao produto em relação ao esforço necessário para implementá-lo, ajudando a identificar prioridades com melhor retorno sobre investimento.
• (R&F) Custo do atraso (Cost of Delay): calcula o impacto financeiro de adiar a implementação de um  requisito / funcionalidade, ajudando a priorizar aqueles que devem ser desenvolvidos mais rapidamente para evitar perdas.
• (R&F) Modelo de pontuação ICE (ICE Scoring Model): avalia  requisitos / funcionalidades com base em Impacto (Impact), Confiança (Confidence) e Facilidade (Ease), fornecendo uma pontuação simples para auxiliar na priorização.
• (R&F) Trabalho mais curto com maior peso (Weighted Shortest Job First – WSJF): prioriza  requisitos / funcionalidades com base na relação entre o valor que agregam e o tempo necessário para implementá-los, favorecendo entregas rápidas de alto valor.
• (R&F) Framework de restrições (Constraints Framework): considera as limitações existentes, como recursos, tempo e tecnologia, para priorizar  requisitos / funcionalidades que sejam viáveis dentro dessas restrições.
• (R&F) Poker de prioridades (Priority Poker): também conhecida como Planning Poker, utiliza uma abordagem colaborativa e lúdica (gamificada), na qual membros da equipe atribuem prioridades aos requisitos de forma consensual.
• (R) Modelo Kano (Kano Model): classifica requisitos com base na satisfação do cliente, diferenciando entre necessidades básicas, de desempenho e encantadoras, para melhor direcionar esforços de desenvolvimento.
• (R) Pontuação de oportunidades (Opportunity Scoring): baseia-se no feedback dos clientes para identificar requisitos que apresentam alta importância, mas baixa satisfação, direcionando melhorias que agreguem valor significativo.
• (R) Método KJ (KJ Method): também conhecido como Affinity Diagramming, organiza ideias e requisitos em grupos temáticos, facilitando a identificação de prioridades e padrões.
• (F) Mapeamento de histórias (Story Mapping): organiza e prioriza requisitos em um fluxo de trabalho visual, garantindo que o desenvolvimento seja alinhado às jornadas dos usuários e aos objetivos do produto.
• (F) Compre um requisito (Buy a Feature): envolve stakeholders ou clientes em um exercício onde recebem um orçamento fictício para “comprar” requisitos desejados, revelando prioridades percebidas e valor atribuído.
• (F) Árvore do produto (The Product Tree): usa uma metáfora de árvore para visualizar o crescimento e a evolução do produto, permitindo que equipes identifiquem áreas que necessitam de desenvolvimento ou inovação.

A negociação e a resolução de conflitos envolvem a mediação de discussões entre os participantes para ajudá-los a reconhecer diferentes pontos de vista, resolver divergências e chegar a conclusões aceitas por todas as partes.

Um processo bem-sucedido inclui a identificação dos interesses subjacentes das partes envolvidas, diferenciando-os de suas posições declaradas, e a busca de soluções que atendam a esses interesses. 

Devemos  garantir que o resultado da negociação esteja alinhado com a solução proposta e com as necessidades do negócio.

Objetivo é alcançar um entendimento comum ou um acordo entre os stakeholders para, assim, manter e fortalecer os relacionamentos entre todas as partes envolvidas.

Habilidade da liderança

A negociação e a resolução de conflitos dependem fortemente da habilidade de liderança, uma das premissas básicas para o sucesso da gestão de requisitos.

A liderança envolve direcionar os esforços de um grupo para um objetivo comum, permitindo que atuem de maneira colaborativa. 

Eles devem utilizar essas habilidades para conduzir grupos diversos de stakeholders durante a elicitação de requisitos, auxiliar na resolução de diferenças, apoiar a priorização e obter a adesão necessária para a implementação da solução.

A negociação exige não apenas a capacidade de lidar com conflitos, mas também a habilidade de antever potenciais pontos de atrito e atuar na gestão e na redução da escalada de conflitos, mitigando impactos negativos e facilitando o consenso.

Como analistas de negócios frequentemente enfrentam desafios relacionados a escolhas difíceis de priorização e conflitos entre requisitos de diferentes grupos de stakeholders, o domínio da negociação se torna essencial para alcançar decisões alinhadas ao negócio.

Integração com a priorização de requisitos

A negociação e a resolução de conflitos frequentemente ocorrem em paralelo com a priorização de requisitos, mas podem ocorrer já durante a licitação para fazer com que todos interessados contribuam para o levantamento das necessidades e o desdobramento em requisitos.

O analista de negócios pode recomendar critérios de priorização, mas a decisão final deve envolver stakeholders com autoridade para estabelecer prioridades. Durante esse processo, a mediação é crucial para minimizar insatisfações quando determinados requisitos são considerados de menor prioridade.

A definição de expectativas sobre como a priorização será conduzida, desde o início da análise de negócios, reduz riscos de insatisfação e resistência por parte dos stakeholders. Habilidades de negociação, gestão de conflitos e facilitação são amplamente utilizadas durante discussões de priorização, especialmente quando há requisitos conflitantes. Muitas vezes, o consenso sobre requisitos é alcançado por meio da negociação, tornando essencial que o analista de negócios facilite diálogos estruturados para alinhar diferentes perspectivas e garantir um desfecho aceito por todas as partes.

Como obter a eficácia desta atividade?

A eficácia da negociação e da resolução de conflitos pode ser atingida por:

• Abordagem planejada: considerar o tom de voz, a postura adotada, os métodos utilizados e a preocupação com as necessidades e emoções das partes envolvidas.
• Reconhecimento de interesses comuns: identificar que as necessidades dos stakeholders, refletidas nos requisitos, nem sempre são conflitantes e que é possível encontrar soluções que beneficiem ambos os lados sem gerar perdas.
• Foco no problema, não nas pessoas: garantir que a discussão se concentre nas questões reais, evitando desgastes nos relacionamentos.
• Processo iterativo: reconhecer que a resolução de conflitos pode exigir múltiplas reuniões para alcançar os objetivos estabelecidos, em vez de esperar que um único encontro seja suficiente para solucionar todas as divergências.
• Habilidade de liderança na mediação: garantir que a negociação seja conduzida de forma estruturada, facilitando o consenso e alinhando a resolução dos conflitos com os objetivos estratégicos do negócio

Como a negociação e a resolução ocorre em paralelo com as outras atividades da gestão de requisitos, o foco está muito mais nas habilidades de liderança e mediação do que em métodos estruturados.

Porém, alguns métodos e ferramentas podem ser adaptados para os momentos de negociação e resolução de conflitos, tais como:

• Matriz de interesses e posições: ajuda a visualizar os interesses subjacentes de cada stakeholder, diferenciando posições declaradas (o que cada parte pede) dos interesses reais (o que realmente precisam). Isso auxilia na construção de soluções que atendam a ambas as partes.
• Mapas de empatia para stakeholders: permite compreender preocupações e motivações dos envolvidos, facilitando a condução de negociações mais eficazes.
• Técnicas de escuta ativa e espelhamento: embora sejam habilidades de liderança, podem ser sistematizadas por meio de checklists e roteiros de condução de diálogos difíceis.
• Role-playing para mediação: simulação de cenários de conflito para preparar analistas de negócios e líderes para lidar com negociações desafiadoras.
• Acordos de engajamento: definição prévia de regras para negociação, ajudando a estabelecer um processo estruturado e a reduzir resistências.
• Frameworks de governança de decisões: modelos que formalizam quem tem autoridade para tomar decisões e como os conflitos serão tratados, garantindo um processo de mediação claro.

A verificação e validação dos requisitos são etapas para garantir a qualidade e o sucesso de um projeto. A verificação tem como objetivo assegurar que os requisitos e especificações, estejam corretos e prontos para o próximo passo, enquanto a validação avalia se esses requisitos atendem às necessidades e expectativas dos stakeholders, especialmente os requisitos do negócio, entregando o valor prometido.

A verificação é um processo colaborativo que envolve analistas e partes interessadas. É realizada de forma contínua durante a análise de requisitos, buscando identificar e corrigir problemas desde o início. Já a validação, concentra-se em obter a aprovação de todos os envolvidos no projeto, garantindo que os requisitos realmente atendam às necessidades reais das partes interessadas (IIBA, 2015; PMI, 2015).

De forma prática, o processo de verificação analisa se os requisitos seguem padrões de qualidade adequados e são úteis para o propósito esperado (IIBA, 2015).

A validação, confirma que os requisitos e projeto refletem as necessidades e valores do negócio, por meio de revisões detalhadas e critérios claros para aprovação (Dehghani, 2019).

Algumas práticas que podem ser utilizadas na Verificação e Validação são:

• Análise de documentação: Examina registros, documentos e especificações anteriores para verificar e validar se os requisitos refletem necessidades previamente identificadas e se estão alinhados a padrões organizacionais e objetivos estratégicos.
• Análise de riscos: Identifica e avalia cenários que podem comprometer o valor dos requisitos, analisando incertezas, impactos potenciais e riscos que possam afetar a viabilidade ou entrega do projeto.
• Análise financeira: Avalia os benefícios econômicos associados aos requisitos, analisando custos, retorno sobre investimento (ROI) e impacto financeiro da implementação para justificar sua viabilidade no projeto.
• Critérios de aceitação e avaliação: Define métricas e padrões de qualidade para garantir que os requisitos sejam claros, testáveis e aceitos pelas partes interessadas, permitindo a criação de testes para validar sua adequação.
• Delphi: Método de consenso que coleta feedback anônimo de especialistas, utilizando rodadas de votação para validar requisitos sem influência de hierarquia, pressão social ou viés de grupo, garantindo decisões mais objetivas.
• Indicadores-chave de desempenho (KPIs) e métricas: Mede a qualidade dos requisitos e avalia seu impacto no desempenho do projeto ou solução, utilizando parâmetros quantitativos e qualitativos para monitorar sua eficácia ao longo do tempo.
• Meta de negócio e modelo de objetivos: Relaciona requisitos às metas e objetivos do negócio para garantir que cada funcionalidade tenha uma justificativa estratégica e agregue valor real à organização e aos usuários finais.
• Matriz de rastreabilidade: Estabelece conexões entre requisitos, objetivos de negócio, modelos de análise e artefatos do projeto, garantindo rastreabilidade e verificando se todos os requisitos possuem justificativa e impacto estabelecido.
• Monitoramento de Itens (item tracking): Garante que problemas, dúvidas e mudanças identificadas durante a verificação e validação sejam documentados, rastreados e resolvidos, evitando impactos negativos na evolução do projeto.
• Peer reviews: Revisões conduzidas por colegas de equipe, como analistas de negócios ou membros do controle de qualidade, para avaliar a lógica, clareza, coerência e aderência dos requisitos aos padrões organizacionais e metodológicos.
• Prototipação: Desenvolvimento de modelos preliminares de interfaces, fluxos ou funcionalidades para validar requisitos com usuários e stakeholders, permitindo ajustes antes da implementação definitiva da solução.
• Revisões estruturadas: Inspeção detalhada dos documentos de requisitos para identificar inconsistências, lacunas ou ambiguidades, garantindo alinhamento com padrões organizacionais e expectativas das partes interessadas.
• Método INVEST: Avaliação estruturada de User Stories para garantir que sejam independentes, negociáveis, valiosas, estimáveis, pequenas e testáveis, assegurando sua viabilidade e qualidade no desenvolvimento ágil.
• Walkthroughs: Revisão coletiva dos requisitos com stakeholders, conduzida em reuniões formais ou informais, para confirmar validade, esclarecer dúvidas e garantir alinhamento com necessidades reais do negócio e usuários.

Segundo a definição de Hood et al. (2008), a gestão de requisitos abrange todas as atividades necessárias para aumentar ou

Avaliar e/ou estabelecer as interfaces com outros processos  não pode ser considerada uma atividade da gestão de requisitos em si. Porém, a avaliação e/ou estabelecimento de interfaces contempla diversas atividades.

Colocamos nessa “sequência” de atividades para que você lembre que em algum momento você deve considerar as interfaces.

Considerando, que os requisitos já foram estabelecidos nas atividades anteriores, eles devem ser mantidos para continuar a prover valor para as equipes de desenvolvimento e, em última análise, para os clientes (stakeholders). Por isso, é importante manter a interface com todas as atividades que se relacionam com a gestão de requisitos tais como:

• Gerenciamento de projetos: garante o alinhamento entre o escopo definido pelos requisitos e o planejamento, execução e controle das atividades do projeto.
• Gestão da qualidade: assegura que os requisitos estejam aderentes aos critérios de qualidade definidos, sendo validados continuamente durante o desenvolvimento.
• Gestão de configuração: mantém o controle das versões e estados dos requisitos ao longo do ciclo de vida, garantindo rastreabilidade e integridade.
• Gestão de riscos: identifica e monitora riscos associados aos requisitos, antecipando problemas que possam afetar a sua implementação.
• Gestão de testes: utiliza os requisitos como base para criação e execução dos testes, validando continuamente se a solução atende ao que foi especificado.
• Gestão de versões: assegura o controle da evolução dos requisitos, documentando alterações e mantendo histórico de modificações.
• Gestão de mudanças: estabelece o processo sistemático para avaliar, aprovar e documentar alterações solicitadas aos requisitos após sua aprovação inicial, mantendo-os atualizados e consistentes.

Segundo o PMI (2016), o monitoramento e controle dos requisitos assegura a gestão contínua do escopo do produto e do projeto, garantindo que os requisitos aprovados sejam acompanhados, mantidos e, quando necessário, ajustados ao longo do ciclo de vida do projeto.

A baseline dos requisitos é gerenciada para garantir alinhamento com as decisões tomadas, e qualquer novo requisito identificado é avaliado quanto ao seu impacto antes da aprovação. Esse monitoramento contínuo permite a adaptação controlada dos requisitos às necessidades do projeto e do produto.

As atividades do monitoramento e controle dos requisitos são: 

• Identificação: Garantia de que cada requisito possua um identificador único, evitando ambiguidades e facilitando sua rastreabilidade ao longo do projeto. Mesmo requisitos excluídos devem manter seus identificadores originais para evitar reutilização e possíveis confusões (Hood et al., 2008).
• Integridade – links: Documentação e manutenção das relações entre requisitos e outras informações relevantes, garantindo rastreabilidade bidirecional e evitando ambiguidades por meio de identificadores únicos (Hood et al., 2008).
• Controle de acesso: Definição de permissões e restrições para modificação e visualização dos requisitos, assegurando que apenas usuários autorizados possam alterá-los  (Hood et al., 2008).
• Versionamento: Registro e acompanhamento de diferentes versões dos requisitos ao longo do tempo, possibilitando a rastreabilidade de mudanças e decisões (IIBA, 2015).
• Gestão de mudança (de engenharia): Processo essencial para administrar as alterações inevitáveis que ocorrem durante um projeto.  Envolve a documentação, análise, aprovação e rastreamento dessas mudanças, mantendo a consistência e rastreabilidade dos requisitos ao longo do tempo (Hood et al., 2008).

• Rastreabilidade: Capacidade de acompanhar a origem, evolução e impacto dos requisitos ao longo do ciclo de vida do projeto, garantindo conformidade e coerência entre artefatos (Gotel & Finkelstein, 1994). Essa abordagem abrange todas as atividades de desenvolvimento, desde a captura (ou elicitação) dos requisitos até os testes finais. Contudo, é fundamental que a decisão de adotar a rastreabilidade seja feita já no início do projeto (Blaauboer, Sikkel e Aydin, 2007). De acordo com Gotel e Finkelstein (1994), existem dois tipos de rastreabilidade:
  • Rastreabilidade pré-especificação dos requisitos: aborda os requisitos antes de serem formalmente introduzidos nas especificações.
  • Rastreabilidade pós-especificação dos requisitos: concentra-se nos requisitos após sua introdução nas especificações formais.

A instabilidade dos requisitos é uma das principais causas de aumento não planejado do escopo e, consequentemente, de custo. O controle de mudança e a rastreabilidade contribuem para que as mudanças solicitadas sejam processadas de uma forma integrada com as outras atividades da gestão de requisitos e com os outros processos afetados  (graças às interfaces com outros processos).

Devido à sua importância na gestão de requisitos, destacamos aqui as principais funcionalidades da rastreabilidade dos requisitos: 

• Garantia de conformidade e controle de qualidade: Esse processo ajuda a garantir que os requisitos atendam aos padrões operacionais e regulamentares necessários. Além disso, dá suporte às atividades de controle de qualidade, ajudando a manter o alinhamento com o esperado (Ford e Triggs, 2006; Kirova et al., 2008).
• Facilitação da gestão de mudanças: Permite identificar e entender o impacto de mudanças nos requisitos, fornecendo análises que ajudam a decidir se essas alterações devem ser aceitas, rejeitadas ou ajustadas (Hull, Jeremy e Dick, 2011).
• Melhoria da qualidade: Ajuda a identificar os valores e características essenciais dos requisitos, garantindo que produtos ou sistemas sejam desenvolvidos de forma correta e consistente, alinhados com as expectativas (Sayão e Leite, 2006; Wiegers e Beatty, 2013).
• Controle e monitoramento do ciclo de vida: Oferece uma visão clara e detalhada de todas as etapas do ciclo de vida dos requisitos, desde sua criação até a entrega final. Isso possibilita ajustes e melhorias contínuas ao longo do processo (IIBA, 2015).
• Suporte à auditoria e documentação: Fornece evidências organizadas de que os requisitos foram rastreados e atendidos, o que é muito útil em auditorias e validações externas (Gotel e Finkelstein, 1994).
• Criação de um repositório centralizado: Pode associar informações sobre os requisitos, conectando-os às decisões tomadas, artefatos criados, códigos e testes. Isso facilita o trabalho em equipe e melhora a colaboração entre diferentes áreas (Wohlrab et al., 2020).

As seguintes práticas podem ser utilizadas no monitoramento e controle dos requisitos:

• Análise de dependências: Identifica relações entre requisitos, determinando quais dependem uns dos outros para serem atendidos. Os requisitos interdependentes são agrupados em uma matriz de rastreabilidade, e algumas ferramentas de gestão ilustram essas conexões por meio de árvores de rastreamento.
• Análise de impacto: Avalia as consequências de mudanças nos requisitos, considerando seus efeitos sobre outros requisitos, o produto, o projeto e o programa. Examina riscos, esforço necessário para a mudança e impactos no custo e cronograma, garantindo que a solução continue alinhada aos objetivos do negócio.
• Matriz de rastreabilidade: Estrutura que vincula os requisitos desde sua origem até os entregáveis que os satisfazem. Facilita o acompanhamento ao longo do ciclo de vida do projeto, garantindo que os requisitos aprovados sejam entregues e oferecendo suporte à gestão de mudanças e do escopo do produto.
• Comitês de controle de mudanças (CCB – change control boards): Grupo formal de stakeholders que avalia, aprova, adia ou rejeita mudanças nos requisitos. Projetos altamente regulados ou complexos podem exigir um CCB estruturado. O comitê decide sobre alterações significativas e pode delegar a aprovação de mudanças menores conforme critérios pré-definidos.

Repetimos abaixo a figura que ilustra as atividades da engenharia & gestão de requisitos distribuídas no tempo. Você pode observar que as atividades de monitoramento e controle dos requisitos ocorrem em paralelo com as demais atividades de engenharia & gestão de requisitos.

Figura 1323: atividades da engenharia & gestão de requisitos distribuídas no tempo

O mercado disponibiliza algumas soluções especializadas em gestão de requisitos, que são frequentemente denominadas Application Lifecycle Management (ALM) ou Requirements Management (RM) tools — que oferecem recursos avançados de rastreabilidade automática, visualização de dependências, controle de mudanças e integração direta com sistemas de teste e desenvolvimento.

Como o monitoramento e controle dos requisitos ocorrem em paralelo com as outras atividades de gestão de requisitos, essas ferramentas na prática apoiam o monitoramento e controle.

Além da rastreabilidade, essa ferramentas possuem as seguintes características:

• Colaboração: Permitem que os membros da equipe interajam de forma eficiente, facilitando a comunicação, o compartilhamento de informações e o acompanhamento de mudanças, especialmente em ambientes de trabalho híbridos ou distribuídos.
• Segurança: Protegem informações sensíveis, garantindo que o acesso aos dados seja controlado de acordo com os papéis e responsabilidades dos membros da equipe, evitando o uso indevido de informações confidenciais.
• Importação e integração: Viabilizam a incorporação de dados de outras aplicações e a integração com ferramentas amplamente utilizadas, reduzindo retrabalho e otimizando o fluxo de trabalho na gestão de requisitos.

Segundo Indeed Editorial Team (2025), em março de 2025, as principais ferramentas de software para a gestão de requisitos são: 

• SpiraTeam: Ferramenta ALM que integra requisitos, testes, releases e tarefas, com interface intuitiva e dashboards para análise em tempo real.
• Jira: Suporte ao desenvolvimento ágil, permitindo planejamento, rastreamento e gestão de requisitos, além da criação de roadmaps de produtos.
• Xebrio: Sistema de gestão de requisitos com rastreamento visual de mudanças, colaboração em tempo real e aprovação de requisitos por clientes.
• Orcanos: Oferece visualização, rastreabilidade de requisitos, gestão de documentos e riscos, além de dashboards e controle de baseline.
• Jama Connect: Focado em requisitos complexos, com rastreabilidade ao vivo, análise de impacto e suporte a testes para melhoria da qualidade.
• Wrike: Ferramenta de gestão de projetos que permite colaboração, rastreamento de requisitos e personalização de dashboards por equipe.
• CodeBeamer: Ferramenta colaborativa que rastreia requisitos funcionais e não funcionais, registra mudanças e permite aprovação personalizada.
• Accompa: Plataforma em nuvem para rastreamento de requisitos, análise de impacto, auditoria e integração com soluções de terceiros via API.
• iRise: Combina prototipagem e gestão de requisitos, permitindo especificação visual de necessidades com foco na interface e experiência do usuário.
• Modern Requirements4DevOps: Integrado ao Azure DevOps, oferece rastreabilidade, automação de testes, colaboração online e documentação centralizada.
• Perforce Helix RM: Ferramenta escalável para equipes distribuídas, com rastreabilidade de requisitos, colaboração em tempo real e análise de impacto.

Uma ferramenta não citada nesta lista é a IBM Rational DOORS, que é  uma plataforma de gestão de requisitos que permite capturar, rastrear, analisar e gerenciar mudanças, garantindo conformidade regulatória e melhorando a colaboração entre equipes. Utiliza inteligência artificial para otimizar a qualidade dos requisitos e a comunicação entre stakeholders, ajudando a controlar escopo e custos ao longo do projeto (IBM, 2025).

Algumas soluções de PLM (product lifecycle management) são mais amplas, podendo englobar outras áreas (engenharia, manufatura, QA, etc.), mas também fornecem funcionalidades que suportam o monitoramento e controle dos requisitos,  pois elas fornecem uma visão integrada de todo o ciclo de vida do produto.

Um exemplo é o SAP Integrated Product Development, que inclui a gestão de requisitos.

Softwares de controle de documentos também podem ser adaptados para apoiar a gestão de requisitos.

A escolha e a combinação entre essas ferramentas dependem do nível de maturidade organizacional e das metas estratégicas estabelecidas, permitindo tanto a profundidade necessária no controle de requisitos quanto a abrangência desejada para a orquestração de todo o processo de desenvolvimento.

Você pode observar na figura 1323 anterior, que a comunicação deve ocorrer durante praticamente todo o ciclo de vida, desde a atividade inicial de análise, em paralelo com a elicitação.

A comunicação desempenha um papel central na gestão de requisitos, assegurando que todas as partes interessadas tenham as informações necessárias para a tomada de decisões ao longo do ciclo de vida do projeto. Envolve a troca contínua de dados entre a equipe interna e os stakeholders, utilizando abordagens estruturadas para mitigar riscos, reduzir retrabalho e garantir alinhamento estratégico.

A comunicação na gestão de requisitos vai muito além do simples compartilhamento de informações. Quando bem conduzida, melhora a qualidade dos requisitos, otimiza processos e aumenta a aceitação do produto final, enquanto falhas nesse fluxo podem comprometer o projeto.

Comunicação proativa e engajamento de stakeholders

A comunicação eficaz facilita o envolvimento ativo dos stakeholders ao longo de todo o processo de requisitos. A troca constante de informações ajuda a esclarecer incertezas, alinhar expectativas e garantir que as necessidades do projeto sejam corretamente compreendidas.

Esse diálogo contínuo reduz o risco de mal-entendidos e possibilita um alinhamento mais preciso entre as soluções desenvolvidas e os objetivos estratégicos da organização.

Comunicação durante a análise e definição de requisitos

Durante a fase de análise, a comunicação frequente entre a equipe de projeto e os stakeholders melhora a qualidade dos requisitos ao minimizar ambiguidades. A troca de informações estruturada permite esclarecer pontos críticos, evitando interpretações errôneas que podem resultar em retrabalho e atrasos.

Métodos como modelagem de requisitos e linguagens de especificação padronizadas ajudam a estabelecer uma base comum para entendimento e tomada de decisão.

Comunicação no monitoramento e controle dos requisitos

A comunicação estruturada é essencial para garantir que o status dos requisitos seja continuamente atualizado e compartilhado. As informações sobre mudanças, impactos e evolução dos requisitos devem ser disseminadas para possibilitar o acompanhamento da rastreabilidade e da conformidade, garantindo que todos os envolvidos estejam cientes das responsabilidades e impactos de cada modificação.

Integração entre diferentes áreas e redução de retrabalho

Um dos desafios mais comuns na comunicação da gestão de requisitos ocorre entre áreas distintas, como vendas e marketing de um lado e desenvolvimento de outro. A falta de um entendimento comum sobre o sistema em desenvolvimento pode comprometer a definição de requisitos e gerar desalinhamentos significativos.

Métodos estruturados de modelagem e documentação reduzem essas dificuldades, proporcionando clareza e garantindo que os requisitos reflitam as reais expectativas dos usuários e clientes.

Impacto da comunicação na eficiência do desenvolvimento

A comunicação eficiente contribui diretamente para a redução dos ciclos de desenvolvimento, pois minimiza erros decorrentes de mal-entendidos e reduz a necessidade de retrabalho. Além disso, um fluxo adequado de informações pode acelerar o tempo de chegada ao mercado (time-to-market), aumentando a competitividade da organização ao permitir o lançamento de mais produtos dentro do mesmo período.

Comunicação com usuários e clientes finais

Além dos stakeholders internos, os usuários e clientes finais também devem estar envolvidos no processo de comunicação da gestão de requisitos. A interação contínua com esses públicos aumenta a precisão na definição dos requisitos, garantindo que os produtos resultantes estejam alinhados às suas necessidades reais.

Produtos desenvolvidos com base em processos sólidos de gestão de requisitos tendem a ter maior aceitação no mercado e melhor aderência às expectativas dos consumidores.

Os métodos e ferramentas anteriormente citados (modelos de requisitos, ferramentas de gestão de requisitos etc.) podem ser suficientes para estruturar o processo de comunicação no contexto da gestão de requisitos. Entretanto, há alguns pontos críticos a serem ponderados:

• Competências interpessoais: Apesar de dispormos de técnicas e plataformas robustas para organizar e disseminar informações (por exemplo, ferramentas de gestão de requisitos e fluxos de aprovação), a eficácia da comunicação depende, em grande medida, de competências interpessoais como escuta ativa, clareza de expressão, liderança situacional e inteligência emocional. Essas habilidades são igualmente cruciais para conduzir conversas difíceis, gerenciar expectativas conflituosas ou realizar negociações complexas.
• Cultura organizacional:  Além das competências interpessoais, a cultura organizacional, influencia fortemente a comunicação. Em empresas com maior maturidade em gestão de requisitos, tende a haver processos claros e legitimados para registro e compartilhamento de demandas, bem como papéis e responsabilidades definidos (por exemplo, Product Owner, Analistas de Negócio, Engenheiros de Requisitos). Contudo, se a cultura organizacional não valoriza a transparência e a colaboração, é provável que surjam lacunas comunicacionais. Nesse sentido, ferramentas e métodos não corrigem sozinhos barreiras culturais ou falta de habilidades de relacionamento.
• Customização do canal de comunicação:  Embora seja prático aproveitar métodos e ferramentas já existentes – como modelos de documentos, repositórios centralizados e processos de controle de versão –, a escolha dos canais de comunicação deve ser cuidadosamente adaptada aos stakeholders. Em alguns casos, reuniões presenciais ou videoconferências podem ser mais eficazes do que trocas assíncronas de mensagens. Em outros, uma ferramenta de controle de tarefas (como Jira ou Trello) pode ser suficiente para garantir o alinhamento entre equipes dispersas. A avaliação contínua da eficácia de cada canal e a flexibilidade para ajustá-lo são práticas essenciais.
• Integração com outras atividades de gestão:  A comunicação no âmbito da gestão de requisitos não acontece de forma isolada. Ela precisa estar integrada aos demais processos, como planejamento, priorização de escopo, validação e controle de mudanças. O uso de ferramentas de versionamento, rastreabilidade e documentação integrada (por exemplo, ALM – Application Lifecycle Management) é crítico, mas precisa ser complementado por rotinas de comunicação sistemática. A qualidade e a velocidade de resposta dentro desses sistemas são resultado tanto das funcionalidades da solução adotada quanto do comprometimento dos envolvidos em manter o conteúdo atualizado e coerente.
• Formalização vs. Flexibilidade:  Quando falamos em ferramentas e métodos de comunicação, há sempre um equilíbrio delicado entre formalização e agilidade. Exagerar na formalização pode gerar burocracia e entravar a troca de informações. Por outro lado, ser excessivamente flexível pode prejudicar a rastreabilidade e a clareza de papéis. A recomendação é buscar uma governança que defina ritos e padrões mínimos de comunicação (por exemplo, reuniões de checkpoint, registros de decisões e atas), sem prejudicar a capacidade de resposta às mudanças.

Utilizar as ferramentas de gestão de requisitos (softwares)?

As ferramentas de gestão de requisitos costumam cobrir a maior parte das necessidades de comunicação relacionadas ao registro e versionamento de requisitos. Mas, quando falamos em comunicação efetiva, abordando desde mensagens rápidas até debates amplos e não estruturados, a adoção de ferramentas corporativas de colaboração pode ajudar a suprir lacunas funcionais ou de uso, reforçando o alinhamento no contexto da gestão de requisitos.

Embora muitas dessas ferramentas incluam funcionalidades como comentários contextuais, fóruns de discussão e integrações com videoconferência, esses recursos nativos nem sempre são tão intuitivos ou eficazes quanto os de plataformas dedicadas à comunicação. Em muitos casos, soluções corporativas de colaboração oferecem melhor usabilidade e maior alcance entre os stakeholders, permitindo interações mais ágeis e engajamento contínuo no processo de requisitos.

Considere:

• Amplitude de usuários: As equipes de requisitos nem sempre incluem todos os stakeholders ou áreas da empresa que também precisam se manter informadas. Plataformas corporativas mais abrangentes (por exemplo, Teams, Slack) podem facilitar a participação de pessoas fora da área técnica, sem exigir acesso ou treinamento em uma ferramenta específica de requisitos.
• Experiência do usuário: Ferramentas de requisitos, ainda que evoluídas, costumam priorizar rastreabilidade, controle de versão e documentação estruturada. Já as plataformas de comunicação primam pela usabilidade e foco em trocas de mensagem ágeis, o que, dependendo do cenário, acaba trazendo mais engajamento e facilidade.
• Complementaridade: Mesmo quando existe uma funcionalidade de chat/discussão no repositório de requisitos, muitas organizações preferem manter um “hub” corporativo de comunicação para fins de governança e padronização. Essas ferramentas servem de camada transversal, integrando diversas equipes e sistemas de informação.

Este tópico é comum para as quatro seções que foram criadas sobre gestão de requisitos, conforme explicamos a seguir.

A elaboração desta seção foi um processo iterativo e estruturado, baseado exclusivamente nas referências citadas, sem recorrer a conhecimentos gerais do ChatGPT. Foram realizadas mais de 200 interações ao longo de quatro semanas para organizar, estruturar e revisar o conteúdo.

Inicialmente, o Sávio Aleixo criou uma versão baseada na sua dissertação de mestrado (Aleixo, 2021).

Em seguida, o segundo autor, analisou o conteúdo, estudou as referências citadas inicialmente e acrescentou outras, chegando a 28 referências, sendo 5 livros e 2 corpos de conhecimentos (BOKs) específicos sobre gestão de requisitos. Mais 3 BOKs foram adicionados sobre business analysis, que é uma abordagem, cujo pilar central é a gestão de requisitos.

Um novo sumário foi estruturado e depois da leitura e estudo das referências, foram extraídos trechos das publicações relacionadas aos tópicos do sumário.

Esses trechos foram passados para o chaGPT 4.o para que fossem resumidos. Nesse processo, o sumário foi modificado muitas vezes. Os autores avaliaram cada resumo criado pelo chatGPT 4.0, que foram editados para manter uma estrutura alinhada com um fluxo.

Em um certo momento, resolvemos integrar a gestão de stakeholders e avaliação de necessidades (needs assessment), que era a proposta tanto do BOK de gestão de requisitos  do PMI (2016), como do BABOK (IIAB, 2015) e outras publicações.

Conforme o conteúdo foi crescido, decidiu-se criar duas seções separadas:

• As atividades e práticas de avaliação de necessidades (needs assessment) - sem explicar com detalhes as práticas (só citando)
• As atividades e prática da gestão de requisitos   - que inclui a engenharia de requisitos (que integramos com a gestão de requisitos, como explicamos na seção principal). Nesta seção, os detalhes das atividades e das práticas foram expandidos. Foi ainda criado um tópico sobre as ferramentas de software.

Como na flexM4i já existia uma seção sobre gestão de stakeholders, ela foi associada à gestão de requisitos, e o resumo do processo de gestão de stakeholders foi inserido na seção principal da gestão de requisitos.

Nessa reestruturação, o chatGPT 1.o e o 4.5 foram utilizados para avaliar possíveis redundâncias. Ao invés de pedir para o chatGPT gerar o texto, no prompt pedimos para ele detectar os pontos, fazer propostas de melhorias pontuais, que foram analisadas e editadas pelo autor para complementar e/o mudar os tópicos dessas seções.

Com o tempo, baseado nas leituras, observamos que a gestão de requisitos é integrada com diversas abordagens e metodologias de desenvolvimento de soluções e inovação.

Na flexM4i, a gestão de requisitos é considerada um processo de apoio da gestão da inovação. O mesmo ocorre com diversos outros processos, alguns dos quais foram citados na publicação de Hood et al. (2008). Decidimos criar uma outra seção, voltada às pessoas interessadas no nível de detalhamento de treinamento e avançado:

•  Abordagens e metodologias que incorporam a gestão de requisitos

A criação dessa nova seção exigiu um estudo das publicações mais relevantes relacionadas com cada uma dessas abordagens e metodologias. O chatGPT 1.o foi utilizado para resumir a descrição dessas abordagens e metodologias, assim como a discussão sobre a integração com a gestão de requisitos. Essa fase foi demorada, para encontrar essas relações.

Basicamente, essas quatro novas seções estavam “prontas”. Neste momento, além da experiência dos autores, conversamos com praticantes da gestão de requisitos para discutir aspectos que iriamos apresentar. Essa discussão demorou um tempo elevado e chegamos na versão final.

Ai o chatGPT 4.o realizou uma análise crítica sobre essas seções para verificar novamente redundâncias e o fluxo do texto.

Com base nos resultados da análise crítica, todas as quatro seções foram novamente reeditadas pelos autores.

Criamos então a figura “Seções relacionadas com a gestão de requisitos na flexM4i”, apresentada no início de cada uma dessas quatro seções, que se tornou um mapa de conteúdo da flexM4i. Nela associamos outras seções da flexM4i relacionadas com a gestão de requisitos.

Essa versão que publicamos pode ainda sofrer ajustes, conforme recebermos feedback de praticantes, como todo o conteúdo da flexM4i. Por este motivo, gerenciamos o versionamento das seções da flexM4i.

O ChatGPT foi utilizado como ferramenta de apoio para sintetizar informações, sugerir formas de organização dos tópicos e revisar a coerência do material. O processo envolveu múltiplas rodadas de ajustes, garantindo que a seção refletisse com precisão os conceitos extraídos das fontes.

Em momentos específicos, o ChatGPT-4.o foi utilizado para revisões mais detalhadas, enquanto o ChatGPT-01 foi acionado para auxiliar em raciocínios mais complexos. Todas as decisões finais e a curadoria do conteúdo foram feitas pelo autor, garantindo alinhamento conceitual e coerência no texto.

Blaauboer, F., Sikkel, K., & Aydin, M. N. (2007). Deciding to adopt requirements traceability in practice. In J. Krogstie, A. Opdahl, & G. Sindre (Eds.), Advanced information systems engineering. CAiSE 2007. Lecture notes in computer science (Vol. 4495). Springer. https://doi.org/10.1007/978-3-540-72988-4_21

Dehghani, N. (2019). Defining requirements management process for product development projects (Master’s thesis, Helsinki Metropolia University of Applied Sciences). Industrial Management. http://urn.fi/URN:NBN:fi:amk-2019060414640

Ficalora, J. P. & Cohen, L. (2010). Quality function deployment and six sigma: A QFD handbook. Pearson Education, 2nd edition.

Ford, M., & Triggs, J. D. (2006). Traceability requirements in electronics assembly. In D. T. Pham, E. E. Eldukhri, & A. J. Soroka (Eds.), Intelligent production machines and systems (pp. 656–662). Elsevier Science Ltd. https://doi.org/10.1016/B978-008045157-2/50114-0

Gotel, O., & Finkelstein, A. C. W. (1994). An analysis of the requirements traceability problem. In Proceedings of the First International Conference on Requirements Engineering (pp. 94–101). Colorado Springs, CO. https://doi.org/10.1109/ICRE.1994.292398 

Gottesdiener, E. (2005). The software requirements memory jogger: A pocket guide to help software and business teams develop and manage requirements (5ª ed.). GOAL/QPC.

Grady, J. O. (2014). System requirements analysis (2nd ed.). Burlington, MA: Elsevier.

Hood, C., Wiedemann, S., Fichtinger, S., & Pautz, U. (2008). Requirements management: The interface between requirements development and all other systems engineering processes. Springer Science & Business Media. 

Hull, E., Jeremy, K., & Dick, J. (2011). Requirements engineering (3rd ed.). London, England: Springer. https://doi.org/10.1007/978-1-84996-405-0 

IBM (2025). IBM Engineering Requirements Management. Disponível em: https://www.ibm.com/products/requirements-management Recuperado em: 14/3/2025.

IIBA (2015). A guide to the business analysis body of knowledge – BABOK (3rd ed.). International Institute of Business Analysis. Toronto, Canada: IIBA.

Indeed Editorial Team (2025). 11 Requirements Management Tools (With Features And Pros). Disponível em: https://in.indeed.com/career-advice/career-development/requirements-management-tools Recuperado em: 14/3/2025 

ISO/IEC/IEEE (2010). ISO/IEC/IEEE 24765: 2010 – Systems and software engineering – Vocabulary. International Organization for Standardization; International Electrotechnical Commission; Institute of Electrical and Electronics Engineers.

ISO/IEC/IEEE 29148 (2011). Systems and software engineering – Life cycle processes – Requirements engineering. International Organization for Standardization; International Electrotechnical Commission; Institute of Electrical and Electronics Engineers.

Jallow, A. K., Demian, P., Baldwin, A. N., & Anumba, C. (2014). An empirical study of the complexity of requirements management in construction projects. Engineering, Construction and Architectural Management, 21(5), 505–531. https://doi.org/10.1108/ECAM-09-2013-0084

Karlsson, J., Wohlin, C., & Regnell, B. (1998). An evaluation of methods for prioritizing software requirements. Information and Software Technology, 39(14–15), 939–947. https://doi.org/10.1016/S0950-5849(97)00053-0

Kirova, V., Kirby, N., Kothari, D., & Childress, G. (2008). Effective requirements traceability: Models, tools, and practices. Bell Labs Technical Journal, 12(4), 143–157. https://doi.org/10.1002/bltj.20272 

Peruzzini, M., Marilungo, E., & Germani, M. (2015). Structured requirements elicitation for product-service system. International Journal of Agile Systems and Management, 84, 189–218. https://doi.org/10.1504/IJASM.2015.073516 

Pierce, M. (2025). 15 Product Feature Prioritization Frameworks Every PM Should Data – Driven Thinking Vs Gut Feelings : Which Is Better ? 1–21. Disponível em: https://theproductmanager.com/topics/product-feature-prioritization-frameworks/ Recuperado em: 10/05/2025

PMI (2013). A guide to the project management body of knowledge (PMBOK), 5th ed.. Newtown Square, PA: Project Management Institute Inc. Newtown Square, Pennsylvania. 

PMI (2015). Business analysis for practitioners: A practice guide. Project Management Institute Inc. Newtown Square, Pennsylvania. 

PMI (2016). Requirements management: a practice guide. Project Management Institute, Inc. Newtown Square, Pennsylvania.

PMI (2017). The PMI guide to business analysis. Project Management Institute, Inc. Newtown Square, Pennsylvania.

PMI (2021). A guide to the project management body of knowledge (PMBOK® Guide), 7th ed.. Project Management Institute, Inc. Newtown Square, Pennsylvania. 

Pohl, K. (2007). Requirements engineering: Grundlagen, Prinzipien, Techniken (1st ed.). Dpunkt Verlag. (Original work published 2007; reprinted 2016).

Sayão, M., & Leite, J. C. S. P. (2006). Rastreabilidade de requisitos. Revista de Informática Teórica e Aplicada, 13(1), 57–86.

Wohlrab, R., Knauss, E., Steghöfer, J.-P., Maro, S., Anjorin, A., & Pelliccione, P. (2020). Collaborative traceability management: A multiple case study from the perspectives of organization, process, and culture. Requirements Engineering. https://doi.org/10.1007/s00766-018-0306-1  

Wiegers, K. E., & Beatty, J. (2013). Software requirements (3rd ed.). Redmond, WA: Microsoft Press.