Pular para o conteúdo principal

Técnicas de levantamento de requisitos

Em um post anterior demos alguns exemplos de técnicas utilizadas para levantamento de requisitos de projetos.

"Há várias técnicas utilizadas para isso, como por exemplo: leitura de obras de referência e livros texto, observações do ambiente do usuário, entrevistas com os usuários, entrevistas com especialistas do domínio -funcionários velhos de guerra que provavelmente utilizarão o seu sistema-,reutilização de análises anteriores, comparação com sistemas preexistentes do mesmo domínio do negócio."

Hoje, falaremos mais profundamente das principais técnicas utilizadas para o levantamento de requisitos de projeto.

Entrevistas

Possivelmente a forma mais utilizada e mais simples para o levantamento de requisitos. O entrevistador prepara um ambiente para que o entrevistado se sinta confiante e seguro para dar as respostas às perguntas formuladas pelo entrevistador. É feito bem no formato de perguntas e respostas mesmo, onde as respostas são os inputs de informação para a definição dos requisitos.
É um processo interativo que pode envolver um ou mais entrevistadores ou entrevistados, mas é bom ficar atento para não envolver pessoas demais ao mesmo tempo e no negócio descambar para uma discussão generalizada. Mais uma coisa, se for aplicar a técnica com dois entrevistadores, planeje-se para que um aplique a entrevista enquanto o outro faz as anotações necessárias e fique atento para requisitos que passaram batidos. Minha sugestão, se possível entreviste pelo menos três futuros usuários (em ocasiões diferentes) do sistema que você está projetando e sempre grave a entrevista para que nenhum detalhe seja perdido. Desta forma você acaba com a necessidade de mais um analista para a aplicação do método e pode rever as respostas a qualquer momento.

Você pode aplicar o método de duas formas
  • Através de entrevistas fechadas - onde as perguntas são definidas previamente, ou;
  • Através de entrevistas abertas - onde não existe um roteiro. O entrevistador vai fazendo várias perguntas a fim de desenvolver um senso crítico das principais necessidades do entrevistado.
Não preciso de dizer que a aplicação exclusiva de entrevias abertas depende muito fortemente da experiência do entrevistador, assim a probabilidade de darem certo sozinhas é muito pequena. O que normalmente é feito, é uma mescla das duas formas. Uma para direcionar o foco da entrevista e a outra para inserir um pouco de improviso para questões que saírem do roteiro previamente preparado.

Agora, para preparar um ambiente saudável para que a entrevista ocorra eu sugiro que:
  • O entrevistador fale menos que o entrevistado, ou seja, seja um bom ouvinte. Se você ficar falando demais o entrevistado para ficar acanhado para responde-lo ou perder a confiança em você. Demonstre interesse no que ele está falando (neurolinguística).
  • Você quer colher informação, certo? Então não vá achando que você já sabe tudo. Assim, o seu julgamento ficará deturpado e no final da entrevista você vai ter direcionado o entrevistado para confirmar aquilo que você achava, não porque estava certo, mas porque você estava cego para as necessidades do entrevistado.
  • Fique atento as opiniões do entrevistado por que só ele sabe o problema que está passando, então ouça-o. Muitas vezes, uma de suas opiniões revela o problema principal.
As pessoas em geral são cooperativas, então deixe o ambiente favorável a isto. Não cometa gafes, não zombe do entrevistado, não use um linguajar que não seja apropriado ao ambiente coorporativo, não faça piadas e nem comentários maldosos e/ou qualquer ação que possa causar uma má impressão, minando assim o ambiente colaborativo onde você chegou.
As informações obtidas através da entrevista complementam outras informações obtidas através de documentos, observações etc. Assim, essa técnica deve ser usada em conjunto com outras técnicas de levantamento de requisitos.

Planejamento

