Análise da parte interessada

No contexto da engenharia de requisitos, entrevistas a stakeholders são usadas como um método de identificação de requisitos de um sistema.

A identificação de requisitos é um dos passos mais importantes do processo de engenharia de software. Consiste na identificação das necessidades do cliente por parte de um analista ou engenheiro de software. Depois de terem identificado estes requisitos, estão aptos para conceber uma solução para o problema. O processo pode ser árduo e moroso. Os especialistas em requisitos contactam os clientes, documentam os seus progressos, analisam a informação reunida para descobrir inconsistências, e depois voltam ao contacto com os cliente. Este ciclo pode assim levar algum tempo, e pode estender-se pelo ciclo de vida do projecto.

Os analistas podem fazer uso de diversas técnicas para obterem os requisitos do cliente. Estas incluem a realização de entrevistas, workshops de requisitos, brainstorming, ou listas de requisitos. Técnicas mais modernas incluem a prototipagem e casos de uso.

Introdução

A utilização de entrevistas é uma das técnicas mais usadas para identificar e assimilar os requisitos do cliente. Trata-se de uma técnica simples e direta que pode ser usada em virtualmente qualquer situação. Um dos aspectos fundamentais deste tipo de entrevistas é garantir que as ideias e predisposições naturais do entrevistador não interfiram com uma livre troca de informação. Isto pode ser algo difícil de conseguir uma vez que cada pessoa é influenciada por um conjunto de vivências pessoais, que podem dificultar a compreensão de ideias vinda de outras pessoas.

No caso dos engenheiros de software, que têm um papel de fornecedores de soluções, normalmente conseguem imaginar (mesmo em fases iniciais do processo) qual o tipo de abordagem e metodologia para resolver o problema em causa. Isto porque em muitos casos o domínio aplicacional é restrito e certos elementos parecem à partida óbvios para a solução final. Este facto, não sendo totalmente negativo, não deixa de muitas vezes colidir com a compreensão do verdadeiro problema a ser resolvido. Assim, é fulcral que o contexto em que o entrevistador se insere interfira o menos possível com a análise do problema proposto.

Elaboração das perguntas

Perguntas de contexto livre

As perguntas de contexto livre ajudam o analista a obter informação acerca do problema, minimizando ao máximo as suas influências pessoais na resposta do cliente. Isto consegue-se através de formular perguntas acerca da natureza do problema sem entrar em detalhes técnicos, evitando entrar em contextos de potenciais soluções. Este conceito de "perguntas de contexto livre" foi introduzido pela primeira vez por Gause e Weinberg [1989].

As perguntas de contexto livre podem ser comparadas a uma técnica usada por vendedores comerciais chamada "venda de soluções". Esta técnica consiste no vendedor fazer uma série de perguntas cujo primeiro objectivo é o de compreender ao máximo o problema do cliente e que soluções o cliente já tem em mente (no caso de já ter alguma). O objectivo destas perguntas é permitir ao vendedor perceber na sua totalidade o verdadeiro problema do cliente, para que possa sugerir soluções eficazes. Este processo permite evidenciar a importância do vendedor como um elemento da solução para o problema dos clientes.

Perguntas centradas na solução

Durante a fase de pesquisa e identificação de requisitos, pode também ser apropriado começar a dirigir o tipo de perguntas mais para o contexto de uma solução, após terem sido obtidas as respostas às perguntas de contexto livre. No fundo, o papel do analista é o de fornecer soluções específicas aos problemas em causa, e não apenas compreender o problema no geral.

A referência a um contexto de solução pode permitir que o utilizador surja com novas ideias, e até mesmo com uma visão diferente do problema, uma vez que é confrontado com uma potencial direção para a sua resolução. Claro que os entrevistados dependem diretamente dos entrevistadores para obter uma contextualização do caso; de outra forma, teriam de ser eles mesmos a ensinar ao entrevistador tudo o que sabem acerca do assunto em causa.

A entrevista

Com alguma preparação, uma estrutura de entrevista bem definida e com os objetivos delineados, não tem necessariamente levada a cabo pelo analista do sistema. Qualquer membro da equipe de trabalho pode realizar a tarefa de entrevistar um utilizador ou cliente de forma correta e com bons resultados. Ainda assim, deve ser dada preferência a membros da equipe com mais aptidões de interação social, e com à vontade para manter uma conversa com os utilizadores num ambiente empresarial e de forma por vezes pouco estruturada.

O guião da entrevista não deve ser demasiado restritivo. Depois de estabelecida uma ligação positiva com o entrevistado, é normal que a entrevista acabe por entrar numa dinâmica própria. Por vezes o cliente pode começar a entrar em grande detalhe acerca das inúmeras dificuldades e problemas da situação em que se encontra. Isto é exatamente o comportamento que procura.

Não há qualquer problema em desviar-se um pouco do contexto da entrevista, desde que mantenha em mente os objetivos que traçou para a entrevista. Após algumas entrevistas (bastam até duas ou três para tal ser notado), o analista/técnico vai concluir que obteve valioso conhecimento acerca do domínio do problema e vai ter uma melhor compreensão do problema a ser trabalhado e das opiniões do utilizador acerca das características que uma solução de sucesso deve ter. Para além disso, o técnico consegue fazer um apanhado das necessidades chave do utilizador ou das funcionalidades do produto.

O entrevistador deve ter sempre em mente que este método deve basear-se numa troca de informação mútua entre entrevistador e entrevistado.

Compilação da informação obtida

Após a realização das entrevistas, o analista já deve ter ficado com um leque de necessidades identificadas. Para compilar o conjunto de necessidades gerais dos utilizadores entrevistados deve ser usado um método que pode ser denominado de "Resumo do Analista".

Esta é a última seção da estrutura de uma entrevista.

Referências

• R. Edward Freeman, Alexander Moutchnik (2013): Stakeholder management and CSR: questions and answers. In: UmweltWirtschaftsForum, Springer Verlag, Vol. 21, Nr. 1. http://link.springer.com/article/10.1007/s00550-013-0266-3
• «Sticky Minds.com - Getting Software Requirements Right» 
• Dean Leffingwell, Don Widrig - Managing Software Requirements: A Use Case Approach, 2nd Edition - Addison Wesley, 2003
• Ian Sommerville - Sofware Engineering, 7th Edition - 2004