PD_Gerenciamento de riscos em requisitos

Prévia do material em texto

DENIZE PIMENTA 
É mestra em informática pela UNIRIO, tem MBA em Gerência de 
Projetos pela UFF, pós-graduada em Análise, Projeto e Gerência 
de Sistemas pela PUC-Rio, é bacharel em análise de sistemas pela 
UNESA, atua como Gerente de Produtos na Globo e é consultora 
de produtos digitais. Certificações: CFPS, IBM RMUC, IBM RUP, 
OMG UML Fundamental, CSPO, PMP, CSM, SAFe e PMI-ACP. 
 
 
 
Gerenciamento de Riscos em Requisitos 
Boas práticas na elicitação de sistemas 
 
 
 
Introdução ......................................................................................................................... 1 
Riscos no Processo de Especificação de Sistemas .................................................................... 2 
Resumo ........................................................................................................................... 19 
Referência........................................................................................................................ 20 
 
Introdução 
Este artigo analisa o que podemos fazer para minimizar problemas e melhorar o desempenho 
na elicitação de requisitos de software. É uma coletânea de sugestões e boas práticas para a 
Engenharia de Requisitos de Sistemas. De forma independente da metodologia adotada, este 
artigo identifica os problemas mais comuns e apresenta técnicas e ações que buscam 
maximizar oportunidades e reduzir ameaças. 
No seu dia-a-dia você encontra problemas como: 
• A visão e o escopo nunca são claramente definidos. 
• Clientes são muito ocupados para investir tempo identificando e definindo requisitos. 
• Requisitos existem na cabeça dos especialistas e nunca foram escritos, esmiuçados ou 
investigados. 
• Clientes afirmam que todos os requisitos são críticos e têm dificuldade em priorizar. 
• Desenvolvedores encontram dificuldades de entendimento e muitas vezes partem 
para a adivinhação. 
• As mudanças são constantes e dificultam a realização de um sistema útil. 
• O escopo aumenta com as mudanças, mas o prazo não é alterado e nenhuma 
funcionalidade é retirada. 
Í N D I C E 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 2 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
• Clientes ainda solicitam funcionalidades que nunca, ou raramente, são utilizadas na 
prática. 
• A especificação é atendida, mas o cliente não. 
• Demais perfis do ciclo de desenvolvimento, como testadores, desenvolvedores, e 
gerentes não conseguem utilizar o requisito para desempenhar sua função com 
perfeição. 
• Falta de envolvimento das pessoas certas para o levantamento dos requisitos e das 
regras do sistema. 
Se pelo menos 3 itens acima se encaixam na sua realidade, leia este artigo e busque aprender 
alternativas para melhorar a investigação e especificação de requisitos minimizando a 
probabilidade e impacto dos riscos negativos no seu projeto. 
 
Riscos no Processo de Especificação de Sistemas 
Estudos recentes elaborados pelo PMI e apresentados no Pulse of the Profession de 2022, 
revelam que nos fatores chave para o sucesso de projetos é apresentado em segundo lugar o 
baixo nível de ‘scope creep’, que é a mudança desordenada das requisições do sistema. 
Apresentando ainda a “obtenção de requisito imprecisa” como a principal causa de falhas em 
projetos. Muitas organizações ainda não têm maturidade em gerenciamento de requisitos e a 
gestão executiva e os patrocinadores não estão valorizando plenamente a importância da 
excelência nesta área. 
Este artigo trata dos riscos relacionados à Engenharia de Requisitos, para iniciar é necessário 
conceituar risco do projeto, que de acordo com o Guia PMBOK® é um evento ou condição 
incerta que, se ocorrer, provocará um efeito positivo ou negativo em um ou mais objetivos do 
projeto. Quando o impacto é positivo, o evento futuro é conhecido como oportunidade, 
quando ocasiona um impacto negativo o risco é chamado de ameaça. Para mais detalhes de 
conceito de risco leia o artigo Gerenciamento de Risco em Projetos (PIMENTA, 2019). 
Logo na introdução do livro, Mulcahy (2010) cita um exemplo de um temporal que ocorre na 
obra de construção de um supermercado e a área da construção sofre pequenos 
empoçamentos impedindo e atrasando o trabalho, mas os operários estão tranquilos e o 
gerente afirma ao cliente para não se preocupar que logo tudo estará resolvido, em seguida 
um helicóptero entra em ação, como em um filme, voando baixo e retirando as poças de água 
do local. O cliente ficou impressionado, pois tudo aconteceu “automaticamente”, sem 
necessidade de se fazer reuniões para decidir o que fazer para solucionar o problema; o 
gerente informou que tudo isto já havia sido acordado anteriormente, em suas reuniões de 
planejamento de risco. 
O Gerenciamento de Riscos ajuda a identificar e priorizar os riscos de forma preventiva, mas é 
preciso tratar os riscos de forma ativa buscando ações para minimizar o impacto ou a 
probabilidade de ocorrência das ameaças e maximizar as chances de ocorrerem 
oportunidades. Desta forma deixamos de trabalhar com o acaso e nos tornamos mais bem 
preparados para lidar com as adversidades do projeto. 
https://www.passeidireto.com/arquivo/94127706/gerenciamento-de-risco-em-projetos?q=%22gerenciamento%20de%20risco%20em%20projetos%22&tipo=1
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 3 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
É importante deixar claro que ameaças ou riscos negativos, são aqueles que ameaçam os 
objetivos do projeto e oportunidades ou riscos positivos são eventos futuros que podem 
contribuir para atingir os objetivos projeto. 
Dentro da engenharia de requisitos vários aspectos devem ser considerados para evitar que 
riscos comuns ameacem os objetivos do projeto e não deixar de aproveitar oportunidades e 
alavancar o projeto. 
Os requisitos de um sistema constituem a especificação das características e propriedades do 
sistema ou uma descrição do que o sistema deve fazer. Existem dois tipos de requisitos: 
funcionais e não-funcionais. De acordo com Wiegers (2003): “Os requisitos funcionais 
descrevem comportamentos observáveis do sistema, apresentando certas condições e 
permitindo ações dos usuários”. Enquanto que os requisitos não funcionais consistem em 
“acordos, condições, termos contratuais, padrões ou normas que o sistema deve atender, na 
descrição de interfaces externas e nas restrições de projeto e implementação”. 
A engenharia de requisitos é um processo que possui um conjunto estruturado de atividades 
destinadas a elicitar, analisar, documentar e validar requisitos. 
Vários nomes são utilizados para conceitos similares, foi adotado neste artigo o termo usuário 
que é o(s) responsável(is) por comunicar as necessidades em nome de todos que vão utilizar o 
sistema, também possui a responsabilidade de aprovar, tirar dúvidas da equipe do projeto, e 
homologar o sistema, também pode ser identificado como cliente ou representante do cliente, 
apesar de entendermos ter uma leve diferenciação nos conceitos. Analista, também conhecido 
como analista de requisitos ou analista de sistemas é quem faz o entendimento das 
necessidades dos usuários, é responsável pela investigação, mapeamento e comunicação das 
necessidades para a equipe, definindo o escopo do sistema. 
O processo inicial de identificação, levantamento, entendimento e especificação de requisitos 
envolvem um procedimento investigativo, por este motivo é utilizado o verbo elicitar. A 
análise é toda reflexão feita nos requisitos, pode ser em forma de diagramas, protótipos, 
modelos, enfim tudo que for necessário para entendimento das necessidades. A 
documentação é o detalhamento feito. A validação engloba revisões e inspeções internas e a 
revisão feita pela área usuária. 
É importante deixar claro qual o objetivo da documentação a ser elaborada, pois se for mera 
formalidade para entregar um artefato, todo esforço em melhorar o processo é em vão e não 
trará nenhuma melhoria. Se o requisitofizer parte do ciclo de desenvolvimento e for utilizado 
para implementação do software, então o mesmo precisa ser entendido, interpretado de uma 
única forma e útil para que todos consigam utilizar como insumo em suas tarefas. 
De acordo com o Guia PMBOK existem 6 (seis) processos para o gerenciamento de riscos nos 
projetos. São eles: 
• O primeiro processo do gerenciamento de riscos é o “Planejar o Gerenciamento dos 
Riscos” que define como abordar, planejar, executar e controlar os riscos do projeto – 
fornecendo a orientação de quais processos, procedimentos, ferramentas e técnicas 
deverão ser utilizados ao longo do projeto. Não é objetivo deste artigo descrever como 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 4 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
planejar ou realizar as análises dos riscos dos projetos. Vamos abordar neste texto a 
identificação dos riscos relacionados a requisitos e ações sugeridas para tratar os riscos 
identificados, elaborando um plano de resposta aos riscos. 
• O segundo processo do gerenciamento de riscos é o “Identificar os riscos” que tem por 
objetivo determinar os riscos que podem afetar o projeto. O principal produto é a 
documentação dos riscos por meio da elaboração de uma lista inicial de riscos, 
denominada registro dos riscos, que será atualizada e complementada nos demais 
processos. Neste processo mapeamos o que pode acontecer, com intuito de proteger 
e favorecer os objetivos do projeto, que na maioria das vezes estão relacionados a 
custo, tempo e escopo. 
 
