Ícone do site Dicas PMP

Diferenciando Requisitos, Restrições e Premissas

Mauro Sotille

O que são os requisitos e qual a sua diferença em relação às restrições? Como determinar quais são as restrições de um projeto e quais são suas premissas? Essas são dúvidas usuais dos alunos dos cursos de gerenciamento de projetos da PM Tech®.

Requisitos mal definidos e incompletos estão entre as principais causas de falhas em projetos, uma vez que estes são a fundação do escopo do projeto e do produto e a base do orçamento, do cronograma e do planejamento da qualidade.

Nesse artigo busco esclarecer o que são os requisitos, as restrições e as premissas, explico as diferenças entre eles e comento sobre sua descrição, seja no em um documento próprio que as descreve,  seja no termo de abertura ou na especificação do escopo do projeto.

 

Requisitos

Os requisitos refletem as necessidades e as expectativas das partes interessadas no projeto, principalmente do cliente, incluindo as condições ou capacidades que estes desejam que sejam cumpridas pelo projeto ou estejam presentes no produto. Por exemplo, se um cliente necessita reduzir os custos de pós-venda, um dos requisitos pode ser de que o projeto inclua um sistema para diagnosticar problemas do produto remotamente.

O desenvolvimento dos requisitos inicia com a análise das informações contidas no termo de abertura, passa pela análise das partes interessadas e sai como resultado do processo “coletar requisitos”. Os requisitos devem ser analisados e registrados com detalhes suficientes para serem medidos, uma vez que vão ser a base para definir as alternativas de condução do projeto e se transformarão na fundação da EAP.

Alguns pontos importantes sobre requisitos:

Como garantir que tenhamos requisitos abrangentes e suficientes?

Cada requisito deve ter uma fonte ou origem (necessidade de negócio, cliente, legislação, etc.), um proprietário (alguém na equipe do projeto) e uma prioridade, baseada em seu impacto no projeto ou produto. Devem ser mensuráveis e testáveis. Sua descrição não pode ser ambígua (ou seja, devem ser escritos de uma forma que tenha apenas uma única interpretação). 

Restrições

As restrições são fatores internos e externos associados ao escopo do projeto que limitam as opções da equipe de gerenciamento do projeto. Em geral são requisitos obrigatórios, impostos pelo cliente ou pela organização executora, que são oriundos do registro de requisitos e são incluídos na declaração do escopo com destaque especial. Quando um projeto for realizado sob contrato, em geral as cláusulas contratuais também se constituirão em restrições.

Exemplos:

As restrições (e as premissas) são usualmente descritas em documento próprio, que contém as restrições e premissas, ou na especificação do escopo, saída do processo “definir o escopo” no Guia PMBOK®.

Premissas

Premissas são fatores associados ao escopo do projeto que, para fins de planejamento, são assumidos como verdadeiros, reais ou certos sem a necessidade de prova ou demonstração.

Note que “premissa” talvez não seja a melhor tradução do termo original em Inglês “assumption” (suposição, hipótese, conjectura, pressuposto, ideia ou teoria que assumimos como verdadeira, ainda que sem comprovação).

Para seguir adiante sem informação absoluta, nós necessitamos fazer suposições e temos de “assumir” que algumas coisas são verdadeiras. Nós assumimos que já que o dia está ensolarado, não vamos precisar levar um guarda-chuva para o trabalho. Que o ônibus vai sair em determinado horário, então vamos para a parada nesse horário. Se esperarmos toda a informação estar disponível, talvez nunca iniciemos o projeto. Tipicamente assumimos que os recursos vão estar disponíveis, que os usuários conhecem seu negócio e que os recursos financeiros estarão disponíveis.

Premissas presumem que o que você está planejando ou confiando é verdadeiro, real ou certo. Por exemplo, seu projeto pode exigir que alguém tenha habilidades especiais de programação do departamento de TI. Sua suposição é que essa pessoa estará disponível quando necessário e exercerá sua habilidade na atividade que você designar. Documente a suposição de que essa pessoa estará disponível quando necessário.

Frequentemente, as equipes de projetos validam as premissas como parte do seu processo de planejamento. Toda a premissa tem um risco associado, uma vez que a mesma pode não ser verdadeira e, ao mostrar-se falsa, pode causar um impacto no projeto. 

Suposições podem incluir qualquer um dos seguintes:

Dica: Em geral podemos descrever uma premissa iniciando a frase por “Parte-se do princípio que …” ou “Supõe-se que …”.

Exemplos:

Validando as premissas

Você desejará verificar e validar essas premissas ao longo do processo de Planejamento e sempre que necessário durante a Execução e Controle do projeto.
As  premissas devem ser examinadas, visando garantir que estes dados não sejam tendenciosos e possuam precisão.
Tomemos um exemplo: Imagine que você vai para a guerra. Qual o maior risco que você corre? Se você julga que o mais crítico é ser alvo da ação do inimigo, veja abaixo a estatística do Departamento de Defesa dos EUA:

Perdas do Exército dos EUA em Conflitos

II Guerra
1942-45		 Coréia
1950-53		 Vietnam
1965-72		 Iraque
1990-91
Acidentes 56%
1.007.704		 44%
77.108		 54%
270.608		 75%
1.406
Fogo Amigo 1%
15.839		 1%
1.943		 1%
4.678		 5%
86
Ação Inimiga 43%
776.105		 55%
97.198		 45%
229.239		 20%
366

Fonte: Departamento de Defesa (EUA)

Ou seja, historicamente os Americanos têm sofrido mais perdas de vidas humanas em acidentes do que pela ação do inimigo. Então não se deixe levar enganar por suposições equivocadas. As premissas identificadas devem ser testadas quanto à estabilidade da suposição e consequências no projeto se a premissa for falsa.
Claro que nem sempre os dados, ou sua fonte, são confiáveis. Desse modo, suposições alternativas, que possam ser verdadeiras, deverão ser identificadas e suas repercussões nos objetivos de projeto deverão ser testadas.

Termo de abertura vs. Especificação do Escopo

Note que, embora o termo de abertura e a especificação do escopo possam ter certo grau de redundância, ambos contendo requisitos para aprovação do projeto, estes são diferentes no nível de detalhe. As informações contidas na especificação de escopo devem ser detalhadas e progressivamente elaboradas. As informações contidas no termo de abertura podem ser de mais alto nível.

Sair da versão mobile