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)

Esta seção apresenta uma visão geral da articulação entre gestão de requisitos, gestão de stakeholders e avaliação de necessidades, que são detalhadas em três seções correspondentes, como ilustra a figura.

Na seção “Abordagens e metodologias que incorporam a gestão de requisitos” consideramos os seguintes tópicos:

• Gestão de requisitos na gestão de projetos, programas e portfólio
• Gestão de requisitos na análise de negócio (business analysis)
• Gestão de requisitos na Engenharia de Sistemas (SEBoK - INCOSE)
• Processos de desenvolvimento de produtos e a gestão de requisitos
• Engenharia de requisitos (norma ISO/IEC/IEEE 29148:2011)
• Gestão de requisitos no modelo CMMI (Capability Maturity Model Integration)
• Gestão de requisitos no SWEBOK (Software Engineering Body of Knowledge)
• Gestão de requisitos na gestão de mudanças de engenharia
• Gestão de requisitos na gestão de riscos
• Gestão de requisitos na agilidade (scrum, SAFe, LESS e XP)
• Convergências e diferenças entre as abordagens

Veja que no lado esquerdo da figura há uma caixa, que indica o link do repositório de “Abordagens de práticas de inovação” com a instrução para você encontrar seções da flexM4i inserindo o tag “requisitos” na busca. Assim, além das seções citadas na figura, você encontrará seções com métodos e ferramentas específicas (práticas) utilizadas nas atividades da gestão de requisitos. Indicamos dessa forma porque este conteúdo é dinâmico e sempre crescente.  

Conheça também  a seção da flexM4i com um checklist de requisitos de produtos e serviços que possui 31 categorias de requisitos. Os requisitos estão colocados na forma de questões. Ele está representado na caixa à direita em baixo.

A caixa acima da anterior tem o link para a metodologia de engenharia de requisitos para um Sistema Produto-Serviço (PSS), que resume um e-book sobre o mesmo assunto e traz alguns casos de desenvolvimento de requisitos para PSS

A gestão de requisitos não é um fim em si mesma; ela funciona como um alicerce para diversas metodologias de desenvolvimento e inovação (por exemplo, modelos ágeis, Stage-Gate® e engenharia de sistemas). Embora seja indispensável para capturar, analisar e manter a rastreabilidade das necessidades de clientes e partes interessadas, a verificação e a validação dos resultados finais costumam transcender o escopo específico da gestão de requisitos.

Na prática, os processos de verificação e validação de uma solução (produto, serviço, processo etc.) podem abranger aspectos não documentados como requisitos formais.

Por exemplo, pode haver exigências regulatórias adicionais descobertas durante ensaios de conformidade, ou surgirem novas preferências de experiência do usuário identificadas em testes de campo.

Embora idealmente todos esses pontos de controle deveriam ser mapeados em requisitos, a realidade do desenvolvimento de produtos, software e serviços mostra que é comum ajustar ou criar novos requisitos à medida que se descobre informação adicional.

Ainda assim, as atividades de verificação e avaliação dentro de cada abordagem de desenvolvimento apoiam-se fortemente nos critérios de desempenho, qualidade e funcionalidades oriundos da gestão de requisitos.

Há empresas que fazem validações que vão além do escopo tradicional de requisitos documentados, pois incluem, por exemplo, testes de aderência estratégica, verificações de indicadores financeiros, aspectos de experiência do cliente que podem ser mais subjetivos, entre outros fatores.

É esse conjunto de requisitos que fornece os parâmetros para identificar se o projeto está atendendo às necessidades esperadas, se há desvios ou se surgiram oportunidades de melhoria. Dessa forma, a gestão de requisitos permanece um pilar estratégico para garantir clareza e coerência no desenvolvimento, mas as metodologias adotadas podem incluir verificações complementares e refinamentos contínuos, mantendo um ciclo virtuoso de retroalimentação e evolução das soluções.

As atividades de verificação e avaliação dessas abordagens e metodologias devem ter seus próprios métodos e ferramentas. A  gestão de requisitos contribui para que durante essas atividades ocorra:

• Critérios simples e eficazes: Requisitos bem elaborados são a base para a construção de indicadores e parâmetros de qualidade, facilitando o monitoramento e a tomada de decisão ao longo do desenvolvimento.
• Comunicação transversal: A gestão de requisitos, quando realizada com envolvimento multidisciplinar (por exemplo, times de engenharia, design, marketing e operações), garante que todos tenham clareza dos objetivos e pré-requisitos, maximizando a efetividade das revisões e avaliações periódicas.
• Integração de processos: Diferentes abordagens de desenvolvimento – como o uso de protótipos, testes de conceito ou revisões de design – utilizarão os requisitos como “checklist” para aferir aderência às necessidades do negócio e às expectativas do cliente.
• Retroalimentação: Os resultados de testes e validações tendem a gerar insights para refinar requisitos ou priorizá-los conforme a evolução do projeto, caracterizando um ciclo de melhoria contínua.

