Existe uma definição exata, porém simples e compreensível, da distinção entre "caso de uso", "História do Usuário" e "Cenário de Uso"?

há várias explicações, mas, no momento, não vejo ninguém que explique as diferenças em uma única frase ou duas ...

(por exemplo, http://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparison muito longo e difícil de obter, cheio de discussões)

Uma história de usuário é uma versão mais informal, mais amigável e menor de um caso de uso , menos o diagrama UML; normalmente é usado em cenários iterativos.

Um cenário de uso é um caso de uso elaborado em um procedimento passo a passo, às vezes acompanhado por um fluxograma.

Para mim, as maiores diferenças entre uma história de usuário e um caso de uso são:

• Uma história de usuário é um documento leve que pode ser escrito em um cartão (para, como, eu quero). Uma história de usuário não captura todos os detalhes, é um suporte informal para a discussão.
• Um caso de uso é um documento pesado que precisa de um documento do Word. Descreve um "fluxo normal" de etapas e / ou ações e "fluxos alternativos" que são detalhados. Um Caso de Uso captura todos os detalhes, é uma especificação formal.

De acordo com Scott W. Ambler em Cenários de uso , esses artefatos se parecem com o fluxo de um Caso de Uso:

Um cenário de uso , ou um resumo, descreve um exemplo do mundo real de como uma ou mais pessoas ou organizações interagem com um sistema. Eles descrevem as etapas, eventos e / ou ações que ocorrem durante a interação. Os cenários de uso podem ser muito detalhados, indicando exatamente como alguém trabalha com a interface do usuário ou descrevendo razoavelmente alto nível das ações críticas de negócios, mas não indicando como elas são executadas.

Honestamente, as diferenças com o fluxo de um Caso de Uso não são claras, mesmo após a leitura deste parágrafo (a última frase talvez seja a mais importante):

Como você pode imaginar, existem várias diferenças entre casos de uso e cenários. Primeiro, um caso de uso geralmente se refere a atores genéricos, como o Cliente, enquanto os cenários geralmente se referem a exemplos de atores como John Smith e Sally Jones. Não há nada que o impeça de escrever um cenário genérico, mas geralmente é melhor personalizar os cenários para aumentar sua compreensão. Segundo, os cenários de uso descrevem um único caminho da lógica, enquanto os casos de uso geralmente descrevem vários caminhos (o curso básico mais os caminhos alternativos apropriados). Terceiro, nos processos baseados na UP, os casos de uso geralmente são mantidos como documentação oficial, enquanto os cenários são descartados depois que não são mais necessários.

Posso estar errado, mas o Cenário de uso realmente soa como o fluxo de casos de uso, mas renomeado com um toque ágil.

Não existe uma definição exata de nada disso. Tudo varia um pouco (ou muito) de empresa para empresa e de sistema para sistema.

Sua melhor aposta é encontrar um exemplo já existente para o seu projeto atual e segui-lo.

Se você estiver criando um novo sistema, poderá encontrar definições de diferentes tipos de casos de uso para o sistema que preferir - Basta escolher o padrão que parece comunicar melhor suas intenções.

Não fique preso a nomes.

Uma história de usuário é sempre informal e descreve a necessidade de um usuário. Um caso de uso pode ser formal ou informal e descreve o comportamento do sistema.

É possível ter histórias de usuário "técnicas", o mesmo não ocorre para casos de uso.

Depois de concluída, a história do usuário geralmente é descartada. Os casos de uso podem ser mantidos durante o ciclo de vida do produto.

O escopo também é diferente. As histórias de usuário geralmente têm um escopo menor e, consequentemente, um caso de uso inclui várias histórias de usuário. Um requisito alterado para um sistema existente é descrito em uma nova história do usuário ou em uma versão atualizada do caso de uso.

A semelhança entre histórias de usuários e casos de uso é que ambos são usados ​​para planejamento e programação.

Uma História do Usuário, quando decomposta em tarefas atribuíveis individualmente aos desenvolvedores, pode ou não ser mais granular e com escopo restrito do que um Cenário de Caso de Uso. Uma história de usuário é sobre a necessidade do usuário - uma meta ou resultado de usar o sistema.

Exemplos de histórias de usuário são:

1. Sou um cliente e quero pagar o saldo da minha conta on-line - uma visão de alto nível
2. Eu sou um cliente e quero atualizar o ano de vencimento nas minhas informações de crédito armazenadas - uma visão bastante granular.

No nível mais alto de abstração, um Caso de Uso soa muito semelhante - Ano de Expiração do Cartão de Atualizações do Cliente -, mas aqui é uma declaração de função e não de objetivo.

À medida que a granularidade dos cenários de Caso de Uso é definida, eles se tornam mais sobre função e procedimento.

A pós-condição de um cenário principal de caso de uso deve ser o mesmo resultado indicado na história do usuário - o ano de vencimento do cartão de crédito do cliente é atualizado.

Os cenários de casos de uso descrevem passo a passo no fluxograma de texto ou processo (não necessariamente UML ou BPM - eu uso um diagrama de fluxo multifuncional padrão para maior clareza e facilidade de uso por consumidores não treinados do caso de uso.

O ponto principal é que as histórias de usuário descrevem necessidades e resultados (o que o sistema precisa fornecer), enquanto os casos de uso descrevem interações entre os atores necessários para atingir a meta - E o que pode dar errado (extensão, cenário alternativo ou de erro) (como o usuário interage com o sistema alcança esse resultado)

Para uma discussão aprofundada sobre esse tópico, sugiro ler http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison no site de Alistair Cockburn. Como ele é signatário do Manifesto Ágil, a pessoa que cunhou as Histórias de Usuário e foi considerado um especialista em Casos de Uso nas últimas duas décadas, acho que ele é uma excelente fonte de mais informações.

_{Nota temporária rápida : Este post precisa de melhorias para responder melhor à pergunta, como 1) detalhes adicionais devem ser incluídos nas referências 2) algumas citações talvez 3) correção geral do inglês 4) qualidade geral da narrativa 5) etc. de volta a ele. Sinta-se livre para melhorar você mesmo.}

