Passei os últimos três meses em uma fase exaustiva - e exaustiva - de levantamento de requisitos de um grande projeto e aprendi, acima de tudo, que não existe uma solução única para todos . Não há processo, nem segredo, que funcione em todos os casos. A análise de requisitos é uma habilidade genuína e, quando você pensa que finalmente descobriu tudo, fica exposto a um grupo totalmente diferente de pessoas e precisa jogar tudo o que sabe pela janela.
Diferentes partes interessadas pensam em diferentes níveis de abstração.
É fácil dizer "falar em nível de negócios, não técnico", mas não é necessariamente tão fácil de fazer . O sistema que você está projetando é um elefante e suas partes interessadas são os cegos que o examinam . Algumas pessoas estão tão profundamente imerso no processo e rotina que eles nem sequer percebem que não é um negócio. Outros podem trabalhar no nível de abstração que você deseja, mas tendem a fazer afirmações exageradas ou até falsas, ou se envolver em pensamentos desejosos.
Infelizmente, você simplesmente precisa conhecer todos os indivíduos como indivíduos e entender como eles pensam, aprender a interpretar as coisas que eles dizem e até decidir o que ignorar.
Dividir e conquistar
Se você não quer que algo seja feito, envie-o para um comitê.
Não se encontre com comitês. Mantenha essas reuniões o menor possível. YMMV, mas, na minha experiência, o tamanho ideal é de 3-4 pessoas (incluindo você) para sessões abertas e 2-3 pessoas para sessões fechadas (ou seja, quando você precisa de uma pergunta específica respondida).
Tento me encontrar com pessoas que têm funções semelhantes no negócio. Há realmente muito pouco a ganhar e muito a perder ao jogar o pessoal de marketing na sala com os contadores de feijão. Procure as pessoas que são especialistas em um assunto e peça que conversem sobre esse assunto.
Uma reunião sem preparação é uma reunião sem propósito.
Algumas outras respostas / comentários fizeram referência à técnica do palhaço, que é excelente para aquelas pessoas problemáticas das quais você simplesmente não consegue obter respostas. Mas não contar com palha-homens demasiado muito, ou as pessoas mais vai começar a se sentir como se estivesse ferrovias eles. Você deve gentilmente cutucar as pessoas na direção certa e permitir que elas apresentem as especificidades, para que elas sintam que são donas delas (e, de certa forma, elas são donas delas).
O que você precisa é de algum tipo de modelo mental de como você acha que os negócios funcionam e como o sistema deve funcionar. Você precisa se tornar um especialista em domínio , mesmo que não seja especialista na empresa específica em questão. Pesquise o máximo possível sobre seus negócios, seus concorrentes, sistemas existentes no mercado e qualquer outra coisa que possa estar relacionada remotamente.
Uma vez nesse ponto, achei mais eficaz trabalhar com construções de alto nível, como casos de uso, que tendem a ser agradáveis a todos, mas ainda é essencial fazer perguntas específicas. Se você começar com "Como você cobra seus clientes?" , você estará em uma reunião muito longa. Faça perguntas que impliquem um processo em vez de limitar o processo no início: Quais são os itens de linha? Como eles são calculados? Quantas vezes eles mudam? Quantos tipos diferentes de vendas ou contratos existem? Onde eles são impressos? Você entendeu a ideia.
Se você perder um passo, alguém normalmente lhe dirá. Se ninguém reclamar, dê um tapinha nas costas, porque você acabou de confirmar implicitamente o processo.
Adie discussões fora do tópico .
Como analista de requisitos, você também está desempenhando o papel de facilitador e, a menos que você realmente goste de passar todo o seu tempo em reuniões, precisa encontrar uma maneira de manter as coisas no caminho certo. Ironicamente, esse problema se torna mais pernicioso quando finalmente as pessoas conversam. Se você não tomar cuidado, pode atrapalhar o trem que você gastou tanto tempo preparando os trilhos.
No entanto - e aprendi isso da maneira mais difícil há muito tempo - você não pode simplesmente dizer às pessoas que um problema é irrelevante . É obviamente relevante para eles , caso contrário eles não estariam falando sobre isso. Seu trabalho é conseguir que as pessoas digam "sim" o máximo possível e colocar uma barreira como essa apenas o leva ao território "não".
Esse é um equilíbrio delicado que muitas pessoas são capazes de manter com "itens de ação" - basicamente uma fila genérica de discussões que você prometeu voltar em algum momento , normalmente marcada com os nomes das partes interessadas que pensavam que era realmente importante. Isso não é apenas por causa da diplomacia - também é uma ferramenta valiosa para ajudar você a lembrar o que aconteceu durante as reuniões e com quem conversar se precisar de esclarecimentos mais tarde.
Analistas diferentes lidam com isso de maneiras diferentes; alguns como o quadro público ou o flip-chart, outros silenciosamente o inserem em seus laptops e seguem delicadamente outros tópicos. Tudo o que você se sentir confortável.
Você precisa de uma agenda
Provavelmente isso é verdade para quase qualquer tipo de reunião, mas é duplamente verdadeiro para reuniões de requisitos. À medida que as discussões se arrastam, as mentes das pessoas começam a se afastar e começam a se perguntar quando você vai entender o que realmente importa. Ter uma agenda fornece alguma estrutura e também ajuda a determinar, como mencionado acima, quando você precisa adiar uma discussão que está ficando fora de tópico.
Não entre lá sem uma idéia clara do que exatamente você quer cobrir e quando . Sem isso, você não tem como avaliar seu próprio progresso, e os usuários o odiarão por muito tempo (assumindo que eles ainda não o odeiam por outros motivos).
Mock It
Se você usar o PowerPoint ou o Visio como uma ferramenta de mock-up, sofrerá com o problema de parecer polido demais . É quase um vale estranho de interfaces de usuário; as pessoas se sentirão confortáveis com desenhos de guardanapos (ou desenhos gerados por computador que se parecem com desenhos de guardanapos, usando uma ferramenta como Balsamiq ou Sketchflow ), porque eles sabem que não é a coisa real - mesma razão pelas quais as pessoas são capazes de assistir personagens de desenhos animados. Mas quanto mais ela se parece com uma interface do usuário real, mais as pessoas querem escolher e mexer nela, e mais tempo gastam discutindo sobre detalhes que são insignificantes.
Definitivamente, faça simulações para testar sua compreensão dos requisitos ( após os estágios iniciais da análise) - elas são uma ótima maneira de obter um feedback muito rápido e detalhado - mas mantenha-as organizadas e não se apresse até que você ' você tem certeza de que está prestando atenção nos seus usuários.
Lembre-se de que uma simulação não é uma entrega , é uma ferramenta para ajudar no entendimento. Assim como você não esperaria ser mantido cativo ao seu mock ao fazer o design da interface do usuário, você não pode assumir que o design está OK simplesmente porque eles deram o polegar para cima ao seu mock-up. Já vi zombarias usadas como muleta, ou pior, como desculpa para ignorar completamente os requisitos; verifique se você não está fazendo isso. Volte e transforme esse mock em um conjunto real de requisitos.
Seja paciente.
É difícil para muitos programadores acreditarem, mas para a maioria dos projetos não triviais, você não pode apenas sentar uma vez e elaborar uma especificação funcional completa. Não estou falando apenas de paciência durante uma única reunião; a análise de requisitos é iterativa da mesma maneira que o código. O Grupo A diz algo e, em seguida, o Grupo B diz algo que contradiz totalmente o que você ouviu do Grupo A. Então, o Grupo A explica a inconsistência e acaba sendo algo que o Grupo C esqueceu de mencionar. Repetir 500 vezes e você tem algo mais ou menos parecido com a verdade .
A menos que você esteja desenvolvendo algum aplicativo CRUD minúsculo (nesse caso, por que se preocupar com os requisitos?), Não espere obter tudo o que precisa em uma reunião, duas ou cinco. Você vai ouvir muito, falar muito e se repetir bastante. O que não é uma coisa terrível, lembre-se; é uma chance de criar um relacionamento com as pessoas que inevitavelmente assinarão a entrega.
Não tenha medo de mudar sua técnica ou improvisar.
Diferentes aspectos de um projeto podem realmente exigir diferentes técnicas de análise. Em alguns casos, a UML clássica (diagrama de caso de uso / atividade) funciona muito bem. Em outros casos, você pode começar com KSIs comerciais ou fazer um brainstorming com um mapa mental ou mergulhar diretamente em modelos, apesar do aviso anterior.
A conclusão é que você precisa entender o domínio por conta própria e fazer sua lição de casa antes de perder o tempo de outras pessoas. Se você souber que um departamento ou componente específico possui apenas um caso de uso, mas é incrivelmente complicado, pule a análise de casos de uso e comece a falar sobre fluxos de trabalho ou fluxos de dados. Se você não usaria a mesma ferramenta para todas as partes da implementação de um aplicativo, por que você usaria a mesma ferramenta para todas as partes dos requisitos?
Mantenha seu ouvido no chão.
De todas as dicas e sugestões que li para a análise de requisitos, essa é provavelmente a que é mais frequentemente ignorada. Sinceramente, acho que aprendi mais a espionar e ocasionalmente travar conversas com bebedouros do que em reuniões agendadas.
Se você está acostumado a trabalhar isolado, tente descobrir onde está a ação para poder ouvir a conversa. Se não puder, faça rondas frequentes, para a cozinha ou o banheiro ou onde quer que seja. Você descobrirá todos os tipos de coisas interessantes sobre como a empresa realmente opera ouvindo o que as pessoas se gabam ou reclamam durante seus intervalos de café e fumaça.
Por fim, leia nas entrelinhas .
Um dos meus maiores erros no passado foi estar tão focado no resultado final que não tive tempo para realmente ouvir o que as pessoas estavam dizendo . Às vezes - na maioria das vezes - pode parecer que as pessoas estão tagarelando sobre nada ou insistindo em algum procedimento que soa totalmente inútil para você, mas se você realmente se concentrar no que elas estão dizendo, perceberá que realmente existe um requisito enterrado lá - ou vários.
Tão brega e insípida quanto parece, os Cinco Porquês é uma técnica realmente útil aqui. Sempre que você tiver essa reação "idiota" (não que você diria isso em voz alta), pare-se e transforme-a em uma pergunta: Por quê? Por que essas informações são digitadas novamente quatro vezes, depois impressas, fotocopiadas, digitalizadas, impressas novamente, fixadas em um painel de partículas, filmadas com uma câmera digital e finalmente enviadas por e-mail ao gerente de vendas? Não é uma razão , e eles podem não saber o que é, mas é o seu trabalho para descobrir. Boa sorte com isso. ;)