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” [1], 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” [2]. O problema é que no mesmo livro, “Software Requirements” [2], 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” [3], 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” [4]. 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. [E é, no diagrama acima é o que chamo de Requisito do Usuário. É também o nome do Caso de Uso]. 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 [2], 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).
The Casos de Uso, Requisitos Funcionais e Probleminhas [Atualizado] by finito, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Brazil License.
Artigos relacionados:
- Um Novo Modelo para Casos de Uso
- Estruturando Requisitos – Parte 1
- (Requisitos) Levanta aí que eu Coleto daqui
- Use Case 2.0: Você precisa dele?
- Engenharia de Requisitos: O Projeto Aslam [atualizado]
Related posts brought to you by Yet Another Related Posts Plugin.
{ 2 comments… read them below or add one }
Paulo,
Concordo em gênero, número e grau com a sua linha de pensamento.
Mais especificamente com as colocações:
“i) Os Casos de Uso “são realmente os requisitos”; e ii) Mas não representam todos os requisitos.”
e
“um caso de uso deve se limitar a explicar o QUE o usuário precisa, não COMO sua necessidade será satisfeita.”
Penso que o real conjunto de requisitos funcionais e não-funcionais são aqueles que levarão ao alcance das metas e objetivos do negócio.
Portanto, mesmo que um (alguns?) requisito não tenha sido previsto na etapa de análise, tanto pelo Analista de Negócios quanto pelo cliente, ele ainda é um requisito, uma vez que ele deveria ser parte integrante da solução proposta para o alcance mas metas e objetivos desejados.
O objetivo do negócio não deve (ou pelo menos não deveria) deixar de ser atingido devido a uma falha de Análise de Negócio (seja por ineficiência do AN ou por omissões do cliente).
Sei que o parágrafo acima soa estranho, mas a realidade é que somos humanos, e como tal é importante termos um processo de desenvolvimento que nos permita correções e ajustes em busca da melhor solução.
Ronan
Eu acho interessante o debate, mas acho que as escolas estão misturadas. o Cockburn, é um dos pais do XP, e quando ele fala sobre casos de uso, o enfoque metodológica é diferente. O Wiegers, também era agnóstico até pouco tempo atrás, quando ele emprestou o seu conhecimento para a Microsoft. Outro ponto, para que não haja confusão é que o caso de uso puro, como foi inventado pelo Jacobson, tem por intuito descrever os requisitos funcionais. Existe um bom compêndio a respeito de separação de requisitos funcionais (hoje a normal e amplamente aceita da IEEE), do Swebok. Obviamente existem diversas tentativas de conversão de um para outro e etc.
Particularmente sou da opinião que uma vez adotada uma linha, não se deve mudar, e um pouco mais além, não se deve comparar. Depois de dar muita aula sobre engenharia de requisitos pura, descobri que quanto mais falava de Jacobson, mais especialistas em Cockburn apareceiam com dúvidas.
Outra coisa que acho que deve ser separa são casos de uso de negócio. Finalmente não posso deixa de dizer, que se sua abordagem é mais ampla, como por exemplo o processo unificado, ou qualquer um dos seus sabores, terá que ser considerado a visão 4+1, disciplinas que vêm antes e depois (aliás pelo que me lembro o Bitner trabalhou na Rational). Nessa situação o caso de uso, nunca vai dizer como fazer, pois isso é papel da disciplina de design.
{ 1 trackback }