Como devemos extrair as necessidades dos clientes?

Por vezes, os clientes acreditam que estão nos passando os requisitos do sistema ao fato de apresentar uma lista simples de necessidades. Um requisito é uma coisa específica (clara, rastreavel, testavel, etc) e muitas vezes os requisitos que recebemos tem algumas destas coisas (mas não todas). A prática RD SP 1.1 começa como “extrair as necessidades” e nos pede pra executar um processo de identificação das necessidades dos requisitos.

Há muitas formas de “extrair” as necessidades de um cliente pois há empresas. Cada um com suas próprias características e estilos, mas há tópicos semelhantes e podemos oferecer alguns exemplos:

- Sessões de levantamento de dados entre o cliente e analistas de sistemas (ou requisitos) onde as necessidades são mapeadas e discutidas através de um simples quadro branco. Certifique-se de trazer sua câmera ou ter um celular que tire fotos visíveis. E sim, as fotos podem ser colocadas sob controle de configuração (e que podem “contar como prova” se adequadamente gerenciados e usados).

- Sessões de Brainstorming que são estruturadas através de uma ferramenta de mapas mentais como mind node (meu preferido) ou mindjet, mas se não tiver nada disso, faça no quadro branco também (e não esqueça da foto). Uma boa prática é começar o mapa pelos principais requisitos e ir detalhando-os o tanto quanto for possível. Use canetas de cores diferentes para destacar o que é crítico ou regras mais complexas. Abordagens gráficas normalmentente fazem um processo dito como “chato” (por seu cliente) em algo diferente e mais produtivo.

- Workshops de priorização onde o cliente apresenta ao pessoal de análise (ou engenharia de requisitos) o que é mais importante para ele. O que ele não pode viver sem? Esta abordagem diferente é muito boa para reduzir o escopo (e retirar perfumarias).

- Uma especificação de requisitos detalhada como uma RFP enviada em um processo de licitação. Isso é muito comum no governo e em grandes projetos. Normalmente elas passam as linhas gerais, mas… ajudam muito. O que você deve lembrar aqui é que o fato de você ter recebido um documento de 400 páginas de requisitos não te exime de fazer seu trabalho. Sempre há falhas.

- Em abordagens agile, protótipos, exemplos de telas ou até rascunhos são o primeiro insumo para o trabalho. Um material preliminar como esse vai ajudar muito seu cliente a definir o que estará mesmo no escopo (e o que ele quer). Este método, claro, é iterativo porque o cliente raramente sabe como passar o que ele realmente quer.

Interpretando literalmente, o CMMI nos diz para “extrair as necessidades”, mas lembre-se que o esforço real pode ser de horas, dias, semanas ou até mais e pode acontecer várias vezes ao longo do tempo de um projeto – O que resulta normalmente em vários releases.

Por fim… faça este trabalho ser algo divertido ao seu cliente… utilize sessões de brainstormind e mapas mentais e… divirta-se.