Identificação dos Riscos em Requisitos de Sistemas 
Uma boa prática para se registrar os riscos durante às atividades de elicitação de requisitos é 
utilizarmos a declaração no formato CRE (Causa – Risco – Efeito). A leitura deve ser feita da 
seguinte forma: devido a <uma causa>, <um evento de risco> pode ocorrer, levando a <um 
efeito no projeto>. 
A seguir serão apresentados os riscos identificados separados por oportunidades e ameaças. 
Oportunidades: 
No. Categoria Causa Risco Efeito 
R001 RH 
Recurso com expertise em 
requisitos e negócio. 
Analista de requisito ter 
conhecimento do negócio. 
Agilidade e facilidade 
no entendimento das 
regras a serem 
estabelecidas. 
R002 Técnico 
Complexidade baixa do 
sistema. 
Ter muitos requisitos que tratam 
funcionalidades cadastrais, sem 
regras de negócio complexas 
(CRUD simples). 
Agilidade na 
construção do 
sistema 
R003 
Partes 
Interessadas 
Sensibilização da alta 
administração da empresa. 
Importância do projeto. 
Disponibilidade integral de um ou 
mais representantes do cliente. 
Agilidade na 
construção do 
sistema 
 
Ameaças: 
No. Categoria Causa Risco Efeito 
R004 
Partes 
Interessadas 
Falta de sensibilização e 
entendimento da alta 
administração da empresa. 
Representante(s) nomeado(s) não 
conhecer(em) o negócio que é 
abordado pelo projeto por 
completo. 
Retrabalho. 
R005 
Partes 
Interessadas 
Basear o levantamento de 
requisitos em apenas uma 
pessoa. 
Redefinição constante de requisitos Retrabalho 
R006 
Partes 
Interessadas 
Falta de sensibilização e 
entendimento da alta 
administração da empresa. 
Falta de interesse da área de 
negócio. 
Demora em obter 
requisitos. 
Retrabalho. 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 5 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
No. Categoria Causa Risco Efeito 
R007 Requisito 
Falta de uso de técnicas de 
elicitação 
Representante dos usuários com 
dificuldade em expressar suas 
necessidades 
Demora em obter 
requisitos. 
R008 Requisito 
Não identificação de 
necessidade. 
Descoberta tardia de 
funcionalidades 
Atraso; retrabalho 
R009 Requisito 
Identificação incompleta da 
necessidade 
Descoberta tardia de novas regras Retrabalho 
R010 Requisito Especificação não adequada 
Dificuldade de entendimento do 
requisito (para demais papéis do 
ciclo de desenvolvimento) 
Demora em tirar 
dúvidas e refazer e 
homologar o 
documento. 
R011 Requisito 
Analistas induzirem 
requisitos aos usuários 
Elicitar e desenvolver 
funcionalidades que não serão 
utilizadas, ou raramente serão 
utilizadas 
Perda de tempo e 
recursos em 
desenvolvimento de 
funcionalidades que 
não agreguem valor 
ao negócio. 
R012 Requisito 
Levantamento do requisito 
não deu ferramentas para 
visualizar o que seria o 
sistema. 
A especificação é atendida, mas o 
cliente não 
Retrabalho, demora 
na homologação do 
sistema, 
R013 Requisito 
Basear o levantamento de 
requisitos na pessoa que 
não possui o consenso de 
todos os usuários. 
Não aceitação do produto final. Retrabalho 
R014 Requisito Especificação não adequada 
O requisito dá margem a mais de 
uma interpretação. 
Retrabalho 
R015 Requisito 
Falta de uso de técnicas de 
elicitação 
Não abordagem de leis ou 
regulamentações que regem 
o assunto 
Definição de funcionalidades ou 
regras que transgridem alguma 
regulamentação. 
Retrabalho 
R016 Processo 
Processo da área de negócio 
mal definido 
Dificuldade em finalizar o 
levantamento. 
Atraso; retrabalho 
R017 Técnico Limitação da tecnologia. 
Especificar requisito inviável ou 
muito custoso de construir. 
Problemas no 
desenvolvimento ou 
adequações nos 
requisitos 
tardiamente. 
R018 Gerencial 
Restrição de custo ou 
recurso. 
Compartilhamento não planejado 
de recurso do projeto 
Demora na 
elaboração e 
conclusão dos 
requisitos. 
R019 Requisito 
Analista de requisito não 
conhece sistemas legados 
Elicitação de funcionalidades já 
desenvolvidas por outros sistemas. 
Perda de tempo e 
recursos em 
desenvolvimento de 
funcionalidades que 
não serão utilizadas. 
R020 Requisito 
Falta de entendimento e 
mapeamento dos requisitos. 
Especificação de requisito que 
afeta outro já homologado. 
Retrabalho 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 6 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
No. Categoria Causa Risco Efeito 
R021 Técnico 
Falta de ferramenta de 
repositório para o projeto. 
Perder arquivos contendo artefatos 
de requisitos. 
Retrabalho 
R022 Externa Doença 
Ausência do analista de requisitos 
ou representante do cliente. 
Paralisação do 
projeto; demora no 
engajamento de outro 
recurso para assumir 
atividades. 
R023 Externa Doença; Demissão; Saída do analista ou usuário 
Paralisação do 
projeto; demora no 
engajamento de outro 
recurso para assumir 
atividades. 
R024 Requisito 
Falta de uso de técnicas de 
elicitação 
Requisito não está completo Retrabalho 
 
