Modelo de levantamento de requisitos: 7 hacks que uso em projetos

Um modelo de levantamento de requisitos só merece existir se forçar as conversas difíceis cedo: quem assina, quem pode bloquear, como é o sucesso e com que rapidez o sistema precisa responder. Este guia é para gerentes de projeto, analistas de negócio e líderes de SAP que precisam de um modelo que sobreviva ao primeiro comitê de direção. Abaixo está o roteiro completo que uso, com um responsável para cada seção, as cinco seções que nunca pulo e sete hacks para entrevistas, priorização e mudanças. Copie o roteiro para o seu próprio documento e preencha-o antes de o design começar.

Certa vez vi um projeto de seis dígitos implodir porque ninguém levantou os requisitos direito. O cliente esperava uma coisa. A equipe de desenvolvimento construiu outra. Todo mundo foi jogado debaixo do ônibus, e foi aí que me chamaram.

O padrão não é incomum. O relatório Pulse of the Profession de 2014 do PMI sobre gestão de requisitos constatou que 47% dos projetos malsucedidos não atingiram seus objetivos por causa de uma gestão deficiente de requisitos. Já vi isso acontecer dezenas de vezes.

Eu mesmo quase caí na mesma situação em um grande rollout de sistema. As partes interessadas estavam em todas as direções. Os desenvolvedores estavam chutando. Paramos, montamos um modelo de requisitos decente e entregamos o que o negócio precisava, no prazo e dentro do orçamento.

A empresa de um amigo gastou US$ 350 mil em um CRM sob medida que ninguém usa. Vendas precisava de uma coisa, o marketing queria outra, e os desenvolvedores construíram o que achavam que todo mundo queria.

Um cliente meu da área de saúde desperdiçou 18 meses em uma implementação de prontuário eletrônico (EMR) que os médicos se recusaram a usar. Ninguém tinha perguntado o que eles precisavam no fluxo de trabalho diário. O projeto foi descartado e reiniciado.

Descobrir tarde sai caro. Um estudo da NASA sobre a escalada do custo de erros constatou que um erro de requisitos pego na integração e nos testes custava de 21 a 78 vezes mais para corrigir do que um pego durante os requisitos. Pego em operação, o múltiplo ia de 29 a mais de 1.500. Em um programa corporativo, essa é a diferença entre um workshop e uma solicitação de mudança de centenas de milhares.

1. RequisitosO custo-base para corrigirPego enquanto os requisitos ainda estão sendo escritos
2. Integração e testes21 a 78 vezes o custoPego quando o sistema já está construído e em teste
3. Operação29 a mais de 1,500 vezes o custoPego depois que o sistema está em produção

Fonte: Estudo da NASA sobre a escalada do custo de erros

Depois de aprender isso do jeito difícil, estas são as cinco seções que nenhum modelo de requisitos deve pular.

1. Resumo executivo com bloco de assinatura

Executivos ocupados não vão ler um documento de requisitos de 30 páginas. Uma vez um patrocinador aprovou um projeto sem entender o que estava assinando e depois perdeu a paciência quando viu o resultado. Limite-o a uma página: impacto no negócio, cronograma, recursos, benefício esperado e um bloco de assinatura nessa mesma página, para que os aprovadores não possam alegar que não viram os detalhes críticos.

2. Mapeamento de papéis e influência

Uma lista de nomes não basta. Você precisa de um mapa de poder: quem pode derrubar o projeto, quem precisa ser consultado, quem só precisa de atualizações. Em um emprego anterior, estávamos seis meses no desenvolvimento quando o jurídico chegou com requisitos que forçaram um redesenho. Ninguém tinha pensado em incluí-los. Mapeie cada departamento afetado, seu representante e sua influência.

3. Objetivos de negócio, não requisitos técnicos

Que problema estamos resolvendo e como vamos medir o sucesso? Um cliente de manufatura implementou um software de estoque exatamente como especificado, e ele desacelerou as operações do armazém em 20%. O modelo deve obrigar as partes interessadas a definir o sucesso do negócio com uma linha de base atual, e não uma lista de funcionalidades.

4. Requisitos funcionais que os desenvolvedores conseguem usar

