Gerenciamento de Requisitos e suas Etapas (3 etapa)

Nesta terceira e última parte, trataremos da análise, documentação, verificação, validação, monitoramento e controle dos requisitos, e avaliação da solução. (Confira a parte 1 aqui e a 2 aqui)
Uma vez elicitados, os requisitos de um projeto devem ser analisados e documentados. Entre os fatores que contribuem para o sucesso dessa etapa, estão a utilização de pessoas qualificadas, a boa comunicação e a colaboração entre os participantes. Ao se analisar os requisitos elicitados, devem ser definidos atributos que permitam a classificação e posterior rastreamento dos requisitos ao longo do projeto. São exemplos de atributos comuns de requisitos: ​

-Data de criação 
-Fonte (parte interessada) 
-Dono (owner) 
- Prioridade 
- Versão 
- Status 
- Entrega ou Épico associados ao requisito 
- Critério de aceitação 
 Esses atributos devem ser documentados juntamente com a descrição do requisito num Registro de Requisitos, o que permitirá também sua rastreabilidade, como no exemplo abaixo: 
​

De particular importância é a utilização de um conjunto de status para os requisitos, o que auxiliará no acompanhamento do ciclo de vida do requisito ao longo do projeto, como no exemplo abaixo. 
 

​Uma documentação consistente de cada requisito permitirá um monitoramento adequado e a validação da solução entregue. Uma descrição de requisito bem formatada consiste dos seguintes elementos: 

- Condição (opcional) 
- Sujeito 
- Verbo ativo no futuro 
- Objeto 
- Regra de negócio (opcional) 
- Resultado (opcional) 
 
Exemplo: 

Quando o usuário clicar no novo botão “inserir conta” [condição], o sistema [sujeito] exibirá [verbo ativo no futuro] a nova tela de inserção de conta [objeto] permitindo a criação de uma nova conta [resultado]. 

No caso de projetos adaptativos onde se utilize o modelo de história de usuário, o formato será próprio: 

Como [Determinado stakeholder ou persona], quero [objetivo ou intenção] para poder [valor esperado]. 

Exemplo: 

Como gerente de portfólio, quero selecionar os projetos por departamento para poder tomar decisões de acordo com o perfil de cada departamento. 

Após a documentação, é necessário verificar os requisitos para garantir que estejam propriamente redigidos e livres de erros. Isso pode ser feito por meio de revisão de pares e inspeções. Uma verificação bem-sucedida requer que certas características de qualidade na descrição de requisitos sejam conhecidas e seguidas. As características a seguir estão presentes em requisitos bem escritos: 

• Não Ambíguo: O requisito tem um significado unívoco e é interpretado da mesma forma pela audiência pretendida. Exemplos: 

- Requisito ambíguo: Quando o empregado passar pelo leitor, o sistema identificará o empregado. 

- Requisito não ambíguo: Quando o empregado posicionar o dedo indicador de qualquer uma das mãos no sensor de leitura de digital, o sistema mostrará a foto do empregado no monitor. 

 

• Consistente. O requisito não contradiz nem duplica outros requisitos. Quando uma mesma entidade é citada em vários requisitos, as palavras utilizadas para se referir a ela devem ser as mesmas.

Exemplos: 

Linguagem inconsistente entre requisitos: 

3.2.1: O sistema de segurança deverá... 

12.4.6: O novo sistema de segurança deverá... 

17.5.3: O sistema de cartão de segurança deverá... 

25.3.7: O sistema de cartão de segurança de RF deverá... 


Linguagem consistente entre requisitos: 

3.2.1: O sistema de segurança deverá... 

12.4.6: O sistema de segurança deverá... 

17.5.3: O sistema de segurança deverá... 

25.3.7: O sistema de segurança deverá... 

1. Correto. O requisito representa corretamente a funcionalidade a ser construída conforme definida pela parte interessada ou por outra fonte de requisitos. 

 

1. Completo. O requisito inclui a informação necessária e condições válidas para que se desenhe, se construa e se teste a solução. Exemplos: 
   
   

 - Requisito incompleto: A sessão de login deve ser encerrada após o número de senhas incorretas ultrapassar o máximo permitido. ​  
 - Requisito completo: A sessão de login deve ser encerrada após três tentativas de senhas incorretas.   

1. Mensurável. O requisito pode ser comprovado ou verificado por meio de análise, teste, inspeção ou demonstração. Exemplos: 
   
   - Requisito não mensurável: A nova linha de produção deverá ser eficiente.   
   - Requisito mensurável: A nova linha de produção deverá produzir em média 5000 tampas de garrafa por dia. 

 