O próximo processo na área de conhecimento de gerenciamento de riscos é o “Realizar a 
Análise Qualitativa dos Riscos”, que visa obter uma lista priorizada de riscos do projeto. Neste 
processo os riscos são analisados sob as perspectivas de probabilidade (chance de o evento de 
riscos ocorrer) e impacto (efeito das consequências caso o risco ocorra). Esta é uma análise 
subjetiva dos riscos, sem se preocupar em quantificá-los. Normalmente são estabelecidas 
escalas de probabilidade e impacto baseadas em critérios qualitativos associados a um 
número. Exemplo: Muito baixo (1), baixo (3), médio (5), alto (7) e muito alto (9). Pode ser 
utilizada também uma matriz de probabilidade e impacto, a fim de facilitar a análise visual. 
Após a análise de cada risco e a associação de sua probabilidade e impacto, multiplicamos os 
valores de P x I, obtendo escore do risco, feito isso basto ordenar os riscos em ordem 
decrescente que teremos uma lista priorizada dos riscos do projeto. 
Após este processo, o próximo é o “Realizar a Análise Quantitativa dos Riscos”. Este processo 
tem por objetivo analisarmos numericamente os riscos e elaborarmos uma lista quantificada 
dos riscos do projeto. Esta análise é realizada apenas para os riscos que foram selecionados no 
processo anterior. Esta é uma análise muito mais complexa e só se justifica para projetos 
muito grandes, com valor significativamente alto em investimento e com duração muito longa. 
A definição se esta análisedeve ser realizada faz parte do plano de gerenciamento de riscos do 
projeto, elaborado ao final do primeiro processo que descrevemos. Algumas das técnicas 
possíveis de serem utilizadas nesta análise são: análise de sensibilidade, análise do valor 
monetário esperado (VME), árvore de decisão e modelagem e simulação, em especial o 
método de Monte Carlo. 
Considerando que os riscos dependem muito de projeto para projeto, e de organização para 
organização, a lista dos riscos identificados neste trabalho foi sintetizada, sendo genérica e 
contendo apenas eventos que podem ocorrer em qualquer projeto. O que seria prioritário e 
urgente tratar em um projeto pode não ser para outro, portanto os processos de análise 
qualitativa e quantitativa não foram abordados de forma prática neste artigo. 
O próximo processo é o “Planejar as Respostas aos Riscos”, que tem por objetivo identificar as 
opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do 
projeto. 
 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 7 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
Neste processo, somente elaboramos resposta para os riscos selecionados da lista priorizada 
resultante dos processos de análise. Como não realizamos a análise qualitativa, 
consideraremos que todos os riscos supra listados são prioritários e precisam ter suas 
respostas identificadas. 
As estratégias que podemos utilizar para tratar as oportunidades e ameaças são: 
Ameaças 
Estratégia Descrição 
Prevenir Eliminar o risco, evitando-o totalmente. 
Mitigar Reduzir a probabilidade e/ou o impacto do risco. 
Transferir Passar o custo da consequência para um terceiro. 
Aceitar 
Ativa: planejar ações (Plano de Contingência) e estabelecer uma 
Reserva de Contingência (tempo, dinheiro ou recursos) para lidar com 
os riscos quando eles ocorrerem. 
Passiva: não faz nada, só documenta e lida com o problema se ocorrer 
(Ação de Contorno). 
 
Oportunidades 
Estratégia Descrição 
Explorar Eliminar a incerteza de um risco fazendo com que a oportunidade 
aconteça. 
Melhorar Aumentar as probabilidades e/ou impactos através da maximização 
dos principais acionadores deste risco. 
Compartilhar Atribuir a propriedade a terceiros para que possam capturar melhor a 
oportunidade. 
Aceitar Passiva: não faz nada, lida com o risco quando ocorrer. 
 
Ações Práticas 
Os riscos apresentados anteriormente foram analisados e algumas ações são sugeridas, 
conforme a tabela a seguir e explicados um a um mais adiante no texto. 
 
