Um dos principais medos que temos quando vamos entregar um sistema que estamos desenvolvendo, é ouvir a seguinte frase: “o sistema parece interessante, bem feito, mas…”. O grande problema está no “mas…”.
O que significa este “mas…”? Significa que alguma coisa está faltando, como por exemplo, uma funcionalidade fundamental, alguma informação necessária ou alguma característica de qualidade esperada. A questão é, porque esta funcionalidade, informação ou característica não foram entregues? Certamente é porque não foram lembradas na ocasião em que a equipe estava elicitando os requisitos. De quem é a culpa? Certamente não é do Usuário que foi interrogado. Com certeza é do Analista de Negócio. Então, o que faltou? Faltou o uso das técnicas e abordagens apropriadas para achar os requisitos.
Os requisitos existem nas mentes dos stakeholders. Cada stakeholder visualiza parte do problema do negócio cuja solução é refletida na forma de Necessidades, que precisam ser identificadas nas três esferas (ou camadas) administrativas da empresa: Estratégica, Tática e Operacional. Particularmente, gosto muito do verbo “achar”. Nosso papel é “achar” as Necessidades em toda a amplitude do negócio, ou seja, nas três esferas administrativas.
Muitas vezes, nos restringimos a identificar Necessidades somente na camada Operacional, porque envolve um público mais fácil de ser acessado, mas em algumas empresas, até esta camada é de difícil acesso. O fato é que a esfera Operacional abriga os usuários do sistema, ou seja, aqueles que interagem diretamente com o sistema. Se o analista de negócio analisar o problema somente do ponto de vista da camada Operacional, certamente irá identificar somente as Necessidades Operacionais do negócio.
Dessa forma, quando for entregar o sistema, os stakeholders Estratégicos e Táticos irão reclamar porque suas Necessidades não foram atendidas. Por isso irão dizer a tão temida expressão “sim, mas…”. Portanto, podemos concluir que as Necessidades existem, independentemente de achá-las ou não. O processo que nos leva a “achar” a totalidade das Necessidades requer o envolvimento das camadas Estratégica, Tática e Operacional.
O conjunto dessas Necessidades é usado como insumo no processo que leva à completa identificação dos requisitos de software. Em outras palavras, podemos afirmar que os requisitos de software são derivados a partir das Necessidades dos stakeholders. Se as Necessidades não forem completamente identificadas, isso implica que um determinado grupo de requisitos, conseqüentemente, não será identificado. Ora, se as Necessidades existem independentemente de achá-las, ou não, conseqüentemente os requisitos também existem, independentemente de achá-los, ou não.
É fácil achá-los? Claro que não. Mas este é o papel do Analista de Negócio. Em minhas aulas e palestras, gosto muito de usar a seguinte analogia. Elicitar requisitos é como achar agulha em um palheiro. As agulhas foram postas lá. Elas existem. Compete a nós achá-las.
Se não as encontrarmos, certamente iremos ouvir dos usuários: “Sim, o sistema parece interessante, mas…”.