O planejamento da entrevista é essencial para que tudo transcorra bem. Sendo assim, prepare-se:
  • Estude o material existente sobre o domínio e a organização: se familiarize com o vocabulário do negócio e utilize-o. É bem vergonhoso quando o entrevistado fala algum termo comum para o ambiente e você não faz a menor ideia do que ele está falando. Conhecendo o linguajar você economiza tempo evitando perguntas sobre assuntos básicos.
  • Defina um objetivo claro para a entrevista: não comece a entrevista sem um direcionamento, você vai andar em círculos e vai irritar o seu entrevistado. Defina a área sobre a qual as perguntas serão feitas, que informações você pretende levantar.
  • Identifique os potenciais entrevistados: inclua pessoas dos diversos níveis da organização. Mas escolha com cautela e se possível peça ajuda do cliente para a escolha pois uma escolha errada inviabiliza toda a entrevista. Além disso, como eu falei anteriormente, não entreviste todos ao mesmo tempo (a não ser que você queira testar as suas habilidades de gestão de conflitos). Entreviste cada um separadamente em um ambiente calmo e sem a presença do chefe, para evitar inibições.
  • Prepare o entrevistado: marque a entrevista com antecedência para que o entrevistado tenha tempo para se preparar. Negocie um tempo, não ultrapassando 2hrs. Geralmente o entrevistado que irá falar com você quanto tempo ele tem disponível para atende-lo, assim priorize as questões principais e mais relevantes e quebra a entrevista em várias partes se necessário.
  • Prepare a entrevista: defina o tipo de questões que serão aplicadas na entrevista, como você irá registrar (se possível grave o áudio), procure realizar a entrevista dos assuntos mais sensíveis em um ambiente reservado e tente ao máximo utilizar um local onde não haverá um alto nível de interrupções (isso acaba destruindo a linearidade do raciocínio do entrevistado, acabando com o ritmo da entrevista).

Roteirize a sua entrevista

Prepare um roteiro com as perguntas que você ache relevante, pense nas possíveis respostas para as perguntas e quais perguntas podem complementa-las, é importante para conduzir a entrevista e mesmo que a siga linearmente o escript programado, o roteiro vai te conduzir para o fechamento da entrevista. Veja no seu roteiro se não ficou uma pergunta para traz e se todos os assuntos foram abordados. Para isso faça o controle de questões.

Em geral as suas perguntas vão ser de 3 tipos:
  • Subjetivas: que permitem respostas abertas. Usadas parar colher opiniões ou em situações exploratórias;
  • Objetivas: que limitas as respostas possíveis. Induzem a respostas curtas e diretas sobre determinado assunto, sem muito espaço para divagações;
  • De aprofundamento: exploram os detalhes de uma outra questão (objetiva ou subjetiva).
A técnica 5W+2H possivelmente irá abranger todos os aspectos dos tipos de questões. Assim se você conseguir obter respostas para todas as dimensões desta técnica, dificilmente alguma coisa ficou para traz.



Faça perguntas simples para obter respostas simples. Ao fazer perguntas longas é bem possível que o entrevistado responda somente uma fração do que foi perguntado, assim já faça a pergunta fracionada (economize tempo).

Se o seu entrevistado ficar em dúvida sobre a resposta de alguma questão é interessante que ela seja replicada para outros entrevistados a fim de reduzir erros e conflitos nas respostas dos entrevistados.

Estruture a sua entrevista

A estrutura de uma entrevista diz respeito a forma como as questões estão organizadas dentro do roteiro. Há 3 formas estruturadas básicas de se organizar as questões de sua entrevista:
Estrutura de pirâmide ou abordagem indutiva: inicia com questões objetivas e, à medida que progride, questões mais subjetivas são inseridas. É útil para situações em que o entrevistado precisa de um "aquecimento" para falar de um determinado assunto ou quando o você deseja obter uma finalização sobre um assunto.


Estrutura funil ou abordagem dedutiva: inicia com questões mais subjetivas e, à medida que a entrevista segue, perguntas objetivas são inseridas. Provê um meio mais fácil e amigável de começar uma bateria de entrevistas. Permite levantar informações detalhadas, sendo desnecessárias longas sequências de questões objetivas e de aprofundamento.
 
 
Estrutura de diamante ou mista: "um pouco de cada", começa com questões especificas depois passa a questões mais gerais e voltando no final com questões especificas. É uma boa forma de estruturar a entrevista, visto que mantém o interesse do entrevistado em uma variedade de questões. Entretanto é mais longa.

Por fim, você pode utilizar a abordagem não estruturada, onde não há uma definição especifica da sequência das questões. A entrevista é sequenciada de acordo com o "andar da carruagem", a cada resposta caminhos possíveis são avaliados e uma sequência é estabelecida. Ocorre em um diálogo mais natural, porém exige muita experiência do entrevistador. Geralmente requer mais tempo para se ter um resultado relevante. Vale ressaltar que, mesmo que as sequências das questões não tenham sido definidas, as questões em si foram. Ou seja, o planejamento ainda é necessário.

Pesquisa/Questionário

Consiste na aplicação de questionário às partes interessadas e posterior análise das respostas. Como se trata de um questionário, não há interação entre o analista e o respondente durante a resposta ao questionário e permite uma rápida obtenção de informações quantitativas e qualitativas de um público alvo numeroso.

Pela similaridade com a entrevista, pode (e é aconselhável) ser utilizada para projetar um questionário com base no que foi descoberto em uma entrevista ou para refinar respostas que não ficaram claras em um questionário.