No. Risco Estratégia Gatilho 
Responsável 
pela ação 
Ação 
R001 
Analista de requisito 
ter conhecimento do 
negócio. 
Melhorar Início do projeto Gerente 
Procurar recurso na 
empresa com expertise 
em requisitos e negócio. 
Melhorar 
Caso não haja 
recurso na empresa 
para completar o 
quadro da equipe 
Gerente 
Contratar recurso na 
empresa com expertise 
em requisitos e negócio. 
R002 
Ter muitos requisitos 
que tratam 
funcionalidades 
cadastrais, sem regras 
de negócio complexas 
Melhorar 
Quando finalizar a 
identificação de 
requisitos 
Qualidade 
Melhorar Impacto: 
definir forma e buscar 
acordo de como 
especificar requisitos 
CRUD simples. Por 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 8 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
No. Risco Estratégia Gatilho 
Responsável 
pela ação 
Ação 
(CRUD simples). exemplo não fazer 
protótipo, não fazer 
especificação de caso 
de uso. 
R003 
Disponibilidade 
integral de um ou mais 
representantes do 
cliente. 
Melhorar 
Na reunião de início 
do projeto 
Gerente 
Sensibilizar os 
envolvidos da 
importância da 
participação ativa do 
cliente. 
R004 
Representante(s) 
nomeado(s) não 
conhecer(em) o 
negócio que é 
abordado pelo projeto 
por completo. 
Mitigar 
Nas reuniões de 
levantamento 
Analista e 
Gerente 
O analista deve avisar 
ao gerente que dúvidas 
não estão sendo 
respondidas pelo 
usuário nomeado. 
O gerente por sua vez 
deve convocar reunião 
com comitê do projeto 
ou alta administração 
da empresa para ações 
cabíveis, como colocar 
mais um usuário 
participando, 
estabelecer um grupo 
de trabalho, substituir o 
usuário nomeado. 
R005 
Redefinição constante 
de requisitos 
Mitigar Iniciação do projeto Gerente 
Estabelecer processo 
de validação por todos 
os usuários, visando 
não ter dependência 
apenas de uma pessoa. 
R006 
Falta de interesse da 
área de negócio. 
Mitigar Iniciação do projeto Gerente 
Agendar reunião prévia 
com a alta 
administração da 
empresa e clientes para 
sensibilizar a 
importância da 
elicitação de requisitos 
Aceitação 
Ativa 
3 faltas seguidas ou 
desmarcações de 
reuniões 
Gerente 
Agendar reunião com 
alta administração e 
clientes para avaliar 
paralisação do projeto. 
R007 
Representante dos 
usuários com 
dificuldade em 
expressar suas 
necessidades 
Aceitação 
Ativa 
Após a primeira 
reunião de 
levantamento com 
sinalização de falta 
de entendimento 
Analista 
Utilizar workshop para 
envolver mais pessoas 
da área. 
Mitigar 
Após o 
levantamento do 
requisito. 
Analista 
Utilizar storyboard ou 
protótipo para que os 
usuários tomem 
conhecimento do 
sistema que está sendo 
construído. 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 9 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
No. Risco Estratégia Gatilho 
Responsável 
pela ação 
Ação 
Aceitação 
Ativa 
Após a primeira 
reunião de 
levantamento com 
sinalização de falta 
de entendimento 
Gerente 
Estabelecer tarefas 
para mapear processo 
do negócio antes de 
requisito do sistema 
R008 
Descoberta tardia de 
funcionalidades 
Mitigar 
Ao final do 
levantamento de 
cada módulo 
Analista 
Fazer workshop com 
todos os usuários 
apresentando o 
protótipo. 
R009 
Descoberta tardia de 
novas regras 
Mitigar 
Ao final do 
levantamento de 
cada requisito, mas 
antes da 
homologação do 
mesmo pelo 
usuário. 
Usuário 
Fazer testes de 
aceitação do usuário. 
R010 
Dificuldade de 
entendimento do 
requisito (para demais 
papéis do ciclo de 
desenvolvimento) 
Mitigar 
Ao final do 
levantamento de 
cada requisito, mas 
antes da 
homologação do 
mesmo pelo 
usuário. 
Analista 
Fazer com que todos 
que utilizarão o requisito 
como insumo (AD, 
desenvolvedor, analista 
de teste) façam 
inspeção do requisito. 
Mitigar Planejamento Gerente 
Fazer planejamento 
adequado para 
comportar reuniões, 
ajustes nos 
documentos, revisões e 
homologação. 
R011 
Elicitar e desenvolver 
funcionalidades que 
não serão utilizadas, 
ou raramente serão 
utilizadas 
Mitigar 
Ao final do 
levantamento 
preliminar (obtenha 
a lista de requisitos) 
Analista 
Fazer uma lista 
priorizada de requisitos 
do ponto de vista do 
negócio. Fazer entregas 
parciais e caso a parte 
final da lista não seja 
interessante ou não 
tenha tempo para 
desenvolver, requisitos 
podem ser cortados 
R012 
A especificação é 
atendida, mas o 
cliente não 
Já está sendo tratado na ação do R009 
R013 
Não aceitação do 
produto final. 
Já está sendo tratado nas ações do R009 e R010 
R014 
O requisito dá margem 
a mais de uma 
interpretação. 
Já está sendo tratado nas ações do R010 
R015 
Definição de 
funcionalidades ou 
regras que 
transgridem alguma 
regulamentação. 
Mitigar 
Na reunião de início 
do projeto 
Gerente 
Obter informações 
sobre legislação e 
órgãos reguladores que 
regem e legisla a área 
de negócio. 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 10 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
No. Risco Estratégia Gatilho 
Responsável 
pela ação 
Ação 
Mitigar 
Antes do início das 
reuniões de 
levantamento 
Analista 
Fazer pesquisa e 
levantar sistemas 
concorrentes no 
mercado, legislação que 
regule o assunto, 
normativos internos, 
etc. 
R016 
Dificuldade em 
finalizar o 
levantamento. 
Aceitar 
O analista identifica 
que cada usuário 
atua de forma 
distinta, ou com 
regras próprias, não 
havendo 
padronizaçãode 
processo de 
trabalho da área. 
Gerente 
Paralisar o projeto ou 
mudar o escopo do 
mesmo para mapear 
processo do negócio 
antes de requisito do 
sistema. Fazer reuniões 
de alinhamento e 
escalar para o 
patrocinador se for o 
caso. 
Mitigar 
Durante o 
planejamento 
Gerente 
Fazer planejamento 
contendo mapeamento 
e estruturação dos 
processos de negócio 
antes da análise de 
requisito de sistema. 
R017 
Especificar requisito 
inviável ou muito 
custoso de construir. 
Mitigar 
Após mobilização da 
equipe 
Qualidade 
Apresentar a equipe os 
componentes prontos 
que devem ser 
reutilizados. 
Mitigar 
Durante o 
levantamento e 
especificação de 
requisitos 
Analista 
Toda e qualquer dúvida 
de tecnologia discutir 
com o arquiteto do 
projeto. 
Mitigar 
Durante o 
levantamento e 
especificação de 
requisitos 
Analista 
Evitar mapear solução, 
focando apenas na 
necessidade. 
R018 
Compartilhamento não 
planejado de recurso 
do projeto 
Mitigar 
Na reunião de início 
do projeto 
Gerente 
Sensibilizar a alta 
administração da 
empresa para que a 
equipe não seja 
interrompida e fique 
comprometida apenas 
com o projeto, caso 
contrário o 
planejamento não será 
cumprido 
R019 
Elicitação de 
funcionalidades já 
desenvolvidas por 
outros sistemas. 
Mitigar Planejamento Gerente 
Mobilizar profissional 
com experiências 
anteriores no cliente. 
Mitigar 
Ao término da 
identificação 
preliminar de 
requisitos 
Analista 
Apresentação do 
projeto aos principais 
envolvidos 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 11 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
No. Risco Estratégia Gatilho 
Responsável 
pela ação 
Ação 
R020 
Especificação de 
requisito que afeta 
outro já homologado. 
Mitigar Planejamento Gerente 
Estabelecer matriz de 
rastreabilidade de 
requisitos e priorizar os 
requisitos que estão 
associados a riscos (o 
gerente não faz a ação 
sozinho, mas é o 
responsável por 
conduzir a equipe em 
reuniões de 
identificação de riscos 
de integração, por 
exemplo). 
R021 
Perder arquivos 
contendo artefatos de 
requisitos. 
Mitigar 
No início do 
planejamento 
Qualidade 
Criar o repositório do 
projeto e instruir a 
equipe de como utilizar 
o mesmo. 
R022 
Ausência do analista 
de requisitos ou 
representante do 
cliente. 
Aceitar 
Quando houver 
comunicação de 
licença médica 
Gerente 
Solicitar e mobilizar 
recurso. 
Mitigar Planejamento Gerente 
Planejar trabalho em 
pares 
R023 
Saída do analista ou 
usuário 
Já está sendo tratado na ação do R022 
R024 
Requisito não está 
completo 
Já está sendo tratado nas ações do R009 e R010 
Mitigar 
Ao término da 
identificação 
preliminar de 
requisitos 
Analista 
Fazer a análise de 
requisitos, construindo 
diagramas lógicos para 
representação do 
sistema. 
 
 
A fim de facilitar, foram estabelecidas respostas genéricas agrupadas aos riscos associados: 
 
