Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Usuario Final. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Usuario Final. Mostrar todas las entradas

domingo, junio 26, 2016

¡El tamaño sí importa!


Vamos al grano. Si la mayoría de tus historias de usuario llegan a “Terminado” apenas unas pocas horas antes de la Revisión del Sprint, todavía pueden ser más pequeñas. Tu equipo debería tener historias tan pequeñas que las puedas finalizar durante las primeras horas o días del Sprint, dependiendo de la duración de este. Así te aseguras desde las primeras de cambio que el equipo está siendo productivo, está enfocado y que van a entregar valor al final de la iteración. ¡Después de todo, finalizar una tarea aumenta la moral del equipo!
Aunque el objetivo de un Sprint no debe medirse en número de historias de usuario a terminar (implementar), sino al cumplimiento de un objetivo específico, siempre es mejor “prometer” o planear terminar varias historias pequeñas o muy pequeñas que muy pocas historias medianas o grandes.
Es evidente: si tienes 10 historias en tu lista de pendientes del sprint (alias el backlog del sprint), y no terminas 2, es mucho mejor que si solo tienes 4 y terminas 2. En ambos casos fallaste en el mismo número de historias, pero en el primer escenario tuviste un acierto del 80% mientras que en el segundo apenas llegaste a la mitad de la promesa del sprint. El resultado es menos alentador si las historias terminadas son dos de 3 puntos y dejaste sin terminar o aun a punto de terminar dos historias de 13. Solo cumpliste con 6 de los treinta puntos que prometiste.
Hablando de puntos, una buena medida, algo que me ha funcionado casi siempre, es implementar historias cuyo puntaje no sobrepase entre una décima parte y una sexta parte de la velocidad del equipo. Es decir, si la velocidad del equipo de desarrollo es 30 puntos por Sprint, las historias a implementar no deberían ser más grandes de 3 a 5 puntos. Historias de ½, 1 y 2 puntos siempre son bienvenidas en este escenario.
Ahora bien, el tamaño de las historias es un concepto relativo. Un equipo de 7 o 9 personas no ve igual una historia de usuario en un sprint de 3 o 4 semanas que un equipo de 3 o 5 personas en un sprint de 1 o 2 semanas. Pero algo en lo que todos estamos de acuerdo es que, una vez terminadas, las historias deben proporcionar valor al negocio. Las cosas así, otro indicador de “pequeño” es Pareto.
El objetivo siempre es encontrar ese 20% de la historia (de funcionalidades que se van implementar vía esa historia) que genere o entregue el 80% del valor total de la misma. A partir de allí, la división se hace de manera orgánica, adicionando historias al backlog de producto que complementen la historia de “más valor”.
También ayuda el nivel de entendimiento de toda la historia y qué tan rápido llegamos a entenderla por completo. Un índice de que quizás la historia no es pequeña es que no la hemos terminado de entender, quizás no están claros algunos de los criterios de aceptación o hay nubes en la conversación (la c de conversación de la historia) relacionadas con los requisitos funcionales o no funcionales a implementar.
El Principio de Sweepnoise, de mi amigo Leonardo Agudelo, ilustra muy bien este punto:


Finalmente, no solo la S de INVEST indica que la historia es pequeña (Sucinta). Un indicativo de que quizás no lo es tanto, es que  algunas partes de la misma (o toda la historia) no sean negociables o que no haya consenso en su estimación o que tengamos dudas acerca de si es posible conducirla a través de un proceso que nos asegure la calidad del producto terminado o de que incluso tenga dependencias con otra(s) historia(s).

Comparte conmigo y con los demás lectores del blog lo que piensas sobre este asunto del tamaño, ¿importa? ¿No importa? ¿Qué haces habitualmente para dividir tus historias de usuario? Cuéntanos tus heurísticas.
---------------------------------------------------------------------------------------------------------------
Para saber más sobre historias de usuario, puedes leer mi artículo introductorio:
Historias de Usuario: un nuevo orden en los requisitos del software:
http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html

Para saber más de los criterios INVEST de las historias de usuario puedes leer mi serie de artículos sobre el asunto.
La serie de artículos "Escribiendo Historias de Usuario Altamente Efectivas":
Escribiendo Historias de Usuario Altamente Efectivas, 1 - Introducción
Escribiendo Historias de Usuario Altamente Efectivas, 2 - Independiente
Escribiendo Historias de Usuario Altamente Efectivas, 3 - Negociable
Escribiendo Historias de Usuario Altamente Efectivas, 4 - Valiosa (y Valuada)

