Quais os problemas que podem acontecer na faze de elicitação e análise de requisitos?

Os principais problemas encontrados são:

•   Os stakeholders não sabem o que realmente querem;
•   Os stakeholders expressam requisitos em seus próprios termos;
•   Diferentes stakeholders podem ter requisitos conflitantes;
•   Fatores políticos e organizacionais podem influenciar os requisitos de sistema;
•   Os requisitos mudam durante o processo de análise. Novos stakeholders podem surgir e o ambiente de negócios pode mudar.
•   Pessoal técnico e usuários finais têm vocabulários diferentes. Consequentemente, eles podem acreditar que estão em perfeito acordo até que o produto final seja entregue;
•   Engenheiros e desenvolvedores tentam ajustar os requisitos para um sistema existente ou modelo, em vez de desenvolver um sistema esepcífico que atenda as necessidades do cliente;
•   A análise é frequentemente conduzida por engenheiros ou programadores, ao invés de pessoal com habilidade e conhecimento do domínio para compreender as necessidades dos clientes;

O ignorante perdido

A elicitação deve ser conduzida pelas pessoas seniores da equipe, adequadamente treinadas. Uma mistura de pessoas mais e menos experientes é desejável para o desenvolvimento do time. É aconselhável ter também alguém que não possua conhecimento do domínio do problema: aqueles que não têm medo de perguntar:  o que isso significa? Além disso, ele ajudará na coleta suficiente de informações e para evitar que seja usado diferentes termos para o mesmo significado

Envolvidos errados

Envolvidos ou especialistas no assunto podem não responder por toda a organização. é importante identificar os seus relacionamentos com o projeto:

- ele está falando por toda a organização?

- existem opiniões diferentes sobre funcionalidades ou demandas não resolvidas?

- os envolvidos são conhecedores sobre o domínio em discussão?

Analistas não treinados

O papel do analista é capturar as necessidades da organização, do projeto ou do produto, e não se enveredar em ilusões com decisões de soluções. Pessoas não treinadas terão dificuldades em separar necessidades da solução do problema:

analista de banco de dados: “devemos ter uma tabela para armazenamento dos nomes dos clientes e seus endereços” em vez de: “o novo sistema deverá armazenar os nomes e endereço dos clientes”.

programador: “o nome do cliente deve utilizar cache para garantir uma recuperação rápida” em vez de: “o novo sistema deverá ser capaz de recuperar o nome e endereço do cliente em menos de 1 s”.

Falha na identificação precisa dos envolvidos

Imagine uma situação com uma reunião com 15 representantes de hospitais, onde um representante sugere uma funcionalidade x e outro representante sugere uma funcionalidade y. Durante a reunião de priorização é determinado que ambas solicitações (x, y) não podem ser atendidas na 1ª versão do sistema de agendamento do hospital.

Infelizmente os nomes e a representatividade de cada solicitante das funcionalidades x, y não foram registradas na reunião:

– funcionalidade x e y oriundas de um representante de uma rede de hospitais com 10.000 e 100 leitos respectivamente.

Dessa forma a informação necessária para a priorização foi perdida.

Falha em coletar informações suficientes

É importante coletar a maior quantidade de informações durante as sessões de elicitação de requisitos. Uma forma de fazer isso é garantir a participação de representantes da análise, do projeto e do time de testes, onde poderão endereçar suas necessidades quanto aos requisitos.

Alguns envolvidos ou especialistas no domínio do problema possuem pouca disponibilidade para se reunir com o analista de requisitos. Após a finalização da fase de elicitação pode ser ainda mais difícil endereçar questões abertas com os envolvidos ou especialistas.

Volatilidade dos requisitos

Se as necessidades estão mudando rapidamente, definir um conjunto estável de requisitos pode não ser possível. É necessário esperar até se obter algum nivel de estabilidade antes de se finalizar um baseline de requisitos para um produto de software.

Entendimento incompleto das necessidades do produto

Ocorre quando os envolvidos estão indecisos quanto as suas necessidades e quanto aos objetivos de seu negócio. Existem várias técnicas, como a prototipagem para ajudar nesse ponto. Criar uma breve especificação do produto também pode ajudar

- é isso que o cliente quer e precisa?

- é factível de construção, com a tecnologia, tempo e orçamento disponível?

- as funcionalidades do produto estão descritas adequadamente?

- está claro porque o cliente iria comprar esse produto de software?

O engenheiro de requisitos tem um profundo conhecimento do dominio

Quando isso ocorre, existe uma tendência de minimizar a comunicação com os envolvidos. A falha na comunicação com os envolvidos pode ser perigosa num domínio onde a tecnologia está mudando rapidamente (telefones celulares, por exemplo)

Envolvidos falam idiomas diferentes

Nesse caso a comunicação pode ser ainda mais difícil e os problemas podem aparecerem em diferentes áreas:

- realização de sessões de elicitação sem problemas

- entendimento de necessidades complexas, processos ou algorítmos

- garantir uma boa qualidade na revisão dos requisitos

Dado essas dificuldades, o uso de técnicas visuais como modelos, diagramas e tabelas para a comunicação de conceitos importantes podem ajudar na comunicação.

Envolvidos tem visões conflitantes

Quando isso ocorre uma discussão acalorada pode acontecer. O conflito deve ser resolvido fora da sessão de elicitação de requisitos, a menos que gaste um ou dois minutos. Deve-se evitar discussões complexas e longas na sessão de elicitação visando não perder a produtividade.

A fase de Elicitação de requisitos é a etapa do projeto onde são extraídas informações do cliente a respeito do que ele deseja no sistema.

Assim, como esta fase é onde o projetista entende as necessidades do cliente, a mesma pode vir a enfrentar problemas.

Com isso, esses problemas podem ser: Erros de comunicação entre cliente e projetista, a falta de um objetivo principal por parte do cliente, clientes que desejam prazos irreais em relação ao projeto e mudanças de requisitos ao longo do projeto devido à falta de visualização de necessidades por parte do cliente.