Falácia da Página em Branco

Falácia da Completeza

Reuniões

O uso da técnica de reunião durante a Elicitação é muito difundido em situações onde vários interessados devem ser ouvidos num mesmo contexto temporal. Pode ser entendida como uma extensão da técnica de entrevista ou da técnica de participação ativa dos atores (Clientes) do UdI.

Uma reunião pode englobar um ou mais atores no papel de engenheiro de requisitos. Os participantes de uma reunião de elicitação de requisitos são os interessados no sistema de software. Eventualmente um moderador de reuniões pode estar presente para ajudar a condução da reunião. A existência de um moderador dependerá do tipo de reunião a ser conduzida, tendo em vista que alguns métodos de reunião demandam o papel de moderador.

Reuniões permitem que requisitos sejam elicitados de uma maneira participativa, já que são vários, os interessados, além dos engenheiros de requisitos, presentes a uma reunião. Essa maneira participativa apresenta vantagens e desvantagens que precisam ser bem exploradas e controladas. Sob a ótica da vantagem tem-se que várias opiniões podem ser contrastadas de modo a enriquecer o conhecimento sendo elicitado. No que diz respeito à desvantagem, é preciso ter cuidados para que não se perca o foco da reunião, nem que divergências não-funcionais, aquelas referentes a aspectos pessoais dos participantes, sobressaiam.

Duas técnicas: “JAD” e “Brainstorm” são bastante mencionadas na literatura de engenharia de software. A última é uma técnica de reunião onde se enfatiza a opinião livre sobre determinados assuntos em pauta, principalmente sob a ótica de aplicação de novas idéias para a resolução de problemas. Esse tipo de técnica, quando bem conduzida e com pessoas criativas, pode, muitas vezes, resolver problemas de uma forma original e criativa. Na elicitação de requisitos a técnica precisa ter uma boa moderação de maneira a evitar a perda de foco, já que uma reunião de elicitação de requisitos não se destina a resolução de um problema, mas de aprofundar o conhecimento sobre determinado tópico. Veja aqui uma descrição sobre "brainstorm", aqui e aqui também.

O “JAD” (“Joint Application Design) tem por objetivo fazer com que os clientes e usuários participem, por intermédio de reuniões, na discussão sobre a definição de um sistema de software. O “JAD” tem formulários e processos bem definidos que ajudam os interessados na representação e discussão do conteúdo de um artefato de software. Vejam, aqui e aqui, textos sobre essa estratégia.

É recomendável a leitura do trabalho de mestrado de Cecilia Camacho sobre reuniões. A autora faz uma evolução de um método criado na PUC-Rio para aumentar o nível de conflito funcional em uma reunião.

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.