Y este otro:

De historias de usuario, culturas y del arte de narrar historias


También puedes visitar el blog Lecciones Aprendidas de mi amigo Jorge Abad:
Video de explicación: Cómo se construyen historias de usuario
Ejemplo: Una historia de usuario - Listado de Morosos
Ejemplo de historia de usuario : Ingreso al sistema
http://www.lecciones-aprendidas.info/2015/03/ejemplo-de-historias-de-usuario-ingreso.html

jueves, marzo 05, 2015

De historias de usuario, culturas y del arte de narrar historias

“Yo no sé muchas cosas, en verdad,

Digo tan solo lo que he visto.
Y he visto que la cuna del hombre
la mecen con cuentos,
que los gritos de angustia del hombre
los ahogan con cuentos,
que el llanto del hombre
lo taponan con cuentos.
Y que el miedo del hombre
ha inventado todos los cuentos…
Yo sé muy pocas cosas, es verdad,
pero me han dormido con todos los cuentos
y sé todos los cuentos ...”
[León Felipe, Aguaviva.]

La vida es una alegoría, los seres humanos no solo estamos configurados como cuerpos biológicos abastecidos de estímulos y pulsiones, pues nacemos en un entorno social y por tanto nos relacionamos, desde lo más esencial –lo familiar, hasta lo más universal, con nuestros semejantes. Pero además poseemos una visión personal para interpretar nuestra cotidianidad, tenemos ideales y pensamientos, emociones y aversiones que nos hacen actuar  de formas particulares al interpretar nuestra realidad.

En todo esto, la narración de historias juega un papel muy importante  en la construcción de conocimiento. La narrativa es una forma de caracterizar los fenómenos de la experiencia humana. Dice Ivar Jacobson en su libro Casos de Uso 2.0 que “la narración de historias permite a las culturas sobrevivir y progresar; es el camino más simple y más efectivo para pasar el conocimiento de una persona a otra. Es la mejor manera de comunicar lo que un sistema debe hacer y hacer que todo el mundo trabaje en el sistema sobre los mismos objetivos.” [1]

Las historias (de usuario) establecen una manera de organizar y comunicar experiencias. Las personas usan instintivamente la narración de historias para organizar un cúmulo de ideas que consideran disperso; además, gracias a ellas pueden organizar lo que saben acerca de su trabajo y de cómo lo hacen. Al narrar historias, las personas nos invitan de una forma u otra  a investigar sus pensamientos, sus sentimientos y sus intenciones. Finalmente, como oyentes y más tarde como lectores de las historias de usuario, adherimos a los acontecimientos, como una exploración de la experiencia de los usuarios, entendiéndolas mejor y de la forma más completa posible, pero sobre todo, comprendiendo su valor real.

Quienes transitamos a diario por el vasto universo del diseño y construcción de productos de software sabemos que es importante enfocarnos en el valor que estos prestarán a sus dueños, los usuarios, y a otros interesados. El mismo Jacobson dice que “solo se genera valor si el sistema se usa realmente; así, es mejor enfocarse en cómo se usará el sistema que en las largas listas de funciones o características que ofrecerá.” [2] Y agrega más adelante: “es fácil capturar y validar la completitud de las historias y estas, a su vez, facilitan filtrar las formas potenciales de usar el sistema que ofrezcan poco o ningún valor real a los usuarios. Este foco constante en el valor permite asegurar que cada entrega del sistema sea tan pequeña como sea posible, a la vez que tenga valor real para los usuarios del sistema y para los interesados que financian el desarrollo.” [3]

Cuenta las historias, no las escribas

En su libro “Fifty Quick Ideas to Improve your User Stories”, Gojko Adzic & David Evans [4], compilan una serie de conceptos sobre cómo mejorar nuestras historias de usuario o, mejor aun, sobre cómo mejorar el desempeño del equipo ágil usando la técnica de las historias de usuario. Me interesó mucho la primera de esas ideas, muy acorde a mi interés actual sobre las historias y la supervivencia de las culturas. Esta idea es precisamente la del título de esta sección: cuenta historias, no las escribas.

Uno de los errores más comunes de las personas que empiezan a usar prácticas ágiles es creer que las historias de usuario son requisitos livianos. Las historias de usuario no son requisitos, son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante, el Equipo de Desarrollo y el Dueño de Producto, pero definitivamente no son requisitos. Este malentendido conduce a situaciones en que las historias sean recolectadas en herramientas de gestión de actividades, con muchos detalles escritos o proporcionados por representantes del negocio.