Ação 1 – Buscar analistas com conhecimento do negócio 
R001 - Analista de requisito ter conhecimento do negócio 
É interessante buscar profissionais que já conheçam do assunto a ser tratado no projeto, em 
contratação no mercado de trabalho ou dentro da própria empresa. Esta ação é de 
responsabilidade do gerente do projeto a ser feita logo no início do trabalho, quando estiver 
planejando os recursos. 
 
Ação 2 – Definir como serão especificados os requisitos do projeto 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 12 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
 
R002 - Ter muitos requisitos que tratam funcionalidades cadastrais, sem regras de negócio 
complexas (CRUD simples) 
Será que todos os requisitos e funcionalidades precisam ser especificados com todo o conjunto 
de documentos estabelecidos, como protótipo, especificação de interface, especificação 
funcional e outros? 
A sugestão é buscar funcionalidades simples, como manutenção dos dados de tipo de 
documento, localidade, tipo de logradouro, ou qualquer cadastro simples, com 
funcionalidades de inclusão, alteração, exclusão e consulta que não haja regra, ou 
complexidade, podemos buscar uma forma mais leve de especificar estas necessidades, ou até 
mesmo deixar de especificar o detalhe. Buscando uma forma de diferenciar de outras 
funcionalidades mais complexas como Gerar Folha de Pagamento dos Funcionários, por 
exemplo, com todos os cálculos, cenários e regras específicas. É importante deixar claro que 
estas são funcionalidades de menor complexidade, mas ainda de relevância para o sistema. 
Esta ação é para o gerente do projeto e analista de requisitos negociarem junto com a área da 
qualidade, caso haja, logo no início do projeto a fim de estabelecer práticas para agilizar a 
especificação de requisitos. Pode ser realizada após a identificação preliminar de requisitos, 
identificando na lista elaborada quais não terão especificação detalhada e qual a forma a ser 
utilizada para especificação. 
A não especificação de requisito pode levar a alguns riscos secundários, que são: deixar de 
especificar algo que não seja simples quanto parecia. Riscos secundários são aqueles que 
surgem após a implementação de uma resposta a um determinado risco. Sempre que planejar 
respostas a riscos, deve se avaliar a possibilidade dessa resposta gerar riscos secundários, e 
garantir que seja feita a identificação, análise e planejamento de respostas também para estes 
riscos. 
No exemplo seguido para mitigar a probabilidade de ocorrer a falta de especificação ou o 
esquecimento de desenvolvimento será adotado fazer a especificação de caso de uso, mas não 
o protótipo e nem a especificação de interface de requisitos identificados como simples logo 
no início do projeto. 
 
Ação 3 – Definir usuários com perfis adequados e promover a participação ativa no projeto 
R003 - Disponibilidade integral de um ou mais usuários 
R004 - Representante(s) nomeado(s) não conhecer(em) o negócio abordado pelo projeto por 
completo 
R005 - Saída do usuário e consequente redefinição de requisitos 
R006 - Falta de interesse da área de negócio 
R008 - Descoberta tardia de funcionalidades 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 13 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
A definição do interlocutor dos usuários para a especificação do projeto é crucial, às vezes 
colocar a definição de requisitos na mão de uma pessoa é tão arriscado que torna-se 
obrigatória a sensibilização de todos os principais envolvidos na escolha e disponibilidade 
desta pessoa. Não podemos permitir que esta decisão seja tomada, por exemplo, de acordo 
com a disponibilidade dos recursos do setor, ou seja, quem tiver tempo livre vai a reunião do 
projeto. 
É importante ter alguém acompanhando de perto desde o início, de preferência com 
disponibilidade integral para que todos os pequenos problemas sejam descobertos logo de 
início e sejam tratados a tempo. 
É importante também estabelecer tarefas intermediárias que reúnam todos os usuários, ou 
um grupo maior, para validar o caminho percorrido, evitando descoberta tardia de problemas. 
É interessante até que o próprio usuário apresente a solução aos demais usuários, o analista 
participa fazendo alguns comentários e anotações para melhorias. 
Esta ação é de responsabilidade do gerente do projeto desde o início do trabalho, para 
estabelecer a importância e criticidade do projeto junto aos usuários e seus superiores, 
sensibilizando que a etapa de requisitos não pode ser jogada de lado ou tratada com menor 
importância, pois significa a construção de ferramenta para uso de todos. Se for mal 
especificada a área terá problemas no ciclo de vida da ferramenta, dificuldade de adaptação à 
ferramenta, dentre outros. O monitoramento da participação efetiva dos usuários nomeados 
também é ação do gerente e deve ser feita ao longo de todo ciclo de desenvolvimento, desde 
levantamento de requisitos até a homologação do sistema, pois todo momento a participação 
do usuário é importante.Como Contingência, podemos definir que caso haja algum problema no projeto com um 
usuário chave, que por exemplo, tenha frequentes ausências em reuniões ou atrasos na 
avaliação de material, o gerente de projeto deve avisar ao comitê do projeto ou a alta 
administração da empresa para que sejam tomadas ações cabíveis, podendo chegar, se for o 
caso, a paralisação ou cancelamento do projeto. 
 
