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

Os links direcionam para os verbetes completos no glossário da flexM4i.

Vamos escolher algumas definições de requisito:

• “Objetivo mensurável ao qual uma solução deve atender, especificando uma capabilidade ou condição que deve ser satisfeita” (Baki et al., 2009, p. 110; Durugbo, 2013, p. 115).
• Um requisito é uma condição necessária para estar presente em um produto, serviço ou resultado (de um projeto) para satisfazer uma necessidade. Requisitos, explícitos ou implícitos, podem vir dos stakeholders, um contrato, políticas organizacionais, padrões ou órgãos reguladores, ou uma combinação entre essas fontes (PMI, 2021).

O que o cliente consegue expressar é uma necessidade do cliente ou um desejo do cliente. Mas também pode possuir dores e problemas, como discutiremos no tópico “Requisito é um artefato das fases iniciais da inovação”. A flexM4i tem mais dois verbetes que detalham as definições de:

• Requisitos dos clientes: são as necessidades dos clientes organizadas, categorizadas e estruturadas.
• 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. Um requisitos de produto pode conter um valor-meta, desdobrado a partir dos requisitos dos clientes (Rozenfeld et al., 2006).

Sinônimos

Especificação do produto é outro termo que expressa de uma maneira mais precisa o que o produto tem de fazer. Requisito do produto, especificação técnica ou característica de engenharia são sinônimos de especificação do produto (Ulrich et al., 2020).

No Scrum, os requisitos são representados por itens do backlog do produto (Product Backlog Items – PBIs), que podem incluir histórias de usuário, funcionalidades (features) e melhorias.

Outros termos relacionados com requisitos já citados são: 

• Desejos do cliente: são carências por satisfações específicas que variam de acordo com a cultura, preferências pessoais e outros fatores. Os desejos têm um forte componente emocional.
• Dores: descrevem qualquer coisa que incomoda seus clientes antes, durante e depois de tentar realizar uma tarefa (job), ou simplesmente impede que eles concluam uma tarefa, além dos riscos associados.. 
• Necessidade do cliente: é uma declaração abstrata dependente do contexto que descreve os benefícios, nas próprias palavras do cliente, que o cliente procura obter de um produto ou serviço.

Requisitos dos clientes versus requisitos do produto

Clientes que já conhecem o conceito do produto, principalmente no caso da relação B2B, são capazes de expressar os requisitos logo no início da inovação sob encomenda. Em alguns casos eles fornecem a especificação do produto ou serviço desejado.

Por exemplo, um cliente pode desejar comprar uma cadeira confortável (requisito do cliente). Um requisito do produto seria “possuir um assento de espuma com densidade D33”, entre outros. Haveria outras características do produto para atender ao requisito do cliente, tais como dimensões, proporção entre as dimensões, acessórios, textura do recobrimento etc.

Quando essas características forem associadas a valores-meta (ou seja, um valor que desejamos atingir – meta), teremos os requisitos de produto correspondentes.

Segundo a norma ISO/IEC/IEEE 24765 (ISO/IEC/IEEE, 2010), um requisito é:

1. uma condição ou capacidade de que alguém necessita para resolver um problema ou alcançar um objetivo (requisito do cliente);
2. uma condição ou capacidade que deve ser atendida ou possuída por um sistema, produto, serviço, resultado ou componente para satisfazer um acordo, norma, especificação ou outro documento formalmente imposto;
3. uma representação documentada de qualquer condição ou capacidade descrita em (1) ou (2).
4. uma condição ou capacidade que deve ser atendida ou possuída por um sistema, produto, serviço, resultado ou componente para cumprir um contrato, norma, especificação ou outro documento formalmente imposto. Os requisitos incluem as necessidades, desejos e expectativas quantificadas e documentadas do patrocinador, cliente e demais partes interessadas.

Quais são os requisitos que tratamos na gestão de requisitos?

A gestão de requisitos considera tanto os requisitos dos clientes como os do produto.

A partir dos desejos, dores, necessidade e muito mais (como ganhos, problemas, oportunidades etc.), podemos derivar requisitos, como ilustra o próximo tópico.

A figura abaixo apresenta uma ilustração dos artefatos das fases iniciais da inovação, para você conseguir localizar onde estão os requisitos.

Figura 1318: artefatos iniciais da inovação 

Pela figura, podemos perceber que os requisitos são explicitados em associação com o conceito de um produto.

Logicamente, quando iniciamos o desenvolvendo um software para apoiar uma função, como controle de estoque, gestão de vendas, controle de pessoal, controle de suprimentos etc., já podemos começar a levantar os requisitos. Isso porque, em desenvolvimento de software, a descrição macro da função já mostra qual o conceito do produto.

Essa função é denominada em algumas metodologias de desenvolvimento de software de objetivo / meta do produto. A partir dessas informações são definidos requisitos, que podem ser representados de diversas maneiras, como por exemplo, user stories, que direcionam o desenvolvimento.

A tecnologia no desenvolvimento de software já está definida.

Isso é diferente em inovações disruptivas, onde a tecnologia às vezes não está definida a priori e nem os princípios de solução. Nesses casos, começamos a levantar informações anteriores e documentar, como no caso da aplicação de metodologias de design thinking. Precisamos entender os stakeholders, obter empatia etc. Essas fases iniciais, que podem vir de diversas fontes para a inovação, como ilustra a figura anterior, muitas vezes são denominadas de avaliação das necessidades (needs assessment) pela comunidade que trata da gestão de requisitos mais formal.

