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

Requisitos conflitantes e dilemas no projeto de software

Arquitetura em projetos de aplicações em nuvem - noções iniciais