Ação 4 – Estabelecer técnicas de elicitação e análise de requisitos de sistemas 
R007 - Representante dos usuários com dificuldade em expressar suas necessidades 
R008 - Descoberta tardia de funcionalidades 
R009 - Descoberta tardia de novas regras 
R012 - A especificação é atendida, mas o cliente não 
R013 - Não aceitação do produto final 
R015 - Definição de funcionalidades ou regras que transgridem alguma regulamentação 
R016 - Dificuldade em finalizar o levantamento 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 14 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
R024 - Requisito não está completo 
Antes de mapear as funcionalidades do sistema é preciso entender se o processo de negócio 
está estabelecido nas áreas usuárias, por exemplo, ao desenvolver sistema para um banco é 
descoberto que cada agência funciona de forma diferente para conceder empréstimo aos 
correntistas, quem está certo? qual o sistema a ser desenvolvido? O mapeamento de 
processos da área de negócio pode ou não ser escopo do projeto, o gerente de projeto deve se 
certificar que há padronização de processos para tomar esta decisão. 
 
Para atacar ativamente estes riscos o gerente de projeto precisa ter a certeza que os principais 
envolvidos estão participativos e o negócio está estabelecido e o analista de requisitos precisa 
conhecer as técnicas de elicitação, independentemente do método de desenvolvimento a ser 
utilizado: tradicional (cascata ou waterfall), processo unificado ou métodos ágeis - todos 
precisam das técnicas de investigação de requisitos. Algumas das principais técnicas de 
elicitação de requisitos são: 
Pesquisa Consiste na busca por informações de um determinado assunto. “busca, indagação, 
inquirição ou investigação”. Podem existir sistemas semelhantes no mercado, quais 
funcionalidades eles têm? Será que a empresa possui algum normativo a respeito? Existe 
alguma legislação sobre o assunto? É crucial que o sistema reflita a legislação que regule o 
assunto, caso contrário, você pode ser conivente com um crime. 
• Vantagens: É uma forma de preparação do analista; é simples e barata. 
• Desvantagens: Somente a pesquisa não é suficiente para a captação das necessidades 
dos usuários. Cuidado com fontes enganosas, pergunte aos usuários qual material 
pode ser utilizado como insumo para entendimento inicial. 
 
Seminário também chamado de “Workshop” e ou dinâmica de grupo, consiste na realização de 
uma reunião planejada com pessoas chave de diversas áreas, com o objetivo em comum, por 
exemplo, de planejar o novo sistema (fechar escopo, detalhar ou aprovar requisitos). O 
workshop de requisitos fornece um framework para aplicar as outras técnicas de identificação 
como, por exemplo, brainstorming, encenação, e revisão dos requisitos existentes. 
• Vantagens: Consenso imediato; Melhor Custo/Benefício. 
• Desvantagens: Pessoas devem estar disponíveis, às vezes pode ser complicado reunir 
todos os principais envolvidos em uma única reunião, nem todos têm agenda, surgem 
imprevistos, a sala pode ficar apertada. 
 
Entrevista técnica recomendável para levantamento de informações passíveis de reflexão. É 
uma forma de levantamento de situação, que conduz as pessoas entrevistadas a darem 
informações sobre determinado assunto, situação, problema ou fenômeno, mediante a 
inquisição planejada sobre os aspectos e dimensões do objeto da pesquisa. O papel do 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 15 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
entrevistador é escutar tudo que o entrevistado disser. Posteriormente deverá ser analisada a 
informação levantada e comparada com o resultado de outras entrevistas. Pode haver 
opiniões divergentes. As pessoas têm percepções diferenciadas. 
• Vantagens: Na entrevista há o contato direto com o usuário, o que possibilita com que 
ele se sinta parte envolvida do processo de desenvolvimento. Há a validação do 
trabalho de forma imediata, é importante após a entrevista repetir todo o 
entendimento para que o usuário realmente faça a validação do que foi dito e 
entendido. 
• Desvantagens: É mais demorado, pois deve ser conversado com os representantes 
individualmente, pode haver informações contrárias, o que pode acarretar em outras 
entrevistas não planejadas anteriormente. 
 
Prototipação o protótipo é a casca do sistema, podemos utilizar o protótipo para diversos fins, 
como por exemplo, validar a interface do usuário. É também uma técnica muito utilizada para 
demonstrar os requisitos funcionais em um modelo do que será o sistema possibilitando a 
materialização e entendimento do que será o sistema para os usuários. 
• Vantagens: Visualização do que será o sistema (modelo) mais cedo; Melhor 
entendimento dos envolvidos; Minimiza riscos futuros. 
• Desvantagens: Precisa de Programador mais cedo, Frustrar expectativas dos 
envolvidos, Perda de tempo em padrão visual. 
 
Alguns riscos secundários devem ser observados, como o usuário acreditar que o sistema está 
pronto e criar expectativas frustradas com esta demonstração. Outro ponto é não deixar claro 
o objetivo do que se quer com esta técnica e perder tempo com validação de interface, por 
exemplo. 
Alternativas mais baratas ao protótipo são: storyboard e wireframe, que ao invés de 
codificação das telas navegáveis, visam apenas o desenho dessas telas para validar 
entendimento. 
Storyboard é o desenho das telas, mostrando o passo a passo para realizar uma determinada 
ação no sistema, aqui não há padrão visual, navegação e nem padrão ergonômico (para 
acessibilidade ou usabilidade). O objetivo é validar a (existência) funcionalidade do novo 
sistema. Desta forma há a validação do entendimento do problema através da primeira 
materialização da solução. 
Fazer testes de aceitação do usuário – solicitar aos usuários que imaginem quando estiverem 
recebendo o sistema pronto (pode ser após a validação do protótipo) qual o tipo de validação 
deve ser feita para aceitar o produto que está recebendo. Deixe que os usuários criem uma 
lista de critérios para esta validação, neste momento novas regras podem surgir. 
 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 16 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