Nada más alejado de una buena práctica. Las historias de usuario implican un modelo totalmente diferente, Gojko y David lo llaman “requisitos por colaboración”, un modelo donde la transferencia de conocimiento vía documentos “pesados” se reemplaza por involucramiento y colaboración, al mejor estilo del Manifiesto Ágil. Ya sabemos que la conversación cara a cara es la forma más efectiva de comunicar información y que una buena discusión entre los interesados y el equipo ágil lleva a mejores preguntas/respuestas, opciones e ideas del producto. Cuando los requisitos se escriben, aun si los llamamos historias de usuario, estas discusiones nunca suceden y las mejores ideas se pierden para siempre. Tengo algo de experiencia en esto, pasé dos décadas escribiendo requisitos de software, todo tipo de requisitos, todo tipo de productos de software.

La recomendación es simple, avanzan Adzic y Evans en su libro: intenta contar historias o que te cuenten historias, en vez de escribirlas. Usa tarjetas físicas o un sistema de tiquetes electrónicos, pero solo como recordatorios de esa conversación que tendrás más adelante. No gastes mucho tiempo tratando de descifrar los detalles de las historias con anticipación. Compromete a los interesados del negocio e involucra a los miembros del equipo en una discusión, busca distintas perspectivas de la historia y explora opciones. Esta es la forma de acceder a los beneficios reales de trabajar con historias de usuario.

Beneficios clave de contar historias

Las discusiones permiten a los representantes del negocio, no solo explicar lo que quieren, sino también asegurarse de que los miembros del equipo entiendan esto correctamente. Uno de los mayores problemas en los modelos tradicionales son los malos entendidos entre los distintos roles en el equipo y entre los interesados, entre quienes existen niveles heterogéneos de conocimiento acerca de las necesidades de cada uno, complemento además del ya típico fenómeno del “teléfono roto” [5]. Es un hecho, explicar una historia cara a cara evita caer en vacíos de conocimiento sobre la historia.

El segundo beneficio, apuntan Adzic & Evans, es el análisis más rápido. Cuando el equipo completo se involucra en una discusión, los vacíos funcionales, las inconsistencias y los requisitos no claros se descubren más rápidamente que cuando una sola persona (léase Analista del Negocio o similar), escribe los detalles.

Pero el beneficio más importante de la comunicación cara a cara, comparada con el paso de información vía documentos, es que la primera produce mejores soluciones, mejores productos. Para ser capaz de construir buenas soluciones, las personas necesitan conocer los planes y las oportunidades del negocio, entender el dominio del problema, tener un conocimiento profundo de las restricciones técnicas estar al tanto de las nuevas tecnologías que potencialmente les puedan servir. Involucrar a un grupo de personas en el análisis desde diferentes perspectivas ayuda al equipo a beneficiarse del conocimiento compartido.

Como lograrlo

La excusa más común para llenarnos de documentación es la insistencia del negocio en la aprobación formal, las regulaciones legales o gubernamentales o las dependencias con terceros. Si es necesario “firmar” las historias hazlo a medida que las discutes. Es más, si el alcance final debe ser aprobado por varios interesados en el negocio, involúcralos en las reuniones de Refinamiento, días antes de la reunión de planificación del Sprint donde se van a construir las historias. En cualquier caso, el Dueño de Producto juega un papel muy importante en la consecución de tales aprobaciones. Es una de sus responsabilidades directas.

Como siempre, ensaya distintos acercamientos y en cada retrospectiva analiza como le fue a tu equipo. Como dice el refrán, la experiencia no se improvisa. Hasta allí el tema, recomiendo amplísimamente los libros que usé como referencia

Referencias

[1] [2] [3] Ivar Jacobson et all. Use Case 2.0. Ivar Jacobson International. 2011. Traducción de Luis Antonio Salazar y Carlos Mario Zapata.

[4] Gojko Adzic & David Evans, Fifty Quick Ideas to Improve your User Stories, © 2013 – 2014 Nueri Consulting LLP

[5] Conocido también en algunas culturas o regiones como el fenómeno o el juego del “teléfono descompuesto”

Para saber más de historias de usuario puedes leer mi serie de artículos en este mismo Gazafatonario:

http://goo.gl/iJvj7
http://goo.gl/NZv4vj
http://goo.gl/e1DSVh
http://goo.gl/eGHQQU

