Técnicas e eventos para elicitação de requisitos

O que é uma Entrevista

Entrevista é um evento em que o analista de requisitos aborda diretamente os stakeholders, isoladamente ou em grupo, para extrair-lhes informações sobre os processos do negócio que será alvo de sistematização. Quanto menor o número de elementos presentes no evento melhor será o aproveitamento. Os fatores limitantes da entrevista é a duração, para um melhor aproveitamento do evento esta não deve se estender em termos de tempo e pelo limitado número de participantes, pois o analista deverá manter o controle da situação, o que acontecerá com um número pequeno de participantes (recomenda-se até 8 pessoas, no máximo). Os stakeholders adequados para esse tipo de evento, bem como, qualquer outro tipo de evento de elicitação de requisitos, são os que são diretamente afetados pelos processos de negócio em questão e, também, os que sofrem as conseqüências diretas desses processos. Nesse caso, é melhor que o grupo dos que sofrem as conseqüências estejam em outro evento e não no mesmo evento dos primeiros. Logicamente, em um momento posterior deverá haver um encontro entre os dois grupos para equalizações nos processos. Nesses eventos são identificadas as Necessidades funcionais (NF), regras de negócio (RN), Restrições funcionais (RF) dos usuários do software.

O que é um workshop

Workshop é um evento em que o analista de requisitos, assessorado por moderadores neutros, submete questões sobre o software ou problemas específicos a um grupo de stakeholder. As vantagens do workshop é que o analista de requisitos estando assessorado e havendo a sua disposição uma certa infra-estrutura operacional, poder-se-á trabalhar em vários turnos, dividindo-se o trabalho em grupo quando necessário. O workshop pode ser utilizado tanto para apresentação de produtos, resultados, como para elicitar requisitos.

O que JAD

JAD é um ciclo programado de reuniões nas quais analistas de requisitos confrontam usuários com objetivo de definir necessidades que nortearão a construção de um sistema. Em JAD há uma atenção especial dirigida ao assunto Condução de Reuniões. Pois a reunião é o elemento constituinte fundamental do JAD.
Por definição, JAD é uma entidade abstrata. Para que esse evento se realize, para que se concretize, a implementação se dá através de uma reunião. O JAD corre o mesmo risco das reuniões, caso haja, um abuso em se resolver qualquer assunto utilizando essa técnica.

O que é um brainstorming

Brainstorming, segundo a análise de requisitos, é uma técnica em que os participantes de um evento para elicitação de requisitos se reúnem em grupo e cada um dos membros desse grupo expõe a sua idéia e expectativa sobre o projeto como um todo ou em pontos determinados. Um moderador neutro deve registrar todas as idéias apresentadas e coordenar a participação e interação de todos os participantes, sem censuras prévias às lucubrações expostas. O tempo de considerações livres (brainstorming) deve ser em média de 15 minutos, sendo que, após esse período deverá se iniciar uma discussão sobre cada um dos pontos levantados visando a sua consolidação. O moderador não deve nunca tentar fazer prevalecer o seu ponto de vista, nem interferir nas considerações de qualquer um dos participantes. Todas idéias deverão, a princípio, serem consideradas. O brainstorming pode ser uma das técnicas empregadas em workshop ou entrevistas.

Concluindo projetos

Não há nada mais gratificante do que vivenciar a conclusão de um projeto. Esse momento nos remete às sensações similares ao nascimento de um filho. É uma sensação satisfatória de dever cumprido, de metas alcançadas. Porém, não é fácil alcançar esse momento de satisfação, sem contar que existem projetos que jamais poderão ser finalizados.

Um projeto é construído a partir de sua base e sua estrutura fundamental estará assentada sobre esses fundamentos que permitirão a sustentação das demais estruturas que serão construídas ao longo do ciclo de vida do projeto. Caso essa fundação não seja bem alicerçada o projeto poderá ser lançado ao fracasso.

Pois bem, a primeira etapa na construção de um projeto que seja passível de conclusão é, que este, tenha seus marcos bem delimitados; suas metas devem ser claras e objetivas. A premissa principal para se alcançar um objetivo é saber qual é, exatamente, esse objetivo.

A elicitação de requisitos dentro da engenharia de software deve ser tratada como um fundamento básico para constituição de base sólida sobre a qual serão erigidos os pilares de sustentação de um projeto.

Os pilares de um projeto são os sub-projetos e processos que o complementam. A maioria desses sub-projetos e processos são intercalados e dependentes e a execução plena de cada um deles influenciará radicalmente na qualidade final do produto que está sendo desenvolvido. Por isso, devemos encarar esses elementos com todo cuidado e acompanhar a sua construção com a seriedade com que é executado o projeto em seu todo. Cada um desses elementos serão fundamentos básicos para que o todo esteja harmonizado, volto a lembrar! Dito isso, é bom ressaltar que em cada um desses elementos devemos atentar para a elicitação de requisitos e determinação das responsabilidades associadas a cada um desses elementos. Esse procedimento é fundamental para a determinação das fronteiras de cada um dos elementos que compõem um projeto.

A determinação de responsabilidades concernentes aos elementos do projeto é uma tarefa árdua, algumas vezes, fica difícil definir com precisão as fronteiras de ação de cada um desses elementos e tendemos a repetir responsabilidades ao logo de um processo de definição de fronteiras para a construção de um elemento.

Quando delimitamos mal essas fronteiras, caímos na armadilha da repetição desnecessária, da indefinição de responsabilidades e da imprecisão de conceitos.

Devemos ter o cuidado de fazer o usuário enxergar também essas responsabilidades e perceber que cada coisa nesse cenário deve ter o seu lugar. Na maioria das vezes, o usuário só consegue perceber o todo e, confusamente, tenta resolver todo o seu problema num processo só e no mesmo momento.

Com habilidade o analista de requisito deve fazê-lo entender que cada processo é um processo ‘limpo’ e objetivo. Sendo que seus objetivos e responsabilidades devem estar claramente definidos. Se essa premissa for negligenciada esse projeto estará fadado ao fracasso.

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.