1. Viável. O requisito pode ser implantado respeitando-se as restrições conhecidas (por exemplo, custo e prazo) e as capacidades do ambiente (por exemplo, tecnologia e conhecimento da equipe). 

 

1. Rastreável. O requisito possui um identificador único, pode ser referenciado ao longo do seu ciclo de vida e rastreado em relação a outros elementos do projeto (fonte, entrega, épico, responsável etc.). 

Num ambiente adaptativo, onde os requisitos são tipicamente representados por histórias de usuário, o acrônimo INVEST pode ser aplicado para garantir a qualidade da descrição das histórias. O acrônimo é derivado das iniciais das seguintes palavras: 

1. Independente. A história de usuário deve ser autônoma, evitando a criação de dependências entre histórias de usuários. 

 

1. Negociável. A história de usuário deve estar sujeita a negociação em relação a seu conteúdo, prioridade, forma e função. 

​

1. Valiosa. A história de usuário deve definir características e funções que tragam valor para o negócio e contribuam com a solução de problemas ou captura de oportunidades. 

 

• Estimável. A história de usuário deve ser clara o suficiente para permitir a geração de uma estimativa válida ou proporcionar discussões que resultem numa tal estimativa. ​

• Simples (Small). A história de usuário deve ser pequena o suficiente para ser implantada numa única iteração. 

1. Testável. A história de usuário deve ser verificável de maneira independente. 

​
 
Com os requisitos documentados e verificados, é importante que se faça uma validação com quem gerou o requisito, para garantir que cada requisito reflita de maneira precisa a intenção da parte interessada. 

Tipicamente percorrem-se os requisitos documentados em conjunto com as partes interessadas para confirmar se os requisitos, conforme descritos, são válidos, e se entregarão o valor desejado. 

A etapa de monitoramento e controle dos requisitos pode ser dividida em certas funções realizadas de maneira iterativa ao longo do projeto para garantir que a documentação de requisitos continue válida. As funções do monitoramento e controle são apresentadas na figura abaixo: 
​

Definir Linha de Base de Requisitos. Uma vez que os requisitos e seus atributos associados tenham sido documentados e validados, é crítico que sejam aprovados. O conjunto de requisitos aprovados para um projeto formam a linha de base de requisitos. Quando se usa uma abordagem adaptativa, o processo de aprovação é iterativo e focado no planejamento de cada iteração com a definição de seu backlog. 
 
Monitorar Requisitos. O monitoramento dos requisitos consiste em acompanhar e manter atualizado o status de cada requisito ao longo do projeto. 
 
Gerenciar Mudanças nos Requisitos. O processo para gerenciar mudanças nos requisitos deve ser definido de antemão, ao se planejar o projeto. Gerenciar mudanças envolve seguir o processo definido para que os requisitos aprovados só sejam alterados se os protocolos de controle de mudança forem seguidos. No caso de métodos adaptativos, a flexibilidade é maior, e requisitos podem ser inseridos no backlog do produto e repriorizados para cada nova iteração. 
 
Documentar e Comunicar Resultados. A comunicação do status corrente dos requisitos do projeto deve ser feita periodicamente para as partes interessadas, o que ajudará a gerenciar as expectativas e a manter um bom nível de colaboração. 
 Uma vez que a solução é desenvolvida, é necessário que seja avaliada. A etapa de avaliação da solução determina quão bem a solução atende às necessidades das partes interessadas. 
A avaliação da solução é realizada geralmente ao final do ciclo de vida do projeto (em abordagens preditivas) ou ao final de cada iteração (em abordagens adaptativas) por meio de testes ou demonstrações do produto. 



Este artigo faz parte do Programa Esteiras de Gestão da Academia DC. Clique aqui, faça sua inscrição e acesse gratuitamente vários conteúdos online para aperfeiçoar suas habilidades gerenciais! 


Referências bibliográficas: 
BORGES, Carlos; MERIGUETTI, Cezar; ROLLIM, Fabiano; Gerenciamento de Projetos Aplicado. 2ª ed. Rio de Janeiro: DC, 2024 

PROJECT MANAGEMENT INSTITUTE. Requirements Management: A Practice Guide. Newton Square: PMI, 2016. 
 PROJECT MANAGEMENT INSTITUTE. Business Analysis for Practitioners: A Practice Guide. Newton Square: PMI, 2015.