miércoles, abril 17, 2013

¿Es usted la persona correcta para responder mis preguntas? O el síndrome del sujeto equivocado



En los proyectos de software estamos llenos de personas que no son “las adecuadas para responder nuestras preguntas”, para establecer las verdaderas necesidades del negocio, para darnos a conocer el problema que tienen, el problema detrás del problema, la causa raíz, el impacto de ese problema y las áreas impactadas. Estamos llenos de personas que constantemente no toman decisiones, que tienen que consultar con alguien más, que no entienden lo que nos están contando durante un proceso típico de educción de requisitos, es decir, durante las entrevistas, al responder cuestionarios o al analizar prototipos, entre otras actividades.

Por eso es que nuestros proyectos están repletos de supuestos, algo con lo que nunca debemos trabajar, sobre todo, porque son supuestos pasivos, que nunca evolucionan ni son gestionados con eficacia. Los supuestos le están haciendo mucho daño a la industria y conducen a la producción de software de baja calidad o que no satisface para nada las necesidades de nuestros usuarios y clientes. Hacemos suposiciones porque nuestra mente es muy sabia y siempre necesita respuestas, necesita comprender lo que pasa en nuestro entorno, y si no se produce la respuesta que requiere, entonces la presume.

Esta necesidad de hacer supuestos es inherente al ser humano: a lo largo de nuestras vidas hay cientos o miles de preguntas que no somos capaces de manifestar explícitamente y, por consiguiente, no conseguimos las respuestas adecuadas. De todas estas preguntas sin responder, hacemos suposiciones para llenar el vacío y la insatisfacción que sobreviene, es la única manera de sentirnos seguros. Si logramos respuestas a medias, hacemos suposiciones, si no obtenemos respuestas, también hacemos suposiciones, nos da lo mismo saber si la respuesta es la correcta o no, simplemente es suficiente con suplir el ansia de saber.

Debido a ello, cuando un interlocutor, un usuario u otra clase de interesado, nos está respondiendo preguntas vía entrevista y nos dice que no está seguro, que va a confirmar tal o cual asunto, que debe reunirse la próxima semana con una o más personas para aclarar un tema, etcétera, nosotros, ni cortos ni perezosos, hacemos supuestos. Es más, nuestros productos de trabajo tienen siempre una sección de Supuestos en la que registramos estas conjeturas y muchas veces no las volvemos a revisar. Mi primer consejo es eliminar esta sección de los documentos, son perjudiciales.

También es bien sabido que los usuarios típicamente no saben lo que el software puede hacer o no tienen las habilidades para sintetizar las soluciones basadas en software a sus problemas reales. Y nosotros muchas veces fallamos al preguntar porque somos propensos a creer que el problema de los usuarios es de índole tecnológica y no algo puramente del negocio. Incluso, antes de eso, fallamos al seleccionar y clasificar correctamente a los usuarios correctos o alguien más toma la decisión por nosotros, lo que deja el proyecto en una incertidumbre mayor que aquella con la que inició.

Los supuestos son atajos hacia la veracidad. El problema es que casi nunca acertamos al escoger el camino apropiado. Siempre que sea posible, reemplacemos esas hipótesis por hechos probados, por evidencias que soporten la toma de decisiones, seleccionando mejor nuestros usuarios, entrevistando al mayor número de personas en el menor tiempo posible, así estaremos en capacidad de verificar las fuentes, de contrastar respuestas y de saber cuándo hemos llegado a la definición correcta del sistema. Invite a varias personas a la sesiones de búsqueda de requisitos, la probabilidad de que una de ellas sea la adecuada aumenta.

Por eso, la siguiente ocasión que inicie un proyecto de software y le toque entrevistar por primera vez a un usuario, pregúntele: ¿Es usted la persona correcta para responder mis preguntas? Sí, ya sé lo que van a decir, en nuestra cultura este tipo de preguntas es fuerte y puede tomarse como una insolencia; es cierto. Por eso tenemos alternativas: ¿quién más cree usted que puede ayudarnos a resolver estas cuestiones? ¿Alguien más está interesado en esta situación? ¿Quién más tiene este problema? ¿Alguien más nos puede acompañar en la reunión? ¿A quién podríamos enviarle estas preguntas? ¿Alguien más puede tomar decisiones cuando usted no está?

¡Las posibilidades son infinitas!

viernes, noviembre 16, 2012

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos: XI


