Finalmente retomo a série sobre Requisitos e Conversas. O tema de hoje são as funções. Depois de descobrir por que determinada solução é necessária, devemos nos concentrar no que ela deve realizar.
Vale a pena relembrar o mapa que guia esta série. No lado esquerdo do diagrama temos a representação do destino da solução. Vemos ali um negócio qualquer² desenhado no mais alto nível possível. Enxergamos apenas seus quatro componentes fundamentais: Objetivos, Recursos, Processos e Regras. Este bloco possui duas ligações com o conjunto de requisitos (em azul). A primeira mostra os Requisitos do Negócio representando os Objetivos. Hoje nos interessa a segunda relação, aquela que diz que Funções suportam Processos de Negócio. Em outras palavras, uma função ajuda alguém¹ a realizar determinado trabalho.
Função, segundo o Houaiss, é “o uso a que se destina algo”. Uma função sempre representa uma ação. Em conjunto, as funções são tudo o que um sistema deve fazer. Descobri-las é um trabalho relativamente simples. As perguntas que nos ajudam a chegar a elas são:
- O que o produto/sistema deve fazer por você?
- Como você gostaria de usar este produto/sistema?
- O que o produto/sistema não deveria fazer?
O “relativamente simples” do parágrafo anterior a(o) incomodou? É provável que sim. Afinal, a grande maioria das pessoas que trabalha com requisitos não vê simplicidade em quase nada de seu dia a dia. A complicação neste ponto vem das respostas dos entrevistados. Clientes e usuários não estão acostumados a estruturar suas respostas. Atributos, restrições, preferências, regras de negócios e, não raro, comentários inteligentes sobre a instabilidade do mundo (do clima, dos negócios, do humor do cônjuge etc) vão completar e poluir as funções pedidas. É responsabilidade do analista a faxina em cada resposta. Ele sabe que o trabalho será menos árduo se suas perguntas forem boas.
A última questão nos lembra que tão importante quanto saber tudo o que o produto/sistema deve realizar é entender o que ele não deve fazer. No trabalho de desenvolvimento de requisitos é crucial que estas questões sejam colocadas em sequência durante um mesmo evento (reunião, entrevista). Desta forma orientamos clientes e usuários a pensar em um número maior de possibilidades.
Mas, existem casos em que os entrevistados simplesmente não sabem o que pedir. Casos onde não obtemos respostas para as questões acima ou, pior ainda, as respostas são incompreensíveis. Momento de tirar da cartola duas solicitações mágicas:
- Prezado , por favor, me conte como você trabalha hoje; ou
- Me mostre como você trabalha hoje
Se a história motivada pela primeira solicitação não fizer muito sentido, lançamos mão da segunda. É quando utilizamos a ferramenta social Observação (apresentada anteriormente nesta série). A quantidade de ruídos gerada a partir dessas solicitações é potencialmente maior que aquela originada das três questões anteriores. Por outro lado, a história narrada ou observada pode ser mais conclusiva. De uma forma ou de outra, a história precisa ser registrada. Como fazê-lo? Veremos no próximo capítulo.
A Nomenclatura Utilizada
Por que não “Requisitos Funcionais”? A distinção entre requisitos funcionais e não-funcionais é meio grosseira. E cria muita confusão, apesar de ser a nomenclatura mais comum em nossos livros técnicos. Por isso esta série adota os termos sugeridos por Gerald Weinberg e Donald Gause no melhor livro sobre requisitos já escrito, Exploring Requirements – Quality Before Design (Dorset House, 1989).
A palavra “funcional” adjetiva algo – o qualifica. Ela anda na moda. Tanto que hoje em dia temos até iogurtes funcionais!
Jobs-to-be-done
O cliente não quer uma broca com ¼ de polegada, quer um furo de ¼ de polegada. Theodore Levitt
A segunda tem a ver com a frase do Levitt. Pense bem, o que o cliente fará com o furo de ¼ de polegada? Qual é a sua real necessidade? Pendurar um quadro, uma prateleira? Ou espiar a formosa vizinha?
Notas:
- Não me esqueci de quem utilizará as funções. O tema já foi tratado anteriormente, por isso não fará parte desta série.
- Se tirarmos as Regras, aquele mágico metamodelo rabiscado acima representa qualquer tipo de destino, ou, melhor dizendo, qualquer tipo de sistema (você, um hardware, uma cidade – enfim, qualquer tipo de sistema).
- Colombo ficou com a fama, mas foi o arquiteto italiano Brunelleschi quem primeiro colocou um ovo em pé. O fez para ilustrar como construiria o famoso domo da Catedral de Florença. E não, esta informação não aparece em Inferno, de Dan Brown.