Por esses motivos, não discutiremos nesta seção as atividades de verificação e validação das soluções finais desenvolvidas, que fazem parte do escopo das abordagens e metodologias de desenvolvimento e inovação específicas.

O Project Management Institute (PMI) apresenta a gestão de requisitos como um processo essencial dentro da governança de projetos, programas e portfólios. Segundo o PMI Requirements Management: a practice guide (PMI, 2016), a gestão de requisitos envolve tanto o desenvolvimento quanto o gerenciamento de requisitos, abrangendo atividades como:

• Avaliação de Necessidades: Identifica e define um problema ou oportunidade de negócio antes do início de um programa ou projeto. Deve ser revisitada caso fatores externos impactem o projeto.
• Planejamento da Gestão de Requisitos: Define a abordagem ideal para gerenciar requisitos dentro do planejamento do programa ou projeto, garantindo alinhamento com os objetivos gerais.
• Elicitação de Requisitos: Coleta informações de stakeholders e outras fontes para compreender as necessidades do negócio, preferências e condições para a solução.
• Análise de Requisitos: Examina, decompõe e sintetiza os requisitos elicitados, transformando-os em um conjunto estruturado e acionável para atender aos objetivos do projeto.
• Monitoramento e Controle de Requisitos: Garante a rastreabilidade contínua dos requisitos, controlando mudanças e assegurando que o escopo do produto permaneça gerenciado ao longo do projeto.
• Avaliação da Solução: Valida a solução implementada ou em implementação para garantir que atenda às necessidades do negócio e entregue o valor esperado.
• Encerramento do Projeto ou Fase: Transfere o produto, serviço ou resultado para a fase de manutenção, garantindo que a solução continue a atender aos requisitos e agregar valor ao negócio.

Esse manual destaca ainda: 

• Integração com os grupos de processos do PMBOK, incluindo planejamento, execução, monitoramento e controle, e encerramento (essa integração se relacionava com as versões do PMBOK, que continham os processos de gerenciamento de projetos)
• Colaboração entre gerentes de projeto e analistas de negócios, reforçando que a gestão de requisitos não ocorre isoladamente, mas dentro de um contexto maior de análise de negócios e governança.

O PMI enfatiza que requisitos são dinâmicos e iterativos, demandando uma abordagem estruturada para evitar desalinhamentos que possam comprometer a entrega do projeto.

Paradigma preditivo versus adaptativo

Hoje, adotamos um paradigma de  gestão de projetos de acordo com o nível de incerteza, risco, novidade e outros, que fica entre o preditivo (também conhecido como tradicional ou plan driven) e o adaptativo (também conhecido como ágil). De acordo com as características citadas, adotamos também o paradigma híbrido, ou seja, combinamos algumas práticas da gestão preditiva com outras da adaptativa. O paradigma de gestão de projetos influencia a gestão de requisitos.

No paradigma preditivo:

• os requisitos são determinados antes do desenvolvimento do projeto ou nas fases iniciais, se elas abrangerem a elicitação de necessidades e requisitos.
• os riscos e custos são previstos e controlados a partir de um planejamento detalhado, que é baseado em uma análise detalhada dos requisitos e limitações antes do desenvolvimento.
• os principais stakeholders são envolvidos em alguns milestones, por exemplo nos gates (se for prática da empresa)

No paradigma adaptativo (ágil)

• os requisitos são elaborados (detalhados) para cada iteração, normalmente em intervalos pré definidos.
• os riscos e custos são fixados e controlados a cada iteração
• os stakeholders principais estão engajados contínua e ativamente.

No paradigma híbrido adota-se uma combinação dessas práticas conforme as características do projeto.

“Análise de negócio é a prática de apoiar a mudança em uma empresa, definindo necessidades e recomendando soluções que agreguem valor aos stakeholders” (IIBA, 2015).

“Análise de negócio é o conjunto de atividades realizadas para garantir que soluções desenvolvidas estejam alinhadas aos objetivos de negócio e proporcionem valor contínuo para a organização. Essas atividades envolvem a identificação de necessidades, definição de soluções e comunicação clara dos requisitos para garantir que produtos e serviços atendam às expectativas dos stakeholders” (PMI, 2017). 

No Business Analysis Body of Knowledge (BABOK) do IIBA

O International Institute of Business Analysis (IIBA) estrutura a gestão de requisitos dentro da disciplina de Business Analysis, conforme descrito no Business Analysis Body of Knowledge (BABOK). Diferentemente do PMI, o BABOK adota uma visão mais ampla e estratégica, considerando requisitos não apenas em projetos, mas em iniciativas estratégicas e operacionais.

Principais aspectos da abordagem do BABOK:

• Gestão contínua de requisitos: Os requisitos podem evoluir mesmo após a entrega do projeto, garantindo alinhamento com os objetivos de longo prazo da organização.
• Ênfase na colaboração com stakeholders: A elicitação de requisitos é um processo interativo e contínuo, envolvendo múltiplas técnicas de análise.
• Estrutura baseada em domínios de conhecimento: O BABOK divide a gestão de requisitos em áreas como elicitação, análise, modelagem e validação, tornando o processo mais abrangente.

