Seqüência obrigatória do último post. A motivação é a seguinte afirmação: “Os passos em um Caso de Uso são Requisitos Funcionais“. A questão parece simples mas esconde alguns “probleminhas”. Minha intenção aqui, além de justificar minha afirmação, é debater os tais “probleminhas”.
Variações do diagrama acima aparecem nas oficinas do programa para Formação de Analistas de Negócios (FAN) e pintou também no seminário do último sábado. Todo mundo parece entender o diagrama sem problemas, mas só repara que a frase que negritei no primeiro parágrafo está implícita no desenho quando executamos os primeiros exercícios. Reparem: um Caso de Uso é um conjunto de Requisitos Funcionais. O nome do caso de uso é um Requisito do Usuário – um requisito funcional que carece de detalhamento. Eu realmente não entendia direito a razão de tanta estranheza, os motivos pelos quais tanta gente acha que passos em um caso de uso e requisitos funcionais são coisas totalmente diferentes. Desconfio que o problema esteja em nossas fontes, praticamente em todas elas.
Alistair Cockburn, em “Writing Effective Use Cases” , diz que podemos utilizar casos de uso em diferentes situações: Descrever um processo de negócio; Documentar o projeto (design) de um sistema; Discutir requisitos (sem descrevê-los); e Representar os Requisitos Funcionais de um sistema. Sobre esta última possibilidade, que é a que nos interessa aqui, Cockburn pede que a gente não se esqueça de duas coisinhas: i) Os Casos de Uso “são realmente os requisitos”; e ii) Mas não representam todos os requisitos.
A mensagem de Cockburn não ganha muito eco em outros trabalhos muito conhecidos. Karl Wiegers, por exemplo, chega a dizer que “na teoria, um conjunto de casos de uso compreende toda a funcionalidade requerida em um sistema” . O problema é que no mesmo livro, “Software Requirements” , Wiegers sugere que “o analista pega as descrições de casos de uso e começa a derivar os requisitos funcionais”. Wiegers defende enfaticamente a existência de um grande documento, uma SRS (Software Requirements Specification) que deve listar todos os requisitos (funcionais e não-funcionais), regras de negócio e outras informações desenvolvidas pelo analista.
Em outro trabalho, “More About Software Requirements” , Wiegers ‘desce do muro’, insistindo que “casos de uso não substituem os requisitos funcionais”. Ele rebate a visão apresentada por Kurt Bittner e Ian Spence em “Use Case Modeling” . Os dois autores afirmam que “no final das contas, todos os requisitos funcionais podem ser capturados como casos de uso, e muitos dos requisitos não-funcionais podem ser associados aos casos de uso”. Desnecessário dizer, mas defendo a visão de Cockburn, Bittner e Spence: Casos de Uso são os Requisitos Funcionais.
As variações em torno desta visão são curiosas. Tyner Blain, por exemplo, parte de uma uma sugestão de Karl Wiegers para gerar a visão representada pelo diagrama acima. Mas, caramba, não vejo ninguém afirmar com todas as letras que “passos em um caso de uso são requisitos funcionais”. Ou melhor, quase ninguém. Depois de uma rápida vasculhada (googlada?) descobri que Kevin Brennan, VP do IIBA, afirmou que “a maioria dos passos em um caso de uso são, de fato, requisitos funcionais”. Quase… Maioria? Prefiro ser mais direto: todos os passos são requisitos funcionais. Eliminando ambiguidades facilitamos o aprendizado e aumentamos a praticidade de uma ferramenta, no caso, dos casos de uso.
No seminário da semana passada minha sugestão foi confrontada por alguns participantes, principalmente por uma senhora que ilustrou seu questionamento com um belo e simples exemplo: uma máquina de café. Segundo ela, “tomar um café” é um requisito. . Na sequência ela citou os passos (que seriam executados por quem quer “tomar um café”):
- Coloca uma moeda
- Seleciona o tipo de bebida
- Retira o copo
O que são os 3 passos acima? Não são funções requeridas pelo usuário para satisfazer sua necessidade ou objetivo maior (tomar um café)? Funções requeridas = Requisitos Funcionais, não? Por que, como sugere Karl Wiegers , eu precisaria extrair requisitos dos passos acima? Para redigi-los de uma forma diferente? Algo como “o usuário precisa de um lugar para colocar a moeda”? Oras… pra quê?
Mas eu temo que a confusão esconda outro probleminha, ainda mais sério. Considere que o passo 2 tenha gerado algo mais ou menos assim: “o usuário pressiona o botão referente ao tipo de bebida que quer”. Talvez o exemplo não esteja muito legal, mas quem disse que precisa ser um botão? E se a interface for outra? O que eu tento ilustrar aqui é que um caso de uso deve se limitar a explicar o QUE o usuário precisa, não COMO sua necessidade será satisfeita. Colocarei minha preocupação de outra forma: quando um caso de uso entra no domínio da solução, explicando ou apontando como determinado requisito será satisfeito, ele perde sua utilidade. Outras ferramentas, como protótipos, storyboards, modelos e código, são mais adequadas para a demonstração do COMO. Casos de uso existem exclusivamente para explicar o QUE o usuário precisa. Portanto, deveria ser utilizado apenas para o aprendizado e domínio do problema.
Mas, como tudo em nossa área, há controvérsias. E diversas outras sugestões, mais ou menos lógicas (e / ou viáveis). Quando insisto em minha proposta tenho dois objetivos: criar uma fronteira mais nítida entre problema e solução (SoC? sorry periferia purista); e simplificar – fornecer uma visão mais coesa de todas as informações necessárias para o desenho de uma solução.
Para encerrar, uma feliz coincidência: há exatamente 1 ano e 1 dia Hugh MacLeod publicava um cartoon que tem tudo a ver com a mensagem aqui: “It’s not what the software does. It’s what the user does.” Deveria virar um poster-lembrete na sala-mesa de todo AN.
Atualização:
Logo depois da publicação deste post troquei um breve papo com o mestre José Paulo Papo. Além de confirmar que concorda com minha sugestão, ele enviou uma preciosa dica ignorada na bibliografia abaixo: “Use Cases: Requirements in Context”, de Daryl Kulak e Eamonn Guiney (Pearson Education, 2003). Tks Papo!
Bibliografia:
- Writing Effective Use Cases
Alistair Cockburn. Addison-Wesley (2001). - Software Requirements
Karl E. Wiegers. Microsoft Press (1999). - More About Software Requirements
Karl E. Wiegers. Microsoft Press (2006). - Use Case Modeling
Kurt Bittner e Ian Spence. Addison-Wesley (2003).
Minha palestra foi a segunda, logo depois do Adail. Baita responsabilidade mas, por outro lado, peguei a platéia devidamente aquecida por TOC, Corrente Crítica e as boas sugestões do Adail. Aliás, antes que eu mergulhe nos meus assuntos, vale dizer que o evento é muito rico exatamente pela diversidade de temas e visões. O Papo apresentou o OpenUP e o Juan (como um maestro na foto ao lado), falou sobre Scrum.
Provocações: i) Caso de Uso não é documentação; ii) Matriz de rastreabilidade não é solução; e iii) Engenharia de Requisitos não significa burocracia e falta de agilidade. Foram as 3 explícitas. A que mais gerou debate, claro, foi a primeira. Principalmente quando eu disse que não consigo entender quando alguém me explica que “levanta os requisitos e depois escreve os casos de uso”. Melhor, o bicho pegou mesmo quando eu falei que jogo os casos de uso no lixo tão logo eles tenham cumprido sua nobre utilidade: ajudar equipe e usuários e clientes a *aprender* os requisitos. Até de “agilista” eu fui chamado, vejam só! hehe.. “Você está dizendo que só o código basta como documentação de um sistema?” Claro que não foi o que eu disse.