Levantamento de requisitos

Hoje o papo é sobre o começo do processo de engenharia de software: os requisitos.

Vou começar com uma analogia que gosto de fazer. Imagine que você não se sentiu bem e foi a um pronto-socorro. Agora, imagine que o médico que o atendeu não examinou direito e já receitou um remédio, mas não era exatamente para o problema que você tinha. Você não melhora, vai a outro médico, que o analisa corretamente, pede exames complementares e dá um diagnóstico mais preciso, encaminhando ao tratamento adequado.

Bem, se você quiser sair fazendo o software, sem fazer o levantamento e a análise dos requisitos, você estará receitando um remédio para um problema que você nem sabe qual é. Não parece nada bom, não é mesmo?

Os requisitos servem para formalizar o domínio do problema. Não que software ou o negócio do seu cliente sejam problemas. É que se chama de problema o desafio que se tem ao preparar um software para apoiar um determinado objetivo, normalmente de algum negócio.

A arquitetura e a codificação ficam mais com o que chamamos de domínio da solução. Mas para saber qual solução propor, é essencial que se entenda profundamente o problema.

Quem conhece e é a melhor referência para fornecer informações para o domínio do problema? Normalmente quem solicitou o software, a quem costumamos chamar de cliente. Algumas convenções de nomenclatura: quem paga pelo software é o patrocinador do projeto; quem é envolvido ou afetado pelo software, o stakeholder. Vou generalizar aqui e chamar todos de clientes.

Primeira lição e bastante significativa: é muita arrogância do analista achar que sabe mais que seus clientes a respeito do negócio em torno do software. No domínio do problema, quem reina soberano é o cliente, não a equipe responsável por fazer o software.

Em contrapartida, quando o assunto é domínio da solução, quem deveria responder por essa é a equipe técnica. É claro que os analistas podem opinar, sugerir, contribuir com os requisitos, ajudando o cliente a descrevê-los e a pensar de uma forma mais simples e objetiva, assim como o cliente pode dar sugestões na solução técnica. Neste caso, quem deve dar a palavra final é o arquiteto responsável. Ele vai dizer se a dica dada pelo cliente será utilizada no projeto. Não é porque o cliente falou que quer o software feito de um jeito que esta necessariamente é a melhor forma.  Resumindo: quem bate o martelo para o domínio do problema é o cliente enquanto para o domínio da solução, o arquiteto.

Levantar requisitos é um exercício complexo. Envolve extrair ideias da cabeça do cliente e traduzi-las em um texto formal, passível de avaliação. Precisamos saber quando um requisito foi implementado com sucesso, de forma objetiva. Eu vejo que o pulo do gato está em perceber que a análise é uma tarefa, de certa forma, ligada à área de humanas, já que envolve compreender o outro, exercitando a empatia. O analista de sistemas deve se colocar no lugar do cliente e tentar experimentar o domínio do problema, viver aquilo.

Por outro lado, é muito comum que esse analista tenha um pé na área de exatas, com uma linha de raciocínio mais parecida com a de um engenheiro. Essa questão de afinidade com ciências humanas ou exatas varia de pessoa para pessoa e simplesmente não tem um certo ou errado. Tudo é questão de perfil.

Se o analista já tem essa facilidade de comunicação e praticar empatia, excelente! No entanto, ele pode ter facilidade de entender os processos e enxergar a cadeia produtiva, bem como suas particularidades, com uma visão de engenharia, que também agrega bastante.

Segunda ideia que quero deixar hoje: o analista de sistemas é um facilitador. Ele ajuda o cliente a se expressar e dar forma às suas ideias, para que a equipe da solução técnica tenha insumo para trabalhar. O cliente conhece do negócio, mas quem sabe escrever requisitos é o analista.

Provocações finais 

No seu contexto, quem define a solução é a mesma pessoa que falou do problema? Está clara a fronteira dos domínio de problema e de solução?
Você considera que seu usuário consegue ajudar na elicitação de requisitos? Você chama seus usuários carinhosamente de "protousuários"? Você acha que seu cliente não sabe o que quer? 


Comentários

  1. Boa noite Murilo, infelizmente durante a formação acadêmica não temos do que é ou como funciona a regra de negócio (salvo aqueles que ja estão no dia a dia dos negócios). Ficaria muito mais fácil muitas das aulas e explicação. Creio, que na maioria das vezes, a gal arrogância que você citou vem de analistas que não conhecem regra de negócio. Sem sombra temos que ter técnicas para entender o que nosso cliente esta querendo dizer, ai concordo sobre de Humanas. Quem conhece é o cliente, o solicitante, o usuário chave, como sera feito, somente nós podemos dizer.
    Obrigado.

    ResponderExcluir

Postar um comentário

Postagens mais visitadas deste blog

Brilho nos olhos

Um breve olhar do que já foi escrito

Requisitos conflitantes e dilemas no projeto de software