O objetivo dessa discussão foi mostrar que diferentes segmentos adotam termos diferenciados para representar artefatos conceituais semelhantes.

Vamos discutir a seguir a comparação entre necessidades e requisitos

Geralmente, as necessidades são levantadas antes dos requisitos, ou seja, os requisitos podem ser derivados de necessidades. Essa é a diferenciação usual na prática.

No entanto, a última parte da definição da norma ISO/IEC/IEEE 24765 cria uma confusão quando afirma que “Os requisitos incluem as necessidades, desejos e expectativas quantificadas e documentadas do patrocinador, cliente e demais partes interessadas”. Isso reforça que, do ponto de vista normativo, “necessidades” também podem ser tratadas dentro do escopo de “requisitos”. Mas a norma acrescenta “quantificadas e documentadas”, o que não necessariamente ocorre no caso de necessidades.

No mundo prático do gerenciamento de projetos e análise de negócios, diferenciar necessidades (mais amplas e estratégicas) de requisitos (especificações detalhadas) ajuda na comunicação com stakeholders e na definição do escopo do projeto.

Assim, a norma e a prática não se contradizem, mas sim abordam a questão em granularidades diferentes.

Por exemplo, uma necessidade de se aumentar a satisfação do cliente, pode se transformar em um “requisito quantificado”, como reduzir em 20% o tempo de atendimento (entre outros requisitos possíveis).

Uma necessidade pode ou não estar relacionada com um produto ou serviço. Às vezes, a necessidade é abstrata e não está relacionada com um produto ou serviço.

Por exemplo, uma necessidade:

• relacionada com um produto – um cliente pode ter a necessidade de sentar em uma cadeira confortável para trabalhar. O produto cadeira já está explícito na necessidade.
• não relacionada diretamente com um produto:  um cliente pode ter a necessidade de estar mais bem informado segundo suas preferências.

(1) No primeiro caso, o conforto poderia ser obtido por meio de algumas características técnicas e mensuráveis do produto (requisitos), tais como, densidade de espuma do assento, tecido do assento, dimensões ergonômicas da cadeira, apoio de braço, tipos de regulagem (altura, inclinação do encosto e do assento) etc.

(2) No segundo caso, precisamos inicialmente desenvolver alguns conceitos de produtos ou serviços para depois especificar os requisitos.

(2.1) se o serviço for uma newsletter, ela precisaria ser configurada e adaptada às características de leitura do cliente.
(2.2) se o produto for um smartphone, precisaria existir um App que possa ser configurado para trazer informações personalizadas.
(2.3) se o serviço for uma conversa em um coffee shop que o usuário frequenta diariamente, algumas pessoas poderiam estar no horário usual expondo as principais informações.
(2.4) se o produto / serviço for um agente de IA, ele precisaria ser configurado para filtrar as informações de interesse do usuário para poder apresentá-las enquanto o cliente se desloca para o trabalho ou na academia na forma de um podcast.

Precisamos ainda elicitar (explicitar) os requisitos mais específicos para as soluções deste segundo caso.

Ou seja, neste segundo caso, precisa haver o desenvolvimento do conceito do produto ou serviço antes de se levantar os requisitos.

A diferenciação entre necessidades e requisitos será importante quando apresentarmos adiante que a avaliação de necessidades (needs assessment), que deve ocorrer antes da primeira atividade da gestão de requisitos, a elicitação.

Imagine um usuário ou cliente que já conhece o conceito do produto. Ele pode ser capaz de especificar requisitos (do cliente) logo no início do desenvolvimento. 

Por exemplo, um cliente sabe o que é um automóvel e pode especificar que gostaria de um carro econômico (requisito do cliente), mas ele pode especificar que gostaria de um automóvel que fizesse 25 km/l (requisito do produto).  Logicamente, um carro econômico pode ser desdobrado em outros requisitos do produto, que resultariam em um custo de propriedade baixo.

Porém, a inovação pode se iniciar com o levantamento de dores, problemas, oportunidades e outras entradas para inovação. Nesses casos, após a determinação das entradas para inovação pode ser determinado um conceito do produto, e a partir dele os requisitos são levantados.

Por exemplo, a insatisfação dos alunos de uma escola superior pode exigir a criação de diversas soluções para resolver esse problema, tais como, professores mais qualificados e motivados, sistemas de apoio, mudança do método de ensino, mudança do ambiente de trabalho, criação de materiais didáticos mais apropriados etc. Cada uma dessas soluções podem ser conceituadas e depois disso podemos levantar os requisitos para orientar o desenvolvimento.

Esses exemplos ilustram que há situações em que certos clientes ou áreas de negócio têm clareza suficiente para apresentar requisitos de forma relativamente estruturada já nas etapas iniciais de um projeto. Isso costuma ocorrer em contextos de soluções bem conhecidas ou quando a organização já acumulou expertise prévia.

Contudo, mesmo nesses casos, é pode ser importante revalidar se esses requisitos refletem efetivamente as necessidades subjacentes do negócio e dos usuários finais. Ou seja, embora alguns clientes venham com demandas detalhadas, ainda assim é indispensável verificar se as premissas por trás desses requisitos estão alinhadas com o problema, a oportunidade ou a dor real a ser solucionada. 

