Cómo escribir casos de uso efectivos

Nombre del caso de uso – Tickets de pedido

El nombre es bueno. Claramente da una indicación de cuál es el caso de uso.

Objetivo: el cliente reserva con éxito entradas para el partido de fútbol en el sitio web

Descripción- El actor visita el sitio web, ve el
horario, selecciona el partido
y asientos, libros el
billete y realiza el pago del partido de fútbol

El objetivo y la descripción se mencionan claramente.
Esto ayudará a los diseñadores.
y los desarrolladores entienden cuál es el
objetivo de sus documentos de diseño y código

Actores: cliente, representante de servicio al cliente
Condiciones previas: el sistema está en funcionamiento.
Activador: el actor ha accedido al sistema para reservar entradas.
Condición posterior: el actor puede reservar boletos. El sistema actualiza la información.

Todos los demás detalles de casos de uso , como Actores,
condiciones previas, condiciones posteriores y
se mencionan los disparadores que ayudarán al
diseño y desarrollo de la aplicación más fácil.

Flujo principal: pasos

1. El actor accede a la web y selecciona reservar entradas
2. El sistema muestra la información de la reserva
3. El actor confirma los detalles de la coincidencia (más detalles en la especificación de la interfaz de usuario)
4. El actor confirma los detalles del asiento (Más detalles en la especificación de la interfaz de usuario)
5. El sistema confirma disponibilidad
6. Sistema presenta formulario para obtener información del usuario
7. El actor da información al usuario (Detalles en otro caso de uso)
8. Sistema presenta formulario para información de pago
9. El actor da información de pago (Detalles en otro caso de uso)
10. El sistema confirma los detalles y proporciona una identificación de reserva
11. El actor guarda el billete
12. El actor sale del sistema.

Casos de uso incluidos

- Hacer el pago

– Generar ID de reserva

Casos de uso extendido

– Generar Nota de Fallo de Pago

– Imprimir billete

Los pasos en el flujo principal son claros pero
Los detalles de la interfaz de usuario se omiten. Detalles de la interfaz de usuario en el caso de uso
sobre la selección de asientos y el partido
la selección puede hacer que el caso de uso sea difícil de manejar.
El caso de uso muestra claramente lo que el actor tiene que hacer y lo que hará el sistema.
El proceso de pago se detalla en un
caso de uso diferente para que las tareas puedan ser
se descompone fácilmente en diferentes componentes de diseño.
Los casos de uso incluidos y extendidos se nombran
para que uno pueda
consúltelos para obtener más detalles.

Flujo alternativo

-cancelar boletos

1. Actor cancela transacción
2. El sistema cancela la transacción

Flujo de excepción

-Entradas no disponibles para partidos seleccionados/asientos seleccionados

1. El sistema muestra un mensaje de error

Se detallan los flujos alternativos y de excepción .

* El caso de uso puede ser más detallado en términos de referencias y flujos alternativos y de excepción. Este ejemplo es para resaltar lo que debe incluirse en un caso de uso bien escrito.

Nombre del caso de uso: pedido de boletos

El nombre no es desde la perspectiva del usuario y parece una definición de proceso empresarial.

Descripción : el actor visita el sitio web, ve el calendario, selecciona el partido y los asientos, reserva la entrada y realiza el pago del partido de fútbol.

Falta el objetivo del caso de uso. Los diseñadores, analistas de pruebas y desarrolladores no entenderán por qué se debe desarrollar esta funcionalidad.

Actores : cliente, representante de servicio al cliente
Activador : el actor ha accedido al sistema para reservar entradas.
Condición posterior : el actor puede reservar boletos. El sistema actualiza la información.

Faltan las condiciones previas.

Pasos de flujo principal

1. El cliente accede a la web y selecciona la opción 'Reservar Entradas' para reservar entradas
2. El sistema muestra la lista de coincidencias en un menú desplegable.
3. El Representante de Servicio al Cliente selecciona del menú desplegable
4. El sistema muestra los detalles de los asientos en un mapa de asientos
5. El actor elige los asientos. Si los asientos no están disponibles y se muestra un mensaje de error.
6. El actor da detalles de pago.
7. El actor reserva el boleto, de lo contrario cancela el boleto.
8. El sistema genera una identificación de reserva utilizando el nombre del cliente y un número de 4 dígitos generado aleatoriamente

Casos de uso incluidos
- Hacer el pago

En los pasos del caso de uso, hay algunas referencias a elementos reales de la interfaz de usuario que pueden confundir al lector. Los flujos alternativos están escritos dentro del flujo principal, lo que dificulta la comprensión de todo el proceso.
Se hace referencia al actor por muchos nombres: 'Cliente, Actor y Representante de servicio al cliente, lo cual es confuso.
La generación de ID de reserva se explica aquí, aunque no es de interés para los actores relacionados con el pedido de boletos.
No hay flujos alternativos, flujos de excepción y no se mencionan todos los casos de uso relacionados.

Este caso de uso carece de claridad y detalles y no ayudará al equipo a desarrollar la funcionalidad correctamente.

1. Nombre
2. Descripción/Objetivo
3. condiciones previas
4. Desencadenar
5. Flujo básico y flujos alternos
6. Escenarios de excepción
7. Publicar condiciones
8. Requisitos especiales si los hay
9. Enlace a los detalles de la interfaz de usuario y otros modelos/diagramas relacionados

1. Detalles de implementacion
2. Procesamiento interno
3. requerimientos no funcionales
4. Los detalles de la interfaz de usuario deben realizarse simultáneamente con los casos de uso, pero en un documento separado

.