Usando o questionário após a entrevista, um analista pode estar procurando quantificar o que foi levantado em entrevistas ou determinar como um sentimento expresso em uma entrevista é realmente difundido ou limitado. Por outro lado, questionários podem ser usados para examinar uma grande amostra de usuários para sentir problemas ou levantar questões importantes, antes de se programar entrevistas.

São um meio eficiente de coletar informações de vários interessados e são úteis quando:
  • As pessoas necessárias estão geograficamente dispersas;
  • Há um grande número de pessoas envolvidas no projeto do sistema e é necessário saber qual proporção de um lado do grupo aprova ou desaprova uma particular característica do sistema proposto;
  • Se deseja saber a opinião global antes de se definir qualquer direção específica para o projeto, em um estudo exploratório;
  • Deseja-se assegurar que os problemas com o sistema corrente foram identificados e tratados em entrevistas que se seguem.

Preparação do questionário

O questionário deve ter questões claras e não ambíguas, fluxo bem definido e administração planejada para detalhes. Além disso, devem-se levantar, antecipadamente, as dúvidas das pessoas que vão respondê-lo.
Questionários podem ter questões objetivas ou subjetivas, porém deve-se tomar cuidado com questões subjetivas pois é impossível listar todas as respostas possíveis para uma pergunta. Assim, deve-se antecipar o tipo de resposta que se espera obter e as respostas devem ser restritas o suficiente para guiar as pessoas para que respondam de uma maneira especifica. Deve-se ainda, tomar cuidado para não permitir respostas muito amplas pois pode dificultar a comparação e interpretação dos resultados. Já as questões objetivas devem ser utilizadas quando é possível listas as possíveis respostas e quando há uma grande amostra de pessoas a examinar. Respostas a questões objetivas são facilmente quantificáveis enquanto as subjetivas são analisadas e interpretadas de maneira diferente.

Assim como na entrevista, conhecer o linguajar do negócio é extremamente importante para que o analista escreva as questões de modo a refletir a terminologia aplicada ao negócio. Assim, tanto as perguntas quanto as respostas serão mais fáceis de interpretar.

Dicas: Para verificar a qualidade do questionário, aplique-o a um grupo piloto pedindo atenção detalhada aos termos utilizados; sempre que possível, use o vocabulário das pessoas que irão responder o questionário, prime pela simplicidade; utilize perguntar simples e curtas; evite a redação tendenciosa; garanta que as questões estão tecnicamente precisas antes de incluí-las no questionário.

Para ordenar as questões, considere os objetivos e, então, determine a função de cada questão para atingir a esses objetivos. Use um grupo piloto para auxiliar ou observe o questionário com os olhos de quem irá responder. Coloque questões que são importantes para serem respondidas primeiro, agrupe itens de conteúdo similar e observe tendências de associação, coloque as questões menos controversas primeiro.

Por fim, os questionários podem ser aplicados de duas formas. Reunindo todos aqueles que irão responder em um mesmo local para aplicação, permitindo uma alta taxa de retorno, instruções uniformes e resultados rápidos ou permitindo que os respondentes administrem quando vão responder ao questionário, correndo o risco de as pessoas esquecerem ou propositalmente ignorarem o questionário.

Vantagens e desvantagens da aplicação de questionários

 


Observação

Nesta técnica, o analista observa os usuários executando os processos no dia-a-dia, sem interferência direta (como um aprendiz) e faz anotações sobre como as tarefas são executadas na prática. O objetivo principal é ganhar conhecimento sobre o que ocorre de fato no ambiente de trabalho e levantar informações que passariam despercebidas quando outras técnicas são usadas.

Através da observação é possível capturar:

  • Requisitos derivados da maneira como as pessoas realmente trabalham e não da maneira como os processos são documentados ou explicados. É possível derivar requisitos implícitos que refletem os processos reais (e não os formais) com os quais as pessoas estão envolvidas.
  • Requisitos derivados do relacionamento entre o indivíduo que toma decisões e outros membros da organização. Esses requisitos são derivados da colaboração e do conhecimento das atividades de outras pessoas.