No PMI guide to business analysis do PMI

A próxima figura representa as áreas de conhecimento do guia de análise de negócio (BA – business analysis) e ilustra sua relação com a gestão de portfólio e de projetos.

Figura 1310: localização da engenharia de requisitos dentro da análise de negócios (BA) de acordo com PMI
Fonte: adaptada de PMI (2017)

 As principais atividades da business analysis, que inclui a gestão de requisitos são:

• Avaliação de Necessidades: Analisa um problema ou oportunidade de negócio, compara o estado atual e futuro, e identifica a solução ideal. O resultado dessa análise orienta a tomada de decisão sobre o investimento na solução.
• Engajamento de Stakeholders:  Identifica e analisa as partes interessadas na solução, definindo como envolvê-las, comunicar e colaborar. Garante um entendimento compartilhado das atividades de Business Analysis e monitora sua efetividade.
• Elicitação: Planeja, conduz e confirma a elicitação de informações sobre necessidades, requisitos e detalhes do produto, obtendo insights de diferentes fontes.
• Análise: Examina e documenta as informações do produto, garantindo que reflitam as necessidades dos stakeholders, estejam alinhadas aos objetivos do negócio e possibilitem o desenho de soluções viáveis.
• Rastreabilidade e Monitoramento: Relaciona requisitos e informações do produto, garantindo que sejam aprovados, gerenciados e que os impactos das mudanças sejam avaliados.
• Avaliação da Solução: Valida uma solução ou parte dela, verificando se atende às necessidades do negócio e entrega valor aos stakeholders.

A Engenharia de Requisitos é amplamente abordada dentro da Engenharia de Sistemas, sendo um dos temas fundamentais do INCOSE (International Council on Systems Engineering) e estruturada no SEBoK (Systems Engineering Body of Knowledge). O INCOSE adota uma visão integrada, considerando todo o ciclo de vida do sistema, desde sua concepção até a operação e manutenção.

No contexto do INCOSE, a Engenharia de Requisitos inclui tanto a definição de requisitos (System Requirements Definition) quanto a Gestão de Requisitos (Requirements Management). Essas atividades abrangem a elicitação, análise, rastreabilidade e verificação dos requisitos ao longo de todo o ciclo de vida do sistema.

O SEBoK organiza essas atividades dentro da disciplina de Engenharia de Sistemas, enfatizando a integração entre componentes e o alinhamento dos requisitos com objetivos operacionais e estratégicos. Embora a Engenharia de Sistemas inclua software, seu foco principal é garantir que os requisitos de software sejam derivados de requisitos de sistema mais amplos, garantindo coerência entre todos os elementos do projeto.

Principais características da gestão de requisitos na Engenharia de Sistemas

• Hierarquia de requisitos: Estrutura os requisitos em diferentes níveis (sistema, subsistema e componentes), garantindo coerência entre os elementos do sistema.
• Rastreabilidade e Gestão de Mudanças: Relaciona requisitos entre diferentes níveis do sistema e acompanha sua evolução ao longo do ciclo de vida, avaliando impactos de mudanças.
• Integração com Engenharia de Software: Os requisitos de software derivam dos requisitos do sistema, assegurando que funcionalidades de software estejam alinhadas com as necessidades operacionais.
• Verificação e Validação de Requisitos: Métodos rigorosos para garantir que os requisitos sejam completos, testáveis e atendam às necessidades operacionais e de stakeholders.

Embora tenha um viés sistemático e técnico, essa abordagem também enfatiza a gestão contínua dos requisitos ao longo do ciclo de vida do sistema, garantindo que mudanças, rastreabilidade e evolução dos requisitos sejam controladas de maneira estruturada.

Geralmente, os requisitos de produto surgem quando já se conhece o conceito do produto.

Existem diversos processos de desenvolvimento de produtos, como o que apresentamos no tópico anterior da Engenharia de Sistemas.

Um modelo genérico, que mostra o conceito da relação das requisitos, especificações e testes é o modelo “V”, que faz parte dos fundamentos de diversos processos de desenvolvimento de produtos. Este modelo “V” é ilustrado na próxima figura.

Figura 1325: Modelo “V” do processo de desenvolvimento de produtos
Fonte: adaptado de Rozenfeld et al. (2006)

Por trás das especificações da arquitetura do produto, sistemas, subsistemas e componentes estão os requisitos, como um dos atributos que direcionam o desenvolvimento das especificações, ilustrados figura abaixo.

Figura 1326: requisitos “como um dos atributos” das especificações de produto, sistemas, subsistemas e componentes no modelo “V” do processo de desenvolvimento de produtos
Fonte: adaptado de Rozenfeld et al. (2006)

