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.
Breve: Processos de Obtenção de Requisitos – Parte (2/8) – Questionário
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.
Nenhum comentário:
Postar um comentário