Depois de uma releitura dos conceitos de arquitetura e modelagem de negócios,  por que não uma série sobre outro tema que é muito caro para este {finito}, requisitos? Até hoje, publiquei apenas onze artigos sobre o tema. Eles estão soltos por aqui. E um tanto datados. Além disso, tenho visto um maior interesse pelo tema. Em buscas que caem neste site e papos que rolam por aí.

Esta série será elaborada em paralelo a uma revisão do material didático de dois treinamentos, {FAN} +Requisitos e {FAN} +Conversas. Os capítulos devem ser um pouco mais curtos e aparecer com mais frequência do que o normal. Nesta introdução aponto o caminho que será seguido e os principais tópicos abordados.

Uma Base de Conhecimentos

Faz tempo que uso o nome Base de Conhecimentos para apresentar o diagrama ao lado. A primeira intenção é didática, como tentarei mostrar no restante deste artigo. Mas, ah como eu gostaria de vê-lo devidamente implantando em uma empresa. Porque está ali praticamente tudo o que é preciso saber sobre projetos e requisitos.  Porque não há caixinhas soltas – nenhuma informação que não possa ser rastreada. Enfim, deixa pra lá (por enquanto).

No lado esquerdo do diagrama temos os quatro elementos fundamentais que compõem qualquer negócio: Objetivos, Recursos, Processos e Regras. Trata-se de um metamodelo de negócio cujo detalhamento está fora do escopo deste trabalho. Se você quiser entender um pouco mais sobre ele, dê uma olhada na série Pensando Negócios. Nos interessam aqui as duas ligações principais entre o modelo de negócios e os requisitos: 1. Requisitos do Negócio representam objetivos; 2. Funções suportam a execução de processos de negócios.

O diagrama sugere que objetivos de negócio podem ser quebrados em um ou muitos requisitos do negócio. Vejamos como isso poderia ou deveria acontecer.

Dirigentes da empresa ACME decidem que um de seus maiores objetivos para o próximo biênio é aumentar a lucratividade em 30%. Sabem que este ganho será produto de duas iniciativas principais: a) Aumento da base de clientes; e b) Redução dos custos de vendas. Ambas iniciativas apontam para uma única grande mudança: o processo de vendas deve ser totalmente revisto. Os vendedores devem ser capazes de realizar no mínimo 30 visitas por dia, um aumento de 50% em relação à média atual. A ACME está ciente de que precisa aprender duas coisas de forma que possa realizar o ganho de produtividade dos vendedores: i) Tornar as visitas de vendas mais eficazes (indicadores: número de negócios fechados e valor médio das vendas); e ii) Tornar as visitas mais eficientes (indicador: duração média de cada visita).

Utilizei uma poderosa ferramentinha para descrever os objetivos do negócio acima: o Balanced Scorecard. Como sugeri em outra oportunidade, sua última perspectiva (Aprendizado & Desenvolvimento) pode ser tratada como fonte (riquíssima) de Requisitos de Negócio. Repare que temos dois grandes requisitos neste momento: aumentar a eficácia e a eficiência das visitas de vendas. No próximo capítulo conversaremos bastante sobre eles.

Requisitos de negócio, dependendo de sua amplitude e complexidade, podem exigir o lançamento de diversos Projetos. Aqui poderíamos engatar uma conversa sobre programas e portfólios. Mas não é esta a intenção do artigo. Basta entender que determinados requisitos de negócio podem requerer n aprendizados e mudanças (leia-se n projetos).

Cada projeto é um conjunto de Requisitos. E talvez seja a hora de, pela milionésima vez, apresentar uma definição para essa palavrinha tão maltratada. Antes, uma definição que você só deveria utilizar como piada ou se quiser enrolar alguém (um belo exemplo de maltrato)¹:

“Ao ler o Guia BABoK® é vital que ‘requisito’ seja tomado pelo sentido mais amplo possível. Requisitos incluem, mas não estão limitados a condições ou capacidades passadas, presentes e futuras em uma organização e descrições de estruturas organizacionais, papéis, processos, políticas, regras e sistemas de informação. Um requisito pode descrever o estado presente ou futuro de qualquer aspecto da organização.”

Um requisito é simplesmente a expressão de uma necessidade ou restrição. Ponto. Se preferir uma definição mais formal, apele ao Houaiss: re.qui.si.to s.m. condição necessária para alcançar certo fim. PONTO! Para que complicar?

O que é necessário, isso sim, é uma visão bem estruturada dos principais tipos de requisitos. Como ilustra o diagrama acima, eles são três:

Estas definições, nada menos que fundamentais, não deveriam mudar dependendo da escola, metodologia ou ferramental empregado. Uma função será sempre uma função, não importa se ela foi descrita na forma de uma user story, uma especificação de caso de uso ou em um documento pra lá de formal.

Pretendo bater forte nos conceitos. Martelá-los mesmo. Mas não ignorarei o lado prático, o trabalho real com requisitos. A série obedecerá a sequência sugerida neste artigo, ou seja: Requisitos do Negócio, Requisitos, Funções, Atributos e Restrições. Cada tema  merecerá no mínimo dois artigos. Semana que vem: Requisitos do Negócio – Os únicos que podem manchar para sempre o seu currículo. Soou dramático? Foi esta a intenção. Inté!

Notas

1. O Guia BABoK® (ainda) não mudou mas eu passo a impressão de estar cada dia mais azedo em relação a ele, né? Não é só impressão não. Mas meu alvo não é mais o BABoK e sim a comunidade que insiste em espalhá-lo sem o mínimo senso crítico. Se senso crítico é uma das principais qualidades esperadas de um analista de negócios, o que dizer? O que fazer? O quanto chorar? Melhor é deixar pra lá.
2. Não passarei toda a série escrevendo “produto, serviço ou sistema”. Vamos combinar o seguinte: nos próximos capítulos vou escrever apenas “sistema”. Por favor, entenda que pode se qualquer tipo de sistema. Um liquidificador é um exemplo de sistema, ok?