Além disso, precisamos considerar outros stakeholders além dos clientes, como agências reguladoras e as necessidades da própria empresas (como sócios ou acionistas que desejam uma taxa de retorno sobre um investimento).

O profissional responsável pelo levantamento de requisitos precisa avaliar se os requisitos coletados não são, por exemplo, apenas “desejos do cliente” sem aderência estratégica ou sem suporte a resultados-chave de desempenho.

Apresentamos aqui o  método QFD (quality function deployment) para desdobrar requisitos de clientes em requisitos de produtos, para mostrar que ter uma visão do conceito do produto é importante para se definir requisitos.

Quando se desdobra requisitos de cliente, após o tratamento das necessidades, precisamos imaginar cenas de uso do produto para conseguir especificar requisitos.

Por exemplo, no desenvolvimento de uma nova impressora multifuncional, temos de imaginar cenas dos diversos stakeholders envolvidos com a impressora para poder especificar características mensuráveis da impressora. O usuário tirando cópias, imprimindo à distância, conectando com diversos dispositivos (notebook, celular); o comprador (tanto o tomador de decisão com o responsável pela aquisição)  comparando a impressora da nossa empresa com as dos concorrentes para poder oferecer um diferencial competitivo; os provedores de “Impressão com serviço” com a necessidade de conexão e controle à distância; os responsáveis pela manutenção etc.

No exemplo acima, conseguimos imaginar cenas porque todos sabemos qual o conceito de uma impressora multifuncional.

Mas se o produto ainda é inexistente, seu conceito inicial precisa ser conhecido, senão não há como imaginar as cenas de uso. Temos de saber se estamos considerando um automóvel, um eletrodoméstico, uma impressora, um equipamento industrial ou eletrônico etc.

Pode haver soluções inovadoras para os produtos que listamos, mas o conceito da função do produto deve ser conhecido para se poder aplicar o QFD.

Uma síntese das diferentes definições no glossário da flexM4i mostra que:

• A engenharia de requisitos abrange
  • Iniciação
  • Definição de interfaces
  • Definição de stakeholders e papéis 
  • Elicitação
  • Descoberta
  • Elaboração
  • Análise
  • Revisão
  • Documentação 
  • Especificação
  • Negociação
  • Conciliar (chegar a um acordo / consenso)
  • Verificação e Validação
  • Manutenção
  • Gerenciamento  
• A gestão de requisitos abrange:
  • Interface com outras disciplinas da engenharia de sistemas
  • Documentação
  • Especificação e modelagem 
  • Análise
  • Priorização
  • Concordância 
  • Rastreabilidade
  • Controlar (identificar inconsistências)
  • Manter atualizados e disponíveis
  • Análise de impacto
  • Controle de mudanças
  • Controle de acesso
  • Comunicação com stakeholders

Na próxima figura, realizamos uma diferenciação entre as atividades principais de engenharia e de gestão de requisitos para separar as superposições entre as atividades dentro e fora das duas sínteses mostradas acima, pois são baseadas em diferentes definições.

Alguns autores, definem que a engenharia inclui a gestão de requisitos. Outros dizem o contrário. Existem também alguns autores que utilizam o termo integrado engenharia & gestão de requisitos.

Segundo Hood et al. (2008), a gestão de requisitos abrange todas as atividades necessárias para aumentar ou manter o valor dos requisitos em um nível elevado após sua elicitação e documentação inicial, ou seja, após a engenharia de requisitos.

A próxima figura também ilustra as diferentes estruturações entre essas práticas. Na flexM4i adotamos na flexM4i que a gestão de requisitos incorpora a engenharia de requisitos.

Figura 1319: comparação entre a engenharia e a gestão de requisitos, considerando-as complementares, e diferentes formas de estruturação dessas práticas

Ambas as práticas estão interligadas, pois a engenharia de requisitos fornece a estrutura para elicitação e documentação eficazes, enquanto a gestão define os processos e ferramentas para manter os requisitos organizados, consistentes e adaptáveis.

Além disso, em cenários de alta complexidade e mudanças constantes, a combinação dessas abordagens ajuda a reduzir riscos, aumentar a eficiência e garantir que o produto final atenda às expectativas dos stakeholders e às demandas do mercado.

Na flexM4i, consideramos que a gestão abrange a engenharia de requisitos, mas você deve adotar a terminologia e prática da sua empresa.

Observe que na figura 1319 anterior ilustramos por trás das atividades o termo “modelos”. Isso significa que podemos utilizar modelos para representar os requisitos em todas as atividades, apesar que formalmente, o primeiro modelo é utilizado para a especificação / documentação. 

O ciclo de vida dos requisitos refere-se às diferentes fases ou estados que um requisito atravessa durante o projeto (IIBA, 2015). Um requisito pode estar em múltiplos estados simultaneamente (por exemplo, “em análise” e “em revisão”). Atribuir condições ou qualificadores a cada requisito ajuda a identificar seu status em momentos específicos (PMI, 2015).

Como mostramos no tópico anterior “Requisito é um artefato das fases iniciais da inovação”, os requisitos surgem de necessidades de negócios ou demandas das partes interessadas. A partir disso, inicia-se o processo de gerenciamento que se estende até a aprovação final, vinculada ao produto ou serviço entregue (IIBA, 2015).

