Entrevistas

Sem dúvida, de todas as técnicas de coleta de fatos, a mais comum e mais conhecida é a entrevista.

Uma entrevista é normalmente uma comunicação entre entrevistado e entrevistador. No caso de engenharia de requisitos, o entrevistador é o engenheiro de requisitos e o entrevistado é o cliente ou um interessado no software para o qual se quer conhecer os requisitos.

Um interessado pode ser desde um futuro operador de um artefato no qual o software fará parte ou o executivo da empresa que pagará pelo software, mas que dificilmente irá interagir com o mesmo. Portanto, a diversidade de entrevistados demandará estratégias distintas de entrevista.

Entrevistas são classificadas como estruturadas ou não-estruturadas. Uma entrevista estruturada requer um prévio conhecimento sobre o contexto onde se aplica a entrevista. Uma entrevista não-estruturada é aplicada quando se inicia o contato com o Universo de Informações e serve para garimpar informações iniciais. Fundamentalmente o entrevistador deixa o entrevistado falar, mas procura orienta-lo para que a entrevista mantenha o foco no tópico de interesse.

O papel do entrevistador na entrevista não estruturada é um papel de aprendizado.

A entrevista estruturada é feita com base em perguntas previamente pensadas ou delineadas, é uma entrevista mais focada porque é dirigida por um elenco de perguntas que já têm um foco específico. Claro, que o entrevistador tem liberdade de inserir perguntas de clarificação ou eventualmente outras que se façam necessárias, mas o núcleo de perguntas já é definido a priori.

Ressaltamos que muitas vezes a equipe pode usar perguntas preparadas por outros atores, mas é comum que os entrevistadores sejam aqueles que elaboram as perguntas.

Perguntas de controle, que usam de redundância para identificar problemas, é uma maneira de auferir mais qualidade nas respostas.

O papel do entrevistador na entrevista estruturada é um papel de questionador.

O engenheiro de requisitos no papel de entrevistador deve ter cuidados ao conduzir uma entrevista, tanto porque pode estar falando com interessados de alto poder de decisão como também com interessados que podem estar receosos de mudanças organizacionais. O principal é estabelecer, desde do início, um clima de colaboração, no o qual a entrevista é um fator importante para que o contexto seja melhor compreendido pelos profissionais de informática.

Uma entrevista pode ser conduzida por mais de um entrevistador e pode ter mais de um entrevistado.

Cabe ao entrevistador tomar notas ao longo da entrevista. Essa tarefa é difícil. O método de anotar palavras chaves e usar setas para ligar essas palavras chave é o mais recomendado, mas exige prática. A prática de gravar entrevistas e anotar com base na gravação é um recurso que pode ajudar, mas é preciso levar em conta que haverá o custo extra de escutar a gravação. Em alguns casos o entrevistado tem interesse que a entrevista seja gravada, assim como alguns preferem que se evite o uso do gravador. É claro que a política de gravação deve ser acordada com o entrevistado.

As anotações de entrevistas tornam-se documentos do processo de construção de requisitos e devem seguir padrões de armazenamento de modo a facilitar consultas futuras. Esses padrões devem atender aos requisitos de rastreamento.

Aponto quatro referências que apresentam diferentes visões sobre entrevistas. Vale a pena
conferir. A primeira tem uma visão jornalística, a segunda apresenta uma visão do ponto de vista social, a terceira mostra o esquema de um curso sobre entrevistas e a quarta mostra um procedimento padrão para entrevistas de auditoria.

Técnicas de Coleta de Fatos (Elicitação)

Conforme o texto da Seção 3 da Parte III são as seguintes as estratégias que se pode utilizar para coletar fatos:

• Leitura de Documentos
• Observação
• Entrevistas
  
• Questionários
• Análise de Protocolos
• Participação Ativa dos Atores (Clientes)
• Enfoque Antropológico
• Reuniões
• Reutilização
• Recuperação do Desenho

Outra estratégia que é bastante útil é o Ordenamento de Cartões. Essa técnica é útil para elicitarmos relacionamentos entre conceitos, com também para identificarmos níveis de abstração utilizados no Universo de Informações. A técnica consiste em distribuir cartões com frases ou palavras para os interessados (clientes) e pedir que, individualmente ou em grupo, eles formem grupos com os cartões e nomeiem os grupos. Em Inglês chama-se de “Card-Sorting”. Veja aqui uma animação de como funciona essa técnica (clique em "Open Sort") (em Inglês).

Identificação de Fontes de Informação