Corte o jargão. Faça cada requisito ser específico e testável. “O sistema deve melhorar a experiência do cliente” não serve para nada. “Os usuários devem conseguir processar uma devolução e emitir um reembolso em menos de 3 minutos” é um requisito. Se você não consegue verificar que foi feito, reescreva.

5. Requisitos não funcionais

Desempenho, segurança, conformidade, disponibilidade, escalabilidade. É a seção que quase todo mundo pula, e aí o sistema cai sob carga ou é reprovado em uma auditoria de segurança. Soube de um projeto de varejo em que o sistema funcionava perfeitamente até a Black Friday, quando colapsou sob carga porque ninguém tinha especificado requisitos de desempenho. Escreva tempos de resposta, disponibilidade, picos de usuários e obrigações de conformidade como números.

Aqui está o roteiro completo. As cinco seções acima ficam dentro dele, ao lado dos registros que o mantêm vivo depois da aprovação.

Seção	O que entra	Responsável	Aprovado por
1. Resumo executivo	Problema, impacto no negócio, cronograma, recursos, benefício esperado. Uma página com bloco de assinatura	Patrocinador, redigido pelo líder de análise de negócios	Patrocinador e finanças
2. Escopo e linha de base de implantação	O que está dentro e fora do escopo, restrições. Para SAP: public edition, private edition ou on-premise	Diretor do programa	Comitê de direção
3. Mapa de papéis e influência	Departamentos, representantes, nível de influência, consultar ou informar	Líder de análise de negócios	Patrocinador
4. Objetivos de negócio	Cada objetivo com um KPI, sua linha de base atual e uma meta	Donos de processo	Patrocinador
5. Requisitos funcionais	ID (por exemplo, REQ-FUN-023), descrição, origem, prioridade, critérios de aceitação, decisão de fit-to-standard	Líderes funcionais	Donos de processo
6. Requisitos não funcionais	Desempenho, segurança, conformidade, disponibilidade; para SAP, a abordagem de extensão para cada gap	Arquiteto de soluções	TI, segurança e conformidade
7. Parking lot	Pedidos adiados, quem pediu, data da próxima revisão	Líder de análise de negócios	Nenhum até ser promovido
8. Registro de rejeitados	O que foi rejeitado, por quê, quando e por quem	Líder de análise de negócios	Patrocinador
9. Registro de mudanças	Toda mudança após a aprovação, com seu impacto em prazo e custo	PMO	Comitê de controle de mudanças

1. Use os Cinco Porquês nas entrevistas com as partes interessadas

Pergunte “do que você precisa?” e você recebe uma lista de desejos. Pergunte sobre a dor: “O que faz você querer jogar o computador pela janela?” Depois pergunte por quê, e por quê de novo, cinco vezes. O requisito real costuma ser diferente do primeiro pedido.

Tive um interessado que insistia em recursos complexos de relatórios. Depois que passamos por seus casos de uso reais, ele precisava de três dashboards simples.

2. Crie um parking lot de requisitos

Boa parte do que as partes interessadas pedem nunca será usada. Quando alguém insiste em algo questionável, não discuto. Coloco no parking lot e mando um lembrete mensal perguntando se aquilo deve passar para os requisitos ativos. A maioria fica estacionada de vez.

3. Use a regra de três com as partes interessadas que mudam de ideia o tempo todo

Elas podem mudar de direção duas vezes sem consequência. Na terceira mudança, escrevem um e-mail ao chefe explicando a mudança e o seu impacto. Ninguém quer enviar esse e-mail. As mudanças param.

4. Use a técnica de alocação de verba para forçar a priorização

Dê a cada parte interessada 100 dólares virtuais para gastar entre todos os requisitos. Ninguém pode ter tudo, então todos põem dinheiro onde importa. Fiz isso com um cliente de serviços financeiros que tinha mais de 200 requisitos “críticos”. Em uma hora, tínhamos os 20 principais de verdade.

5. Numere todos os requisitos

Use um formato consistente, como REQ-FUN-023. Isso acaba com a confusão de “de qual requisito estamos falando?”, que desperdiça tempo de reunião. Registre a origem, quem pediu e por quê, para saber quem chamar quando for preciso cortar itens.