Examinar seus modelos pode fornecer informações valiosas sobre as diferenças entre esses termos.

Caso de uso

Existem vários modelos para casos de uso. Encontrei 3 após uma pesquisa rápida: 1 , 2 , 3 . Alguns pontos que eles (às vezes vagamente) têm em comum são:

1. Nome do caso de uso / título
2. Descrição - algum texto breve que descreve o escopo.
3. Ator (es) / Ator principal - pessoa (s) que interagem com esse caso de uso específico.
4. Pré - condição - qualquer coisa que este caso de uso possa assumir como verdadeira antes de iniciar seu ciclo de vida.
5. Cenário de sucesso - uma sequência de etapas que descreve o fluxo correto de eventos que ocorrem.

6. Extensões - fluxo do aplicativo quando ele se desvia do fluxo do cenário de sucesso:

   1. Fluxos alternativos - outras opções de fluxo correto
   2. Fluxos de exceção - fluxo de eventos para quando as coisas dão errado

7. Garantia de sucesso (também conhecida como condição pós) - estado da aplicação depois que tudo estiver pronto

Alguns pontos adicionais que podem ser incluídos são Nível , Garantias mínimas , Gatilho , etc.

Acima está o que chamamos de caso de uso totalmente vestido . Você pode simplificar a criação de casos de uso usando um caso de uso casual usando apenas os pontos mais importantes, por exemplo:

1. Título
2. Atores
3. Sequência de eventos

Os casos de uso foram criados e popularizados por Ivar Jacobson no final dos anos 80 e início dos anos 90. Mais tarde, outras pessoas também contribuíram para seu trabalho (uma delas é Alistair Cockburn, autor de Writing Effective Use Cases ). Para parafrasear Martin Fowler casos de uso podem fazer uso de texto e diagramas UML, mas as suas maiores mentiras valor no texto dele. Eles são melhores quando não são grandes e fáceis de ler.

História do usuário _{(aka. Recurso)}

História do usuário - uma pequena história que descreve um recurso específico. Existe um padrão comum de como escrever uma história de usuário, que é:

Como um tipo específico de usuário
, quero fazer algo
para que, por algum motivo .

Além disso, a história do usuário pode ter critérios de aceitação .

Como você pode ver, esse modelo é muito menor que o do caso de uso. As histórias de usuários são comumente associadas à região scrum / ágil / xp do desenvolvimento de software. Eles devem ser escritos em pequenas regiões da superfície, como post-its e / ou em scrum boards. Lá, eles recebem (geralmente) valores pontuais que se aproximam de quanto esforço precisa ser investido na ^{ref da} história do usuário .

Bill Wake desenvolveu a mnemônica do INVEST para descrever quais qualidades uma boa história de usuário deve ter, e tomarei emprestado o breve resumo de Martin Fowler em seu site :