Após a identificação e especificação de requisitos é preciso pensar no desenvolvimento, neste 
momento alguns ajustes nos requisitos podem surgir. Por exemplo, ao validar o modelo de 
dados foi identificado que para excluir um cliente todas as compras deste cliente deveriam ser 
excluídas também. Outros diagramas podem auxiliar a especificação de requisitos, como 
diagrama de atividades, diagrama de estados, dentre outros. 
O gerente de projeto pode buscar treinamento para os analistas da equipe para tomarem 
conhecimento das técnicas de elicitação citadas acima. 
O gerenciamento eficaz de requisitos gera baseline dos requisitos aprovados para 
proporcionar o controle de mudanças. 
 
Ação 5 – Estabelecer revisões dos requisitos 
R010 - Dificuldade de entendimento e uso do requisito 
R014 - O requisito dá margem a mais de uma interpretação 
R017 - Especificar requisito inviável ou muito custoso de construir 
R019 - Elicitação de funcionalidades já desenvolvidas por outros sistemas 
R024 - Requisito não está completo 
 
A falta de tempo para a especificação e mapeamento adequado das necessidades pode gerar 
documentos pobres e desentendimentos posteriores, para evitar isto o analista deve buscar a 
qualidade e confirmação do entendimento com todos os envolvidos, principalmente do cliente 
e tambémdos demais profissionais que participam do desenvolvimento e que irão utilizar o 
requisito como insumo de suas atividades. 
O gerente de projetos deve elaborar um planejamento adequado das tarefas, mas como não 
há bola de cristal um requisito estimado por todos como simples pode ter complexidade 
elevada no decorrer do seu levantamento, fazendo com que o gerente tenha que atuar no 
monitoramento e controle colocando outros colaboradores para revisão dos requisitos, 
colocando tarefas em paralelo, dentro do possível, etc. O que não podemos admitir é partir de 
estimativa irreal, caso o analista já tenha entendimento que o levantamento vai custar mais 
tempo do que o previsto ele deve imediatamente avisar ao gerente para que tome as medidas 
cabíveis. 
O framework Scrum define uma cerimônia, Planejamento da Sprint, no início de cada pequeno 
ciclo de desenvolvimento (Sprint) para que haja entendimento da equipe sobre quais 
requisitos / histórias de usuários serão implementadas (O que será feito), assim como as 
tarefas necessárias para implementação (Como será feito). A fim de facilitar a identificação da 
estimativa de esforço / complexidade, utilizam uma técnica denominada “Planning Poker”, que 
consiste de um baralho de 10 cartas para cada jogador, baseada na sequência de Fibonacci, 
onde após a leitura da história por um facilitador, os membros da equipe selecionam a carta 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 17 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
que corresponde ao seu entendimento sobre o esforço de desenvolvimento pra a história. 
Caso o entendimento seja diferente, tamanhos diferentes o surgirão na votação, levando à 
conversação e diálogo sobre as divergências apresentadas; repetindo sucessivamente as 
rodadas, de forma que todos cheguem a um consenso do entendimento do trabalho a ser feito 
e a sua complexidade. 
As inspeções têm o objetivo de agregar qualidade nos artefatos do projeto, portanto devem 
ser bem aceitas pelo profissional que elabora o documento, que deve entender que toda 
dúvida, ou sugestão feita para a documentação deve servir como motivador para melhorar seu 
documento. 
Caso o analista que faz o levantamento de requisitos não seja o responsável pela construção 
do sistema e como o requisito é insumo para o desenvolvimento é preciso: 
• Ter certeza que não está sendo mapeada a solução e sim a necessidade; e 
• Definir de antemão que o requisito é viável tecnicamente ou se há outra alternativa 
possível, mas econômica, de melhor usabilidade, mais rápida construção, etc. 
Portanto é importante estabelecer um canal de comunicação entre o analista e o arquiteto 
para que antes de ter um requisito homologado e difícil para o desenvolvimento, propostas 
possam entrar e facilitar o trabalho futuro. 
Alguns preparativos podem ser feitos antes mesmo da execução do projeto, em especial no 
início do planejamento, tais como: 
• a elaboração de checklist para verificação de requisitos, buscando a padronização das 
revisões feitas pelas equipes. 
• estabelecer processo de revisões por pares dentro da própria equipe, por exemplo 
outro analista de requisitos. 
• estabelecer processo de revisão pelos principais afetados na equipe, por exemplo, AD, 
desenvolvedor e analista de teste. 
O Guia PMBOK descreve um processo denominado “Planejar o Gerenciamento do Escopo” que 
abrange todas estas atividades e procedimentos. 
Os usuários também devem fazer revisão dos requisitos, pode ser que uma reunião para iniciar 
o trabalho seja interessante para mostrar qual o trabalho a ser feito, pois todos os 
documentos em conjunto formam os requisitos do sistema. Após a revisão do cliente obtém-se 
a aprovação dos requisitos e se estabelece a baseline do projeto. 
Funcionalidades de controle de acesso, por exemplo, podem já estar desenvolvidas e 
implantadas por outro sistema, tornando desnecessário o trabalho duplicado em outro 
sistema e a interface com o mesmo obrigatória. Desta forma é interessante ter profissionais 
que já conheçam os sistemas legados da empresa, caso seja possível. De qualquer forma é 
importante que ao final da identificação prévia dos requisitos do sistema o analista faça uma 
apresentação do que é o novo sistema a ser desenvolvido para todos os envolvidos que 
herdarão o sistema para sustentação. 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 18 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
Ação 6 – Priorize o desenvolvimento pela importância e riscos dos requisitos 
R011 - Elicitar e desenvolver funcionalidades nunca utilizadas na prática 
R020 - Especificação de requisito que afeta outro já homologado. 
 
Nunca invente ou sugira necessidades, apenas as identifique e especifique junto aos usuários. 
Também não forneça ou entregue mais do que foi definido no escopo do projeto (Gold 
Plating), pois de acordo com o PMI esta não é uma boa prática de gerenciamento de projeto. 
Outra forma de conter requisitos que não serão utilizados é priorizar os mesmos, deixando os 
de menor importância para desenvolvimento em momento oportuno ou até não 
desenvolvendo, cortando escopo do projeto. Algumas técnicas podem ser utilizadas para 
priorização de requisitos, são elas: 
• Monopoly Money: distribuir quantia de dinheiro (falso, de brinquedo) aos usuários e 
solicitar que os mesmos distribuam a quantidade limitada (20% do total de requisitos) 
de recursos na lista de requisitos. 
• MoSCoW: separar os requisitos pelas categorias Must (tem que ter), Should (deveria 
ter), Could (poderia ter) ou Would (interessante ter). Devemos executar primeiro todos 
os requisitos Must, isto é, são os itens de primeira necessidade. Quando não existirem 
mais requisitos Must, devem ser realizados os requisitos Should e assim por diante, até 
o término de todos os requisitos que o projeto possui. 
• Lista priorizada: Estabelecer a lista de requisitos em ordem numérica crescente, ao 
invés de categorias subjetivas como importância alta, média ou baixa, pois a tendência 
é colocar todos os requisitos de prioridade alta. 
 
