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

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

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

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.

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.

Esta atividade visa formar um entendimento claro da situação que a organização deseja abordar, garantindo que a solução escolhida seja adequada para resolver o problema ou explorar a oportunidade identificada. Para isso, é necessário evitar a definição precoce de uma solução e focar na análise do contexto organizacional. O resultado é uma declaração de situação, validada por stakeholders, que servirá de base para as próximas etapas.

Práticas recomendadas:

• Análise comparativa
• Análise da concorrência
• Análise de documentos
• Entrevistas
• Observação
• Análise de mercado
• Experimentação, prototipagem e testes (normalmente, em associação com alguma abordagem ou metodologia, entre as citadas no próximo quadro)

O objetivo dessa atividade é compreender o ambiente atual da organização, identificando fatores internos e externos que possam estar causando o problema ou influenciando a oportunidade. Isso permite determinar quais elementos da situação atual devem permanecer inalterados e quais devem ser modificados para alcançar a situação futura desejada.

Práticas recomendadas:

As mesmas práticas da atividade anterior podem ser utilizadas para a avaliar a situação atual. No caso do detalhamento do entendimento do “problema”, podemos ainda utilizar. 

• Análise mais detalhada de documentos
• Entrevistas mais focadas baseadas em questões fechadas com a possibilidade de realização de surveys (se houver uma amostra significativa)
• Observação focada na ocorrência do “problema”
• Diagramas de Pareto para focar no que for mais relevante
• Análise de causa raiz (são vários métodos e ferramentas) quando o “problema” identificado precisar ser analisado
• Fluxos de processo para obter um contexto no qual o “problema” ocorre.

Esta atividade consiste em definir as mudanças necessárias para transformar a organização da situação atual para a desejada, garantindo que os problemas sejam resolvidos ou as oportunidades exploradas. O processo envolve a identificação de novas capabiliidades organizacionais e a priorização de mudanças estratégicas.

Práticas recomendadas:

• Diagramas de afinidade para agrupar ideias e percepções em categorias que mostrem padrões e oportunidades de melhoria no estado futuro.
• Benchmarking para comparar práticas, produtos ou processos da organização com referências externas, identificando padrões e inspirações para a situação futura. 
• Tabela de capacidades (Capability Table)
• Brainstorming (Brainstorming)
• Oficinas facilitadas (Facilitated Workshops)
• Modelo de funcionalidades (Feature Model)
• Análise de lacunas (Gap Analysis)
• Modelo de Kano para priorização dos requisitos
• Modelo de alinhamento de propósito (Purpose Alignment Model)
• Matriz de capacidades da solução (Solution Capability Matrix)

Nesta atividade, são aplicadas técnicas analíticas para examinar possíveis soluções para o problema identificado. A atividade envolve a identificação de opções viáveis, a realização de análises de viabilidade e a recomendação da solução mais adequada com base em critérios estratégicos.

Práticas recomendadas:

• Análise comparativa (Benchmarking)
• Análise de custo-benefício (Cost-Benefit Analysis)
• Técnicas de elicitação (Elicitation Techniques)
• Injeção de funcionalidades (Feature Injection)
• Técnicas de decisão em grupo (Group Decision-Making Techniques)
• Técnicas de avaliação de valor (Valuation Techniques)
• Classificação ponderada (Weighted Ranking)

O roadmap de produto fornece uma visão estratégica da evolução do produto ao longo do tempo, ajudando a alinhar o desenvolvimento do produto com os objetivos organizacionais e permitindo um planejamento estruturado de entregas futuras.

Práticas recomendadas:

• Oficinas facilitadas (Facilitated Workshops)
• Modelo de funcionalidades (Feature Model)
• Definição da visão do produto (Product Visioning)
• Mapeamento de histórias (Story Mapping)

Esta atividade reúne informações analisadas para apoiar a seleção das melhores iniciativas organizacionais, garantindo que a justificativa do projeto esteja bem fundamentada e seja economicamente viável. O Business Case estabelece os benefícios esperados, a viabilidade financeira e o alinhamento estratégico da solução proposta.

Práticas recomendadas:

• Análise de documentos (Document Analysis)
• Oficinas facilitadas (Facilitated Workshops)
• Glossário
• Definição da visão do produto (Product Visioning)
• Mapeamento de histórias (Story Mapping)

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.

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. 

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.