Independente : as histórias podem ser entregues em qualquer ordem.
Negociável : os detalhes do que está na história são co-criados pelos programadores e pelo cliente durante o desenvolvimento.
Valioso : a funcionalidade é vista como valiosa pelos clientes ou usuários do software.
Estimativa : os programadores podem apresentar uma estimativa razoável para a construção da história.
Pequena : as histórias devem ser construídas em uma pequena quantidade de tempo, geralmente uma questão de pessoa-dia. Certamente você deve conseguir criar várias histórias em uma iteração.
Testável : você deve poder escrever testes para verificar se o software dessa história funciona corretamente.

Cenário de uso

O cenário de uso segue o padrão GWT, que significa Dado quando, então:

Cenário : título
Fornecido : um fato específico
E : outro fato específico (pode ser opcional)
Quando : algum evento acontece
Então : outro evento acontece

Os cenários de uso estão associados ao desenvolvimento orientado a comportamentos. Parece muito semelhante a um teste. Martin Fowler em seu blog fornece um pouco de história e raciocínio por trás dos cenários de uso. Aqui está a parte importante:

A parte fornecida descreve o estado do mundo antes de você começar o comportamento especificado neste cenário. Você pode pensar nisso como as pré-condições para o teste.
A seção quando é o comportamento que você está especificando.
Finalmente, a seção then descreve as alterações que você espera devido ao comportamento especificado.

Os cenários de uso podem ser usados ​​para escrever um teste para o seu aplicativo. Para citar o último parágrafo da postagem de Martin:

Embora o estilo Given-When-Then seja sintomático ao BDD, a idéia básica é bastante comum ao escrever testes ou especificações por exemplo. Meszaros descreve o padrão como teste de quatro fases. Suas quatro fases são Configuração (Dada), Exercício (Quando), Verificar (Então) e Desmontagem. Bill Wake veio com a formulação como Organizar, Agir, Afirmar.

Referências para estudos mais aprofundados:

Páginas da Wikipedia para caso de uso , história do usuário , cenário de uso
Os blogs de Martin Fowler sobre caso de uso , história do usuário , cenário de uso

Não estou familiarizado com a história do usuário, mas quando examinei isso há vários anos:

Um Caso de Uso é uma tarefa importante.
Cenários do usuário são as várias maneiras pelas quais a tarefa pode ser executada. Portanto, todo caso de uso tem um ou mais cenários. O Caso de Uso é o resumo, os Cenários do Usuário são um catálogo de todas as instâncias possíveis dessa tarefa abstrata.

Portanto:
Caso de Uso A: O usuário se autentica com ID e senha.

Cenários:
1. O ID é reconhecido, a senha está correta. (cenário "dia de sol")
2. O ID é reconhecido, a senha está incorreta.
3. O ID é reconhecido, a senha está incorreta pela terceira vez.
4. ID não é reconhecido.

Sempre pensei em casos de uso como uma maneira de definir requisitos de maneira narrativa para o cliente em seus termos. w / r / t acima, se o cliente disser "Mas e se tentarem efetuar login entre meia-noite e uma quando o sistema estiver inativo?", descobrimos outro cenário para a tarefa de autenticação e alguns requisitos adicionais.

Uma história de usuário é do ponto de vista do cliente, às vezes é incorreta ou incompleta. Pode não levar em consideração o desempenho, a manipulação de erros ou nada no back-end.

Um caso de uso é do ponto de vista do desenvolvedor. É preciso e completo. Deve responder a todos os requisitos dos clientes.

"Caso de uso" e "história do usuário" são os mesmos no sentido em que representam "requisitos" do cliente.

Caso de uso é a maneira como o sistema é usado em cada caso, normalmente representado como uma interação entre ator e sistema ou entre sistemas.

A história do usuário é o ponto de partida na jornada para criar uma ferramenta auxiliada por computador que permitirá que o usuário final faça alguma coisa e normalmente começa com uma frase simples usando quem, o quê, por quê ("Como um usuário que fecha o aplicativo, desejo ser solicitado a salvar tudo o que foi alterado desde o último salvamento, para que eu possa preservar o trabalho útil e descartar o trabalho incorreto. "). Essa história de usuário precisa ser cultivada em um caso de uso que os desenvolvedores empregam para criar um aplicativo e os testadores para realizar testes.

Da perspectiva de um QA Tester, eles não estão testando "histórias de usuários", mas "casos de uso", o que significa que estão testando as funcionalidades do software.

O objetivo do cenário de uso é capturar a essência da interação do usuário com seu sistema para atingir uma meta, sem se aprofundar nos detalhes das ações do sistema ou no design real. O foco está no usuário, não no sistema.

... O Caso de Uso também inclui instruções sobre o que o sistema fará, enquanto o Cenário de Uso evitará essa discussão.

Você ainda não determinou como implementá-lo.

No site de artes do produto .