As tarefas fundamentais da gestão do ciclo de vida dos requisitos são:

• Rastreabilidade: Garantir que cada requisito esteja conectado a um objetivo ou entrega específica do projeto.
• Preservação: Manter os requisitos documentados, acessíveis ao longo do projeto, para eventuais projetos semelhantes e situações em que os requisitos podem ser reutilizados.
• Priorização: Classificar os requisitos de acordo com sua importância ou impacto no projeto.
• Avaliação de Mudanças: Revisar e avaliar como mudanças nos requisitos podem afetar o projeto.
• Aprovação: Obter validação formal dos requisitos por todas as partes interessadas.

Representação do Estado dos Requisitos: Durante o projeto, os requisitos são monitorados usando indicadores claros para refletir seu status atual (por exemplo, “em andamento”, “aprovado” ou “concluído”) (PMI, 2015). Esses indicadores ajudam a equipe a tomar decisões sobre ajustes ou revisões necessárias.

Alinhamento e Coerência: Garante que os requisitos, o projeto e as expectativas das partes interessadas permaneçam alinhados (IIBA, 2015). Isso assegura que o projeto seja conduzido de forma organizada e que suas entregas atendam às necessidades identificadas.

Gestão Contínua e Valor Pós-Implementação

A gestão de requisitos não termina com sua implementação.

Mesmo após serem entregues, os requisitos precisam ser monitorados e gerenciados para garantir que continuem gerando valor para o negócio (Dehghani, 2019).

Sempre que você estiver desenvolvendo um produto, sistema ou serviço que envolva múltiplas partes interessadas, complexidade técnica ou grande volume de requisitos. Isso inclui exemplos como:

• Projetos com múltiplos stakeholders e alta complexidade: A prática ajuda a alinhar diferentes interesses, evitando conflitos e garantindo que as necessidades de cada stakeholder sejam consideradas.
• Projetos de desenvolvimento de software: A gestão de requisitos assegura que as funcionalidades atendam aos objetivos dos usuários e que mudanças sejam controladas durante todo o ciclo de desenvolvimento.
• Projetos de infraestrutura e engenharia: Em setores como construção, energia, telecomunicações ou manufatura de grandes equipamentos, o controle de especificações técnicas e normas regulatórias é fundamental.
• Setores altamente regulados (ex.: aeroespacial, farmacêutico, automotivo): Quando a conformidade é prioritária, a gestão de requisitos permite rastrear aderência a normas e padrões de segurança e qualidade.
• Lançamento de novos produtos e serviços: Garantir que as necessidades de mercado e dos clientes estejam alinhadas às capacidades técnicas é essencial para o sucesso do produto.

• Garantir alinhamento com as necessidades de negócio ao longo de todo o ciclo de vida: Ajuda a priorizar e revisar requisitos em cada fase, mantendo o foco contínuo nos objetivos do projeto ou produto.
• Reduzir retrabalho, custos e riscos: Ao identificar e documentar requisitos desde o início e rastrear mudanças adequadamente ao longo do tempo, podemos diminuir a probabilidade de refazer partes significativas do projeto e identificar precocemente riscos.
• Facilitar o rastreamento e o gerenciamento de mudanças: Permite controlar quaisquer alterações nos requisitos em todas as etapas, sem prejudicar o cronograma e o orçamento. Além disso, durante o ciclo de vida do produto, as mudanças podem ter impactos (como recall) que devem estar alinhadas com a gestão de requisitos.
• Assegurar a satisfação do cliente e a conformidade regulatória: Garante que o resultado final seja funcional, atenda às expectativas e cumpra eventuais normas aplicáveis durante todo o ciclo de vida do produto ou sistema.
• Melhorar a comunicação entre equipes: Documentar e compartilhar requisitos de forma clara evita ambiguidade e promove colaboração em diferentes estágios do desenvolvimento e pós-implementação. Assim, podemos manter as equipes alinhadas com as informações atualizadas.

Este tópico é baseado em Hood et al. (2008).  Os textos nas caixas são comentários do autor desta seção.

• Falta de transparência e medo de exposição: A gestão de requisitos exige transparência nas atividades do projeto ou da engenharia de sistemas. Pessoas inseguras podem temer que seus erros sejam expostos, preferindo manter problemas ocultos a enfrentá-los proativamente.
• Ambiguidade de papéis e responsabilidades: Muitas organizações não têm papéis bem definidos, gerando incertezas sobre o que cada membro da equipe faz. A gestão de requisitos exige colaboração e compartilhamento de informações, o que pode incomodar aqueles que preferem trabalhar isoladamente.
• Resistência ao compartilhamento de informações: Em algumas culturas, compartilhar informações equivale a perder poder e influência. Até mesmo em níveis hierárquicos baixos, pode haver resistência, muitas vezes motivada pela insegurança em expor a qualidade do próprio trabalho.
• Medo das mudanças: A introdução da gestão de requisitos envolve mudanças nos processos e formas de trabalho. Algumas pessoas temem perder o status de “heróis da empresa”, que dominam as formas antigas de contornar problemas e se destacam pela adaptação ao caos.
• Impacto na relevância profissional: Novos processos podem tornar certas funções obsoletas, como ocorreu com a introdução de computadores pessoais que reduziram a necessidade de datilógrafos.
• Insegurança tecnológica: A adoção de novas ferramentas e softwares pode gerar desconforto, especialmente se o novo sistema for mais complexo ou exigir mais tempo de uso.
• Cultura organizacional punitiva: Se a organização vê os erros como fracassos pessoais, os colaboradores podem preferir evitar mudanças para não serem responsabilizados.
• Maturidade organizacional insuficiente: Implementar mudanças requer uma maturidade organizacional que permita suporte e comprometimento em todos os níveis hierárquicos.

