¿Existe una definición exacta, pero simple y comprensible de la distinción entre "caso de uso", "Historia de usuario" y "Escenario de uso"?

Hay bastantes explicaciones, pero en este momento, no veo a nadie que explique las diferencias en una sola oración, o en dos ...

(por ejemplo, http://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparison muy largo y difícil de obtener, lleno de discusión)

Una historia de usuario es una versión más informal, más amigable y más pequeña de un caso de uso , menos el diagrama UML; se usa típicamente en escenarios iterativos.

Un escenario de uso es un caso de uso elaborado en un procedimiento paso a paso, a veces acompañado de un diagrama de flujo.

Para mí, las mayores diferencias entre una historia de usuario y un caso de uso son:

• Una historia de usuario es un documento liviano que se puede escribir en una tarjeta (para, como, quiero). Una historia de usuario no captura todos los detalles, es un soporte informal para la discusión.
• Un caso de uso es un documento pesado que necesita un documento de Word. Describe un "Flujo normal" de pasos y / o acciones y "Flujos alternativos" que se detallan. Un caso de uso captura todos los detalles, es una especificación formal.

Según Scott W. Ambler sobre escenarios de uso , estos artefactos se parecen al flujo de un caso de uso:

Un escenario de uso , o para abreviar, describe un ejemplo del mundo real de cómo una o más personas u organizaciones interactúan con un sistema. Describen los pasos, eventos y / o acciones que ocurren durante la interacción. Los escenarios de uso pueden ser muy detallados, lo que indica exactamente cómo alguien trabaja con la interfaz de usuario, o un nivel razonablemente alto que describe las acciones comerciales críticas, pero no indica cómo se realizan.

Honestamente, las diferencias con el flujo de un caso de uso no son claras, incluso después de leer este párrafo (la última oración es quizás la más importante):

Como puede imaginar, hay varias diferencias entre los casos de uso y los escenarios. Primero, un caso de uso generalmente se refiere a actores genéricos, como el Cliente, mientras que los escenarios generalmente se refieren a ejemplos de actores como John Smith y Sally Jones. No hay nada que le impida escribir un escenario genérico, pero generalmente es mejor personalizar los escenarios para aumentar su comprensión. En segundo lugar, los escenarios de uso describen una única ruta de la lógica, mientras que los casos de uso generalmente describen varias rutas (el curso básico más cualquier ruta alternativa apropiada). En tercer lugar, en los procesos basados ​​en UP, los casos de uso a menudo se conservan como documentación oficial, mientras que los escenarios a menudo se descartan después de que ya no son necesarios.

Puedo estar equivocado, pero el Escenario de uso realmente suena como un flujo de casos de uso, pero se renombró con un toque ágil.

No hay una definición exacta de ninguna de estas cosas. Todo varía un poco (o mucho) de una compañía a otra y de un sistema a otro.

Su mejor opción es encontrar un ejemplo ya establecido para su proyecto actual y seguirlo.

Si está creando un nuevo sistema, puede encontrar definiciones de diferentes tipos de casos de uso para el sistema que prefiera: simplemente elija el patrón que parezca comunicar mejor sus intenciones.

No te obsesiones con los nombres.

Una historia de usuario es siempre informal y describe la necesidad de un usuario. Un caso de uso puede ser formal o informal, y describe el comportamiento del sistema.

Es posible tener historias de usuario "tecnológicas", lo mismo no es cierto para los casos de uso.

Una vez hecho esto, la historia del usuario generalmente se descarta. Los casos de uso pueden mantenerse durante el ciclo de vida del producto.

El alcance también es diferente. Las historias de usuarios suelen tener un alcance más pequeño y, en consecuencia, un caso de uso comprende varias historias de usuarios. Un requisito modificado para un sistema existente se describe en una nueva historia de usuario o en una versión actualizada del caso de uso.

La similitud entre las historias de usuarios y los casos de uso es que ambos se utilizan para la planificación y la programación.

Una historia de usuario cuando se descompone en tareas que se pueden asignar individualmente a los desarrolladores puede o no tener un alcance más granular y limitado que un escenario de caso de uso. Una historia de usuario trata sobre la necesidad del usuario: un objetivo o resultado de su uso del sistema.

Ejemplos de historias de usuarios son:

1. Soy un cliente y quiero pagar el saldo de mi cuenta en línea, una vista bastante de alto nivel
2. Soy un cliente y quiero actualizar el año de vencimiento de mi información de crédito almacenada, una vista bastante detallada.

En el nivel más alto de abstracción, un Caso de uso suena muy similar: Año de vencimiento de la tarjeta de actualizaciones del cliente, pero aquí es una declaración de función en lugar de objetivo.

A medida que se definen la granularidad de los escenarios de casos de uso, se vuelven más sobre la función y el procedimiento.

La condición posterior de un escenario principal de caso de uso debe ser el mismo resultado que el indicado en la historia del usuario: se actualiza el año de vencimiento de la tarjeta de crédito del cliente.

Los escenarios de casos de uso describen paso a paso, ya sea en texto o en un diagrama de flujo del proceso (no necesariamente UML o BPM: utilizo un diagrama de flujo multifuncional estándar para mayor claridad y facilidad de uso por parte de consumidores no capacitados del caso de uso.

La conclusión es que las Historias de usuarios describen las necesidades y los resultados (lo que el sistema necesita entregar), mientras que los casos de uso describen las interacciones entre los actores necesarios para alcanzar el objetivo, y lo que puede salir mal (escenarios de extensión, alternativa o error) (cómo interactúa el usuario con el sistema logra ese resultado)

Para una discusión en profundidad sobre este tema, sugiero leer http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison en el sitio web de Alistair Cockburn. Como es signatario del Manifiesto Ágil, la persona que acuñó las Historias de usuarios y ha sido considerado un experto en casos de uso durante las últimas décadas, creo que es una excelente fuente para obtener más información.

_{Nota temporal rápida : esta publicación necesita mejoras para responder mejor a la pregunta, como 1) se deben incluir detalles adicionales de las referencias 2) algunas citas tal vez 3) la corrección general del inglés 4) la calidad general de la narrativa 5) etc. de vuelta a eso. Siéntase libre de mejorarlo usted mismo.}