O detalhamento de um requisito pode afetar outro, desta forma é indicado buscar especificar 
requisitos independentes. A priorização de requisitos tem foco principal na informação dos 
usuários, mas devido a algum risco a equipe do projeto pode solicitar a priorização de algum 
requisito. Riscos de tecnologia, integração ou qualquer outro. Portanto na utilização das 
técnicas descritas acima envolva também a equipe do projeto. 
É importante mencionar que a responsabilidade de mapear os riscos é do gerente do projeto, 
mas é impossível identificar todos os riscos do projeto sozinho. O gerente deve reunir a equipe 
e usuários para identificação de riscos. 
Ação 7 – Eliminar os impedimentos do projeto 
R018 - Compartilhamento não planejado de recurso do projeto 
R021 - Perder arquivos contendo artefatos de requisitos 
O Scrum define o papel do Scrum Master para eliminar os impedimentos e deixar a equipe 
livre para atuar no projeto. 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 19 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
É interessante deixar acordado logo de início que o plano feito, seja a data final de um 
cronograma ou um sprint, foi elaborado com a perspectiva de trabalho com equipe dedicada, 
caso algum membro da equipe seja requisitado o prazo e escopo estabelecidos ficam 
ameaçados. Caso haja entendimento inicial que algum membro seja cedido com alocação 
parcial este esforço deve ser previsto. 
No início do projeto o repositório do projeto deve ser criado, bem como as permissões de 
leitura e gravação concedida aos membros da equipe do projeto. 
Ação 8 – Estabelecer o trabalho em pares 
R022 - Ausência do analista ou usuário 
R023 - Saída do analista ou usuário 
O XP – Extreme Programming implementa a prática de programação em pares, esta é uma boa 
técnica para minimizar o impacto da ausência (temporária ou definitiva) de um recursodo 
projeto. Mas nem sempre é possível adotar esta prática, pois duplicando os recursos há um 
aumento direto nos custos, mesmo que isto seja justificado com a melhoria do artefato 
produzido. 
Ter um recurso disponível para fazer as revisões garante que tenha um recurso adicional com 
conhecimento no negócio, se este recurso puder assumir no caso de alguma ausência a curva 
de aprendizado é menor, pois o mesmo já possui conhecimento anterior. 
Monitoramento e Controle dos Riscos 
Não basta ter feito tudo isso até aqui sem antes ter certeza que todas as ações descritas 
anteriormente foram bem entendidas e há um responsável ciente do que precisa ser feito, ou 
seja, a comunicação é muito importante no gerenciamento de riscos. 
O gerente de projeto precisa ficar atento na identificação de novos riscos e realimentar todos 
os processos para estar bem preparado para qualquer eventualidade. O processo depois de 
planejar as respostas aos riscos é monitorar e controlar os riscos. Nesse processo ocorre ao 
longo do projeto e monitora os gatilhos, identifica novos riscos e avalia a efetividade das 
respostas aos riscos. 
O analista de requisitos precisa conhecer todas as técnicas de elicitação e especificação de 
requisitos e estar sempre atualizado na sua área e atento aos usuários para mudar a ação, 
propor melhorias no processo de desenvolvimento e manter o gerente do projeto informado 
sobre o andamento das ações de mitigação e novos riscos, caso haja. 
 
Resumo 
Podemos concluir que o gerenciamento de riscos de projetos esbarra em outras áreas de 
conhecimento, como custo, tempo, recursos humanos, aquisições, dentre outras. As ações 
pensadas para responder ativamente o risco devem entrar no planejamento do projeto, como 
Gerenciamento de Riscos em Requisitos – Boas Práticas na Elicitação de Sistemas 
~ 20 ~ 
D
EN
IZ
E 
PI
M
EN
TA
 
tarefas no cronograma, previsão de custos, etc. para desta forma garantir que o risco terá o 
impacto ou a probabilidade minimizada. 
Os métodos ágeis nos trazem uma grata lembrança – requisito não é o objetivo final do 
projeto e sozinho não agrega valor ao negócio, mas há de se convir que a parte crucial do 
projeto de desenvolvimento de sistemas é a identificação correta das necessidades para ser 
possível mapear e desenvolver a solução adequada, como foi visto, na atualidade encontramos 
vários problemas nesta etapa inicial. 
A lista de riscos apresentada neste artigo não cobre todos os riscos de requisito do seu projeto, 
cada projeto é individual e único, possui características próprias, ou seja, vários outros 
problemas, dificuldades ou oportunidades precisam ser identificadas e analisadas. Itens 
citados aqui, como riscos ou ações, também podem não encaixar muito bem à realidade do 
seu projeto ou empresa. Por exemplo, é citada ação para trabalho em duplas, nem todo 
projeto ou empresa, tem a possibilidade de duplicar os recursos do projeto, é certo que mitiga 
riscos, mas também aumenta o custo. Quais são as restrições do seu projeto? Não aceite nada 
como verdade absoluta, apenas utilize este material para reflexão. 
Não existe fórmula mágica para escrever bons requisitos e ter bons resultados em projetos de 
desenvolvimento de sistemas. A prática é o melhor professor, portanto: 
• Mantenha claro o que é esperado, ou seja, tenha uma boa comunicação. 
• Esteja aberto ao aprendizado. 
• Use padrões de mercado, mas faça adaptações necessárias ao projeto. 
• Avalie a utilidade do processo como um todo e continue melhorando sempre. 
 
Referência 
PMI’s Pulse of the Profession. November 2022. Project Management Institute. 
Guia PMBOK 5a edição 
WIEGERS, Karl Eugene, Software Requirements, Practical techniques for gathering and 
managing requirements throughout the product development cycle. 2003. 
MULCAHY, Rita. Risk Management – Tricks of the Trade for Project Managers. 2010. 
PIMENTA, Denize. Gerenciamento de Riscos em Projetos. Passei Direto, 2019. Disponível em: 
https://www.passeidireto.com/arquivo/94127706/gerenciamento-de-risco-em-
projetos?q=%22gerenciamento%20de%20risco%20em%20projetos%22&tipo=1. Acesso em: 
11/12/2022.