6. Devolva os requisitos na linguagem da parte interessada

Depois de documentar, leia os requisitos de volta para as partes interessadas com as palavras delas. Monte um protótipo ou wireframe rápido para tudo o que for complexo antes de o desenvolvimento começar. Os mal-entendidos aparecem enquanto ainda são baratos.

7. Documente o que foi rejeitado

Alguém vai trazer de volta um requisito rejeitado no quinto mês. “Discutimos isso em abril, e aqui está o motivo pelo qual decidimos contra” encerra essa conversa rapidamente. Sem o registro, você tem a mesma discussão de novo.

Os sete hacks funcionam em qualquer projeto. Os programas SAP precisam de três itens extras no modelo.

O modelo de implantação entra na linha de base

Registre o modelo de implantação antes de levantar os requisitos funcionais: S/4HANA Cloud Public Edition (por meio do GROW with SAP ou do RISE), Private Edition (normalmente por meio do RISE) ou on-premise. Ele define o que é possível. A public edition não permite modificar o core, então os requisitos que dependem de processos fora do padrão precisam ser remodelados ou rejeitados. A private edition e o on-premise permitem mais, ao custo de esforço nos upgrades.

Levante os requisitos antes dessa decisão e você vai reescrever muitos deles quando ela chegar.

Uma decisão de extensão para cada gap

A abordagem de clean core da SAP significa que cada gap precisa de uma decisão registrada: configurá-lo, estendê-lo usando APIs liberadas (on-stack com ABAP Cloud ou side-by-side no SAP BTP) ou rejeitá-lo. Na public edition isso é imposto pelo produto. Na private edition e no on-premise é uma orientação firme da SAP, e cada modificação que você permitir vira trabalho de upgrade mais tarde. Coloque a decisão na seção 6 do modelo, ao lado de desempenho e segurança, e dê a um arquiteto a autoridade para aprová-la. Meu guia de clean core explica os níveis.

A IA redige, as pessoas decidem

A IA agora ajuda com a papelada. O SAP Cloud ALM oferece um recurso de geração de requisitos que redige requisitos a partir das transcrições dos workshops de fit-to-standard em um modelo, pago por meio de AI units. Assistentes gerais, como o Microsoft Copilot, redigem resumos e atas a partir das anotações de reunião.

As ferramentas de redação com IA economizam tempo de verdade na papelada quando o material de origem está limpo. Elas não mudam a entrevista. Uma pessoa ainda faz os Cinco Porquês. E nenhuma ferramenta faz um chefe de departamento assinar o resumo executivo. Validação, priorização e aprovação continuam sendo trabalho humano.

Desenvolvimento de software. Acrescente restrições técnicas, pontos de integração, fluxos de usuário (os passos reais que os usuários seguem, e não apenas as funcionalidades) e critérios de aceitação de aprovado/reprovado. Deixamos isso passar em um projeto de portal do cliente e passamos três meses discutindo se as funcionalidades estavam “funcionando direito”.

Melhoria de processos. Mapeie o estado atual com todos os workarounds bagunçados que as pessoas não mencionam em reuniões, avalie o impacto por papel e registre linhas de base de desempenho concretas. Um cliente de manufatura reformulou o processo do seu armazém sem linhas de base. Seis meses depois, não conseguia provar a melhoria nem justificar o gasto.

Seleção de fornecedores. Separe o indispensável do desejável, pondere os critérios de pontuação e detalhe as expectativas de suporte e de implementação até a exaustão. Vi uma empresa escolher um fornecedor quase só por funcionalidades e pela impressão das demonstrações. Ignorou os requisitos de suporte e acabou com um sistema que não conseguia implementar sem grandes honorários adicionais de consultoria.

Para projetos menores: Trello para movimentar os requisitos pelas etapas de aprovação, Google Docs com comentários para revisão e Miro para o mapeamento de processos em workshops.

Para programas corporativos: Jira com um add-on de gestão de requisitos, Confluence para documentos vivos (seus recursos de IA agora ficam sob a marca Rovo da Atlassian) e Modern Requirements se você usa o Azure DevOps. Nos programas SAP, o SAP Cloud ALM reúne requisitos, user stories e casos de teste em um só lugar, ligados ao roadmap do SAP Activate.

