web
counter
+Requisitos: As Funções

+Requisitos: As Funções

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 [cliente/usuário], 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
Em conversas sobre marketing e inovação o termo jobs-to-be-done (trabalhos a executar) é colocado como se fosse um ovo de Brunelleschi³. Quase sempre acompanhado da famosa frase do Levitt. Faz sentido trazer esse papo para cá e fazer duas observações. Uma função é um job-to-be-done – um trabalho que o cliente ou usuário precisa executar. Peço perdão pela obviedade, mas esta primeira observação se fez necessária.

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:

  1. 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.
  2. 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).
  3. 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.