Materiais, Manuais e Tutoriais>JAVA>Entrevista

Entrevista

A obtenção de requisitos é o processo de reunir informações sobre os sistemas existentes e sobre o sistema proposto. Para isso são usadas como fontes de informações documentações atuais, conhecimento de usuários do sistema e outros participantes do projeto e especificação de sistemas atuais utilizados e de outros sistemas similares.

 

Uma técnica simples, importante e que pode ser utilizada em qualquer situação é a entrevista.

 

Uma entrevista pode ser aberta ou fechada:

 

  • Entrevista Aberta, não existe um roteiro a ser seguido, o entrevistador explora vários assuntos e busca uma compreensão mais ampla das necessidades;
  • Entrevista Fechada, o entrevistado responde a um conjunto de perguntas específicas e pré formuladas.

 

Na prática costuma ser realizada uma mistura desses dois tipos, procurando utilizar o melhor dos dois mundos, tendo algumas perguntas para serem usadas como ponto de partida e perguntas chave que serão importantes para o projeto e prosseguindo de forma mais livre (mas mantendo foco) para entender melhor as necessidades do entrevistado.

 

A entrevista é bastante útil para o entendimento geral do sistema atual e para entender as dificuldades enfrentadas e novas necessidades dos usuários. Mas ela pode ser menos eficiente para obtenção de requisitos ligados as estruturas organizacionais, pois nem sempre numa organização a estrutura real de tomada de decisões coincide com a estrutura oficial e esse tema geralmente é um assunto “tabu”.

 

Para uma entrevista produtiva o Analista de Requisitos ou Analista de Sistemas precisa de uma prévia preparação (estruturação da entrevista). Algumas dicas são:

 

  • Preparação de uma lista de perguntas iniciais e perguntas importantes. Nessas perguntas, num primeiro momento, é importante uma maior liberdade e evitar a indução de respostas, em fases mais adiantadas poderão ser utilizadas perguntas com respostas mais fechadas;
  • Revisão das perguntas momentos antes da entrevista e eventualmente consultas (se forem necessárias e breves) poderão ser feitas durante a entrevista;
  • Antes da entrevista é útil fazer uma pesquisa sobre a empresa e sobre o entrevistado, isso evitará desperdício de tempo, mas informações importantes devem ser verificadas durante a entrevista;
  • Repostas poderão ser anotadas numa agenda durante a entrevista ou gravadas eletronicamente (muitas pessoas se sentem desconfortáveis com informações sendo gravadas, então...). O ideal é manter um equilíbrio de tempo entre anotações e perguntas, tentando não “quebrar” o raciocínio e a entrega de informações do entrevistado.


Modelo de uma entrevista estruturada:


Parte 1 – Estabelecendo o perfil do cliente/usuário

 

Previamente poderão ser pesquisadas informações como nome do entrevistado, cargo, nome da organização, ramo de atividade, entre outras informações relevantes.

 

No inicio da entrevista algumas perguntas são:

 

Quais são as suas responsabilidades?

Quais são os produtos do seu trabalho?

Para quem você gera esses produtos?

Como é medido o seu sucesso?

Quais são os problemas que interferem para o sucesso de seu trabalho?

O que, se existe, facilita ou dificulta o seu trabalho?

 

Parte 2 - Avaliando o Problema

 

Para quais problemas faltam boas soluções?

 

Quais são? (Dica: Continue perguntando, “Mais algum?”).

 

Para cada problema, pergunte:

  • Por que esse problema existe?
  • Agora, como resolvê-lo?
  • Como você poderia resolvê-lo?

Parte 3 - Entendendo o Ambiente do Usuário

 

Quem são os usuários?

Qual é a sua formação?

Qual é a sua experiência em computação?

Os usuários são experientes nesse tipo de aplicação?

Quais plataformas são usadas?

Quais são os planos para a futura plataforma?

Outras aplicações usadas são relevantes para essa aplicação? Se sim, fale um pouco sobre elas.

Quais são as suas expectativas para a usabilidade do produto?

Quais são as suas expectativas para o tempo de treinamento?

Que tipo de auxílio ao usuário você precisa (ex: cópia impressa ou documentos on-line).

 

Parte 4 - Recapturando para Entender

 

Você me disse que:

(Liste os problemas que o cliente descreveu com suas próprias palavras).

  • ·
  • ·          
  • ·          
  • ·          

Eles representam adequadamente os problemas que você está tendo com a solução existente?

Quais outros problemas, caso exista, você está enfrentando?

 

Parte 5 - Suposições do Analista sobre o Problema do Cliente

 

(Valide ou invalide suposições).

(Se não foi discutido) Quais problemas, se houver, estão associados: (Liste quaisquer necessidades ou problemas adicionais que você acha que está preocupando o cliente ou o usuário).

  • ·          
  • ·          
  • ·          

Para cada problema sugerido, pergunte:

 

Esse é um problema real?

  • Quais são as razões deste problema?
  • Como você gostaria de resolvê-lo?
  • Qual é o peso da solução desse problema, comparado aos outros que você mencionou?

 

Parte 6 - Avaliando a sua Solução (se aplicável)

 

(Resuma as principais capacidades da solução que você propôs).

O que aconteceria se você conseguisse:

  • ·          
  • ·          
  • ·          

Como você classificaria cada uma dessas capacidades, por ordem de sua importância?

 

Parte 7 - Avaliando a Oportunidade

 

Quem na sua organização precisa dessa aplicação?

Quantos usuários desse tipo usariam a aplicação?

O que você considera que seja uma solução bem sucedida?

 

Parte 8 - Avaliando Necessidades de Segurança, Desempenho e Suportabilidade (pode não ser aplicável a todos os usuários)

 

Quais são suas expectativas sobre a segurança?

Quais são suas expectativas sobre o desempenho?

Você irá dar suporte ao produto ou serão outras pessoas que farão isso?

Você tem necessidades especiais de suporte?

O que você pensa sobre a manutenção e serviços de rede?

Quais são os requisitos de segurança?

Quais são os requisitos de instalação e configuração?

Existem requisitos especiais de licenciamento?

Como o software será distribuído?

Existem requisitos de etiquetagem ou de empacotamento?

 

Parte 9 - Outros Requisitos

 

Existe algum requisito legal, de regulação, ambiental ou de padronização que deva ser atendido?

Você acha que existem outros requisitos que devemos conhecer?

 

Parte 10 - Fechamento

 

Existe alguma outra questão que eu deveria ter feito?

Se depois, eu tiver alguma dúvida, posso ligar para você? Enviar e-mail?  Você concorda em participar de uma revisão de requisitos?

 

Parte 11 - Resumo do Analista

 

Depois da entrevista, e enquanto as informações estiverem frescas em sua mente, resuma as três necessidades ou problemas de maior prioridade identificados pelo usuário/cliente.

 

1.

2.

3.

 

Os resultados das entrevistas deverão ser compilados. É esperado que se encontrem necessidades e problemas comuns entre os entrevistados. Esse será o inicio de um “repositório” de requisitos que dará origem aos futuros documentos de requisitos.

Embora seja importante, a entrevista não deve ser o único método de obtenção de requisitos, mas utilizada em conjunto com outros métodos.

 

 

 

Fontes:

 

SOMMERVILLE, Ian. Engenharia de Software. 8. edição. São Paulo. Pearson Education do Brasil. 2007.

LEFFINGWELL, Dean; WIDRIG, Don. Managing Software Requirements. 1. edição, Reading MA, Addison-Wesley Professional. 1999.

Compartilhe com seus amigos!



Teste de mesa | Tecnologia | Ciência | Informática