Identificando los escenarios
https://engineerdesistemas.blogspot.com/2016/09/identificando-los-escenarios.html
Cuando estamos en la tarea de describir un escenario de caso de uso lo que generalmente estamos buscando es escribir un objetivo que un actor pueda cumplir con un solo encuentro, con una sola iteración, dentro de esa acción estamos intentando permanecer enfocados en lo que es el objetivo del usuario.
Por ejemplo si expresamos "iniciar sesión en la aplicación": en un principio puede sonar como un caso de uso, un verbo activo y que generalmente tiene múltiples pasos, múltiples condiciones. Hay que considerar también que uno podría haber olvidado la contraseña, no se podría requerir registrarse para continuar en muchas más cosas. Pero si enfatizamos a que los actores se centren en su objetivo nos damos cuenta de que su objetivo del sistema no es "iniciar sesión" sino que es la razón para la identificación para realizar cualquier otra cosa.
De tal forma que esa otra cosa en el sistema por ejemplo podría ser:
-comprar elementos
-crear un nuevo documento
-realizar un equilibrado de las cuentas
Por otro lado podríamos tener por ejemplo:
-iniciar sesión
-escribir un libro
-fusionar organizaciones
Los anteriormente mencionados no serían objetivos en sí mismo y además son demasiado amplios o involucrarían múltiples encuentros.
Un simple caso de uso puede tener múltiples escenarios, aquel tipo de escenario que es completamente exitoso que no tiene ningún tipo de problemas que de momento vamos a enfocar.
Que pasa si todo va bien
En este tipo de casos de uso no necesitaríamos escribir caminos o extensiones alternativas, en este caso de uso por ejemplo en el que el sistema valida los elementos que un cliente ha introducido dentro de un carrito de compras.
O en su defecto para ver otras alternativas alternativas, qué pasa cuando nos hemos quedado sin exigencias para un producto o que pasa por ejemplo cuando el cliente cancela el pedido entero o cuando todo lo que ha seleccionado ha sido rechazado.
No se trata de que tengamos en cuenta todos aquellos eventos posibles aunque técnicamente sea muy poco probable que ocurra a los cuales se deban realizar algún tipo de acción.
Cuando se escriba se recomienda usar voz en activo, es decir omitir palabras no necesarias.
Esto no: al sistema se le da la información de pago y envío por parte del cliente.
Esto sí: el cliente proporciona información de pago y envío.
Otro error común de redacción es poner demasiado detalle.
Esto no: el sistema se conecta al procesador externo de pago sobre HTTPS y usa JSON para enviar la información de pago a validar, y espera la respuesta del sistema delegado.
Por ejemplo si expresamos "iniciar sesión en la aplicación": en un principio puede sonar como un caso de uso, un verbo activo y que generalmente tiene múltiples pasos, múltiples condiciones. Hay que considerar también que uno podría haber olvidado la contraseña, no se podría requerir registrarse para continuar en muchas más cosas. Pero si enfatizamos a que los actores se centren en su objetivo nos damos cuenta de que su objetivo del sistema no es "iniciar sesión" sino que es la razón para la identificación para realizar cualquier otra cosa.
De tal forma que esa otra cosa en el sistema por ejemplo podría ser:
-comprar elementos
-crear un nuevo documento
-realizar un equilibrado de las cuentas
Por otro lado podríamos tener por ejemplo:
-iniciar sesión
-escribir un libro
-fusionar organizaciones
Los anteriormente mencionados no serían objetivos en sí mismo y además son demasiado amplios o involucrarían múltiples encuentros.
Un simple caso de uso puede tener múltiples escenarios, aquel tipo de escenario que es completamente exitoso que no tiene ningún tipo de problemas que de momento vamos a enfocar.
Que pasa si todo va bien
En este tipo de casos de uso no necesitaríamos escribir caminos o extensiones alternativas, en este caso de uso por ejemplo en el que el sistema valida los elementos que un cliente ha introducido dentro de un carrito de compras.
O en su defecto para ver otras alternativas alternativas, qué pasa cuando nos hemos quedado sin exigencias para un producto o que pasa por ejemplo cuando el cliente cancela el pedido entero o cuando todo lo que ha seleccionado ha sido rechazado.
No se trata de que tengamos en cuenta todos aquellos eventos posibles aunque técnicamente sea muy poco probable que ocurra a los cuales se deban realizar algún tipo de acción.
Cuando se escriba se recomienda usar voz en activo, es decir omitir palabras no necesarias.
Esto no: al sistema se le da la información de pago y envío por parte del cliente.
Esto sí: el cliente proporciona información de pago y envío.
Otro error común de redacción es poner demasiado detalle.
Esto no: el sistema se conecta al procesador externo de pago sobre HTTPS y usa JSON para enviar la información de pago a validar, y espera la respuesta del sistema delegado.
