" link="" lightbox="yes" url="http://www.pfvasconcellos.eti.br/blog/wp-content/uploads/2008/02/fig5-1b.jpg" ]

Casos de Uso, Requisitos Funcionais e Probleminhas [Atualizado]

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”.

Núcleo da Base de Conhecimentos do ANVariaçõ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.

Resumo de Tyner BlainAs 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é”):

  1. Coloca uma moeda
  2. Seleciona o tipo de bebida
  3. 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:

  1. Writing Effective Use Cases
    Alistair Cockburn. Addison-Wesley (2001).
  2. Software Requirements
    Karl E. Wiegers. Microsoft Press (1999).
  3. More About Software Requirements
    Karl E. Wiegers. Microsoft Press (2006).
  4. Use Case Modeling
    Kurt Bittner e Ian Spence. Addison-Wesley (2003).
  • Pingback: Rendiconti: O Seminário GP e o Caso Criado » finito()

  • Ronan Lucio

    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

  • Luiz David Szilagyi

    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.

  • Diego Souto

    Paulo,

    Primeiramente, parabéns e obrigado pelo conhecimento compartilhado.

    Quanto ao que é dito no livro “Writing Effective Use Cases” de Alistair Cockburn sobre Casos de Uso poder representar Requistos (“1.3 Requisitos e caso de uso”), pra mim fica claro que o autor afirma que não serviria para representar todos os requisitos, contudo, representariam, sim, todos os requisitos funcionais de um projeto.

    Um abraço.

    • pv

      Olá Diego,

      Curioso como um artigo meio velhinho (é de 2008!) ainda recebe visitas e merece comentários como o seu. Tanto tempo depois, sigo “brigando” para que as especificações de casos de uso sejam vistas como sugerido aqui. Raramente uma ferramenta tão bem intencionada e relativamente simples gerou tanta controvérsia.

      Obrigado pela participação. Abraços!

      Paulo Vasconcellos

      • Diego Souto

        Paulo,

        A gente vê cada caso de uso por aí que é importante se reoxigenar com bons artigos como este.

        Apenas entendo que seria necessário uma pequena alteração no segundo parágrafo para que seja transcrito de forma mais fiel o que é dito por Alistar Cockburn no livro ““Writing Effective Use Cases” – conforme eu falei no meu comentário anterior -.

        Abraço.

        • pv

          Olá Diego,

          Legal sua preocupação em relação ao texto original do Cockburn. Até fui buscar minha edição para confirmar: transcrevi literalmente as “duas coisas que devemos ter na cabeça quando escrevemos casos de uso como requisitos”, da página 13 do texto original em inglês.

          Acho que o artigo não confunde ao afirmar e reiterar que casos de uso nos ajudam a descobrir e descrever os requisitos funcionais de um sistema. Só não usei todas as palavras do Cockburn.

          Agradeço a colaboração. Abraços!

          Paulo Vasconcellos

          • Diego Souto

            Olá, Paulo.

            A minha discordância é que você conecta o tópico “duas coisas que devemos ter na cabeça quando escrevemos casos de uso como requisitos” com “Representar os Requisitos Funcionais de um sistema”. Veja, o Cockburn não está se referindo estritamente aos requisitos funcionais mas a todos os requisitos.

            Acredito que ficaria mais coerente com o livro se o segundo parágrafo fosse assim escrito:

            “(…) Discutir requisitos (sem descrevê-los); e Representar os Requisitos 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) Não representam todos os requisitos, mas a porção comportamental, a função exigida.

            Um abraço e obrigado pela oportunidade de estar trocando idéias com você.

            • pv

              Uai Diego,

              Agora não entendi: a “porção comportamental” não é representada pelos “requisitos funcionais”?

              Abraços!

              Paulo Vasconcellos

              • Diego Souto

                Sim.
                Não procurei negar isso, pelo contrário: “e ii) Não representam todos os requisitos, mas a porção comportamental, a função exigida (ou se preferir os requisitos funcionais).”

                No meu entendimento “mudar de lugar” a citação de requisito funcional dentro do parágrafo é uma mudança sutil, mas que tornaria a citação (ainda) mais coerente. Porque apenas transcrevi o que é dito no livro por Cockburn, suprimindo trechos menos relevantes, mas sem alterar nada.

                Mas é um pequeno detalhe que não fere – de forma alguma – a qualidade do artigo e não merece que nos debrucemos sobre ele.

                Um abraço.

                • pv

                  Ô Diego,

                  Toda conversa vale a pena quando o tema não é “pequeno”. Demorei, mas entendi sua preocupação. Que faz todo sentido.

                  Muito obrigado. Abraços!

                  Paulo Vasconcellos