"Los buenos consejos no son tomados en cuenta generalmente, pero eso no es motivo para no darlos."
Agatha Christie
Consejo Adicional: ¿Cómo luce un caso de uso inefectivo?
Caso de Uso: Apertura de Productos y Servicios
Secuencia Básica:
1.     Muestre una lista de productos y servicios de la siguiente forma:
  •         La ventana izquierda lista todas las categorías de productos y servicios de la compañía (Ahorro e Inversión, Crédito Hipotecario, Otros Créditos)
  •         La ventana inferior muestra los datos que se solicitan para el producto seleccionado
  •         La tercera ventana muestra todos los productos y servicios que tiene actualmente el cliente
2.     Haga:
3.     El usuario hace clic en una categoría de producto o servicio
4.     Muestre los productos disponibles en esa categoría en orden alfabético
5.     El usuario hace clic en un producto
6.     Se actualiza la ventana inferior para solicitar los datos necesarios para la apertura del producto y el usuario hace clic en el botón “Solicitar Producto”.
7.     Chequee si el usuario cumple los requisitos necesarios para solicitar ese producto y que el producto esté disponible para su “tipo de persona” (Natural o Jurídica)
8.     Si el producto está disponible y el usuario cumple los requisitos necesarios, adicione el producto al usuario. Muestre la lista actualizada de productos del usuario, con el nuevo producto en estado “Solicitado”. Si no, muestre el mensaje “El cliente no cumple los requisitos necesarios. Seleccione otro producto.”
9.     Repita desde 3 hasta que el usuario haga clic en “Terminar Solicitud”
10.   Almacene la solicitud y regrese a la pantalla principal.
¿Y cómo luce un caso de uso efectivo?
Caso de Uso: Solicitar Producto
Actor: Cliente
Secuencia Básica:
1.     El Cliente solicita abrir un producto
2.     El sistema muestra la lista de productos actuales del cliente y muestra una lista de productos disponibles
3.     El Cliente selecciona el producto a solicitar
4.     El sistema verifica que el Cliente cumple con los requisitos necesarios y adiciona el producto a la lista de productos del cliente, en estado “Solicitado”.
5.     El sistema almacena la solicitud
Veamos algunos aspectos importantes de estas dos versiones:
Versión Inefectiva
Versión Efectiva
El nombre del caso de uso no es apropiado
El nombre está escrito como una frase verbal simple (en el formato “hacer algo”)
No tiene un actor definido
Tiene un actor principal, el Cliente.
El caso de uso se refiere a “el usuario” como actor del mismo. “Usuario” no es un concepto formal, es un humano, puede actuar como diferentes instancias de varios actores distintos.
El caso de uso se refiere a “el cliente” como actor del mismo. “Actor” es un concepto formal, puede ser un humano o un sistema, existe sólo si un usuario hace algo.
Está escrita en una especie de pseudocódigo y en lenguaje técnico.
Está escrita en prosa
Relaciona muchos aspectos de la interfaz de usuario. Orientado al Sistema.
Está escrito en términos del negocio (del usuario). Orientado al Negocio.
Aborda elementos que pueden ser disímiles en su tratamiento (productos y servicios, categorías de productos)
Aborda sólo productos. Incluso, los casos de uso deberían especificarse para un único producto a la vez.
Algunos pasos son complejos, difíciles de leer o muy largos. (Pasos 1 y 8).
Los pasos son claros, en el formato “el sistema hace…el actor hace”
La secuencia básica parece abarcar todos los escenarios posibles del caso de uso
La secuencia básica deja muchos escenarios para secuencias alternativas, como la solicitud de servicios o cuando el cliente no cumpla con las condiciones exigidas.
Parece haber sido especificado por completo en una sola pasada.
Le faltan detalles, pero estimula la creación iterativa de casos de uso.
Algunos pasos describen acciones consecutivas ejecutadas por el sistema y por el usuario a la vez.
Todos los pasos están escritos como expresiones verbales simples.
El verdadero truco con los casos de uso es mantenerlos simples. No nos preocupemos acerca de las formas del caso de uso, solo procuremos garabatearlos en una hoja de papel en blanco o en una página en blanco de un procesador de palabras simple, o en unas tarjetas indexadas blancas. No nos preocupemos por cubrir todos los detalles de inmediato. Los detalles no son importantes hasta mucho después. No nos preocupemos por capturar todos los casos de uso desde el principio; esa es una tarea imposible.
La única cosa para recordar sobre casos de uso es: mañana van a cambiar. Sin importar que tan diligente seamos a la hora de capturarlos, sin importar que tan meticulosamente registremos los detalles, sin importar que tan sistemáticamente pensemos acerca de los casos de uso, sin importar el mucho esfuerzo que hagamos para explorar y analizar los requisitos, mañana los casos de uso cambiarán.
Después vendrán las herramientas sofisticadas de apoyo. Las herramientas aumentan nuestra productividad, nos ayudan a clasificar, a buscar, a estimar, pero no hacen el trabajo por nosotros.
Esta es una visión minimalista del proceso, algunos la llaman ágil. Simplemente es una manera de hacer las cosas, una manera efectiva en ciertos casos. Ese es el verdadero sentido de esto: para cada proyecto, para cada actividad, debemos buscar o construir el mejor camino para ir de principio a fin y entregar el mejor de los resultados, el único posible.