Por outro lado, essa técnica não é apropriada para obter requisitos de domínio, bem como pode ser difícil identificar novas características a serem acrescentadas ao sistema. Assim, a observação deve ser combinada com outras técnicas de levantamento de requisitos.
Quando aplicadas em conjunto, observação pode ser usada para confirmar ou negar informações de entrevistas e/ou questionários. Também se podem entrevistar as pessoas observadas para completar informações obtidas de uma observação. A observação pode ser combinada também com a prototipagem. Uma vez construído um protótipo, podem-se observar os usuários utilizando o protótipo, de modo a avaliar o mesmo e derivar novos requisitos. Além disso, deve-se ressaltar que a efetividade de uma observação pode variar na medida em que os usuários têm tendência a ajustar o modo como realizam suas tarefas quando sabem que estão sendo observados. Neste cenário avalie interromper a observação se a diferença for muito significativa, seja porque está atrapalhando o trabalho dos observados ou porque o trabalho passou a ser realizado de forma distinta da usual.

Planejando a aplicação


No planejamento, o analista deve definir o que observar, quem observar, quando, onde, porque e como.
É muito importante despender um tempo conhecendo as pessoas envolvidas e estabelecendo uma relação de confiança.
Deve-se assumir que as pessoas que estão sendo observadas são boas em seu trabalho e procurar capturar meios não padronizados de trabalhar. Esses meios frequentemente apontam para eficiências no processo de trabalho que foram incorporadas a partir da experiência individual.
Devem-se tomar notas detalhadas das práticas de trabalho durante a observação e redigir um relatório. É possível aprender bastante com os detalhes de como as pessoas trabalham. Somente após diversos desses detalhes terem sido coletados, é que um quadro coerente vai emergir.
É útil que o analista, antes de iniciar o trabalho, informe as pessoas e diga como a observação vai ser conduzida e seu propósito.

No que se refere à definição de quando realizar a observação, é importante não considerar apenas se o indivíduo (ou indivíduos) a serem observados estarão trabalhando nos processos de interesse no período agendado, mas também se esse processo de negócio de interesse tem uma ocorrência significativa no período considerado.

Prototipação

 

Um protótipo é uma versão inicial do sistema que é desenvolvido no início do processo de desenvolvimento. Neste caso, o protótipo é desenvolvido com o propósito de apoiar o levantamento e a validação de requisitos. Assim, uma característica essencial é que ele seja desenvolvido rapidamente.

A prototipagem é uma técnica valiosa para o levantamento de requisitos. Ela torna os requisitos mais reais e diminui lacunas de entendimento. Ao colocar o usuário na frente de uma porção inicial ou uma imitação do sistema, a prototipagem estimula os usuários a pensar e a estabelecer um diálogo sobre os requisitos. As considerações tecidas sobre o protótipo ajudam a se obter um entendimento compartilhado dos requisitos.

A principal razão para se desenvolver um protótipo é resolver incertezas a respeito dos requisitos do sistema o mais cedo possível. Assim, essas incertezas devem ser usadas para decidir que partes do sistema prototipar e o que se espera aprender com as avaliações do protótipo.

A prototipagem permite capturar as reações iniciais do usuário em relação ao sistema. Essas reações podem ser obtidas através de observação, entrevistas, questionário ou relatório de avaliação e podem ser usadas para guiar iniciativas em direção de melhor atender as necessidades dos usuários, bem como para ajudar a estabelecer (ou rever) prioridades e redirecionar planos. Usuários, por sua vez, podem vislumbrar novas capacidades, não imaginadas antes da interação com o protótipo e que surgiram da experimentação com o mesmo.

Vale a pena tomar nota: Se um protótipo for desenvolvido para apoiar o levantamento de requisitos, faz sentido utilizá-lo posteriormente na validação. Contudo, não vale a pena desenvolver um protótipo apenas para apoiar a validação de requisitos.

Quanto as camadas de arquitetura que são efetivamente implementadas, um protótipo pode ser:
  • Não-operacional ou de interface: como está implícito no nome, não funciona. Apenas a camada de interface foi implementada. O sistema não faz nenhum processamento propriamente dito.
  • Operacional: funciona como se supõe que o sistema real deveria funcionar e implementa de alguma forma todas as camadas da arquitetura do sistema.

Quanto ao uso futuro, um protótipo pode ser:
  • Descartável: não se pretende utiliza-lo como parte real do sistema a ser fornecido.
  • Evolutivo: é desenvolvido para se aprender mais sobre o problema e se ter a base de uma parte ou de todo o software a ser fornecido.

Quanto ao conjunto de funcionalidades, um protótipo pode ser:
  • Características selecionadas: apenas uma porção do sistema é implementada no protótipo.
  • Completo: o protótipo apresenta todas as características do que se imagina ser o sistema real.

Usuários são fundamentais na prototipagem. Para capturar as reações dos usuários em relação ao protótipo, outras técnicas de levantamento de informação devem ser usadas em conjunto. Durante a experimentação do usuário com o protótipo, pode-se utilizar observação. Para capturar opiniões e sugestões, podem ser empregados, além da observação, entrevistas e questionários.