Hood et al. (2008) propõem as seguintes práticas para mitigar as resistências à gestão de requisitos listadas:

• Identificar necessidades: Mapeie as preocupações e expectativas dos envolvidos, garantindo que as mudanças respondam às reais demandas organizacionais.
• Colocar as pessoas no centro: Envolva os colaboradores na elaboração de novos processos e ferramentas, legitimando sua participação e incentivando a adesão.
• Envolver os stakeholders desde o início : Promova diálogos abertos sobre objetivos e benefícios, reduzindo a percepção de imposição e ampliando o comprometimento.
• Oferecer treinamento e coaching: Garanta suporte contínuo, capacitando a equipe para lidar com métodos e ferramentas e desenvolvendo confiança na adoção das práticas.
• Adotar abordagem gradual: Implemente novas práticas de forma progressiva, testando em projetos-piloto e aprendendo com cada etapa para aumentar a aceitação.
• Definir pessoas-chave: Identifique profissionais capazes de liderar o processo, servindo como influenciadores e exemplos de sucesso para os demais.
• Criar um centro de competências: Centralize conhecimentos, processos e boas práticas, oferecendo suporte permanente para equipes iniciantes em gestão de requisitos.

• Instituir um comitê de direção: Inclua gestores sêniores para monitorar resistências, lidar com barreiras culturais e reforçar o comprometimento de toda a liderança.

Segundo Fernandes & Machado (2016), a engenharia de requisitos, que consideramos integrada à gestão de requisitos, possui as seguintes características: 

• Processo colaborativo e cooperativo entre os responsáveis pela obtenção dos requisitos e os stakeholders
• Natureza iterativa e incremental, permitindo revisões e refinamentos contínuos
• Não segue uma sequência rígida, possibilitando transições entre atividades de forma flexível
• Adapta-se a mudanças e feedbacks contínuos para melhorar a definição dos requisitos
• Aplicável em diversos contextos de desenvolvimento e abordagens..

Para garantir que os requisitos capturam de forma adequada essas demandas, devemos aplicar um processo estruturado de gestão de stakeholders, com as seguintes atividades:

• Identificação dos stakeholders: Assegura que todas as partes interessadas impactadas pela solução sejam consideradas, garantindo que nenhuma demanda relevante seja negligenciada.
• Entendimento e análise das necessidades e influências: Estabelece uma base sólida para a elicitação e validação dos requisitos, permitindo compreender as expectativas, preocupações e impactos que cada stakeholder pode ter sobre a solução.
• Priorização dos stakeholders: Equilibra diferentes interesses, garantindo que as demandas mais críticas sejam alinhadas com os objetivos estratégicos do projeto e que os stakeholders com maior influência sejam adequadamente gerenciados.
• Engajamento contínuo dos stakeholders: Assegura que os requisitos sejam compreendidos, validados e aceitos ao longo do ciclo de vida do projeto, evitando retrabalho e desalinhamentos tardios. Esse engajamento envolve comunicação estruturada e colaboração ativa entre todas as partes envolvidas.
• Engajamento dos stakeholders internos: Além dos stakeholders para os quais a inovação está sendo desenvolvida, os envolvidos no projeto de desenvolvimento da inovação também precisam estar engajados. Isso inclui desde o C-level até os responsáveis pela manutenção, assistência técnica e atendimento ao cliente, garantindo que suas contribuições sejam incorporadas ao longo do processo.
• Monitoramento dos stakeholders: Permite ajustar estratégias de envolvimento conforme as necessidades evoluem, garantindo alinhamento e comprometimento durante todo o ciclo de vida da inovação.

A gestão de stakeholders não apenas viabiliza a definição precisa dos requisitos, mas também contribui para seu sucesso ao manter os stakeholders envolvidos e comprometidos durante todo o ciclo de vida da inovação.

A elicitação de requisitos corresponde à primeira atividade formal da gestão de requisitos. Ela aprofunda as informações levantadas na avaliação de necessidades ao traduzi-las em requisitos concretos (ainda que muitas vezes sejam inicialmente imprecisos ou incompletos). Aqui, o analista de negócios vai além de uma mera coleta, pois envolve a facilitação de discussões, a investigação de problemas e oportunidades, e a articulação dos desejos e necessidades dos stakeholders em requisitos estruturados.

Na avaliação de necessidades (needs assessment), costuma-se operar em um patamar estratégico, identificando e priorizando problemas, dores, oportunidades e, em última instância, as necessidades que justificam o lançamento de um projeto ou iniciativa. É um momento em que ainda não há clareza sobre a solução, nem requisitos definidos.