W953BAF3WB56

miércoles, noviembre 14, 2012

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos: X

Consejo 10
No usemos expresiones del tipo: “el sistema verifica si se cumple tal condición” y más adelante: “si se cumple la condición, haga esto”, y para terminar: “si no se cumple la condición, haga esto otro.” Este es un patrón que viene de la programación de computadores, es más bien pseudocódigo y la primera de las acciones no cumple con una de las premisas importantes de un caso de uso y es que cada acción lleve la secuencia del caso de uso un paso más adelante que el anterior. Vemos claramente que “el sistema verifica si se cumple tal condición” no avanza en el proceso, en cambio, debemos esperar hasta la siguiente operación: “si se cumple…” para continuar la secuencia.
En cambio, escribamos el caso de uso en términos de escenarios:
n. El sistema verifica que tal condición se cumple y hace…
n+1. El actor hace…
En una secuencia alterna especificamos lo que ocurre cuando la condición no se cumple:
nA1. El sistema verifica que tal condición no se cumple y hace…
(n+1)A2. El actor hace…
Como en:
4. El sistema verifica que el Cliente tiene capacidad de endeudamiento y solicita el valor del crédito
5. El actor ingresa el valor del crédito
Y en la secuencia alterna:
4A1. El sistema verifica que el Cliente no tiene capacidad de endeudamiento y solicita la identificación del avalista
4A2. El actor ingresa la identificación del avalista
Ejemplo
Consideremos este fragmento de caso de uso para verificar los fondos de una cuenta bancaria con miras a hacer efectivo un cheque.
Caso de Uso: Verificar fondos cuenta
Actor: Cajero
Secuencia Básica:
1.     El caso de uso inicia cuando el Cajero decide verificar los fondos disponibles para un cheque
2.     El sistema solicita el tipo y número de cuenta
3.     El Cajero ingresa el tipo y número de cuenta
4.     El sistema verifica que el número de cuenta existe y que está Activa y solicita el número del cheque
5.     El cajero ingresa el número del cheque
6.     El sistema valida que el número del cheque está dentro del rango autorizado y que no está contraordenado, y solicita el valor del cheque
7.     El cajero ingresa el valor del cheque
8.     El sistema verifica que hay fondos suficientes para pagar el cheque
9.     El caso de uso termina
Secuencia Alterna 1:
4A. El número de cuenta no existe
4A.1. El sistema verifica que el número de cuenta no existe y muestra el mensaje: “El número de cuenta dado no existe. Verifique.”
4A.2. El caso de uso continúa en el paso 2 de la secuencia básica.
Secuencia Alterna 2:
6A. El número del cheque no está dentro del rango autorizado
6A.1. El sistema verifica que el número del cheque no está dentro del rango autorizado y muestra el mensaje “El número del cheque no está autorizado. Verifique.”
6A.2. El caso de uso continúa en el paso 5 de la secuencia básica
Secuencia Alterna 3:
8A. No hay fondos suficientes para pagar el cheque
8A.1. El sistema verifica que la cuenta no tiene fondos suficientes para pagar el cheque y muestra el mensaje “Fondos insuficientes. Verifique.”
8A.2. El caso de uso continúa en el paso 7 de la secuencia básica
La escritura limpia del caso de uso lo hace claro, preciso y consistente, entre otros atributos deseables en un caso de uso. Nótese que es posible que haya más secuencias alternas.
Para saber más de casos de uso pueden visitar la sección Lecturas Fundamentales de mi Gazafatonario IT. En particular, pueden leer la Lectura Fundamental 3: Casos de Uso: Del Todo y de sus Partes.
Esta serie de consejos útiles para escribir casos de uso inicia en: