1. Introdução

No planejamento de um novo projeto, o alinhamento entre o problema que o projeto pretende resolver e o produto ou serviço que será entregue ao final está entre as atividades com os entregáveis mais importantes para todo o planejamento. Um levantamento de requisitos precário (incompleto, impreciso ou mal comunicado) tende a gerar uma especificação imperfeita do que precisa ser feito e do que precisa ser entregue, fazendo com que o entregável final não atenda às expectativas do cliente e, consecutivamente, que o projeto falhe ou que seja preciso retomar as etapas de planejamento e execução, gerando prejuízo. A Figura 1 ilustra esse fenômeno: a cada nova pessoa pela qual a informação original passa, parte dela se perde, se generaliza ou se distorce, até que o entregável final se afaste de forma relevante da necessidade que o originou.

Felizmente, já existem diversas ferramentas voltadas a melhorar o levantamento de requisitos, buscando garantir uma coleta de informações mais precisa e mais próxima do que o cliente realmente precisa. Entre essas ferramentas destacam-se três técnicas amplamente utilizadas: a entrevista, definida como uma "conversa direcionada com um propósito específico, que utiliza um formato pergunta resposta" (CARVALHO, 2009, p. 4), na qual o entrevistado é questionado sobre as suas necessidades, premissas e peculiaridades; o questionário, indicado "quando há diversos grupos de usuários que podem estar em diversos locais [...] elaboram-se pesquisas específicas de acompanhamento com usuários selecionados, cuja contribuição em potencial pareça mais importante, pois não seria prático entrevistar todas as pessoas em todos os locais" (MENDONÇA, [20--], p. 2); e o brainstorm, "uma técnica para geração de ideias [que] consiste em uma ou várias reuniões que permitem que as pessoas sugiram e explorem ideias" (MENDONÇA, [20--], p. 2).

A utilização dessas e de outras técnicas para levantar as necessidades de um projeto enriquece o trabalho como um todo, mas esse processo tem uma complexidade inerente à colaboração entre diferentes pessoas, e pode exigir várias rodadas até que se consiga levantar toda a informação necessária. Um dos motivos para isso é que, como pessoas, carregamos premissas e valores próprios, e tendemos, de forma inconsciente, a generalizar, a omitir e a distorcer informações ao transmiti-las adiante. Esse processo normalmente não é consciente, e é resultado das próprias experiências de vida de cada indivíduo, conforme discutido na seção 2.1.

Por esse motivo é útil recorrer a ferramentas que auxiliem a explorar e a descobrir informações e necessidades durante o levantamento de requisitos. Neste trabalho, propõe-se que essa exploração seja conduzida por meio de um mapa de descoberta: uma estrutura que parte de uma necessidade central e, a partir dela, se ramifica em novas possibilidades e temas correlacionados, até que toda a cadeia de informações relevantes esteja mapeada. Para que essa exploração produza resultados coesos e aplicáveis, este trabalho propõe enriquecer a técnica de mapas mentais (seção 2.3) com conceitos de gerenciamento de processos de negócio (seção 2.4), que ajudam a garantir a coerência e a completude de cada etapa mapeada, e com os três pilares do Scrum (seção 2.5), que ajudam a manter o processo adaptável a mudanças de contexto ao longo do tempo.

Este artigo está estruturado em seis seções, incluindo esta introdução. A seção 2 apresenta o referencial teórico que sustenta a proposta, cobrindo a distorção da informação, as técnicas tradicionais de levantamento de requisitos, os mapas mentais, o gerenciamento de processos e a agilidade. A seção 3 descreve os procedimentos metodológicos adotados na construção deste trabalho. A seção 4 apresenta o mapa de descoberta de requisitos propriamente dito, detalhando seus princípios de construção, a estrutura de cada etapa e dois exemplos aplicados. A seção 5 discute as contribuições e os limites da proposta. Por fim, a seção 6 traz as considerações finais e a agenda de pesquisas futuras.

2. Referencial Teórico

2.1 Distorção da informação e comunicação em equipes