Na gestão de requisitos, o foco é refinar e controlar o escopo, traduzindo necessidades, desejos e expectativas em requisitos específicos, rastreáveis e testáveis. Embora existam sobreposições entre descobrir necessidades e documentá-las como requisitos, a essência da gestão de requisitos está em garantir que essas definições sejam formalmente registradas e alinhadas com os stakeholders, bem como geridas ao longo do ciclo de desenvolvimento.

As atividades da avaliação de necessidades (needs assessment) que geralmente ocorrem antes da gestão de requisitos são (PMI, 2017 p.55):

• Identificar problema ou oportunidade, que na flexM4i sintetizamos juntamente com outras entradas em: oportunidade, desafio ou ideia.

• Avaliar a situação (estado) atual, que a solução vai mudar.
• Determinar a situação futura para estabelecer uma visão de onde queremos chegar.
• Identificar opções viáveis e recomendações, que delineiam uma visão mais concreta da solução, ou seja, o estabelecimento do conceito do produto ou serviço a ser desenvolvido.
• Desenvolver o roadmap do produto para mostrar a evolução do produto no tempo alinhada com os objetivos organizacionais.
• Elaborar o Business Case para apoiar a tomada de decisão entre opções viáveis

Já vimos que “alguns clientes já conseguem especificar requisitos logo no início de um desenvolvimento”.

Mesmo que ainda, em alguns casos, o cliente “adiante” requisitos, a  avaliação de necessidades pode ser realizada de uma forma reduzida ou ser parcialmente incorporada à gestão de requisitos. 

Para manter a robustez no delineamento das soluções, a etapa de entender as motivações e o contexto estratégico (avaliação de necessidades) não deve ser ignorada.

Depende do grau de novidade?

Uma distinção entre Avaliação de Necessidades e Gestão de Requisitos não se limita ao grau de novidade (radical ou incremental). De fato, tende a existir um contínuo entre inovação incremental e radical, mas os dois conceitos (necessidades versus requisitos) costumam coexistir em maior ou menor intensidade, independentemente do tipo de inovação.

• Em inovações mais radicais, a incerteza sobre o que realmente se pretende alcançar costuma ser maior, o que reforça a importância de uma fase robusta de Avaliação de Necessidades. Nesses cenários, inclusive, podem surgir necessidades latentes, não explicitadas inicialmente pelos stakeholders.
• Em inovações incrementais, pode haver mais clareza sobre o que o mercado ou a organização necessita, mas ainda assim vale a pena estruturar e validar essas necessidades de forma metódica para assegurar que o esforço incremental esteja alinhado com objetivos estratégicos. 

Devemos sempre procurar obter uma compreensão aprofundada das necessidades antes de consolidar requisitos.

Porém, para produtos mais simples, quando partimos de um conceito estabelecido e temos segurança sobre as necessidades, podemos partir diretamente para a elicitação de requisitos, sem realizar a avaliação de necessidades.

Para alcançar resultados consistentes, é fundamental adotar as práticas e estar atento aos desafios e detalhes da gestão de requisitos.

PREMISSAS

• Compromisso organizacional: O sucesso da gestão de requisitos depende do alinhamento com os objetivos organizacionais e do envolvimento ativo das partes interessadas. A falta de apoio da alta gestão e dos patrocinadores pode comprometer a efetividade do processo de requisitos e aumentar o risco de falha no projeto.
• Valor do planejamento da gestão de requisitos: A gestão de requisitos deve ser reconhecida como um domínio estratégico, trazendo retorno positivo para a organização, stakeholders, gestores de projetos e equipe. Um planejamento estruturado da gestão de requisitos reduz riscos e melhora a eficiência do desenvolvimento de soluções.
• Entenda o que são os requisitos: Eles são a base do que será desenvolvido. Um requisito é mais do que uma simples ideia e desejo; ele deve ser mensurável, rastreável e verificável. Confira a definição do que é um requisito.
• Estabeleça um ciclo de vida claro: Desde a captura (elicitação) até a validação, cada requisito deve passar por etapas bem definidas. Veja a discussão sobre o ciclo de vida dos requisitos.
• Conhecimento do domínio: A elicitação de requisitos deve ser conduzida por profissionais que tenham conhecimento do domínio ou acesso a especialistas no assunto. Compreender os termos, processos e procedimentos específicos do contexto do projeto é essencial para formular as perguntas certas e definir requisitos de forma precisa e realista.  
• Definição de processos de controle: Implemente um processo de gerenciamento que define critérios para acesso, qualidade e manutenção dos requisitos. Conheça as atividades e práticas detalhadas da gestão de requisitos.
• Equipe qualificada: A análise de requisitos deve ser conduzida por profissionais com as competências adequadas desde o início do processo, pois há pouca oportunidade de desenvolver habilidades críticas durante a execução. Ter especialistas capacitados melhora a qualidade da análise e reduz falhas na definição dos requisitos.
• Colaboração ativa na análise de requisitos: O sucesso da análise de requisitos depende da interação contínua e colaborativa entre os stakeholders e os analistas responsáveis. Um ambiente que favorece o diálogo aberto facilita a identificação de expectativas implícitas e permite que os requisitos sejam refinados de forma mais precisa e alinhada com as necessidades reais do projeto.

DICAS