Echar un vistazo a sus plantillas puede proporcionar información valiosa sobre las diferencias entre estos términos.

Caso de uso

Existen múltiples plantillas para casos de uso. Encontré 3 después de una búsqueda rápida: 1 , 2 , 3 . Algunos puntos que (a veces vagamente) tienen en común son:

1. Nombre del caso de uso / título
2. Descripción : texto breve que describe el alcance.
3. Actor (s) / Actor principal - persona (s) que interactúan con este caso de uso particular.
4. Precondición : todo lo que este caso de uso puede suponerse verdadero antes de comenzar su ciclo de vida.
5. Escenario de éxito : una secuencia de pasos que describe el flujo correcto de eventos que tienen lugar.

6. Extensiones : flujo de aplicación cuando se desvía del flujo del escenario de éxito:

   1. Flujos alternativos : otras opciones de flujo correcto
   2. Flujos de excepción : flujo de eventos para cuando las cosas salen mal

7. Garantía de éxito (también conocida como condición posterior): estado de la aplicación después de que todo esté hecho

Algunos puntos adicionales que se pueden incluir son Nivel , Garantías mínimas , Activador , etc.

Arriba está lo que se llama un caso de uso completamente vestido . Puede simplificar la creación de casos de uso utilizando un caso de uso informal utilizando solo los puntos más vitales, por ejemplo:

1. Título
2. Actor (s)
3. Secuencia de eventos

Los casos de uso fueron creados y popularizados por Ivar Jacobson a finales de los 80 y principios de los 90. Más tarde, otras personas también contribuyeron a su trabajo (una de esas personas es Alistair Cockburn, autor de Writing Effective Use Cases ). Para parafrasear a Martin Fowler casos de uso pueden hacer uso de texto y diagramas UML, pero sus mentiras más grandes de valor en el texto de la misma. Son mejores cuando no son grandes y fáciles de leer.

Historia de usuario _{(también conocida como Característica)}

Historia del usuario: una pequeña historia que describe una característica particular. Hay un patrón común de cómo escribir una historia de usuario, que es:

Como un tipo particular de usuario
, quiero hacer algo
por alguna razón .

Además, la historia del usuario puede tener criterios de aceptación .

Como puede ver, esta plantilla es mucho más pequeña que la del caso de uso. Las historias de usuarios se asocian comúnmente con la región scrum / agile / xp del desarrollo de software. Están destinados a escribirse en pequeñas regiones de superficie, como notas adhesivas, y / o en tableros de scrum. Allí, se les dan (generalmente) valores de puntos que se aproximan a la cantidad de esfuerzo que se debe invertir en esa ^{referencia de la} historia del usuario .

Bill Wake desarrolló la INVERSIÓN mnemónica para describir qué cualidades debe tener una buena historia de usuario, y tomaré prestado el breve resumen de Martin Fowler de su sitio web :