Passos úteis para o desenvolvimento de um protótipo:


  • Defina o propósito de um protótipo antes de começar a construí-lo.
  • Trabalhe com módulos gerenciáveis: para fins de prototipagem não é necessário e muitas vezes, nem desejável, construir um sistema completo.
  • Construa o protótipo rapidamente: a construção de um protótipo durante as fases de levantamento e análise de requisitos não pode consumir tempo em demasia, caso contrário perde sua finalidade. Para acelerar a construção, use ferramentas adequadas.
  • Modifique o protótipo em iterações sucessivas: o protótipo deve ser alterado em direção às necessidades do usuário. Cada modificação requer uma nova avaliação.
  • Enfatize a interface com o usuário: as interfaces do protótipo devem permitir que o usuário interaja facilmente com o sistema. Um mínimo de treinamento deve ser requerido. Sistemas interativos com interfaces gráficas são muito indicados à prototipagem.


Vantagens e desvantagens da prototipação

Vantagens
  • Permite alterar o sistema mais cedo no desenvolvimento, adequando-o mais de perto às necessidades do usuário (menor custo de uma alteração).
  • Permite descartar um sistema quando este se mostrar inadequado (análise de viabilidade).
  • Possibilita desenvolver um sistema que atenda mais de perto as necessidades e expectativas dos usuários, na medida em que permite uma interação com o usuário ao longo de todo o ciclo de vida do desenvolvimento.
Desvantagens
  • Gerência do projeto: Normalmente, várias iterações são necessárias para se refinar um protótipo. Sob esta ótica, surge uma importante questão: quando parar? Se essa questão não for tratada com cuidado, a prototipagem pode se estender indefinidamente. É importante, pois, delinear e seguir um plano para coletar, analisar e interpretar as informações de feedback do usuário. Além disso, em alguns casos, trabalhar com protótipos pode ser caro e demandar muito tempo.
  • Considerar o protótipo como sendo o sistema final: o maior risco da prototipagem é que usuários, ao verem um protótipo rodando, concluam que o projeto está próximo de seu fim, achando que o protótipo é o sistema final. Analogamente, os desenvolvedores podem se sentir tentados a transformar protótipos descartáveis no sistema, não levando em conta que a qualidade pode não ter sido apropriadamente considerada. Assim, gerenciar expectativas é fundamental para um uso bem sucedido da prototipagem. Todos que veem o protótipo devem entender seu propósito e suas limitações.

Comentários

Postagens mais visitadas deste blog

Histórias de usuários e análise MoSCoW

Olá Pessoas! Vocês sabem o que são histórias de usuários? Você, desenvolvedor maroto, tá lá na tranquilidade do seu cubículo, quando um ser surgindo de Deus sabe onde pede que você desenvolva um sistema com centenas de features por que a planilha de excel dele tá dando pau. Daí você, experiente e sincero manda a real prá ele... Em tradução livre:1-Eu não posso te dar todas essas funcionalidades na primeira versão; 2-E cada funcionalidade precisa de ter o que chamamos de "História de usuário"; 3-OK, vou te dar uma história: você me dá todas as funcionalidades ou eu vou arruinar a sua vida.   Bom, no quadro acima temos uma ideia bem humorada do que é uma história de usuário. Normalmente utilizada em métodos ágeis de desenvolvimento, a história de usuário é uma descrição simples -em linguagem natural- e curta -normalmente em um parágrafo- das funcionalidades que o sistema deve ter para atender aos objetivos do cliente negócio . Mas, não são os requisitos que ...

Estudo de Viabilidade

Já falamos um bocado de coisas sobre análise de requisitos de sistemas: o que são esses tais requisitos, como identifica-los e documenta-los. Beleza, e agora? Agora, eu quero voltar um pouco no tempo e perguntar uma coisa muito importante. Será que vale a pena desenvolver um sistema? A resposta a princípio parece ser trivial, mas não é. Se tomarmos como base uma empresa grande, com muitos funcionários e um orçamento bem gordinho, que tem parte de suas operações atreladas a planilhas de Excel, a resposta tende para o SIM. Mas, se mudarmos as condições, talvez o investimento em um sistema informatizado não se justifique (neste momento). É por isso que existe uma técnica chamada de análise de viabilidade e que deveria ocorrer antes da concepção de qualquer projeto, ou quando se percebe a necessidade do tal projeto. Daí você me fala, mas não sou eu que tenho que fazer isso. Meu trabalho só começa quando essa atividade já foi realizada e a resposta para a pergunta já foi dada. E você tem...