• Engaje e analise os stakeholders ao longo do ciclo de vida: Envolva as partes interessadas desde o início e ao longo do processo de requisitos. Realize uma análise de stakeholders para entender seus impactos e influências, revisitando essa análise conforme surgirem novos stakeholders ou mudanças no projeto. A falta desse acompanhamento pode levar a requisitos incompletos, incorretos ou ignorados. Busque ativamente a participação de um conjunto diverso de stakeholders para capturar diferentes perspectivas e reduzir o risco de requisitos faltantes. Realize reuniões para coletar as necessidades, alinhar expectativas e valide os requisitos frequentemente para evitar surpresas.
• Planeje e prepare a elicitação de requisitos: A elicitação de requisitos exige planejamento prévio para definir quais stakeholders envolver, em que ordem e quais métodos utilizar. O nível de esforço necessário deve ser avaliado com base na complexidade e no tipo de projeto, pois diferentes contextos demandam abordagens distintas. O planejamento adequado evita retrabalho e garante que os requisitos capturados sejam mais completos e precisos.
• Documente tudo: Não confie apenas na memória ou em discussões informais. Registre os requisitos, mudanças e decisões.
• Representação coerente: Certifique-se de que os requisitos estejam claramente documentados e organizados. Utilize formatos padronizados para evitar ambiguidades
• Simplifique e priorize: Use métodos como MoSCoW para classificar requisitos (Must, Should, Could, Won’t). Evite sobrecarregar o projeto com requisitos desnecessários. Veja as práticas (métodos e ferramentas) listados para cada atividade da gestão de requisitos na seção“Atividades e práticas da gestão de requisitos”. 
• Compreensibilidade e fácil acesso: Estruture os requisitos de maneira que sejam fáceis de entender para todas as partes interessadas. Garanta que estejam armazenados em um local centralizado e acessível aos membros da equipe. 
• Rastreie constantemente e monitore requisitos-chave: Relacione cada requisito a um entregável ou teste para garantir sua rastreabilidade ao longo do projeto. Além disso, identifique requisitos críticos e monitore-os continuamente, pois sua não conformidade pode comprometer os objetivos do projeto. A rastreabilidade evita a perda de informações, facilita a gestão de mudanças e assegura que os requisitos mais impactantes sejam controlados com maior rigor.
• Aprovação e revisão contínua: Submeta os requisitos a revisões periódicas para assegurar sua importância e precisão. Estabeleça um processo claro para aprovações dos requisitos preservados, mantendo registros das decisões tomadas.
• Use ferramentas apropriadas: A gestão de requisitos pode ser manual, semi automatizada ou automatizada. Escolha ferramentas que atendam às necessidades do projeto. Conheça uma lista de ferramentas de gestão de requisitos no tópico “Análise – práticas de documentação e especificação (modelos)” da seção “Atividades e práticas da gestão de requisitos”.
• Reutilização dos requisitos: Procure manter os requisitos reutilizáveis, mesmo com mudanças no projeto, pois essa prática resulta nos seguintes benefícios:
  • Entrega mais rápida: Reduz o tempo total do projeto.
  • Redução de custos: Minimiza despesas de desenvolvimento.
  • Consistência: Mantém uniformidade dentro de uma aplicação e entre sistemas diferentes.
  • Benefícios para a equipe: Aumento de produtividade e trabalho mais eficiente, ocasionando menos erros e retrabalho, consequentemente deixando o processo mais preciso. 
  • Requisitos validados: Economizam tempo na revisão e aceleram aprovações e etapas subsequentes, como testes.
  • Estimativa de esforço: Reutilizar requisitos facilita as estimativas de esforço de implementação (Wiegers & Beatty, 2013).
• Integre a gestão de requisitos com outras abordagens essenciais: A gestão de requisitos não ocorre isoladamente e deve estar alinhada com práticas que influenciam ou são influenciadas pelos requisitos. Isso inclui a gestão de stakeholders e avaliação de necessidades, bem como a gestão do ciclo de vida dos requisitos. Além disso, a gestão de requisitos deve estar integrada a metodologias e frameworks que desenvolvem soluções, garantindo que as entregas atendam aos requisitos estabelecidos. Entre essas abordagens estão:
  • Gestão de projetos, programas e portfólio, garantindo que requisitos sejam controlados e rastreados ao longo do ciclo de vida do projeto.
  • Análise de negócio (business analysis), para alinhar requisitos às necessidades organizacionais e estratégicas.
  • Engenharia de Sistemas (SEBoK – INCOSE) e Engenharia de requisitos (ISO/IEC/IEEE 29148:2011), fornecendo abordagens formais para elicitação, especificação e validação de requisitos.
  • Modelos de maturidade como CMMI e SWEBOK, que estruturam boas práticas para processos de desenvolvimento.
  • Gestão ágil de projetos, que muitas vezes evita o termo “requisitos”, mas trabalha com backlog, histórias de usuário e outros artefatos que desempenham a mesma função.
  • Gestão da inovação, que demanda flexibilidade para lidar com requisitos incertos ou emergentes, especialmente em ambientes exploratórios.

CUIDADOS

• Cuidado com a ambiguidade: Evite requisitos vagos como “o sistema deve ser rápido”. Em vez disso, defina metas específicas, como “tempo de resposta inferior a 2 segundos”.
• Gerencie mudanças com critérios claros: Nem todas as mudanças são necessárias ou viáveis. Avalie o impacto em prazos, custos e qualidade antes de aceitar mudanças.
• Mantenha a comunicação eficiente e contínua: A qualidade dos requisitos depende de uma comunicação frequente e oportuna entre equipe do projeto, stakeholders e demais envolvidos. A falta de precisão pode gerar retrabalho e impactos negativos nas fases seguintes do desenvolvimento. Use ferramentas colaborativas para registrar decisões, compartilhar informações e garantir que dúvidas sejam resolvidas rapidamente.
• Evite ignorar requisitos não funcionais: Aspectos como segurança, desempenho e usabilidade são tão importantes quanto funcionalidades principais.
• Garanta a aceitação formal dos requisitos pelo cliente: A aceitação formal dos requisitos pelo cliente (interno ou externo) é essencial para a transição do projeto para sua fase de encerramento. Sem essa validação, há riscos de desalinhamentos e dificuldades na realização dos benefícios esperados. Estabeleça critérios claros para a aceitação e documente formalmente as aprovações para evitar ambiguidades e retrabalho.

Como apresentado nesta seção, a engenharia & gestão de requisitos deve estar integrada com:

• Gestão de stakeholder e
• Avaliação de necessidades.

A gestão de requisitos confunde-se com a Gestão do ciclo de vida dos requisitos.

Conforme está explicado na seção “Abordagens e metodologias que incorporam a gestão de requisitos”, a gestão de requisitos obviamente se relaciona com a práticas que desenvolvem soluções, que devem atender a requisitos, tais como:

• Gestão de projetos, programas e portfólio;
• Análise de negócio (business analysis);
• Engenharia de Sistemas (SEBoK – INCOSE);
• Processos de desenvolvimento de produtos;
• Engenharia de requisitos (norma ISO/IEC/IEEE 29148:2011);
• Modelo CMMI (Capability Maturity Model Integration);
• SWEBOK (Software Engineering Body of Knowledge);
• Gestão de mudanças de engenharia;
• Gestão de riscos;
• Gestão ágil de projetos – sem que o termo “requisitos” seja utilizado.

O que foi feito: Duas empresas, uma de software (Empresa Alfa) e outra de outsourcing (Empresa Beta), foram analisadas quanto ao uso da rastreabilidade de requisitos em seus projetos. A Empresa Alfa utiliza rastreabilidade para monitorar o progresso do projeto, enquanto a Empresa Beta focava na gestão de mudanças e na identificação de áreas impactadas por alterações nos requisitos.

Como fizeram: Na Empresa Alfa, a rastreabilidade era limitada e voltada para acompanhar o desenvolvimento geral do projeto, com baixo envolvimento dos colaboradores nas práticas de rastreabilidade. Já na Empresa Beta, foi implementado um modelo estruturado de rastreabilidade, utilizando templates e a ferramenta JIRA para automatizar e facilitar o rastreamento de requisitos.

Resultados práticos: A Empresa Beta conseguiu otimizar seu processo de rastreabilidade, permitindo identificar mais facilmente os impactos de mudanças e tomar decisões com base em dados confiáveis. Por outro lado, a Empresa Alfa, com práticas menos desenvolvidas, enfrentou desafios devido à falta de engajamento dos colaboradores, comprometendo a eficácia da rastreabilidade e seu potencial para agregar valor ao projeto.

O que aprenderam com isso: A rastreabilidade de requisitos é mais eficaz quando há um envolvimento ativo dos colaboradores e quando se utiliza ferramentas e processos bem estruturados, como o modelo da Empresa Beta. Além disso, empresas com diferentes motivações podem adaptar as práticas de rastreabilidade às suas necessidades específicas, seja para acompanhar o progresso do projeto ou para gerenciar mudanças com mais eficiência.

O que foi feito: Uma grande varejista resolveu juntar dois catálogos online: um para consumidores e outro para empresas. A ideia era economizar na manutenção e facilitar a criação de novos recursos que pudessem servir para os dois públicos.

Como fizeram: Primeiro, trabalharam nos requisitos do catálogo de consumidores, aproveitando o que já existia. Depois, usaram esses mesmos requisitos como base para o catálogo corporativo, ajustando só o que era diferente e adicionando funções específicas para as empresas.

Resultados práticos: Economizaram tempo no desenvolvimento e entregaram o projeto dentro do prazo. Com isso, garantiram que as funcionalidades do produto, atendessem tanto consumidores quanto empresas.

O que aprenderam com isso: Reutilizar requisitos é uma forma inteligente de trabalhar, quando os projetos possuem partes semelhantes. Fazer ajustes pontuais e incluir novos requisitos, permite ajustar para os públicos diferentes, sem perder tempo começando tudo do zero. Essa abordagem, ajudou a gerenciar melhor o tempo e os recursos do projeto, além de alcançar os objetivos do negócio com eficiência Wiegers, K. E., & Beatty, J., (2013).

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.

Aleixo, S. R. (2021). Barreiras e benefícios da rastreabilidade dos requisitos no desenvolvimento de projetos (Dissertação (Mestrado). Universidade de São Paulo, São Carlos. Recuperado de https://www.teses.usp.br/teses/disponiveis/18/18156/tde-07022022-165701/

Baki, B. et al. (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, v. 21, n. 1, p. 106–126, 2009

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. 

Fernandes, J. M., & Machado, R. J. (2016). Requirements in engineering projects. Cham: Springer International Publishing.

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 

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  

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.