Expectativas, Requisitos, Critérios, Restrições e Premissas

Atualizado em 12/04/2024
Blog de Gerenciamento de Projetos
Controle, Entradas do Guia PMBOK®, Escopo, Execução, Planejamento, Processos do Guia PMBOK®, Qualidade

O Guia PMBOK® define em seu glossário:

“Requisito / Requirement. Uma condição ou capacidade que deve ser atendida ou possuída por um sistema, produto, serviço, resultado ou componente para satisfazer um contrato, uma norma, uma especificação ou outro documento impostos formalmente. Os requisitos incluem necessidades, desejos e expectativas quantificados e documentados do patrocinador, do cliente e de outras partes interessadas.” (PMI, p. 442)

“Critérios de aceitação / Acceptance Criteria. Os critérios, inclusive requisitos de desempenho e condições essenciais, que devem ser atendidos antes que as entregas do projeto sejam aceitas.” (PMI, p.425)

Requisitos são “necessidades, desejos e expectativas quantificados e documentados”. Ou seja, as expectativas das partes interessadas só são consideradas no plano do projeto quando tiverem sido quantificadas e documentadas na forma de requisitos aprovados para serem incluídas no escopo do projeto (supus “necessidades” e “desejos” incluídos no termo “expectativas”).

Ou seja, nem toda expectativa será quantificada ou aprovada, portanto, atendida pelo escopo do projeto ou fase. É de fundamental importância, portando, que a Matriz de Rastreabilidade de Requisitos documente quais expectativas se tornaram requisitos de fato, e que o Patrocinador e outras partes interessadas relevantes confirmem a lista de requisitos aprovada.

Alguns requisitos serão satisfeitos pela realização de entregas e por isso devem ser mapeados na Matriz de Rastreabilidade de Requisitos aos critérios de aceitação e entregas que os satisfarão.

Outras expectativas e requisitos não são “mapeáveis” em entregas e critérios de aceitação. Exemplo: “o projeto deve terminar em menos de seis meses”. O leitor conhecedor do Guia PMBOK® dirá: “Mas isto é uma restrição”, e de fato o Guia PMBOK ® define em seu glossário:

“Restrição / Constraint [Entradas]. O estado, a qualidade ou o sentido de estar restrito a uma determinada ação ou inatividade. Uma restrição ou limitação aplicável, interna ou externa, a um projeto, a qual afetará o desempenho do projeto ou de um processo. Por exemplo, uma restrição do cronograma e qualquer limitação ou condição colocada no cronograma do projeto que afeta o momento em que uma atividade do cronograma pode ser agendada e geralmente esta na forma de datas impostas fixas.” (PMI, p. 442)

Ocorre que mesmo uma restrição nasce como uma expectativa (p.ex., “terminar rapidamente” que precisa ser quantificada (“em 6 meses”) e que pode ou não ser aprovada quando analisada em conjunto com as outras expectativas e requisitos. Documentar o processo de avaliação de requisitos incluindo as (potenciais) restrições no mesmo processo de “Coletar requisitos” é a sugestão do autor deste blog para os colegas gerentes de projeto.

Em alguns casos, um critério de aceitação pode ser mais facilmente gerenciado se for representado também como uma restrição. P.ex., uma entrega pode ter como critério de aceitação ser entregue até uma data limite, caso contrário, a entrega será rejeitada, pois não tem mais utilidade. Uma restrição adicionada ao cronograma sobre o marco que representa a entrega fará com que o cálculo das datas e do caminho crítico já considere esta restrição e, portanto, facilite o gerenciamento da realização do critério de aceitação associado a esta restrição. Incluir na Matriz de Rastreabilidade de Requisitos todos os relacionamentos entre expectativas, requisitos, critérios de aceitação e restrições que forem representados nas linhas de base de escopo, prazo, custo e qualidade.

E as premissas? As premissas manifestam expectativas da equipe de gerenciamento do projeto, que também é parte interessada no projeto. As premissas podem então ser representadas na Matriz de Rastreabilidade de Requisitos como expectativas e requisitos da equipe de gerenciamento. Acrescentar as premissas na Matriz de Rastreabilidade de Requisitos não é prática mencionada no Guia PMBOK®, nem é prática comum hoje, porque também não é prática comum reconhecer a equipe de gerenciamento do projeto como parte interessada com direito (ou seja, fonte) de requisitos. No entanto, relacionar as premissas com os requisitos de outras partes interessadas será útil quando for necessário abandonar alguma premissa (p.ex., “o projeto pode ser concluído no prazo limite definido como restrição desde que tais e tais premissas sejam satisfeitas”), e usar a Matriz de Rastreabilidade de Requisitos para este relacionamento evita a criação de mais um documento. Para o leitor, fica o exercício de (re)ler a descrição do processo 5.1 Coletar os Requisitos no Guia PMBOK® 4.a edição, imaginando a inclusão da equipe de gerenciamento entre as partes interessadas que fornecem premissas como requisitos.

A seguir: “Até onde descer na EAP (WBS)?”

Conheça melhor Fernando Dias e veja seus outros artigos e contribuições para nossa Comunidade de GPs.

Veja também

Templates/Modelos:

Exemplos de Projetos:

Fundamentos

- Premissas de um projeto
- Restrições de um projeto

Referências bibliográficas

MONTES, Eduardo. Introdução ao Gerenciamento de Projetos, 1ª Ed. São Paulo; 2017.

PMI - PROJECT MANAGEMENT INSTITUTE. Guia PMBOK®: Um Guia para o Conjunto de Conhecimentos em Gerenciamento de Projetos, Sexta edição, Pennsylvania: PMI, 2017.

Dias, F. R. T. Gerenciamento dos Riscos em Projetos. Rio de Janeiro: Elsevier, 2014

Saiba mais Gestão dos Riscos

Fundamentos sobre riscos de projetos

Gerenciamento dos riscos

Entradas e Saídas dos Processos do Guia PMBOK®

Verifique nas entradas seus Modelos/Templates e exemplos

Ferramentas de Riscos do Guia PMBOK®

Metodologia aderente ao PMBOK

Artigos sobre gerenciamento dos riscos

Grupos de interesse em projetos

Junte-se ao Grupo de Gestão de projetos de forma gratuita e tenha acesso a eventos, fórum e conteúdo exclusivo.

Fernando Rodrigues Teixeira Dias

FERNANDO RODRIGUES TEIXEIRA DIAS é Master in Project Management pela George Washington University (2002), mestre em administração de empresas pela Faculdade de Economia, Administração e Contabilidade da Universidade de São Paulo (1999), pós-graduado em Gestão Ambiental pelo Senac-SP (2008) e engenheiro eletrônico pelo ITA (1988). Fernando possui mais de 25 anos de experiência em gerenciamento de projetos de TI, reengenharia de processos em instituições financeiras e consultorias de engenharia, telecomunicações e TI. Fernando é um dos criadores da pós-graduação em gerenciamento de projetos do Senac-SP, onde foi coordenador de 2004 a 2010 e até hoje é professor. A dupla experiência acumulada como docente e profissional confere a Fernando um modo próprio de interpretar e transmitir de forma didática os padrões do Project Management Institute – PMI®, o que inclui recomendações práticas sobre o que considerar ao adotar as boas práticas incluídas nestes padrões. Autor do livro ‘Gerenciamento dos Riscos em Projetos‘ (2014) da coleção Grandes Especialistas Brasileiros. Fernando é nosso especialista em gestão de riscos / gerenciamento dos riscos e responsável pelo Fórum sobre Gerenciamento dos Riscos. Fernando foi o PMO responsável pela criação da seção Pergunte ao PMO.