A ISO/IEC/IEEE 29148:2011 define os processos, atividades e diretrizes para a Engenharia de Requisitos ao longo do ciclo de vida de sistemas e software. Ela estabelece as boas práticas para elicitação, análise, especificação, validação e gestão de requisitos, servindo como uma referência central para organizações que trabalham com sistemas complexos e desenvolvimento de software.

Essa norma foi desenvolvida como parte do alinhamento entre as normas ISO/IEC 15288 (processos de ciclo de vida de sistemas) e ISO/IEC 12207 (processos de ciclo de vida de software), oferecendo diretrizes aplicáveis tanto à Engenharia de Sistemas quanto à Engenharia de Software.

Principais atividades / processos

1. Definição de Requisitos dos Stakeholders

• Identificação dos stakeholders envolvidos no sistema.
• Elicitação das necessidades, expectativas e restrições dos stakeholders.
• Análise das necessidades e transformação em requisitos formais dos stakeholders.
• Definição dos critérios de validação para os requisitos dos stakeholders.

2. Análise de Requisitos

• Refinamento dos requisitos dos stakeholders para derivar requisitos do sistema.
• Identificação de requisitos funcionais, não funcionais e de qualidade.
• Garantia de que os requisitos sejam completos, consistentes e verificáveis.
• Verificação da viabilidade dos requisitos antes de prosseguir para o design do sistema.

3. Requisitos em Outros Processos Técnicos

• Consideração dos requisitos no design arquitetural do sistema.
• Relacionamento dos requisitos com processos de verificação e validação.
• Estabelecimento de métricas para rastrear o cumprimento dos requisitos.

4. Gestão de Requisitos (Requirements Management)

• Controle da rastreabilidade dos requisitos ao longo do ciclo de vida.
• Gestão de mudanças e impactos nas especificações de requisitos.
• Monitoramento da conformidade dos requisitos ao longo do desenvolvimento.

O modelo CMMI evoluiu, como mostra a descrição extensiva que fizemos dele no glossário.

Versão 2.0

Na versão anterior (2.0), quando ainda havia modelos separado por aplicação, no modelo CMMI-DEV (para desenvolvimento), existiam duas áreas de processo (que hoje são denominadas de áreas de práticas), relacionadas com a gestão de requisitos:

1. Desenvolvimento de Requisitos (RD – Requirements Development): Esta área de processo, situada no Nível de Maturidade 3, foca na elicitação, análise e estabelecimento de requisitos de clientes, produtos e componentes de produtos. As práticas específicas incluem:

• SG 1: Desenvolver Requisitos do Cliente
  • SP 1.1: Elicitar Necessidades
  • SP 1.2: Transformar Necessidades das Partes Interessadas em Requisitos do Cliente
• SG 2: Desenvolver Requisitos do Produto
  • SP 2.1: Estabelecer Requisitos do Produto e de Componentes do Produto
  • SP 2.2: Alocar Requisitos de Componentes do Produto
  • SP 2.3: Identificar Requisitos de Interface
• SG 3: Analisar e Validar Requisitos
  • SP 3.1: Estabelecer Conceitos Operacionais e Cenários
  • SP 3.2: Estabelecer uma Definição de Funcionalidade e Atributos de Qualidade Necessários
  • SP 3.3: Analisar Requisitos
  • SP 3.4: Analisar Requisitos para Alcançar Equilíbrio
  • SP 3.5: Validar Requisitos

2. Gestão de Requisitos (REQM – Requirements Management): Esta área de processo, situada no Nível de Maturidade 2, visa gerenciar os requisitos dos produtos e componentes do projeto, garantindo alinhamento entre esses requisitos e os planos e produtos de trabalho do projeto. As práticas específicas incluem:

• SG 1: Gerenciar Requisitos
  • SP 1.1: Compreender os Requisitos
  • SP 1.2: Obter Compromisso com os Requisitos
  • SP 1.3: Gerenciar Mudanças nos Requisitos
  • SP 1.4: Manter a Rastreabilidade Bidirecional dos Requisitos
  • SP 1.5: Garantir Alinhamento entre o Trabalho do Projeto e os Requisitos

Versão 3.0

Na versão atual, que reestruturou o CMMI e unificou as diferentes aplicações, a práticas estão estruturadas dentro de categorias, áreas de capabilidade (no verbete do glossário que citamos acima, você pode observar quais a estrutura das práticas do CMMI).

A área de prática “Requirements Development & Management” (RDM) combina os princípios de desenvolvimento e gestão de requisitos que anteriormente eram tratados separadamente no CMMI-DEV. Agora, dentro da área de capacidade “Ensuring Quality” (ENQ), o RDM tem um papel central na definição, análise, rastreabilidade e alinhamento dos requisitos ao longo do ciclo de vida do projeto.

No CMMI 3.0, essa área de prática reforça a necessidade de:

• Elicitação e definição dos requisitos das partes interessadas, garantindo que as necessidades sejam bem compreendidas e transformadas em especificações técnicas e funcionais claras.
• Gestão da rastreabilidade bidirecional, assegurando que os requisitos sejam mantidos alinhados com os produtos de trabalho e planos do projeto.
• Avaliação contínua dos requisitos, incluindo a análise de impactos, controle de mudanças e validação para garantir que as entregas finais atendam às expectativas e restrições definidas.

Ao integrar o desenvolvimento e a gestão de requisitos em uma única área de prática, o CMMI 3.0 promove maior consistência na engenharia de requisitos, garantindo que os processos de definição e controle sejam aplicados de forma estruturada e com foco na qualidade.

O SWEBOK (Software Engineering Body of Knowledge) organiza o conhecimento essencial da engenharia de software, incluindo a engenharia de requisitos como uma de suas principais áreas. Diferente do SEBoK, que trata a engenharia de sistemas de forma ampla, o SWEBOK foca exclusivamente no desenvolvimento de software, estabelecendo diretrizes para a especificação, análise, validação e gestão de requisitos.

Estrutura da Engenharia de Requisitos no SWEBOK

O SWEBOK divide a engenharia de requisitos em cinco atividades principais:

1. Elicitação de Requisitos

• Processo de identificar as necessidades do cliente, usuários e outras partes interessadas.
• Métodos comuns incluem entrevistas, questionários, brainstorming, análise de documentos e workshops.

2. Análise de Requisitos

• Organização e refinamento dos requisitos identificados, garantindo clareza, viabilidade e consistência.
• Técnicas como modelagem de casos de uso, diagramas de estados e fluxogramas auxiliam na análise.

3. Especificação de Requisitos

• Formalização dos requisitos em um documento estruturado, como o Software Requirements Specification (SRS) baseado na norma IEEE 830.
• Diferenciação entre requisitos funcionais (o que o software faz) e requisitos não funcionais (desempenho, segurança, usabilidade).

4. Validação de Requisitos

• Processo de verificar se os requisitos documentados realmente refletem as necessidades do usuário e são viáveis.
• Métodos incluem prototipagem, revisões técnicas e simulações.

5. Gestão de Requisitos

• Controle das mudanças nos requisitos ao longo do desenvolvimento do software.
• Manutenção da rastreabilidade dos requisitos desde a elicitação até a implementação.
• Uso de ferramentas como JIRA e IBM DOORS para rastrear mudanças e impactos.

Princípios da Gestão de Requisitos no SWEBOK

A abordagem do SWEBOK para gestão de requisitos segue alguns princípios essenciais:

• Iteratividade – A engenharia de requisitos não é um processo linear; envolve ciclos contínuos de refinamento.
• Rastreabilidade – Cada requisito deve estar vinculado às suas origens e às decisões do projeto.
• Gerenciamento de mudanças – Os requisitos evoluem, e um controle rigoroso das alterações é essencial.
• Formalização – A especificação deve seguir padrões para evitar ambiguidades e facilitar a comunicação entre as equipes.

Gestão da mudanças de engenharia é uma prática, com processo correspondente, da gestão da configuração de produtos (ou sistemas), que tem o objetivo de assegurar que modificações nos itens de um produto e suas interfaces sejam avaliadas, aprovadas e implementadas de maneira controlada, garantindo a rastreabilidade, a integridade do sistema e a minimização de impactos no desempenho, custo e prazo do projeto.  

Não confundir com a gestão de mudanças na perspectiva das pessoas e da organização !

É também um dos processos do “Monitoramento e controle de requisitos” apresentados na seção “Atividades e práticas da gestão de requisitos”. 

As mudanças ocorrem para resolver problemas ou para aproveitar oportunidades, como ilustra a próxima figura.

Figura 1324: mudança de engenharia originando de problemas ou oportunidades
Fonte: Rozenfeld et al. (2006)

Problema é algo que o usuário identifica como a não-conformidade de um atributo de qualidade, esperado do produto ou processo. Um problema possui causas e consequências (efeitos).

Oportunidade é uma lacuna de negócio ou tecnologia que uma empresa ou um indivíduo percebe, que existe entre a situação atual e o futuro previsto a fim de capturar uma vantagem competitiva, responder a uma ameaça, resolver um problema ou lidar com uma dificuldade” (Koen et al., 2002). 

Para resolver o problema ou aproveitar a oportunidade, podemos fazer uma proposta de mudança. Essa proposta pode possuir somente a descrição do problema ou da oportunidade, ou já conter alguma solução, conforme o grau de conhecimento do proponente. No caso de conter somente a descrição do problema ou da oportunidade, deve existir uma fase de análise, que cria a proposta. No caso de já contar com uma proposta de solução, devemos fazer uma análise da viabilidade de sua implantação.

O método (ou processo) de mudança de engenharia contém as seguintes atividades (Rozenfeld et al., 2006):

• Identificar a mudança

• • • encaminhar o problema / oportunidade
    • avaliar o problema / oportunidade
    • solicitar a mudança: abrir um pedido de mudança de engenharia (ECR – engineering change request)
    • encaminhar a solicitação (ECR)

• Propor a mudança

• • • analisar a mudança
    • propor uma solução
    • ordenar a mudança: abrir uma ordem de mudança (ECO – engineering change order)
  • Alterar as informações do produto (e consequentemente os requisitos)
    • planejar a mudança
    • verificar o plano de mudança
    • executar a mudança (nas informações das especificações)
    • aprovar a mudança (nas informações das especificações)

• Implementar a mudança

• • avaliar o impacto e definir a efetividade
  • liberar a mudança (para ser implementada)
  • modificar as ordens de fabricação ou os pedidos de compra existentes com base na especificação antiga
  • modificar a configuração do produto / serviço (que inclui os requisitos)
  • divulgar mudança (que pode incluir um recall, caso o produto já estiver no mercado)
  • acompanhar a implementação da mudança
  • arquivar toda documentação

Falamos de mudanças dos itens de um produto. Elas têm consequências sobre os requisitos, pois um novo item provavelmente provavelmente gera novos requisitos ou mudanças em requisitos existentes. Então, como mostrado na atividade de “Monitoramento e controle de requisitos”, ao conduzir o processo de gestão de mudanças de engenharia, tratamos de forma integrada os requisitos para garantir a integridade das informações e rastreabilidade dos requisitos. 

A gestão de riscos é um processo essencial para mitigar impactos negativos sobre projetos, produtos e organizações. No contexto da gestão de requisitos, a gestão de riscos desempenha um papel fundamental ao identificar e tratar incertezas relacionadas à definição e ao gerenciamento de requisitos.

Classificação de Riscos

Os riscos na gestão de requisitos podem ser categorizados em diferentes domínios (Hood et al., 2008):

• Riscos do projeto: Impactam o cronograma e os recursos do projeto.
• Riscos do produto: Afetam a qualidade e o desempenho do produto desenvolvido.
• Riscos do negócio: Relacionam-se à viabilidade estratégica e organizacional.
• Riscos técnicos: Resultam de incertezas tecnológicas e da implementação dos requisitos.
• Riscos humanos: Envolvem falhas na comunicação e na gestão de stakeholders.
• Riscos de processo: Decorrem de deficiências nos métodos e ferramentas utilizadas na gestão de requisitos.

Processo de gestão de riscos

As atividades do processo genérico de gestão de riscos listadas a seguir são resumidas do processo apresentado na seção “Gestão de riscos da inovação”, ilustrado na próxima figura.

Figura 512: processo genérico de gestão de riscos
Fonte: adaptado da  norma ISO 31000:2018, de gestão de riscos

• Escopo, contexto e critérios: Considera o ambiente interno e externo, definindo objetivos, escopo, critérios e parâmetros para avaliar riscos, alinhados à política de gestão de riscos.
• Identificação dos riscos: Levanta fontes, impactos, eventos e suas causas, garantindo uma lista abrangente que inclua riscos por falta de ação.
• Análise dos riscos: Examina causas, consequências, probabilidades e fatores que influenciam os impactos, preparando a base para decisões.
• Avaliação dos riscos: Compara riscos identificados com critérios definidos, priorizando aqueles que exigem tratamento e ajustes em controles existentes.
• Tratamento dos riscos: Define ações para mitigar, transferir, aceitar ou eliminar riscos, considerando custo-benefício e implementação de contramedidas.
• Monitoramento e análise crítica: Acompanha a efetividade das ações, analisa resultados, ajusta estratégias e registra lições aprendidas.
• Registro e relato: Documenta decisões, ações e impactos, promovendo o aprendizado organizacional e reutilização de medidas eficazes.

Contribuição da Gestão de Requisitos para a Gestão de Riscos

A integração da gestão de requisitos com a gestão de riscos fornece  informações críticas sobre incertezas e impactos ao longo do ciclo de vida de um projeto ou sistema. Essa integração minimiza ameaças ao projeto e também melhora a tomada de decisão, garantindo maior previsibilidade e alinhamento entre objetivos estratégicos, técnicos e operacionais.

Essa integração ocorre de diversas maneiras (Hood et al., 2008):

• Rastreabilidade entre requisitos e riscos: A gestão de requisitos estabelece conexões entre requisitos e riscos identificados, permitindo um rastreamento detalhado das possíveis ameaças associadas a cada requisito. Esse vínculo facilita a análise do impacto de mudanças e auxilia na priorização de ações para mitigar riscos antes que eles comprometam o projeto.
• Identificação de riscos inerentes aos requisitos: Certos atributos dos requisitos podem indicar potenciais riscos, como:
  • Volatilidade: Requisitos que sofrem muitas mudanças ao longo do projeto podem sinalizar instabilidade ou incertezas nos objetivos do sistema.
  • Complexidade: Quanto mais complexo um requisito, maior o risco de dificuldades na implementação, testes e integração.
  • Custo: Requisitos de alto custo podem se tornar inviáveis financeiramente ou gerar impactos significativos caso sofram alterações.
• Uso da gestão de requisitos para apoio à identificação de riscos: Além da análise dos próprios requisitos, a gestão de requisitos pode contribuir com métodos estruturados para identificação de riscos, como a utilização de checklists de riscos baseados em projetos anteriores, análise de cenários de uso e falha (misuse cases) e levantamento de riscos por meio de workshops com stakeholders.
• Documentação e acessibilidade de contramedidas: O repositório de requisitos pode servir como um banco de dados centralizado para registrar riscos associados, decisões tomadas e contramedidas implementadas. Isso assegura que todos os stakeholders tenham acesso às informações relevantes e que a rastreabilidade entre requisitos, riscos e soluções adotadas seja mantida.
• Apoio à avaliação contínua de riscos: A gestão de requisitos facilita o monitoramento dos riscos ao longo do projeto, pois mantém atualizados os vínculos entre mudanças nos requisitos e impactos sobre riscos já identificados. Isso permite ajustes mais ágeis nas estratégias de mitigação conforme novas informações surgem.

• No Scrum, a responsabilidade pelos requisitos está com o Product Owner, que prioriza e refina o backlog.
• No LeSS, a gestão de requisitos se baseia em um backlog único e na coordenação lean de múltiplos times, mantendo a adaptação contínua e garantindo o alinhamento estratégico em grande escala.
• No SAFe, requisitos são alinhados com estratégia, fluxo de valor e execução iterativa.
• No XP, os requisitos são derivados do feedback contínuo dos clientes e da programação orientada a testes (TDD – Test Driven Development).

Segundo Kasauli et al. (2021), a adoção de métodos ágeis em sistemas complexos traz desafios adicionais para a gestão de requisitos, especialmente quando há integração entre software e hardware. Pesquisas indicam que …

… a conciliação entre métodos ágeis e a engenharia de requisitos tradicional exige um equilíbrio entre flexibilidade e previsibilidade.

Entre os desafios mais comuns estão a dificuldade em sincronizar diferentes ciclos de desenvolvimento, a necessidade de manter um entendimento compartilhado dos requisitos e a rastreabilidade sem gerar burocracia excessiva.

Para lidar com essas questões, frameworks como SAFe e LeSS incorporam práticas como backlog único, solution intent e refinamento contínuo, permitindo maior alinhamento entre os requisitos e a entrega iterativa de valor.

No Scrum, a responsabilidade pelos requisitos está com o Product Owner, que prioriza e refina o backlog. Os requisitos são representados por itens do backlog do produto (Product Backlog Items – PBIs), que podem incluir histórias de usuário, funcionalidades e melhorias. Os itens do backlog do produto são gerenciados por meio de:

• Priorização dinâmica pelo Product Owner, com base no valor de negócio.
• Definição incremental e refinamento contínuo (Backlog Refinement).
• Rastreabilidade baseada na entrega de incrementos de software, sem documentação extensiva.

O LESS é um framework que adapta o Scrum para ambientes de múltiplos times, mantendo foco na entrega contínua de valor. Ele opera com um Product Backlog único e papéis enxutos, priorizando a colaboração entre equipes e a transparência no fluxo de trabalho. Na gestão de requisitos, o LeSS mantém os princípios ágeis de adaptação constante e feedback contínuo, ao mesmo tempo em que coordena múltiplas equipes para garantir alinhamento estratégico e maximização de valor em escala corporativa.

No SAFe, a gestão de requisitos ocorre em diferentes níveis organizacionais:

• Épicos (nível estratégico): Grandes iniciativas de transformação.
• Features (nível de programa): Funcionalidades de alto nível que entregam valor ao cliente.
• Stories (nível de time): Pequenos incrementos que contribuem para a entrega das features. A rastreabilidade dos requisitos é garantida por meio do Kanban de Portfólio, Programa e Times, alinhando estratégia e execução.

No XP, a gestão de requisitos é altamente colaborativa e voltada para:

• Histórias de usuário como principal forma de captura de requisitos.
• Feedback contínuo e desenvolvimento iterativo.
• Automação de testes para garantir que os requisitos implementados atendam às expectativas.

Apesar das diferenças nos enfoques, todas as abordagens compartilham alguns princípios fundamentais:

• Importância da rastreabilidade e controle de mudanças: Todas enfatizam a necessidade de gerenciar a evolução dos requisitos ao longo do ciclo de vida do projeto ou sistema.
• Qualidade dos requisitos como fator crítico para o sucesso: Independente do contexto, um requisito mal definido pode comprometer todo o projeto, impactando escopo, custo e prazo.
• Uso de técnicas de elicitação, modelagem e validação: Cada abordagem utiliza técnicas apropriadas ao seu contexto, seja por meio de documentação formal, modelagem gráfica, user stories ou workshops colaborativos.

Por outro lado, há diferenças significativas entre os enfoques:

• Foco do PMI: Gestão de requisitos dentro da governança de projetos. Priorização de escopo e alinhamento estratégico, com forte integração aos grupos de processos do PMBOK.
• Foco do BABOK (IIBA): Gestão de requisitos dentro da análise de negócios, com um olhar mais amplo e estratégico, considerando iniciativas corporativas além do escopo de um único projeto.
• Foco da Engenharia de Requisitos (INCOSE, ISO/IEC): Abordagem técnica voltada para sistemas completos (hardware, software e interfaces), com alto rigor metodológico, rastreabilidade total e controle estrito de mudanças.
• Foco na Engenharia de Software (CMMI, IEEE, SWEBOK, Ágil): Dependendo do contexto, pode seguir desde abordagens formais e estruturadas (como CMMI e IEEE) até metodologias mais dinâmicas e adaptativas (como Scrum e XP), onde requisitos evoluem continuamente por meio de backlog e iterações.

Enquanto PMI e BABOK tratam os requisitos como parte de um processo gerencial e estratégico, Engenharia de Requisitos e Engenharia de Software enfatizam um viés técnico, com maior nível de detalhamento e especificação.

Como o foco da flexM4i é a gestão da inovação, destacamos essa relação com a gestão de requisitos. A maior parte das abordagens e metodologias apresentadas anteriormente podem ser consideradas abordagens e metodologias de inovação. Portanto, as relações apresentadas já mostram diferentes formas de se integrar a gestão de requisitos com a gestão da inovação.

A gestão de requisitos direciona o esforço criativo e assegura que os resultados atendam às expectativas do negócio e dos stakeholders, com foco no cliente. Ou seja, abrangem também requisitos regulatórios e outros tipos de regulamentações. Dessa forma, a gestão de requisitos viabiliza produtos, serviços ou processos mais aderentes ao valor pretendido, contribuindo para uma entrega mais ágil e assertiva.

Já vimos na seção principal sobre gestão de requisitos, que eles surgem no final da fase inicial da inovação. Tão logo conseguimos formalizar os requisitos, eles se tornam parte estruturante do escopo de desenvolvimento. Assim, a inovação se beneficia de requisitos bem definidos para alinhar expectativas, avaliar o impacto de mudanças e guiar tomadas de decisão em cada ciclo de concepção e entrega.

Por exemplo, em uma empresa que desenvolve um novo serviço digital, a fase inicial de inovação pode revelar necessidades de integração com plataformas externas ou novas exigências de segurança de dados. Se essas necessidades forem convertidas em requisitos explícitos e rastreáveis, as equipes de desenvolvimento podem priorizar recursos mais adequados e tomar decisões de investimento com mais embasamento.

As atividades de rastreabilidade e controle de mudanças da gestão de requisitos constituem um fator de sucesso para assegurar que iniciativas inovadoras permaneçam conectadas aos objetivos organizacionais e gerem resultados tangíveis.

A gestão de requisitos é um processo de apoio transversal da gestão da inovação, que potencializa a geração de valor, pois diminui retrabalhos e reduz riscos ao longo do ciclo de vida de uma solução (produto, serviço, processo etc.)

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.

ABNT (1994). NBR 5462 Confiabilidade e Mantenabilidade.

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

Baki, B., Bas, T., Kocabasoglu, C., & Satir, A. (2009). An application of integrating SERVQUAL and Kano’s model into QFD for logistics services: A case study from Turkey. Asia Pacific Journal of Marketing and Logistics, 21(1), 106–126. 

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

Durugbo, C. (2013). Integrated product-service analysis using SysML requirement diagrams. Systems Engineering, 16(1), 111–123. https://doi.org/10.1002/sys.21229 

Echeveste, M., Cannarozzo, M., & Sastre, R. (2020). Engenharia de requisitos em sistemas produto-serviço: do modelo de negócio ao conceito. In R-PSS: Métodos e casos (p. 126). Marcavisual Editora e Projetos Culturais Ltda. 

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 

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

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 

Koen, P., Ajamian, G. M., Boyce, S., Clamen, A., Fisher E., Fountoulakis S., Johnson, A., Puri P. & Seibert, R. (2002). Fuzzy Front End: Effective Methods, Tools, and Techniques. In: Belliveau, P.; Griffin, A.; Somermeyer, S. (Eds.). The PDMA Tookbook for New Product Development. New York: John Wiley & Sons, p. 5–35.

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  

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

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

Project Management Institute. (2016). Business analysis for practitioners: A practice guide. Newtown Square, PA: Project Management Institute.

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.

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

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

Rozenfeld, Henrique; Forcellini, Fernando Antônio;  Amaral, Daniel Capaldo; Toledo, José Carlos de; Silva, Sérgio Luis; Alliprandini, Dário Henrique; Scalice, Régis Kovacs  (2006). Gestão de desenvolvimento de produtos: uma referência para a melhoria do processo. Editora Saraiva, São Paulo.

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

U.S. Department of Defense. (2002). MIL-HDBK-61B: Configuration management guidance. Department of Defense. 

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.