A programação neurolinguística oferece um modelo útil para compreender por que a informação se altera à medida que passa de uma pessoa para outra durante um levantamento de requisitos. Segundo Bandler e Grinder (1977, p. 38), "generalização é o processo pelo qual os elementos ou partes do modelo de uma pessoa se afastam de sua experiência original e vêm a representar toda a categoria da qual a experiência é um exemplo. Nossa habilidade para generalizar é essencial para enfrentar o mundo". Esse mesmo processo, que em contextos cotidianos é adaptativo e necessário, pode fazer com que um requisito específico seja relatado de forma ampla demais, perdendo detalhes relevantes para o projeto.

Além da generalização, os autores descrevem a eliminação como o processo pelo qual "prestamos atenção seletivamente a certas dimensões de nossa experiência e excluímos outras" (BANDLER; GRINDER, 1977, p. 37), e a distorção como "o processo que nos permite fazer substituições em nossa experiência de dados sensoriais. A fantasia, por exemplo, permite-nos um preparo para experiências que possamos ter antes que elas ocorram" (BANDLER; GRINDER, 1977, p. 38). Os três processos, generalização, eliminação e distorção, ocorrem de forma simultânea e amplamente inconsciente sempre que uma pessoa comunica uma necessidade a outra, e se acumulam a cada nova etapa da cadeia de comunicação, conforme ilustrado na Figura 1.

Esse fenômeno se intensifica em equipes, nas quais o levantamento de requisitos frequentemente depende de múltiplas conversas, em diferentes momentos, com diferentes interlocutores. Silva (2019), ao estudar os conflitos em equipes presenciais de desenvolvimento de software, observa que boa parte dos desentendimentos técnicos entre membros de uma equipe tem origem em falhas de comunicação e em interpretações divergentes de uma mesma informação, o que reforça a necessidade de instrumentos que tornem o processo de descoberta de requisitos mais estruturado e menos dependente da memória e da interpretação individual de cada participante.

2.2 Técnicas tradicionais de levantamento de requisitos

Pinheiro (2015) situa o levantamento de requisitos entre as primeiras e mais determinantes atividades da engenharia de software, argumentando que boa parte dos problemas encontrados em fases posteriores do desenvolvimento, como retrabalho, atraso e insatisfação do cliente, tem origem em requisitos mal levantados ou mal especificados nas etapas iniciais do projeto.

Entre as técnicas mais utilizadas para essa atividade estão a entrevista, o questionário e o brainstorm, já apresentadas na seção 1. Pontes (2022) acrescenta que, independentemente da técnica escolhida, o levantamento de requisitos deve buscar três qualidades simultâneas: completude, isto é, cobrir todas as necessidades relevantes; precisão, isto é, registrar essas necessidades sem ambiguidade; e rastreabilidade, isto é, permitir relacionar cada requisito à necessidade original que o gerou. Essas três qualidades orientam, direta ou indiretamente, os princípios de construção do mapa de descoberta de requisitos apresentados na seção 4.

2.3 Mapas mentais como ferramenta de descoberta

O mapa mental é uma ferramenta que pode ser utilizada para organizar o pensamento, e se diferencia por sua simplicidade de uso. Ele pode ser descrito como um "diagrama visual colorido, usado para capturar informações" (BUZAN, 2019, p. 22). Para utilizá-lo, é necessário, no mínimo, um papel e um lápis, a partir dos quais se parte de uma ideia central e se ramificam outras ideias, informações e restrições, até que todo o cenário desejado esteja mapeado.

"Para atingir essa finalidade, no entanto, ele apela para o funcionamento do córtex cerebral. Ativa um pensamento que faz uso dos dois hemisférios cerebrais: o esquerdo, que é o hemisfério lógico, e o direito, o hemisfério criativo" (BUZAN, 2019, p. 22). Marques (2008, p. 17) reforça essa perspectiva ao afirmar que os mapas mentais "podem ser entendidos como sistemas de análise e apresentação de informação. A fundamentação da sua eficácia baseia-se nos resultados de estudos relativos ao funcionamento dos hemisférios cerebrais, da memória, dos mecanismos da aprendizagem e da percepção". A Figura 2 ilustra essa divisão funcional entre os dois hemisférios.

Para criar um mapa mental, é necessário, primeiro, definir o tema central e posicioná-lo no centro da folha. A partir dele, ramificam-se novas informações ou necessidades à medida que surgem. Se o objetivo, por exemplo, for escrever um livro, "escrever um livro" seria posicionado no centro, e dele se ramificariam os temas necessários para que o livro fosse escrito, como pesquisa, estrutura, revisão e publicação. Após essa primeira ramificação, cada um desses temas seria novamente analisado e ramificado, e assim sucessivamente, até que o mapa alcançasse um nível de detalhe satisfatório para o seu propósito. A Figura 3 ilustra esse processo com um mapa mental genérico para a publicação de um livro.

O exemplo da Figura 3 é intencionalmente genérico e tem como único objetivo demonstrar o mecanismo de ramificação de um mapa mental: um tema central que se desdobra em subtemas, e cada subtema, por sua vez, em novos subtemas, até o nível de detalhe desejado. A seção 4.3 aplica esse mesmo mecanismo, já enriquecido pelos princípios das seções 4.1 e 4.2, a um exemplo concreto de levantamento de requisitos.

2.4 Gerenciamento de processos e cadeia de valor

Neste trabalho, adota-se a seguinte definição de processo: um conjunto de ações, ou etapas, organizadas em sequência, no qual uma etapa precisa ser concluída para que a próxima se inicie e cujo objetivo é entregar algo ao seu final, produto ou serviço, de forma padronizada. Diferentemente de um projeto, um processo pode ser executado diversas vezes com o objetivo de gerar entregáveis próximos entre si.

Para que um processo funcione de forma consistente, é necessário controlar, na medida do possível, os insumos, as variáveis e as saídas de cada etapa, de modo que se comportem conforme o planejamento inicial e que o entregável final seja coerente com o esperado. Segundo o CBOK, um processo de negócio "é um trabalho que entrega valor para os clientes ou apoia/gerencia outros processos" (ABPMP, 2013, p. 47), sendo definido também como "agregação de atividades e comportamentos executados por humanos ou máquinas para alcançar um ou mais resultados" (ABPMP, 2013, p. 47).

Um conceito particularmente útil para este trabalho é o de cadeia de valor, que, segundo o CBOK, "captura processos e atividades que adicionam valor ao serviço ou produto entregue ao cliente. Proporciona uma visão geral, mas não uma visão detalhada dos processos" (ABPMP, 2013, p. 93). Assim como uma cadeia de valor, cada etapa de um mapa de descoberta de requisitos deve ter uma razão de existência clara, sob risco de se tornar um item sem correspondência a nenhuma ação a ser tomada, ou pequena demais para ser executada isoladamente, hipótese em que deve ser avaliada a possibilidade de fundi-la a outras etapas coerentes com ela. O objetivo do gerenciamento de processos, aplicado ao levantamento de requisitos, é garantir que cada etapa mapeada tenha seus elementos bem definidos: o motivo de sua existência, os insumos necessários para resolvê-la e o que ela entrega ao seu final.

2.5 Agilidade e os três pilares do Scrum

Toda atividade executada ao longo de um período fica sujeita, durante esse período, a mudanças de mercado ou de direcionamento que afetam o seu desenvolvimento. Por isso, durante o mapeamento de requisitos é necessário construir etapas maleáveis ou ramificar etapas de contingência de modo que o projeto possa se adequar a essas mudanças sem se inviabilizar. A cultura ágil oferece um conjunto de práticas voltado exatamente a esse objetivo: "a agilidade nos negócios refere-se à adaptação evolutiva rápida, contínua e sistemática e à inovação empresarial direcionada para obter e manter a vantagem competitiva" (WIKIPÉDIA, 2022, tradução nossa).

Este trabalho aborda especificamente o Scrum, um "framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções adaptativas para problemas complexos" (SCHWABER; SUTHERLAND, 2020, p. 4). Como aqui não se trata de gerenciamento de projetos, mas de levantamento de requisitos, não se aborda o Scrum em sua totalidade; a proposta é utilizar, de forma emprestada, os seus três pilares e a prática de histórias de usuário para modelar um mapa de maior valor para o processo.

Os três pilares do Scrum, transparência, inspeção e adaptação, orientam diretamente a estrutura de cada etapa do mapa de descoberta de requisitos, detalhada na seção 4.2. A transparência exige que "o processo emergente e o trabalho [...] sejam visíveis tanto para quem executa o trabalho quanto para quem recebe o trabalho" (SCHWABER; SUTHERLAND, 2020, p. 5). A inspeção exige que "os artefatos [...] e o progresso em direção às metas acordadas [...] sejam inspecionados com frequência e diligência para detectar variações ou problemas potencialmente indesejáveis" (SCHWABER; SUTHERLAND, 2020, p. 5). E a adaptação exige que, "se algum aspecto de um processo se desviar fora dos limites aceitáveis ou se o produto resultante for inaceitável, o processo que está sendo aplicado ou os materiais que estão sendo produzidos [sejam] ajustados [o mais rápido possível] para minimizar novos desvios" (SCHWABER; SUTHERLAND, 2020, p. 5).

Complementarmente, na criação de uma história de usuário, informa-se de forma simples, mas não incompleta, o que se espera entregar com a interação, utilizando perguntas abertas que ajudem a detalhar objetivamente a expectativa: como, quero, devo, preciso, porque. Ainda que não obrigatórias, as histórias de usuário se mostraram eficazes no desenvolvimento ágil, contribuindo para a definição de escopo e para a execução das atividades. Costa (2018) observa que a força das histórias de usuário está justamente em sua simplicidade: ao concentrar a atenção da equipe na motivação de cada necessidade, em vez de em uma especificação exaustiva, elas reduzem o risco de se levantarem requisitos tecnicamente corretos, mas desconectados do valor que deveriam gerar. Neste trabalho, essa mesma lógica é utilizada em cada etapa do mapa de descoberta de requisitos, buscando garantir que cada uma delas tenha seu motivo de existência e seus objetivos bem definidos.

3. Procedimentos Metodológicos

Este trabalho tem natureza aplicada e caráter propositivo, alinhando-se ao que a literatura de metodologia científica denomina pesquisa de desenvolvimento metodológico: seu produto não é a validação estatística de uma hipótese, mas a formulação sistemática de um instrumento replicável, o mapa de descoberta de requisitos, a partir da articulação entre fundamentação teórica e prática profissional.

A construção da proposta seguiu três etapas. Na primeira, foi realizada pesquisa bibliográfica sobre distorção da comunicação, técnicas de levantamento de requisitos, mapas mentais, gerenciamento de processos e métodos ágeis (seção 2), com o objetivo de identificar conceitos e instrumentos já consolidados na literatura que pudessem sustentar teoricamente a proposta. Na segunda etapa, esses conceitos foram articulados à experiência do autor em levantamento de requisitos de projetos de tecnologia, período no qual se consolidou a necessidade de um instrumento que unisse a flexibilidade exploratória dos mapas mentais à coesão do gerenciamento de processos e à adaptabilidade dos métodos ágeis. Na terceira etapa, os princípios, a estrutura e os exemplos resultantes dessa articulação foram sistematizados na proposta apresentada na seção 4.

Esta é a segunda versão deste trabalho. A primeira foi apresentada em 2021, como trabalho de conclusão de curso (SANTOS, 2021); esta versão revisa a redação do trabalho original, amplia de forma significativa o referencial teórico, acrescenta esta seção de procedimentos metodológicos e recria, como diagramas de autoria própria, as quatro figuras originalmente utilizadas, mantendo inalterado o núcleo técnico da proposta: os princípios de construção do mapa, a estrutura de cada etapa e os dois exemplos aplicados.

4. O Mapa de Descoberta de Requisitos

O mapa de descoberta de requisitos deve ser compreendido como um instrumento de exploração, e não como a modelagem de um processo sequencial. Ele parte de uma necessidade central, previamente definida, a partir da qual se ramificam novas possibilidades e temas correlacionados, até que se alcance uma cadeia de informações suficientemente detalhada para sustentar o planejamento do projeto.

4.1 Princípios de construção

É fundamental atentar para o fato de que o mapa de descoberta de requisitos modela ideias e não um processo: ele deve ser orientado à exploração e não a um fluxo contínuo e linear. Se cada etapa do mapa for tratada como parte de uma sequência obrigatória, na qual uma etapa só pode ser levantada depois que a anterior estiver concluída, o mapeamento perde parte de sua capacidade de descobrir soluções ou problemas que não decorrem de forma linear da etapa que os originou, mas que são coerentes com o mapa como um todo.

Ainda assim, cada etapa precisa ter uma razão de existência clara, seja uma necessidade, seja um objetivo. Uma etapa sem essa razão, ou pequena demais para ser executada isoladamente, deve ser reavaliada quanto à possibilidade de ser fundida a outras etapas coerentes com ela, de modo que o mapa mantenha etapas capazes de se explicar sozinhas, aproximando-se do conceito de cadeia de valor apresentado na seção 2.4.

Definido o ponto focal, isto é, o objetivo macro do projeto a partir do qual se deseja levantar os requisitos, ou um subobjetivo derivado dele, inicia-se a análise respondendo a quatro perguntas centrais: o que essa etapa vai entregar, ou o que se espera que aconteça; o que ela precisa para ser executada; como, quando e por quem ela será executada; e se existe alguma outra etapa ou atividade que precise existir para que ela tenha sucesso. Cada item descoberto por meio dessas perguntas deve ser avaliado quanto a pertencer à etapa em análise ou a constituir uma nova atividade a ser ramificada e posteriormente analisada da mesma forma.

Uma boa prática é iniciar por um mapa macro, com itens globais, e a partir dele construir mapas mais detalhados para cada item derivado do objetivo macro. Utilizar diretamente o objetivo macro em um único mapa tende a gerar um mapa muito grande e complexo, o que dificulta a descoberta de todas as etapas necessárias. A decisão sobre o nível de ramificação de cada novo mapa deve ser tomada pelo líder responsável, avaliando a profundidade necessária para que o levantamento seja suficiente, sem se tornar inviável de administrar.

4.2 Estrutura de cada etapa

Cada etapa do mapa deve conter, no mínimo, quatro elementos, diretamente inspirados na prática de histórias de usuário (seção 2.5): a história, que liga a etapa ao objetivo e ao entregável que a justificam; o entregável, que define o que será produzido pela etapa e em qual formato; o como, que define de que forma a etapa será executada; e o responsável, que define quem conduzirá a atividade, não necessariamente a mesma pessoa responsável pelo projeto como um todo. Quando pertinente, também deve ser registrado o quando, isto é, quando a atividade será ou começará a ser realizada, ainda que o mapa não deva ser confundido com um cronograma.

Essa estrutura opera os três pilares do Scrum apresentados na seção 2.5 diretamente sobre o mapa. A transparência é garantida ao se registrar, em cada etapa, a história e o entregável esperado de forma visível a todos os envolvidos, e não apenas a quem a levantou. A inspeção é garantida ao se avaliar cada etapa quanto à sua razão de existência e à suficiência de seus insumos, conforme os princípios da seção 4.1, antes de considerá-la concluída. E a adaptação é garantida pela própria lógica de ramificação do mapa: quando uma etapa se revela insuficiente, ambígua ou incompleta, ela pode ser reaberta e ramificada em novas etapas, sem que isso comprometa o restante do mapa já levantado.

Além disso, é comum que a solução de uma etapa ou de uma dúvida levantada durante sua análise já seja descoberta durante a própria modelagem do mapa. Nesses casos, essa solução deve ser documentada como parte da etapa, evitando que o conhecimento gerado durante o levantamento se perca antes de chegar à especificação final do projeto.

4.3 Exemplo aplicado: página de edição de cadastro

Para exemplificar a aplicação do mapa de descoberta de requisitos, considere-se o levantamento de requisitos para a construção de uma nova página de edição de cadastro em um sistema preexistente. O ponto de partida é o objetivo principal, posicionado no centro do mapa, a partir do qual se analisa quais atividades precisam existir para que esse objetivo seja alcançado com sucesso. No exemplo da Figura 4, essa análise resultou em três ramificações: a definição do layout da página, a definição da comunicação de dados necessária para a coleta e a edição das informações, e a definição da segurança e das regras de edição do cadastro.

Como pode ser observado na Figura 4, cada uma das três etapas segue a estrutura definida na seção 4.2: a história, ligada ao objetivo e ao entregável da etapa; o entregável esperado e seu formato; o como, isto é, de que forma a atividade será realizada; e o responsável pela sua execução, que, como no caso da etapa de comunicação de dados, pode ser um perfil técnico diferente do responsável pelas demais etapas. Como discutido na seção 4.2, em algumas situações a própria solução, como no caso da API de edição de cadastro identificada durante a análise da etapa de comunicação de dados, já é descoberta durante a modelagem do mapa, e deve ser documentada assim que surgir.

O próximo passo é repetir essas ações em cada nova etapa ramificada, até que se alcance uma profundidade suficiente para que todos os fatores relevantes ao objetivo principal estejam mapeados. A cada nova etapa, deve-se sempre analisar o que é necessário para concluí-la (os insumos) e quais recursos precisam existir para que ela seja executada (as variáveis); quando um insumo necessário ainda não existir, isto é, quando não houver etapa que o gere, deve-se ramificar da etapa em análise uma nova atividade responsável por entregá-lo. Como discutido na seção 4.1, a ordem entre essas etapas não é relevante: o mapa de descoberta de requisitos não é um processo sequencial, mas um instrumento de exploração.

5. Discussão

O mapa de descoberta de requisitos aqui proposto se diferencia de um mapa mental genérico, como o exemplificado na Figura 3, ao incorporar dois elementos adicionais. O primeiro é a estrutura de cada etapa, apresentada na seção 4.2, que aproxima o mapa da lógica de histórias de usuário e de cadeia de valor (seções 2.4 e 2.5), garantindo que cada etapa levantada tenha uma razão de existência clara e comunicável. O segundo é a incorporação explícita dos três pilares do Scrum, transparência, inspeção e adaptação, como critérios de qualidade aplicados diretamente sobre o mapa, e não apenas sobre o projeto que dele decorre.

Essa combinação contribui para os três objetivos anunciados no título deste trabalho: confiabilidade, na medida em que a estrutura de cada etapa reduz o espaço para requisitos sem razão de existência ou sem entregável definido; detalhamento, na medida em que a lógica de ramificação incentiva a exploração de necessidades secundárias que dificilmente surgiriam em uma entrevista ou em um questionário isolados; e adaptabilidade, na medida em que a lógica exploratória, e não sequencial, do mapa permite reabrir e ramificar etapas sem comprometer o levantamento já realizado.

Ao mesmo tempo, a proposta apresenta limitações que devem ser reconhecidas. A primeira é a dependência da habilidade do facilitador que conduz a construção do mapa: assim como a entrevista e o brainstorm, o mapa de descoberta de requisitos depende da capacidade de quem o conduz de formular boas perguntas e de perceber quando uma etapa está incompleta. A segunda é que o mapa não substitui a especificação formal de requisitos, tampouco define, por si só, um cronograma; ele antecede e alimenta essas atividades, mas não as elimina. A terceira é que a distorção da informação discutida na seção 2.1 não é eliminada pelo mapa, apenas mitigada por sua estrutura: como qualquer instrumento conduzido por pessoas, ele permanece sujeito a generalizações, omissões e distorções.

Essas limitações, em particular a dependência de dados qualitativos levantados por um facilitador, apontam para uma linha de pesquisa em desenvolvimento pelo autor, provisoriamente denominada Metodologia Ala. Enquanto o mapa de descoberta de requisitos aqui proposto ajuda a explorar e a estruturar as necessidades de um projeto, a Metodologia Ala propõe-se a tratar situações em que, a partir de um mapa de possibilidades já levantado, seja necessário comparar rotas de ação alternativas entre si, utilizando simulação probabilística e otimização para estimar o melhor e o pior cenário de cada rota antes de sua execução. As duas propostas são, portanto, complementares: uma organiza a descoberta das possibilidades; a outra, uma vez que essas possibilidades existam, orienta a escolha entre elas.

6. Considerações Finais

Este artigo propôs o mapa de descoberta de requisitos, um instrumento que enriquece o levantamento de requisitos por meio da combinação entre a técnica de mapas mentais, conceitos de gerenciamento de processos de negócio e os três pilares do Scrum. A proposta articula a lógica exploratória e não linear dos mapas mentais (BUZAN, 2019; MARQUES, 2008) à coesão da cadeia de valor do gerenciamento de processos (ABPMP, 2013) e à adaptabilidade da cultura ágil (SCHWABER; SUTHERLAND, 2020), buscando responder à distorção da informação inerente à comunicação entre pessoas (BANDLER; GRINDER, 1977) que compromete, com frequência, os processos tradicionais de levantamento de requisitos.

Como discutido na seção 5, a principal contribuição da proposta está na estrutura de cada etapa do mapa, história, entregável, forma de execução e responsável, que aproxima o levantamento exploratório de requisitos da lógica já consolidada das histórias de usuário, e na aplicação explícita dos três pilares do Scrum como critérios de qualidade sobre o próprio mapa, e não apenas sobre o projeto que dele decorre.