Na Seção 2 da Parte III, descrevemos a importância da identificação das fontes de informação. Afinal, é da qualidade das fontes de informação que dependemos para elicitarmos o conhecimento do que se demanda do software a ser construído ou evoluído.

Além de ressaltarmos que as fontes de informação podem ser de diferentes tipos, além de pessoas, detalhamos heurísticas gerais que ajudam na identificação de fontes de informação.

Em um artigo publicado no WERpapers, um método para identificação de fontes de informação é proposto. O método é colaborativo e envolve pelo menos três engenheiros de requisitos. São 5 as etapas a serem seguidas pelo método.

1. Seleção: nesta etapa, cada engenheiro de requisitos, usando as heurísticas como as da Seção 2, elabora uma lista de fontes de informação encontradas no Universo de Informações. A heurística principal consiste em que observar as fontes de informação que respondem as perguntas: O que? Quem? e Onde?. O “o que” normalmente leva a documentos ou sistemas, o “quem” leva a atores do Universo de Informações e “onde” leva a lugares onde o software irá operar.
2. Desenho: cada engenheiro desenha um grafo de influência ligando através de relacionamentos as várias fontes de informação.
3. Consolidação: em uma reunião os engenheiros constroem coletivamente um grafo que consolide os grafos construídos individualmente.
4. Eleição: em uma reunião com base no grafo consolidado os engenheiros discutem e propõem estratégias de elicitação para cada fonte.
5. Avaliação: através de reunião os engenheiros estabelecem prioridades e custo associados a cada fonte.

Elicitação

A palavra acima é um neologismo. Foi criada para distinguir essa tarefa tão fundamental para a construção de software.

O texto na Parte III define-a como uma mescla de outras palavras como: clarear, entender, extrair. A Figura 1 da Parte III procura detalhar a semântica de elicitar.

A Necessidade da Elicitação

A Seção 1 (Introdução) da Parte III ressalta a importância da tarefa de entendermos o que é preciso ser feito, antes de começarmos a fazer. Essa afirmação é óbvia, mas é muitas vezes esquecida por engenheiros que se apressam em construir antes de entender exatamente o que se deseja construir. Para ressaltar a importância da tarefa de ELICITAR citamos no texto dois autores: von Neumann e Polya. Dois matemáticos: um deles é o responsável pela teorização que levou a concepção dos computadores digitais; outro é responsável por uma série de trabalhos no campo da matemática e do seu ensino, em particular a maneira de resolver problemas.

Sobre von Neumann repito aqui o que escrevi em outro lugar:

Por que os requisitos são importantes? São várias as razões, mas: a mais evidente é porque não se pode construir nada, sem que antes saiba-se o que se quer construir. Eu utilizo, há muito tempo, uma frase atribuída a von Neumann que diz:

There is no sense in being precise about
something when you do not even know what you
are talking about.

Esta frase foi encontrada em um dos livros de Gerald Weinberg. Cabe a ele a citação original. Vale lembrar quem foi von Neumann. Veja também este elo.

Sobre Polya, utilizei três questões que são freqüentes em várias citações ao seu trabalho:

a) “What is the unknown?” ( qual a incógnita?)
b) “Do you know a related problem?” (conheces um problema semelhante?)
c) “Could you restate the problem?” (podes repetir o problema com suas palavras?)

Alcino Simões e Lisette Poggioli fornecem mais detalhes sobre o tema. A Universidade de Lisboa disponibiliza um resumo sobre Polya.

Além das citações a Polya e a von Neumann, gostaria de ressaltar alguns truísmos que identifiquei em um artigo de Michael Jackson, e que considero de fundamental importância.

a)"Distinguish the machine from the problem domain"
b) "Don’t restrict description to the machine",
c) "State explicitly what is described".
d) “Requirements Are Not Given Properties”,
e) “The Model Is Not the Reality”, and
f) “The Problem Is Not at the Interface”

Esses “mantras” estão contextualizados na diferença que Jackson faz da máquina computacional (software e hardware) e o contexto no qual essa máquina irá atuar (“problem domain”). Para ele requisitos é a ponte entre o contexto (Universo de Informações) e a máquina.

Desses seis “mantras” é importante saber: que o “problema” não está na interface, que requisitos não são propriedades previamente existentes, que a máquina deve ser entendida como separada do Universo de Informações e que o modelo não é a realidade.

Fundamentalmente, os “mantras” de Jackson expressam a necessidade da elicitação dos requisitos, e que esses precisam refletir a perspectiva da máquina e a perspectiva do contexto onde a máquina irá atuar.