Dificuldades comuns com Requisitos

Dificuldades comuns com Requisitos

1. As dificuldades mais comuns ao se aplicar a Engenharia de Requisitos

   • Comunicação
     • Uma das dificuldades mais comuns ao trabalho de requisitos é conseguir comunicar-se de forma clara, seja com as partes interessadas, seja com os demais membros da equipe do projeto.
     • O analista de requisitos deve estar sempre atento à ambiguidade nas mensagens – tanto das que envia quanto das que recebe.
     • A ambiguidade aumenta a chance de uma compreensão equivocada pelos demais profissionais atuando no desenvolvimento e, consequentemente, de uma construção de produto que não atende ao seu propósito.
     • Uma solução que diminui o problema da ambiguidade é atentar para o fato de que a comunicação não se constitui simplesmente da mensagem:
       • Emissor: alguém que emite a mensagem.
       • Receptor ou destinatário: a quem se destina a mensagem.
       • Código: a maneira pela qual a mensagem se organiza.
       • Canal de comunicação: meio físico ou virtual que assegura a circulação da mensagem.
       • Mensagem: é o objeto da comunicação, constituída pelo conteúdo das informações transmitida.
       • Referente: o contexto, a situação à qual a mensagem se refere.
     • . Denomina-se ruído os elementos que perturbam e que dificultam a compreensão pelo destinatário.
     • Outra dificuldade relativa à comunicação é manter sintonizados todos os envolvidos na Engenharia de Requisitos, sejam membros da equipe de requisitos, sejam as partes interessadas.
       • A solução que a humanidade criou para lidar com essa complexidade foi a hierarquia.
   • Acesso às partes interessadas
     • A dificuldade de acesso mais comum é quando a parte interessada é de fora da organização (clientes, fornecedores, parceiros, aliados etc.).
     • Se esse intermediário falhar no seu papel, certamente o produto entregue ao final do projeto terá sérios problemas.
     • Outro caso de dificuldade de acesso à parte interessada é quando ela não deseja se envolver tanto no trabalho de requisitos. Em geral, alega-se “falta de tempo” para participar de reuniões. Pode-se dividir esse cenário em dois casos:
       • O primeiro é aquele em que a parte interessada necessária ao trabalho de requisitos não é a demandante direta do projeto, ou não se beneficiará de forma direta dos resultados dele.
       • O segundo caso é aquele em que a parte interessada é a demandante direta do projeto.
     • Quando a falta de tempo para se reunir é uma desculpa para alguém não se envolver no projeto, deve-se buscar outras formas de levantar informação além de entrevistas.
       • Outras opções são as técnicas de observação, análise de documentos e questionário. Ou também pode-se tentar encontrar outra pessoa com mais disponibilidade ou interesse e que possa fornecer as mesmas informações. Quase sempre há essa opção.
     • O ideal é trabalhar para que a presença do analista seja desejada por aqueles que podem criar essa barreira.
   • Indecisões/Indefinições do usuário
     • A dificuldade de o usuário em saber o que quer, ou, então, de se expressar corretamente quanto ao que deseja e isso varia a intensidade com que ocorre, desde a parte interessada que não sabe expressar sua necessidade até aquela que expressa a necessidade errada.
     • A princípio, pode-se pensar que a culpa por essa dificuldade é do usuário; afinal, seria sua obrigação ter uma visão clara da necessidade.
       • E o grande valor que o analista de requisitos pode agregar com o seu trabalho é justamente conseguir compreender corretamente as necessidades do usuário, ainda que este, a princípio, não saiba bem o que quer.
     • Para essas partes interessadas, deve-se também buscar um método mais adequado de obtenção de informação, como entrevistas e prototipação.
   • Requisitos implícitos ou não ditos
     • O papel do analista de requisitos é descobrir as necessidades das partes interessadas, estejam elas à tona (explícitas) ou mais ocultas (implícitas). É ilusão achar que o trabalho de requisitos se restringe ao que está explícito.
     • Não há nenhuma ferramenta ou técnica que garanta que a especificação de requisitos está completa. Por isso, a dificuldade em lidar com necessidades implícitas.
     • A observação é muito útil também, tanto para ganhar conhecimento do negócio quanto para perceber o que não foi dito e prototipação é útil para antecipar a descoberta dos requisitos implícitos.
   • Mudança
     • Uma reclamação muito comum entre alguns analistas de requisitos é a frequência alta de mudanças em requisitos.
     • É importante entender a natureza da mudança para identificar se esse fenômeno é um problema que deve ser tratado ou não.
       • Há também as mudanças que fogem ao controle do trabalho do analista de requisitos.
       • Há mudanças que poderiam ser evitadas.
       • E muitas mudanças são benéficas ao projeto, pois aumentam o seu valor agregado.
       • Mas, mesmo ainda dentro desse cenário de mudanças inevitáveis, é possível prever que algumas acontecerão.
     • Quanto maior o tamanho do projeto, maior tende a ser sua duração e, consequentemente, maior a incidência de mudanças.
   • Conflitos
     • Quanto maior a quantidade de partes interessadas em um projeto, maior o potencial de conflitos de interesses, necessidades e informações.
     • Os conflitos podem ser de várias naturezas: de ordem pessoal, profissional, político, familiar etc. Entender sua origem ajuda na solução.
     • Podem-se listar alguns conflitos comuns:
       • Requisitos de partes interessadas que são inviáveis de atender simultaneamente.
       • Requisitos de partes interessadas que são inviáveis de atender simultaneamente.
       • Solicitações de partes interessadas fora do escopo do projeto.
       • Partes interessadas que são adversárias, antipáticas ou hostis umas às outras.
       • Falta de sintonia entre as áreas de negócio envolvidas.
   • Resistência a Mudança
     • Todo projeto de software implica em algum tipo de mudança para as partes interessadas.
     • A primeira coisa que o analista deve buscar é compreender o impacto que o projeto acarretará a cada parte interessada
     • Manter a zona de conforto é a reação natural da maioria, por isso é frequente encontrar resistência a mudanças.
     • . Há também os casos onde, de fato, a mudança pode trazer perdas para algumas partes interessadas
   • Parte interessada não domina seu negócio
     • O analista deve buscar conhecer bem o negócio, através de outros meios (estudo de documentação disponível ou identificar outras pessoas com mais conhecimento – quase sempre há), para conseguir fazer um bom trabalho.
   • Parte interessada não lê a especificação de requisitos
     • Seguir com o projeto sem nenhum feedback da parte interessada sobre a especificação representa um alto risco de construir um produto que não trará satisfação..
     • Alguns motivos possíveis são:
       • Partes interessadas não compreendem a importância da especificação e entendem o papel de revisão como mera burocracia.
       • A estratégia adotada de apresentação da especificação para aprovação pode estar errada.
       • Parte interessada já está (ou acha que está) ciente do que será entregue e não vê necessidade de revisar a especificação, pois já sabe o que está contido al
   • Partes interessadas insaciáveis com requisitos
     • Essa característica expansiva dos requisitos torna a gestão do escopo de projetos um desafio.
     • Porque as partes interessadas sempre têm necessidades a serem satisfeitas;
     • Se o analista não estiver atento, começa a incorporar ao projeto todos os requisitos que vão surgindo durante a interação.
   • Consistência
     • O trabalho de requisitos vai sendo desenvolvido de forma evolutiva; a especificação é criada e vai recebendo incrementos, melhorias e correções ao longo do tempo.
     • O conhecimento do autor da especificação vai mudando (aumentando) durante esse processo e partes da especificação elaboradas ao início podem já ter uma perspectiva diferente de partes elaboradas posteriormente.
     • Isso pode resultar em uma especificação final de requisitos com inconsistências.
   • Necessidade de Vagas
     • Transformar essas necessidades vagas em necessidades claras e específicas é responsabilidade do analista de requisitos.
     • O trabalho de requisitos não se conclui enquanto houver um nível alto de incerteza sobre as necessidades a serem atendidas.
     • Encontrar uma especificação de requisitos, em tese finalizada, mas com requisitos vagos é quase sempre um sintoma de preguiça ou desatenção do autor. E, consequentemente, sua utilidade fica comprometida.
   • Priorização
     • A priorização tem como função assegurar que os recursos do projeto sejam focados nos itens mais relevantes.
     • O analista de requisitos participa da discussão de priorização para ajudar no processo, mostrando eventuais impactos das decisões e esclarecendo melhor cada requisito, se necessário.
     • A grande dificuldade é ter as partes interessadas assumindo a responsabilidade da priorização.

2. Lucas Limas Sousa Torres - nº 415479