Independiente : las historias se pueden entregar en cualquier orden
Negociable : los detalles de lo que hay en la historia son co-creados por los programadores y el cliente durante el desarrollo.
Valioso : la funcionalidad es vista como valiosa por los clientes o usuarios del software.
Estimado : los programadores pueden llegar a una estimación razonable para construir la historia.
Pequeño : las historias deben construirse en un período de tiempo reducido, generalmente una cuestión de días-persona. Ciertamente, deberías poder construir varias historias dentro de una iteración.
Comprobable : debería poder escribir pruebas para verificar que el software para esta historia funciona correctamente.

Escenario de uso

El escenario de uso sigue el patrón GWT que significa Given-When-Then, así:

Escenario : título
Dado : un hecho particular
Y : otro hecho particular (puede ser opcional)
Cuándo : ocurre algún evento
Luego : sucede algún otro evento

Los escenarios de uso están asociados con el desarrollo impulsado por el comportamiento. Suena muy similar a una prueba. Martin Fowler en su publicación de blog da un poco de historia y razonamiento detrás de escenarios de uso. Aquí está la parte importante:

La parte dada describe el estado del mundo antes de comenzar el comportamiento que está especificando en este escenario. Puede considerarlo como las condiciones previas para la prueba.
La sección when es ese comportamiento que estás especificando.
Finalmente, la sección entonces describe los cambios que espera debido al comportamiento especificado.

Los escenarios de uso se pueden usar para escribir pruebas para su aplicación. Para citar el último párrafo de la publicación de Martin:

Aunque el estilo Dado-Cuándo-Entonces es sintomático para BDD, la idea básica es bastante común cuando se escriben pruebas o especificaciones por ejemplo. Meszaros describe el patrón como prueba de cuatro fases. Sus cuatro fases son Configuración (Dado), Ejercicio (Cuándo), Verificar (Entonces) y Desmontaje. A Bill Wake se le ocurrió la formulación como Arrange, Act, Assert.

Referencias para estudios posteriores:

Páginas de Wikipedia para casos de uso , historia de usuario , escenario de uso
Blogs de Martin Fowler sobre caso de uso , historia de usuario , escenario de uso

No estoy familiarizado con User Story, pero cuando lo investigué hace varios años:

Un caso de uso es una tarea importante.
Los escenarios de usuario son las diversas formas en que la tarea puede desarrollarse. Por lo tanto, cada caso de uso tiene uno o más escenarios. El caso de uso es el resumen, los escenarios de usuario son un catálogo de todas las instancias posibles de esa tarea abstracta.

Entonces:
Caso de uso A: el usuario se autentica con identificación y contraseña.

Escenarios:
1. Se reconoce la identificación, la contraseña es correcta. (escenario "día soleado")
2. Se reconoce la identificación, la contraseña es incorrecta.
3. Se reconoce la identificación, la contraseña es incorrecta por tercera vez.
4. La identificación no se reconoce.

Siempre he pensado en los casos de uso como una forma de definir los requisitos de forma narrativa para el cliente en sus términos. w / r / t lo anterior, si el cliente dice "¿Pero qué pasa si intentan iniciar sesión entre la medianoche y la una cuando el sistema está inactivo?", hemos descubierto otro escenario para la tarea de autenticación y algunos requisitos adicionales.

Una historia de usuario es desde el punto de vista del cliente, a veces es incorrecta o está incompleta. Es posible que no tenga en cuenta el rendimiento, el manejo de errores o nada en el backend.

Un caso de uso es desde el punto de vista del desarrollador. Es preciso y completo. Debe responder a todos los requisitos de los clientes.

"Caso de uso" e "historia de usuario" son iguales en el sentido de que representan "requisitos" del cliente.

El caso de uso es la forma en que se usa el sistema en cada caso, normalmente representado como una interacción entre actor y sistema o entre sistemas.

La historia del usuario es el punto de partida en el viaje para crear una herramienta asistida por computadora que permita al usuario final hacer algo, y normalmente comienza con una oración simple usando quién, qué, por qué ("Como usuario que cierra la aplicación, quiero que se le solicite que guarde todo lo que haya cambiado desde la última vez que lo guardé para poder preservar el trabajo útil y descartar el trabajo erróneo ". Esa historia de usuario luego debe ser cultivada en un caso de uso que los desarrolladores empleen para construir una aplicación, y los probadores para realizar las pruebas.

Desde la perspectiva de un comprobador de control de calidad, no están probando "historias de usuarios", sino "casos de uso", lo que significa que están probando las funcionalidades del software.

El propósito del escenario de uso es capturar la esencia de la interacción del usuario con su sistema para lograr un objetivo, sin sumergirse en los detalles de las acciones del sistema o el diseño real. El foco está en el Usuario, no en el sistema.

... Caso de uso también incluye declaraciones sobre lo que hará el sistema, mientras que el Escenario de uso evitará esta discusión.

Aún no ha determinado cómo lo va a implementar.

Del sitio de productos artísticos .