Planejamento, Cronograma e Custos
Tipos de requisitos no PMBOK: negócio, partes e solução
Os tipos de requisitos no PMBOK existem para resolver um problema bem conhecido: a lista de requisitos que só tem funcionalidades. Ela descreve telas e relatórios, mas não diz por que o projeto existe, quem precisa de quê, como os dados antigos chegam ao sistema novo nem quem decide se a entrega está aceita. Esses buracos aparecem na véspera da implantação, quando custam mais caro.
Classificar cada requisito num dos seis tipos funciona como uma lista de conferência. Se uma categoria está vazia, ou ninguém perguntou, ou o assunto foi decidido de cabeça e não ficou registrado. A técnica para levantar os requisitos (entrevistas, oficinas, protótipos) está no artigo sobre coleta de requisitos do projeto. Aqui o foco é o que cada tipo significa e como usá-lo.
Formação relacionada
Microsoft Project Professional
Cronogramas confiáveis, linha de base, controle de desvio e relatórios que sustentam decisão de diretoria.
Quais são os tipos de requisitos no PMBOK
O Guia PMBOK, do Project Management Institute (PMI), apresenta essa classificação no processo de coletar os requisitos, nas edições organizadas por processos. A 8ª edição reorganizou o guia em princípios, domínios de desempenho e áreas de foco, mas a classificação continua sendo a referência usada em análise de negócios e nas provas de certificação.
| Tipo | Pergunta que responde | Quem costuma fornecer |
|---|---|---|
| De negócio | Por que a organização faz o projeto e que resultado espera? | Patrocinador, diretoria, business case |
| Das partes interessadas | O que cada grupo precisa para trabalhar com o resultado? | Usuários, áreas afetadas, clientes, órgãos reguladores |
| De solução: funcionais | O que o produto precisa fazer? | Usuários-chave, analistas de negócio |
| De solução: não funcionais | Como o produto precisa se comportar (desempenho, segurança, disponibilidade, usabilidade)? | TI, segurança da informação, operação |
| De transição e prontidão | O que é preciso, temporariamente, para sair do estado atual e chegar ao novo? | Operação, TI, RH, treinamento |
| Do projeto | Que condições o projeto em si precisa cumprir (prazos, marcos, contratos, regras internas)? | Patrocinador, PMO, área de compras |
| De qualidade | Que critérios provam que uma entrega foi bem feita e pode ser aceita? | Cliente, área de qualidade, quem dá o aceite |
Os quatro primeiros falam do resultado: o produto, serviço ou mudança que o projeto entrega. Os dois últimos falam do projeto: como ele deve ser conduzido e como as entregas serão aceitas. Essa divisão importa porque os requisitos do resultado sobrevivem ao projeto (alguém vai operar o sistema), enquanto os do projeto se encerram com ele.
Requisitos de negócio e das partes interessadas
Requisitos de negócio descrevem a necessidade da organização como um todo. São poucos e de alto nível: "reduzir o pagamento de horas extras indevidas", "cumprir a nova exigência do órgão regulador até o fim do ano". Eles vêm do business case e do termo de abertura e são a régua para decidir se um pedido detalhado faz sentido. Um requisito de solução que não serve a nenhum requisito de negócio é candidato a corte.
Requisitos das partes interessadas descrevem o que um grupo específico precisa para conviver com o resultado. O gestor de uma loja quer aprovar ajustes de ponto pelo celular; o departamento pessoal quer fechar a folha sem redigitar dados; o sindicato quer que o espelho de ponto fique acessível ao empregado. Cada grupo enxerga uma parte do problema, e é comum os pedidos entrarem em conflito. O registro por grupo mostra de quem veio cada pedido, o que ajuda na hora de negociar prioridades.
Requisitos de solução: funcionais e não funcionais
Os requisitos de solução traduzem as necessidades anteriores em características do produto. Eles se dividem em dois grupos.
- Funcionais: o que a solução faz. "O sistema calcula as horas extras por funcionário a cada fechamento." "O gestor recebe um aviso quando há marcação faltando."
- Não funcionais: as condições para a solução funcionar bem. "A marcação é registrada em até 3 segundos." "O sistema fica disponível nos horários de troca de turno." "Só o departamento pessoal altera marcações já fechadas."
Os não funcionais são os que mais faltam nas listas, porque ninguém os pede espontaneamente. O usuário não diz "quero que funcione com sinal fraco de internet"; ele só reclama quando não funciona. Por isso a pergunta precisa ser feita de forma ativa, com a TI e com quem opera.
Requisito de solução bom é verificável. "Sistema rápido" não é requisito; "consulta do espelho de ponto em até 5 segundos com 300 usuários simultâneos" é, porque dá para testar.
Requisitos de transição e prontidão
São as capacidades temporárias para levar a organização do jeito atual ao novo: migração de dados, treinamento, período de operação em paralelo, mudança de procedimento, comunicação aos afetados, suporte reforçado nas primeiras semanas. Quando o novo processo está estável, eles deixam de existir.
É o tipo mais esquecido e o que mais derruba implantações. O sistema fica pronto, mas o histórico de banco de horas não foi migrado, os gestores não foram treinados ou ninguém definiu o que acontece com as marcações do mês em que os dois sistemas conviveram. Se a sua lista não tem nenhum requisito de transição, a pergunta "o que precisa acontecer no dia da virada?" ainda não foi feita.
Requisitos do projeto e requisitos de qualidade
Requisitos do projeto são condições que o trabalho precisa cumprir, independentemente do produto: "a implantação nas lojas acontece fora do período de fechamento da folha", "o fornecedor é contratado pelo processo de compras padrão", "o projeto apresenta status quinzenal ao comitê". Eles alimentam o cronograma, o plano de aquisições e o plano de comunicações.
Requisitos de qualidade definem como se prova que uma entrega está boa: critérios de aceite, testes obrigatórios, quem aprova. "A folha de um mês é calculada nos dois sistemas e as diferenças ficam abaixo do limite combinado com o departamento pessoal" é um requisito de qualidade. Sem ele, o aceite vira opinião.
Exemplo: os seis tipos num projeto de ponto eletrônico
O exemplo é ilustrativo. Uma rede varejista com lojas em vários estados vai substituir o controle de ponto em papel por um sistema eletrônico integrado à folha de pagamento.
| Tipo | Exemplo de requisito | Ligado a |
|---|---|---|
| Negócio | NEG-01: eliminar a redigitação de marcações no fechamento da folha | Business case |
| Partes interessadas | PI-03: gestores de loja aprovam ajustes de ponto pelo celular | NEG-01 |
| Solução funcional | SOL-07: o sistema envia ao gestor, diariamente, a lista de marcações incompletas | PI-03 |
| Solução não funcional | SOL-12: a marcação é aceita sem internet e sincronizada quando a conexão volta | PI-03 |
| Transição e prontidão | TRA-02: saldo de banco de horas de cada funcionário migrado e conferido pelo departamento pessoal antes da virada | NEG-01 |
| Projeto | PRJ-04: nenhuma loja muda de sistema na semana de fechamento da folha | NEG-01 |
| Qualidade | QUA-01: um mês de folha calculado nos dois sistemas, com diferenças explicadas e aceitas pelo departamento pessoal | NEG-01 |
Repare na última coluna. Cada requisito aponta para o requisito de nível acima que o justifica. Essa ligação é o que a matriz de rastreabilidade de requisitos registra, e ela permite responder, no meio do projeto, "se tirarmos o SOL-12, que necessidade deixa de ser atendida?".
Repare também no que a classificação revelou. Num primeiro levantamento, só com os usuários, apareceriam SOL-07 e talvez PI-03. O TRA-02 e o PRJ-04 surgiram porque a equipe perguntou especificamente sobre transição e restrições do projeto. São justamente os que mais atrasariam a implantação se fossem descobertos no fim.
Como usar a classificação no seu projeto
- Comece pelos requisitos de negócio. Escreva de dois a cinco, a partir do termo de abertura. Eles são o filtro para todo o resto.
- Levante os requisitos por grupo de partes interessadas. Registre de quem veio cada pedido.
- Classifique tudo o que foi levantado. Uma coluna "tipo" na planilha de requisitos basta.
- Procure as categorias vazias ou magras. Nenhum não funcional? Nenhum de transição? Marque uma conversa específica para isso.
- Ligue cada requisito ao de nível acima. Requisito sem "pai" ou é necessidade não registrada, ou é desejo que não serve ao objetivo.
- Leve os requisitos aprovados para o escopo. Os de solução e de transição viram entregas na Estrutura Analítica do Projeto (EAP); os de qualidade viram critérios de aceite; os do projeto viram restrições no cronograma e no plano.
A passagem dos requisitos para a declaração de escopo, com exclusões e critérios de aceite, está no modelo de escopo do projeto. E o lugar dos requisitos dentro do controle do escopo como um todo está em gerenciamento do escopo do projeto.
Erros comuns ao classificar requisitos
- Discutir a classificação em vez do conteúdo. Se um requisito fica entre "partes interessadas" e "funcional", escolha um e siga. O objetivo é achar lacunas, não acertar uma prova.
- Tratar requisito de negócio como funcionalidade. "Ter um aplicativo" não é necessidade de negócio; é uma solução. Pergunte "para quê?" até chegar ao resultado esperado.
- Deixar os não funcionais para a TI decidir sozinha. Disponibilidade e tempo de resposta afetam o usuário e o custo. São decisões de negócio com apoio técnico.
- Esquecer que transição tem custo e prazo. Migração e treinamento precisam de atividades, responsáveis e orçamento no plano, não de uma linha genérica "implantação".
- Escrever critério de qualidade que não dá para medir. "Sistema estável" não permite aceite. Defina o teste e o limite.
Para aplicar agora, abra a lista de requisitos do seu projeto, acrescente a coluna de tipo e conte quantos há em cada um dos seis grupos. As categorias vazias são a pauta da próxima conversa com as partes interessadas. O guia de planejamento de projetos mostra onde os requisitos entram na sequência do plano. E se você quer dominar requisitos, escopo e os demais temas do guia na versão mais recente, a formação Gestão de Projetos 360° com PMBOK 8 e IA, da Projeto Diário, trabalha o PMBOK 8 ao vivo, com uso de inteligência artificial no dia a dia da gestão.
