sexta-feira, janeiro 25

O zen e a arte de elicitar requisitos

A elicitação de requisitos é uma arte complexa. Desta feita, por estar sujeita aos humores do detentor das ‘Necessidades’ que muitas vezes não sabe exatamente o que quer, torna a fixação dessa informação, um processo complicado. É comum, depararmos com analistas de requisitos desesperados com a falta de definição por parte de quem deveria definir. Não é incomum, também, um stakeholder (usuário) que não tenha noção exata do que está acontecendo ao seu redor e que, simplesmente, caiu de pára-quedas num projeto e ainda não tem domínio dos processos ao seu redor. Outro problema envolvido nesse espectro é a quantidade de processos e artefatos que os processos obrigam, ao analista de requisitos, construir.
Pare, respire e analise...
O usuário – operador de ferramentas, só consegue enxergar as suas necessidades objetivamente a partir de uma visão objetiva. Com isso quero dizer que, na maioria das vezes nos basta construir os seguintes artefatos:
Relação das necessidades do stakeholders;
Relação das funcionalidades do software;
Relação dos requisitos não funcionais;
Diagrama geral de relacionamento entre casos de uso;
Relação das regras gerais e especificas dos casos de uso;
Matriz de rastreabilidade entre funcionalidades x necessidades x regras gerais x casos de uso;
Especificação de caso de uso;
Projeto de interfaces.
Em minha visão, esses artefatos são fundamentais para a construção de um software e para a fixação de necessidades de usuários são essenciais o documento de regras gerais e específicas e o projeto de interfaces.
Ultimamente, tenho tentado em meus projetos com essa seqüência de atividades:
1º ciclo:
Brainstorm e reuniões para levantamento das necessidades fundamentais dos usuários;
Levantamento de necessidade, regras do negócio;
Identificação de funcionalidades (requisitos funcionais) e requisitos não funcionais;
Organização das regras de negócio;
Construção dos casos de uso;
Construção das especificações de caso de uso;
Projeto de interfaces
2º ciclo:
Workshop para validação dos requisitos, utilizando-se como insumos as regras gerais e regras específicas para os casos de uso e projeto de interface.
O fato de o usuário validar as suas necessidades a partir de um projeto de interfaces (protótipo mediamente funcional), faz com que ele tenha mais clareza e objetividade em suas funções. Se Ganha em termos de tempo e precisão. O profissional de requisitos, por alcançar mais agilmente os seus objetivos e concluir suas tarefas de uma forma mais precisa minimizando o retrabalho fará com que esse profissional esteja mais relaxado e, conseqüentemente, mais produtivo. Tudo isso, por uma rápida reorganização no processo de trabalho.

1 Comments:

At janeiro 29, 2008 10:19 AM, Anonymous Anônimo said...

Olá Gilmar!
Só tenho a agraceder por você dividir seu conhecimento conosco! Seu blog é de grande valia para quem procura uma boa leitura!
Abraços,
Daniele Dickel

 

Postar um comentário

<< Home