Ô 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

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 ṇo fere Рde forma alguma Рa qualidade do artigo e ṇo merece que nos debrucemos sobre ele.

Um abraço.

Uai Diego,

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

Abraços!

Paulo Vasconcellos

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

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

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.

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

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.

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