A ferramenta importa menos do que a conexão. Ligue os requisitos ao plano do projeto e aos casos de teste, e envie notificações automáticas quando um requisito mudar. “Eu não sabia que isso tinha mudado” mata mais projetos do que ferramentas ruins. Depois que os requisitos são aprovados, meu guia sobre como evitar o scope creep em implementações SAP trata de mantê-los assim, e os quality gates do SAP mostram onde a aprovação dos requisitos se encaixa no ciclo de governança.

Um modelo que ninguém abre depois da aprovação é teatro. Os que funcionam são curtos, têm dono seção por seção e são atualizados toda vez que alguém muda de ideia, o que, em qualquer programa que valha a pena, acontece toda semana.

Quais são as 5 etapas do levantamento de requisitos?

1. Elicitação: coleta de informações por meio de entrevistas, workshops e observação
2. Análise: organização, priorização e resolução de conflitos entre requisitos
3. Documentação: redação da especificação (BRD, FRD ou user stories, conforme o método)
4. Validação: confirmação de que os requisitos refletem necessidades reais e podem ser testados
5. Gestão: acompanhamento das mudanças pelo resto do projeto

Cada etapa se apoia na anterior. Apressar a elicitação, como a maioria das equipes faz, cria problemas em todas as etapas seguintes.

Qual é a diferença entre um BRD e um FRD?

Um Business Requirements Document (BRD) cobre as necessidades do negócio: contexto, metas, partes interessadas, restrições e requisitos de alto nível. Ele responde a “do que o negócio precisa?”

Um Functional Requirements Document (FRD) cobre como o sistema vai se comportar: user stories, comportamento do sistema, interfaces e critérios de aceitação. Ele responde a “o que o sistema deve fazer?”

Sempre começo pelo BRD para obter o alinhamento do negócio antes do FRD. As equipes que pulam direto para o FRD costumam construir um sistema tecnicamente correto que resolve o problema errado.

Quais são os 3 tipos de requisitos?

1. Requisitos de negócio: por que o projeto existe, seus objetivos e medidas de sucesso
2. Requisitos funcionais: o que o sistema deve fazer
3. Requisitos não funcionais: com que qualidade ele deve fazer (desempenho, segurança, escalabilidade, conformidade)

A maioria dos fracassos de projeto que vi remonta à falta de requisitos não funcionais. O sistema faz o que foi pedido e depois cai sob carga real ou é reprovado em uma auditoria de conformidade.

Como o modelo de implantação do SAP muda o levantamento de requisitos?

Registre-o primeiro. O S/4HANA Cloud Public Edition não permite modificar o core, então os requisitos construídos sobre processos fora do padrão precisam ser remodelados ou rejeitados. A Private Edition e o on-premise permitem mais flexibilidade, mas cada modificação aumenta o esforço de upgrade.

Levante os requisitos funcionais antes da decisão e você vai refazer muitos deles. Acrescente uma decisão de extensão registrada (configurar, estender por meio de APIs liberadas ou rejeitar) para cada gap.

O que torna um requisito testável?

Uma condição de aprovado/reprovado clara e mensurável. “O sistema deve ser rápido” não é testável. “Os resultados de busca devem retornar em menos de 2 segundos para 95% das consultas em carga padrão” é.

Meu teste: você consegue escrever o caso de teste agora, com critérios claros de aprovado/reprovado? Se não, reescreva o requisito. Requisitos não testáveis causam mais disputas no go-live do que qualquer outra coisa que eu veja.

Como evitar que os requisitos mudem o tempo todo?

1. Controle de mudanças: qualquer mudança após a aprovação documenta seu impacto em prazo, orçamento e recursos antes que alguém a aprove. Torne visível o custo da mudança.
2. Parking lot: os novos pedidos vão para o parking lot, e não direto para o escopo. Revise todo mês. A maioria dos pedidos que parecem urgentes não sobrevive à espera.
3. Quality gates: defina o que significa “requisitos completos” e não comece o design até que isso seja atendido.

Nos programas SAP, a decisão de extensão acrescenta uma verificação técnica por cima: um pedido que exige uma modificação do core precisa passar pelo arquiteto antes de poder ser aprovado.