Engenharia de Software - TÉCNICAS DE ENTREVISTAS E DE COLETA DE DADOS

TÉCNICAS DE ENTREVISTAS E DE COLETA DE DADOS

2.1 Introdução
Este texto apresenta algumas diretrizes para as entrevistas que você fará durante a fase
de análise de sistemas do projeto de desenvolvimento de um sistema. Provavelmente
entrevistará usuários, gerentes, auditores, programadores e auxiliares que utilizam sistemas já
existentes (informatizados ou manuais) e também várias outras pessoas envolvidas.
Por que fazemos entrevistas durante a análise de sistemas? Porque:
• Precisamos coletar informações sobre o comportamento de um sistema atual ou sobre
os requisitos de um novo sistema de pessoas que têm essas informações
armazenadas em algum lugar em suas cabeças.
• Precisamos verificar nossa própria compreensão, como analistas de sistemas, do
comportamento de um sistema atual ou dos requisitos de um novo sistema. Essa
compreensão deve ser adquirida através de entrevistas em combinação com
informações coletadas de modo independente.
• Precisamos coletar informações sobre o(s) sistema(s) atual(is) para a execução do
estudo de custo/benefício para o novo sistema.
2.2 Tipos de Entrevistas
A forma mais comum de entrevista é uma reunião pessoal e direta entre você (talvez
acompanhado por até dois analistas auxiliares do projeto) e um ou mais interlocutores
(entrevistados). Normalmente são efetuadas anotações por um dos entrevistadores; menos
costumeiramente, a entrevista pode ser gravada ou um(a) secretário(a) tomará notas durante a
entrevista.
Pode-se perceber que as informações obtidas em uma entrevista também podem ser
obtidas por outros meios, por exemplo, solicitando-se que os entrevistados respondam por
escrito a um questionário formal, ou solicitando que descrevam por escrito os requisitos do
novo sistema. Também podemos aumentar as entrevistas pela presença de vários
especialistas (que podem até conduzir a entrevista enquanto o analista de sistemas participa
como assistente), como peritos em indústria/comercio, psicólogos comportamentais e
negociadores. E, finalizando, deve-se lembrar que outros meios de obtenção de dados (ex.:
videocassete, gravadores, etc...) podem ser utilizados para registrar uma entrevista.
Durante a década de 80, uma forma especializada de entrevista tornou-se popular em
algumas empresas; conhecida como JAD (Joint Application Development) ou projeto acelerado,
ou análise em equipe, e por vários outros nomes. Ela consiste em uma rápida entrevista e um
processo acelerado de coleta de dados em que todos os principais usuários e o pessoal da
análise de sistemas agrupam-se em uma única e intensiva reunião (que pode prolongar-se de
um dia a uma semana) para documentar os requisitos do usuário. A reunião costuma ser
supervisionada por um profissional experiente e bem treinado que atua como mediador para
encorajar melhores comunicações entre os analistas de sistemas e os usuários.
Freqüentemente, este supervisor é apoiado por algumas pessoas que se dedicam
integralmente ao processo. Engenharia de Software
Prof. Walteno Martins Parreira Jr Página 13
Embora todas essas variações tenham de fato sido utilizadas, elas são relativamente raras
e não serão discutidas em maiores detalhes neste texto. A entrevista mais utilizada ainda é a
reunião pessoal entre um analista de sistemas e um usuário final.
2.3 Problemas Fundamentais
Inicialmente pode parecer que o processo de entrevistar um usuário seja uma questão
simples e direta. Afinal, o analista e o usuário são pessoas inteligentes e capazes de
expressarem. Os dois são pessoas racionais e ambos têm o mesmo objetivo: passar
informações relativas a um novo sistema proposto da mente do usuário para a do analista.
Qual é o problema?
Na realidade, existem muitos problemas que podem ocorrer. Em muitos projetos de alta
tecnologia, tem-se observado que a maioria dos problemas difíceis não envolvem hardware
nem software, mas sim o pleopleware. Os problemas de peopleware na análise de sistemas
são muitas vezes encontrados nas entrevistas. Os problemas mais comuns a que você deve
estar atento são:
• Entrevistar a pessoa errada no momento errado. É muito fácil, por causa dos
problemas e interesses organizacionais, falar com a pessoa que é o perito oficial na
orientação do usuário, que demonstra nada saber a respeito dos verdadeiros
requisitos do sistema; também é possível perder a oportunidade de falar com o
usuário desconhecido que realmente sabe quais são os requisitos. Mesmo que
encontre a pessoa certa, talvez o analista tente entrevistá-la durante um período em
que o usuário não está disponível ou esteja mergulhado sob outras pressões e
emergências.
• Fazer perguntas erradas e obter respostas erradas. A análise de sistemas é, como
Tom DeMarco gosta de dizer, uma forma de comunicação entre estranhos. Os
usuários e os analistas de sistemas têm vocabulários diferentes, experiências básicas
diferentes e muitas vezes um diferente conjunto de pressuposições, percepções,
valores e prioridades. Desse modo, é fácil fazer ao usuário uma pergunta racional
sobre os requisitos do sistema e o usuário não entender absolutamente a pergunta,
sem que nenhum dos dois perceba o fato. E é fácil para o usuário prestar-lhe algumas
informações sobre os requisitos e o analista não entender essas informações,
novamente sem que nenhum dos dois perceba o fato. As ferramentas de modelagem
são uma tentativa de fornecer uma linguagem comum e sem ambigüidades para
diminuir esses mal entendidos. Porém as entrevistas costumam ser realizadas em
uma língua comum (inglês, espanhol, francês, português etc.),portanto o problema é
real. Isso explica porque é tão importante marcar entrevistas subseqüentes para
confirmar que ambas as partes entenderam as perguntas e as respostas.
• Criar ressentimentos recíprocos. existem algumas razões pelas quais o usuário
pode não se sentir à vontade ou mesmo colocar-se em posição antagônica na
entrevista com um analista de sistema (ex.: porque ele percebe que o verdadeiro
objetivo do novo sistema que o analista está especificando é tomar-lhe o emprego). E
o analista pode ressentir-se do modo como o usuário está respondendo as perguntas.
Em qualquer caso, o ressentimento pode surgir entre as duas partes, tornando a
comunicação muito mais difícil.
Não existe um modo mágico de garantir que esses problemas não ocorrerão; eles são a
conseqüência das interações pessoa-a-pessoa, e cada uma dessas interações é única.
Contudo, as sugestões dadas a seguir podem ajudar a reduzir a probabilidade desses
problemas; fora isso, dependerá de prática para melhorar cada vez mais em cada entrevista
subseqüente. Engenharia de Software
Prof. Walteno Martins Parreira Jr Página 14
2.4 Diretrizes Para a Realização de Entrevistas
As seguintes diretrizes podem ser de grande auxílio na direção de entrevistas bemsucedidas com o usuário.
2.4.1 Desenvolva um Plano Geral de Entrevistas
Antes de tudo, é extremamente importante que o analista descubra quem deve ser
entrevistado. Caso contrário, desperdiçará o tempo de todos e criará um enorme tumulto, por
falar com pessoas erradas sobre coisas erradas.
Isso requer que obtenha um organograma da empresa que mostre as pessoas da
organização usuária, bem como a hierarquia entre elas. Se não existir um organograma formal,
encontrar alguém que saiba como a organização funciona e pedir ajuda. Se o organograma
existir, certificar-se de que esteja correto e atualizado; as empresas muitas vezes modificam-se
com muito mais freqüência do que o ciclo editorial anual em que os diagramas são produzidos!
O fato de conhecer o esquema organizacional não diz necessariamente com quem o
analista deve entender-se; às vezes, a pessoa que mais sabe a respeito de algum aspecto de
um sistema é um funcionário administrativo ou burocrata que sequer aparece no organograma.
Muitas vezes existem três níveis de usuários em uma organização grande e complexa (o
usuário verdadeiro, o usuário supervisor operativo e o usuário supervisor executivo) e é muitas
vezes de grande importância falar com todos os três níveis.
Em muitos casos também é importante conversar com os usuários na seqüência adequada
e na combinação certa. Por vezes o analista poderá saber em que seqüência os usuários
deverão ser entrevistados face a seu conhecimento geral da organização e por vezes os
próprios usuários lhe dirão uma vez que saibam que serão entrevistados.
2.4.2 Certifique-se de que tem Autorização para Falar com os Usuários
Em algumas organizações informais não haverá restrições na escolha dos usuários com
quem falar ou sobre como as entrevistas serão marcadas. Porém isso não é comum em
empresas grandes; é politicamente perigoso vagar pela organização usuária realizando
entrevistas sem prévia autorização.
Na maioria dos casos, a autorização virá ou do encarregado de um setor usuário (um
departamento ou divisão) ou do representante da empresa que estará auxiliando o projeto de
desenvolvimento do sistema. Em qualquer caso, os usuários têm legítimas razões em querer
aprovar, antecipadamente, quem será entrevistado:
• Eles podem saber que alguns usuários não serão capazes de compreender ou
exprimir bem os requisitos do sistema.
• Eles podem desconfiar de que alguns dos usuários do nível operativo sejam rebeldes
que apresentarão requisitos falsos (ou requisitos que a direção não aprova).
• Eles podem recear que as entrevistas interfiram com as atribuições normais de
trabalho que os usuários tenham de executar. Por causa disso, desejarão marcar as
entrevistas para os momentos apropriados.
• Eles podem recear que as entrevistas sejam vistas como o início de um esforço de
substituição dos usuários humanos por um sistema computadorizado, provocando
demissões e coisas desse gênero.
• Eles podem considerar que eles próprios (os diretores) sabem mais a respeito dos
requisitos do sistema do que qualquer outro e por isso não desejam que você
entreviste qualquer usuário de nível operativo. Engenharia de Software
Prof. Walteno Martins Parreira Jr Página 15
• Pode estar havendo uma batalha política em andamento em um nível de chefia muito
mais elevado, entre o setor usuário e a organização de desenvolvimento de sistemas.
Desse modo, o gerente usuário pode não ter reais objeções a suas entrevistas, porém,
impedindo que elas sejam feitas, ele estará enviando uma mensagem política para o
chefe do chefe do seu chefe.
Por todos esses motivos, é uma boa medida obter uma prévia autorização. Na maior parte
dos casos, basta uma autorização verbal; se a organização for terrivelmente burocrática ou
paranóica, pode–se precisar de uma autorização escrita. Isso, a propósito, também significa
que o analista deve estar atento à política organizacional se tiver certeza da necessidade de
falar com um usuário (normalmente um usuário do nível operativo) com quem tenha sido
avisado para não conversar.
2.4.3 Planeje a Entrevista para Fazer Uso Eficiente do Tempo
O principal aspecto desta sugestão é que deve-se compreender que está tomando o tempo
do usuário e que ele (ou o chefe dele) pode achar até que o analista esteja desperdiçando o
tempo dele. Assim sendo, é importante o planejamento e preparação tão antecipadamente
quanto possível para poder fazer uso eficiente da entrevista.
A primeira coisa a fazer é certificar-se de que o usuário conhece o assunto da entrevista.
Em alguns casos isso pode ser feito por telefone; em outros, pode ser adequado preparar uma
lista das perguntas que serão feitas, ou dos tópicos que serão abordados, ou dos DFD que
necessita ser revisados, e remetê-la ao usuário com um dia ou dois de antecipação. Se não
puder fazer isso, é um indício de que de fato o analista não está preparado para a entrevista. E
se o usuário não tiver lido o material remetido, é sinal de que:
• está muito ocupado,
• está desinteressado,
• opõe-se a toda a idéia da entrevista ou
• é incapaz de entender as perguntas apresentadas.
Um aspecto relacionado: coletar, antes da entrevista, tantos dados pertinentes quanto
possível. Se houver formulários ou relatórios que sejam pertinentes à discussão, geralmente
poderá obtê-los antecipadamente. Se existirem outros documentos escritos do usuário
descrevendo o novo ou o antigo sistema consiga-os e estude-os antes da entrevista.
Se tiver preparado as perguntas antecipadamente, o analista deve ser capaz de realizar a
entrevista em uma hora ou menos. Isso é importante; não só o usuário é geralmente incapaz
de reservar mais do que uma hora de cada vez, mas também as pessoas normalmente não
conseguem se concentrar intencionalmente (principalmente se estiverem examinando
diagramas um tanto estranhos) por mais do que uma hora. Isso naturalmente significa que
deve-se organizar a entrevista para abranger um escopo relativamente limitado, focalizando
normalmente uma parte do sistema. Isso também pode significar que tenha de marcar algumas
entrevistas com o mesmo usuário para abranger inteiramente a área em que ele está
envolvido.
Finalizando, marcar uma reunião subseqüente para rever o material que foi coletado.
Normalmente, após a entrevista, o analista irá para sua mesa com todas as informações
colhidas na entrevista, e executará bastante trabalho com os dados brutos. Pode haver DFD a
serem desenhados ou itens a serem criados no dicionário de dados; cálculos de
custo/benefício podem precisar ser feitos; as informações provenientes da entrevista podem
precisar ser correlacionados com dados de outras entrevistas, e assim por diante. Em qualquer
caso, os dados dessa entrevista serão manipulados, documentados, analisados e convertidos
em uma forma que o usuário pode nunca ter visto antes. Desse modo, pode ser necessário
marcar uma entrevista posterior para verificar: Engenharia de Software
Prof. Walteno Martins Parreira Jr Página 16
• que o analista não cometeu nenhum engano em seu entendimento do que o usuário
lhe disse,
• que o usuário não mudou de opinião nesse ínterim,
• que o usuário entende a notação ou a representação gráfica dessas informações.
2.4.4 Utilize Ferramentas Automatizadas que Sejam Adequadas, Mas Não
Abuse
Durante a entrevista, pode-se achar conveniente utilizar ferramentas de prototipação,
principalmente se o objetivo da entrevista for discutir a visão que o usuário tem da interface
pessoa-máquina. De modo semelhante, se estiver revisando um diagrama de fluxo de dados e
discutindo possíveis modificações, poderá achar prático usar uma ferramentas CASE.
Lembre-se, que o objetivo dessas ferramentas é facilitar as discussões e não complicá-las;
elas devem permitir que o analista e o usuário examinem alternativas e modificações com
rapidez e facilidade; elas podem ajudar a registrar o conhecimento de um requisito do usuário e
corrigir imediatamente quaisquer erros que tenha sido cometido.
Se, a tecnologia introduzir-se no assunto, deve-se deixar fora da entrevista. Se o usuário
tiver de aventurar-se além de seu ambiente normal de atividade (para outro prédio, na sala do
computador) poderá encarar a ferramenta como um aborrecimento. Se o usuário não estiver
familiarizado com a tecnologia de computadores e for solicitado a utilizar a ferramenta, poderá
rejeitá-la. E se o analista não estiver familiarizado com a ferramenta (ou se a ferramenta for
lenta, apresentar erros ou de emprego limitado) isso interferirá sensivelmente na entrevista. Em
qualquer desses casos, talvez seja preferível usar a ferramenta off-line depois da entrevista;
então, poderá mostrar ao usuário a saída da ferramenta sem causar quaisquer problemas
desnecessários.
2.4.5 Tente Descobrir quais Informações o Usuário tem mais Interesse
Se o analista tiver de desenvolver um modelo completo de sistema para alguma parte de
um sistema, possivelmente necessitará determinar entradas, saídas, funções, características
tempo-dependentes e a memória armazenada do sistema. Porém a ordem em que se obtém
essas informações costumam não ter muita importância. Mas pode significar muito para o
usuário, e deve deixá-lo começar a entrevista por onde ele preferir. Alguns usuários desejarão
começar pelas saídas, isto é, pelos relatórios e valores de dados que eles querem que o
sistema produza (na realidade, eles talvez nem saibam que entradas serão necessárias para
produzir as saídas desejadas). Outros usuários poderão estar mais interessados nas entradas
ou nos detalhes de uma transformação funcional. Outros ainda preferirão falar sobre os
detalhes dos dados de um depósito de dados. Deve-se esforçar para enxergar os requisitos do
sistema da perspectiva desses usuários, e conservar esta perspectiva em mente quando fizer
as perguntas necessárias sua entrevista.
2.4.6 Use um Estilo Adequado de Entrevistar
Como diz William Davis [Davis, 1983]: Sua atitude em relação à entrevista é importante na
determinação de seu sucesso ou fracasso. Uma entrevista não é uma competição. Evite
ataques; evite o uso excessivo do jargão técnico; conduza uma entrevista, não uma tentativa
de persuasão. Fale com as pessoas, não fale muito alto, nem muito baixo, nem indiretamente.
Uma entrevista não é um julgamento. Faça perguntas detalhadas, mas não faça perguntas
para confirmar outras respostas. Lembre-se que o entrevistado é o perito e que é você que
precisa de respostas. Para concluir, de modo algum critique a credibilidade de outras pessoas. Engenharia de Software
Prof. Walteno Martins Parreira Jr Página 17
Fazer perguntas detalhadas nem sempre é fácil; dependendo da personalidade do
entrevistado e do tema da entrevista, pode-se precisar de um conjunto de estilos para extrair as
informações necessárias. Alguns estilos que podem mostrar-se úteis:
• Relacionamentos. Pedir ao usuário para explicar o relacionamento entre o que está
em discussão e as demais partes do sistema. Se o usuário estiver falando sobre um
assunto (p.ex.: um cliente), pedir-lhe que explique seu relacionamento sob outros
aspectos; se ele estiver descrevendo uma função (ex.: uma bolha de um DFD), pedirlhe que explique seu relacionamento com outras funções. Isso não só o auxiliará a
descobrir mais detalhes sobre o item em pauta, mas também o ajudará a descobrir
interfaces (ex.: fluxos de dados de uma bolha para outra no DFD) e relacionamentos
formais.
• Pontos de vista alternativos. Solicitar ao usuário que descreva o ponto de vista de
outros usuários em relação ao item que esteja sendo discutido. Perguntar ao usuário,
por exemplo, o que seu chefe pensa sobre uma bolha do DFD, ou um tipo de objeto
do DER; ou pergunte o que pensa seu subordinado.
• Detalhamento. Solicitar ao usuário uma informal descrição narrativa do item em que
estiver interessado. Fale-me sobre o modo como você calcula o valor das remessas.
Ou, se estiver falando com o usuário sobre um tipo de objeto no DER, poderia dizerlhe: Fale-me a respeito de um cliente. O que você sabe (ou precisa saber) sobre um
cliente?
• Dependências. Perguntar ao usuário se o item em discussão depende, para sua
existência, de alguma outra coisa. Isso é especialmente útil quando se discutem
possíveis tipos de objetos e relacionamentos no DER. Em um sistema de controle de
pedidos, por exemplo, pode-se perguntar ao usuário se seria possível haver um
pedido sem que haja um cliente.
• Confirmação. Dizer ao usuário o que acha que ouviu ele dizer; usar suas próprias
palavras em lugar das dele e peça confirmação. Pode-se dizer: Deixe-me ver se
entendi o que você disse...
2.5 Possíveis Formas de Resistência na Entrevista
Deve-se estar preparado para o fato de que alguns usuários serão contrários à idéia de
uma entrevista; essa é uma das razões para garantir que o chefe ou alguém com autoridade no
setor esteja ciente e tenha permitido a entrevista. Algumas das objeções mais comuns e
algumas possíveis respostas a essas objeções:
• Você está tomando tempo demais de mim. A resposta a isso é explicar que
compreende, e desculpar-se pelo tempo que precisará tomar, mas que já preparou
tudo e fará a entrevista no tempo mais curto possível. Isso naturalmente exige que o
analista chegue pontualmente na hora marcada para o início da entrevista, mantenha
a discussão no rumo previsto, e encerre-a no momento em que tenha dito que o faria.
• Você está ameaçando meu emprego. Isso muitas vezes é uma reação emocional
que pode ou não ter fundamento. Embora possa pensar em várias maneiras de
responder a esse comentário, lembre-se de que o analista não é o patrão dessa
pessoa e que não está em posição de garantir que o emprego dela não esteja em
perigo, ou de informá-la do contrário. Ele vai considerar o analista como o perito em
eficiência cuja tarefa é orientar a direção em como o emprego dele pode ser eliminado
pela informatização. A solução para esse problema, caso ele ocorra, é fazer com que
seja levado ao conhecimento dos níveis superiores dos usuários e obter o
pronunciamento oficial, se possível, pessoalmente ou por escrito. Engenharia de Software
Prof. Walteno Martins Parreira Jr Página 18
• Você não conhece nossa empresa, como você quer dizer-nos como deve ser o
novo sistema? A resposta a essa pergunta é: Você tem razão! E por isso que o estou
entrevistando para saber o que você pensa sobre quais devam ser os requisitos!. Por
outro lado, deverá sugerir várias maneiras de melhorar as coisas (especialmente se
parte ou todo o serviço realizado atualmente pelo usuário for em um antigo e
ineficiente sistema); assim, esse tipo de comentário pode ser inevitável. Entretanto, o
verdadeiro truque é continuar sendo tão respeitoso quanto possível e reconhecer
constantemente a experiência do usuário na sua área, embora continuando a
perguntar se ele poderia explicar-lhe porque sua idéia não funcionaria.
• Você está tentando mudar o modo como as coisas são feitas aqui. O artifício
neste caso é mostrar ao usuário que embora possa estar propondo algumas (radicais)
mudanças na implementação do sistema atual, não é pensamento modificar as
características essenciais desse sistema, exceto nas áreas onde eles mesmos tenham
solicitado uma alteração. Devemos lembrar, que algumas das características da
implementação do sistema atual podem ser preservadas, por causa das interfaces do
sistema atual com outros sistemas externos que exijam que as entradas ou saídas
apresentem formatos prescritos.
• Não queremos esse sistema. Esta é uma variação da queixa você está querendo
tirar meu emprego. A verdadeira resposta é que o analista está ali, conduzindo a
entrevista, porque a direção quer o novo sistema. Não é da sua competência
convencer os usuários operativos que eles devem querer o novo sistema; fazer isso é
colocar o peso da responsabilidade sobre seus ombros, onde ela não deve ficar.
• Por que você está desperdiçando nosso tempo com esta entrevista? Sabemos o
que queremos, e se você fosse competente, você saberia imediatamente o que
queremos. Por que você não vai em frente e constrói o sistema? Esta é uma
reclamação difícil de se lidar, porque relaciona-se com o fato fundamental de que os
usuários e os analistas de sistemas estão falando línguas diferentes e estranhas.
Lembre-se, que com a disponibilidade das linguagens de quarta geração e dos
computadores pessoais, o usuário pode achar que pode construir ele próprio o
sistema; sucessos fáceis com projetos simples (planilhas eletrônicas, por exemplo)
podem ter-lhe dado a impressão de que todos os sistemas são fáceis de implementar.
Isso pode explicar a impaciência em relação ao analista.
2.6 Outros Problemas
As diretrizes acima alertaram sobre os inúmeros problemas políticos com que o analista
pode se defrontar em uma entrevista e os muitos motivos pelos quais o usuário pode mostrarse hostil. Mas ainda existem alguns problemas para os quais deve-se estar atento:
• Uma discussão que focalize mais os problemas de implementação do que os
problemas dos requisitos. Isso muitas vezes ocorre quando o usuário diz: Eis como
eu gostaria que você construísse o sistema... . Isso acontece quase sempre quando o
usuário está raciocinando em termos da implementação do sistema atual; e pode
acontecer se o usuário conhecer alguma coisa da tecnologia de computadores (ex.:
quando ele possui um PC particular ou quando ele é um ex-programador). Lembrar
que não é obrigação em uma entrevista de análise descrever características de
implementação do sistema a não ser que sejam tão importantes que realmente
pertençam ao modelo de implementação do usuário.
• Confusão entre sintomas e problemas. Isso ocorre em muitas áreas, não apenas na
área do processamento de dados. O que pode acontecer nas entrevistas de análise de
sistemas. Entretanto, boa parte dele depende de onde a fronteira foi estabelecida no
diagrama de contexto: se a queixa do usuário é um sintoma ou um problema depende Engenharia de Software
Prof. Walteno Martins Parreira Jr Página 19
de ela estar associada a alguma coisa dentro dos limites do sistema ou fora deles.
Desse modo, deve-se dar especial atenção ao desenvolvimento do modelo ambiental.
• O usuário pode ser incapaz de explicar o que ele quer que o sistema faça ou
pode mudar de opinião. Esse é um problema comum e o analista de sistemas deve
estar preparado para ele. Quanto maior for esse problema mais importante torna-se a
prototipação.
• Desentendimento entre usuários de mesmo nível, subordinados e chefes.
Infelizmente, isso coloca o analista de sistemas no papel de mediador entre as partes
em desentendimento. Como analista, não pode abdicar desse papel; não pode dizer:
Quando vocês decidirem o que querem e entrarem em um acordo, procurem-me. Em
vez disso, deve-se agir como um negociador conduzindo todos os interessados a uma
sala e trabalhando com eles na tentativa de chegar a um consenso. Isso, infelizmente,
envolve habilidades e procedimentos fora do escopo deste texto.
• Descobrir disparidades entre o padrão oficial e a pratica do trabalho. Durante as
entrevistas, o analista descobre que podem existir algumas disparidades entre a
versão oficial de como o sistema funciona e como realmente ocorre no nível
operacional. Neste caso, o analista deve utilizar a diplomacia quando relatar estas
discrepâncias para a gerência, pois o pessoal de nível operacional pode relutar em
admitir que as operações nem sempre seguem os padrões oficiais de trabalho.
2.7 Formas Alternativas de Coleta de Dados
As entrevistas não são o único modo de coleta de informações sobre os requisitos de um
sistema. Na realidade, quanto mais informações puder colher de outras fontes, mais produtivas
poderão ser as entrevistas pessoais. Alternativas para as entrevistas:
• Questionários. Pode remeter questionários escritos para os usuários dentro da
organização, para as pessoas (ou setores) que interagem com o sistema, para os
diretores que aprovaram o projeto e para outros.
• Demonstrações feitas pelos fornecedores. Os fornecedores de hardware e os
fornecedores de software podem já haver desenvolvido sistemas prontos para a
aplicação em que você esteja interessado. Solicitando-lhes uma demonstração dos
recursos desses sistemas pode não somente auxiliá-lo a decidir se o produto é uma
boa solução, mas também revelar funções e dados armazenados que você pode não
ter percebido.
• Visitas a outras instalações. Procure outras empresas que estejam no mesmo ramo
de atividades ou que tenham sistemas semelhantes aquele em que você esteja
trabalhando. Combine uma visita à instalação para obter informações diretas sobre as
características e aptidões do sistema.
• Coleta de dados. Procure formulários, relatórios, manuais, procedimentos escritos,
registros, imagens de tela de terminais e listagens de programas que já existam na
organização usuária. Lembre-se, todavia, que esses recursos normalmente estão
relacionados com a implementação atual do sistema; devemos lembrar que isto
costuma incluir informações redundantes e/ou contraditórias e/ou obsoletas. Não
obstante, isto muitas vezes é um bom ponto de partida para você familiarizar-se com o
terreno antes de iniciar as entrevistas pessoais com o usuário.
• Pesquisa externa. Se você estiver construindo um sistema para uma nova aplicação,
para a qual o usuário não dispõe de qualquer experiência para descrever os
requisitos, talvez seja necessário tentar obter informações em sociedades
profissionais, ou em periódicos e livros técnicos e em relatórios de pesquisas. Engenharia de Software
Prof. Walteno Martins Parreira Jr Página 20
2.7.1 Questionário de Pesquisa
Essa ferramenta é muito conveniente quando há um grande número de usuários ou vários
grupos de usuários em locais diferentes. Nestas situações não é prático entrevistar todas as
pessoas, mas tão logo as informações obtidas através dos questionários tenham sido
analisadas, podem ser realizadas entrevistas com usuários selecionados.
Podem ser usados diversos formatos para o questionário de pesquisa, tais como: de
múltipla escolha, lista de verificação (checklist), questões abertas (descritivas) e combinações
das anteriores. Os passos para a utilização do questionário de pesquisa são:
a) Preparação do questionário:
• Identifique o tipo de informação que deseja obter, como problemas experimentados ou
oportunidades a explorar;
• Definidos os requisitos, escolha um formato apropriado para o questionário;
• Monte questões de forma simples, clara e concisa;
• Se incluir questões abertas, observar o espaço necessário para a resposta;
• Agrupar as questões por tópicos ou áreas afins;
• Se possível, enviar junto com o questionário uma carta da direção da empresa
explicando os motivos e a importância da pesquisa para a organização.
b) Identificação dos respondentes
• O questionário deve ser personalizado com o nome, função e localização do
respondente;
• Elaborar um controle de identificação das pessoas que receberão os questionários.
Utilizar o controle para monitorar a situação dos questionários.
c) Distribuição do questionário
• Distribua o questionário junto com as instruções de preenchimento;
• Indique claramente o prazo para a devolução do questionário e a forma de devolução.
d) Análise das respostas
• Consolide e análise as informações fornecidas pelos questionários devolvidos;
• Documente as principais descobertas;
• Envie uma cópia do relatório com as principais descobertas para cada respondente
como uma cortesia pelo tempo dedicado à pesquisa.
2.7.2 Observações no ambiente
A análise de observação é uma técnica de observação de fatos muito efetiva. Ela pode ser
usada para diversas finalidades, como processamento e confirmação de resultados de uma
entrevista, identificação de documentos que devem ser coletados para análise, esclarecimento
do que está sendo feito no ambiente atual.
Esta técnica é simples. Durante algum tempo, o analista fica observando os usuários em
seu ambiente enquanto eles executam suas tarefas diárias. Freqüentemente o analista fará
perguntas para conhecer o funcionamento e as atividades desenvolvidas. É importante explicar
para as pessoas que serão observadas o que será observado e porque. Os passos para a
observação são:
a) Antes: Engenharia de Software
Prof. Walteno Martins Parreira Jr Página 21
• Identifique as áreas a serem observadas;
• Obter a aprovação da gerencia apropriada para executar a observação;
• Obter os nomes e funções das pessoas-chaves que serão envolvidas no estudo de
observação;
• Explicar a finalidade do estudo;
b) Durante:
• Familiarizar-se com o local de trabalho a ser observado;
• Observar os agrupamentos organizacionais atuais;
• Observar as facilidades manuais e automatizadas em uso;
• Coletar amostras de documentos e procedimentos escritos que são utilizados nos
processos observados;
• Acumular informações estatísticas das tarefas observadas: freqüência que ocorrem,
estimativas de volumes, tempo de duração, etc...
• Enquanto interage com os usuários, tente ser objetivo e não comentar as formas de
trabalho de maneira não construtiva;
• Observar também as exceções;
• Terminando as observações, agradeça às pessoas o apoio e a colaboração
dispensada ao seu trabalho.
c) Após:
• Documente as descobertas resultantes das observações;
• Consolide os resultados;
• Reveja os resultados consolidados com as pessoas observadas e/ou com seus
superiores. c