Esta é a segunda versão deste trabalho, revista a partir da publicação original de 2021 (SANTOS, 2021). Em relação à primeira versão, mantém-se o núcleo técnico da proposta, os princípios de construção do mapa, a estrutura de cada etapa e os dois exemplos aplicados, ampliando-se a fundamentação teórica, a discussão dos resultados e o rigor da redação.

Como agenda de pesquisas futuras, além do aprofundamento e da validação empírica do mapa de descoberta de requisitos em projetos de diferentes portes e segmentos, destaca-se o desenvolvimento da Metodologia Ala, linha de pesquisa em estruturação voltada à comparação de rotas de ação por meio de simulação probabilística e de otimização, a ser aplicada às possibilidades levantadas por instrumentos exploratórios como o proposto neste trabalho.

Referências

• ASSOCIATION OF BUSINESS PROCESS MANAGEMENT PROFESSIONALS (ABPMP). BPM CBOK: guia para o gerenciamento de processos de negócio: corpo comum de conhecimento. V. 3.0. [S.l.]: ABPMP, 2013.
• AZEVEDO JUNIOR, D. P. de; CAMPOS, R. de. Definição de requisitos de software baseada numa arquitetura de modelagem de negócios. Produção, São Paulo, v. 18, n. 1, p. 26-46, 2008. Disponível em: https://doi.org/10.1590/S0103-65132008000100003. Acesso em: 05 jun. 2022.
• BANDLER, R.; GRINDER, J. A estrutura da magia I: um livro sobre linguagem e terapia. São Paulo: Summus, 1977.
• BUZAN, T. Dominando a técnica dos mapas mentais. São Paulo: Pensamento-Cultrix, 2019.
• CARVALHO, P. Técnicas de levantamento de requisitos. 2009. Disponível em: http://pedrofcarvalho.com.br/PDF/ENGENHARIA_ANALISE_LEVANTAMENTO_REQUSITOS_2.pdf. Acesso em: 05 jun. 2022.
• COSTA, L. Engenharia de software essencial: um guia rápido com foco em agile. [S.l.]: Leandro Costa, 2018.
• MARQUES, A. Utilização pedagógica de mapas mentais e de mapas conceptuais. 2008. Dissertação (Mestrado em Expressão Gráfica, Cor e Imagem) – Universidade Aberta de Portugal, Lisboa, 2008. Disponível em: http://hdl.handle.net/10400.2/1259. Acesso em: 05 jun. 2022.
• MENDONÇA, R. A. R. de. Levantamento de requisitos no desenvolvimento ágil de software. Goiânia: PUC Goiás, [20--]. Disponível em: https://silo.tips/download/levantamento-de-requisitos-no-desenvolvimento-agil-de-software. Acesso em: 12 jul. 2026.
• PINHEIRO, A. F. Fundamentos da engenharia de software: conceitos básicos. [S.l.]: Álvaro Farias Pinheiro, 2015.
• PONTES, N. M. Introdução à modelagem de requisitos de software. [S.l.]: Nelson Medeiros Pontes, 2022.
• SANTOS, E. P. Aumentando o índice de confiança e adaptabilidade dos resultados do processo de levantamento de requisitos. 2021. Trabalho de Conclusão de Curso (Especialização em Engenharia de Software) – Rede Futura de Ensino, Nova Lima, 2021.
• SCHWABER, K.; SUTHERLAND, J. O Guia do Scrum: o guia definitivo para o Scrum: as regras do jogo. 2020. Tradução de Pedro Silva e Mário Pereira. Disponível em: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Portuguese-European.pdf. Acesso em: 12 jul. 2026.
• SILVA, N. Uma teoria sobre conflito em equipes presenciais de desenvolvimento de software. 2019. Tese (Doutorado em Ciência da Computação) – Universidade Federal de Pernambuco, Centro de Informática, Recife, 2019. Disponível em: https://repositorio.ufpe.br/handle/123456789/35864. Acesso em: 05 jun. 2022.
• WIKIPÉDIA. Agilidade nos negócios. In: WIKIPÉDIA: a enciclopédia livre. [São Francisco, CA]: Fundação Wikimedia, 2022. Disponível em: https://en.wikipedia.org/wiki/Business_agility. Acesso em: 05 jun. 2022.

Como citar