Una descripción de caso de uso explica cómo un actor logra un objetivo interactuando con un sistema. Complementa un diagrama de casos de uso:

• Diagrama de casos de uso: Muestra actores, alcance del sistema y relaciones.

• Descripción de caso de uso: Explica el comportamiento detallado, condiciones, reglas y resultados.

Un diagrama proporciona el mapa; la descripción proporciona la ruta.

1. ¿Qué es un caso de uso?

Un caso de uso representa un objetivo valioso que un actor externo logra a través de un sistema.

Ejemplos:

• El cliente realiza un pedido

• El empleado presenta una reclamación de gastos

• El paciente agenda una cita

• El administrador crea una cuenta de usuario

• El cliente restablece una contraseña

Un buen caso de uso es:

• Orientado a objetivos

• Valioso para un actor

• Descrito desde la perspectiva del usuario

• Independiente de diseños de pantalla específicos

• Centrado en el comportamiento observable del sistema

Nombres de casos de uso deficientes y mejorados

Utilice una frase corta verbo-sustantivo como Presentar reclamación de gastos, Rastrear envío, o Aprobar solicitud de préstamo.

2. Conceptos clave

2.1 Actores

Un actor es un rol externo que interactúa con el sistema.

Un actor puede ser:

• Una persona

• Una organización

• Otro sistema de software

• Un dispositivo de hardware

• Un disparador programado o basado en el tiempo

Ejemplos:

• Cliente

• Agente de soporte

• Auxiliar de almacén

• Pasarela de pago

• Servicio de correo electrónico

• Administrador

Un actor es un rol, no necesariamente un individuo específico. Por ejemplo, “Cliente” suele ser mejor que “Jane Smith”.

Actores principales y de apoyo

El actor principal inicia el caso de uso para lograr un objetivo.

El actor de apoyo asiste al sistema durante la ejecución.

Ejemplo:

• Actor principal: Cliente

• Actor de apoyo: Pasarela de pago

• Caso de uso: Realizar pedido

El cliente inicia el pedido, mientras que la pasarela de pago autoriza el pago.

2.2 Límite del sistema

El límite del sistema define qué está dentro del sistema que se está modelando.

Para una tienda en línea, el límite podría incluir:

• Navegar por los productos

• Añadir producto al carrito

• Realizar pedido

• Realizar pago

• Rastrear pedido

Los siguientes están fuera del límite:

• Cliente

• Pasarela de pago

• Empresa de entrega

• Proveedor de correo electrónico

El límite evita la confusión sobre la responsabilidad del sistema.

2.3 Caso de uso

Un caso de uso debe describir una interacción completa que produzca un resultado significativo.

Por ejemplo:

Realizar pedido:Un cliente selecciona productos, proporciona información de entrega, paga por el pedido y recibe una confirmación del pedido.

«Validar número de tarjeta de crédito» podría ser una función del sistema, pero generalmente es demasiado pequeña para ser un objetivo de usuario independiente. En cambio, podría ser parte de Realizar pedido o Realizar pago.

2.4 Precondiciones

Una precondición establece lo que debe ser cierto antes de que comience el caso de uso.

Ejemplos:

• El cliente tiene una cuenta activa.

• El producto está disponible para la venta.

• El empleado está autenticado.

• La cita está programada.

• El carrito de compras contiene al menos un artículo.

Una precondición no es una acción realizada por el caso de uso.

Precondición deficiente:

El cliente inicia sesión.

Precondición mejorada:

El cliente está autenticado.

2.5 Poscondiciones

Una poscondición establece lo que es cierto después de que finaliza el caso de uso.

Ejemplos:

• El pedido está registrado.

• El pago está autorizado.

• Se envía un correo electrónico de confirmación.

• La reclamación de gastos tiene un estado de presentada.

• La cuenta de usuario está marcada como activa.

Las postcondiciones deben describir resultados, no detalles de implementación.

Postcondición deficiente:

La pedidos tabla se actualiza.

Postcondición mejorada:

El pedido se almacena y está disponible para su cumplimiento.

2.6 Escenario principal de éxito

El escenario principal de éxito, también llamado el flujo básico o camino feliz, describe la interacción normal exitosa.

Cada paso debe describir:

1. Una interacción entre el actor y el sistema

2. Una respuesta del sistema

3. Una acción empresarial significativa

Ejemplo:

1. El cliente selecciona productos.

2. El sistema muestra el carrito actual.

3. El cliente ingresa la información de entrega.

4. El sistema valida la información de entrega.

5. El cliente envía el pedido.

6. El sistema solicita la autorización del pago.

7. La pasarela de pagos autoriza el pago.

8. El sistema registra el pedido.

9. El sistema muestra la confirmación del pedido.

Evite detalles específicos de la interfaz a menos que sean esenciales para el requisito.

Paso deficiente:

El cliente hace clic en el botón azul en la esquina inferior derecha.

Paso mejorado:

El cliente envía el pedido.

2.7 Flujos alternativos

Un flujo alternativo describe una variación válida del escenario principal.

Ejemplos:

• El cliente elige la recogida en tienda en lugar de la entrega.

• El cliente paga con un método de pago guardado.

• El administrador aprueba una reclamación con condiciones.

• El usuario se autentica utilizando un código de un solo uso.

Los flujos alternativos pueden volver a unirse al flujo principal.

Ejemplo:

A1. El cliente utiliza un método de pago guardado
En el Paso 6, el cliente selecciona un método de pago guardado. El sistema solicita autorización utilizando ese método y luego continúa en el Paso 7.

2.8 Flujos de excepciones

Un flujo de excepción describe una condición no exitosa o anormal.

Ejemplos:

• El pago es rechazado.

• El producto está agotado.

• La autenticación falla.

• El servicio externo no está disponible.

• Los datos requeridos son inválidos.

Un flujo de excepción debe explicar:

• Dónde ocurre el problema

• Qué hace el sistema

• Qué ve el actor

• Si el caso de uso termina o se reanuda

Ejemplo:

E1. El pago es rechazado
En el Paso 7, la Pasarela de Pago rechaza la transacción. El sistema muestra el motivo, marca el pedido como no pagado y permite al cliente seleccionar otro método de pago.

2.9 Relaciones de Incluir y Extender

incluir

Usar incluir cuando un caso de uso siempre invoca otro comportamiento reutilizable.

Ejemplo:

• Realizar Pedido incluye Calcular Total

• Realizar Pedido incluye Autenticar Cliente

• Retirar Efectivo incluye Verificar PIN

El comportamiento incluido es obligatorio.

Realizar Pedido <<include>> Calcular Total

extender

Usar extender cuando un comportamiento opcional o condicional complementa un caso de uso base.

Ejemplo:

• Realizar Pedido puede ser extendido por Aplicar Código de Descuento

• Finalizar Compra puede ser extendido por Agregar Mensaje de Regalo

El comportamiento extendido no siempre se ejecuta.

Aplicar Código de Descuento <<extend>> Realizar Pedido

Una regla útil:

• Incluir: “Esto siempre ocurre como parte del caso de uso.”

• Extender: “Esto puede ocurrir bajo ciertas condiciones.”

No use incluir y extender simplemente para dividir cada flujo en pequeñas partes. Una descomposición excesiva hace que el modelo sea difícil de entender.

2.10 Generalización

La generalización representa la herencia entre actores o casos de uso.

Ejemplo:

• Empleado es un actor general.

• Gerente es un actor especializado que hereda el comportamiento del Empleado.

Manager --|> Empleado

Utilice la generalización cuando el elemento especializado sea genuinamente un tipo del elemento generalizado, no simplemente porque dos elementos compartan algunos pasos.

3. Plantilla estándar de descripción de caso de uso

La siguiente plantilla funciona bien para documentos de requisitos, especificaciones de proyectos y modelos de análisis.

ID del caso de uso:
Nombre del caso de uso:
Objetivo:
Alcance:
Nivel:
Actor principal:
Actores de soporte:
Partes interesadas e intereses:

Disparador:

Precondiciones:

Garantías mínimas:

Garantías de éxito:

Escenario principal de éxito:
1.
2.
3.

Flujos alternativos:
A1.
A2.

Flujos de excepción:
E1.
E2.

Requisitos especiales:
- Rendimiento
- Seguridad
- Usabilidad
- Disponibilidad
- Cumplimiento

Reglas de negocio:

Requisitos de datos:

Frecuencia y volumen:

Supuestos:

Preguntas abiertas:

Casos de uso relacionados:

Explicación de los campos

4. Ejemplo: Realizar pedido

UC-001 — Realizar pedido

Objetivo:
Permitir a un cliente comprar uno o más productos.

Alcance:
Tienda en línea

Nivel:
Objetivo del usuario

Actor principal:
Cliente

Actores de apoyo:

• Pasarela de pago

• Servicio de inventario

• Servicio de correo electrónico

• Servicio de entrega

Partes interesadas e intereses:

• Cliente: Desea comprar productos con éxito y recibir confirmación.

• Tienda: Desea registrar un pedido válido y cobrar el pago.

• Almacén: Necesita información precisa de cumplimiento.

• Pasarela de pago: Necesita una solicitud de pago válida.

• Servicio de entrega: Necesita una dirección de entrega completa.

Disparador:
El cliente envía el carrito de compras para finalizar la compra.

Precondiciones:

• El cliente tiene al menos un artículo en el carrito.

• Los productos están disponibles para pedir.

• El cliente proporciona una dirección de entrega válida.

• El sistema puede comunicarse con el servicio de pago.

Garantías mínimas:

• Ningún pedido sin pagar se considera confirmado.

• El cliente es informado si el pedido no puede completarse.

• El inventario reservado se libera si el pago falla.

Garantías de éxito:

• El pago está autorizado.

• El pedido se registra.

• El inventario se reserva.

• El cliente recibe una confirmación.

• La información de cumplimiento está disponible para el almacén.

Escenario principal de éxito

1. El cliente revisa el carrito de compras.

2. El sistema muestra los productos, cantidades, precios, impuestos, costo de envío y total.

3. El cliente proporciona la información de entrega.

4. El sistema valida la información de entrega.

5. El cliente selecciona un método de pago.

6. El cliente envía el pedido.

7. El sistema verifica la disponibilidad del producto.

8. El sistema solicita la autorización del pago a la Pasarela de Pago.

9. La Pasarela de Pago autoriza el pago.

10. El sistema crea el pedido.

11. El sistema reserva los productos pedidos.

12. El sistema envía una confirmación del pedido al cliente.

13. El sistema muestra el número de pedido y la fecha estimada de entrega.

Flujos alternativos

A1. El cliente utiliza una dirección guardada

En el Paso 3, el cliente selecciona una dirección previamente guardada. El sistema muestra la dirección y continúa en el Paso 4.

A2. El cliente utiliza un método de pago guardado

En el Paso 5, el cliente selecciona un método de pago guardado. El sistema utiliza ese método y continúa en el Paso 6.

A3. El cliente elige la recogida en tienda

En el Paso 3, el cliente elige la recogida en tienda en lugar de la entrega. El sistema muestra las tiendas disponibles y las fechas de recogida, luego continúa en el Paso 5.

Flujos de excepciones

E1. Producto no disponible

En el Paso 7, el sistema determina que un producto no está disponible. El sistema identifica el producto no disponible, actualiza el carrito y solicita al cliente que revise el pedido.

E2. El pago es rechazado

En el Paso 9, la Pasarela de Pagos rechaza el pago. El sistema no confirma el pedido, libera las reservas de inventario, muestra el mensaje de error y permite al cliente seleccionar otro método de pago.

E3. La Pasarela de Pagos no está disponible

En el Paso 8, la Pasarela de Pagos no responde dentro del tiempo de espera configurado. El sistema marca el intento de pago como pendiente, informa al cliente y evita el envío duplicado del pedido.

Reglas de negocio

• Un pedido debe contener al menos un producto.

• La cantidad del producto debe ser mayor que cero.

• Un producto no puede ser pedido cuando el stock disponible es insuficiente.

• El pago debe ser autorizado antes de que se confirme el pedido.

• Los precios y los impuestos se calculan utilizando las reglas de precios vigentes.

• Un cliente puede cancelar un pedido solo antes de que comience su cumplimiento.

Requisitos especiales

• El resumen del pedido debe mostrarse en un plazo de dos segundos bajo carga normal.

• La información de pago no debe almacenarse en texto plano.

• Los envíos duplicados no deben crear pedidos duplicados.

• El sistema debe registrar un rastro de auditoría para los cambios en el estado del pago y del pedido.

5. Niveles de casos de uso

Las descripciones de los casos de uso pueden redactarse en diferentes niveles de detalle.

Caso de uso a nivel de resumen

Un caso de uso de resumen describe un proceso comercial amplio.

Ejemplo:

Cumplir el pedido del cliente

Esto puede incluir:

• Recibir el pedido

• Seleccionar productos

• Empaquetar el pedido

• Despachar el pedido

Caso de uso a nivel de objetivo del usuario

Este es generalmente el nivel más útil para el análisis de requisitos.

Ejemplo:

Realizar pedido

Describe un objetivo que un actor principal puede lograr en una sola sesión.

Caso de uso a nivel de subfunción

Esto describe un comportamiento del sistema más pequeño y reutilizable.

Ejemplos:

• Calcular el total del pedido

• Validar el pago

• Generar factura

Los casos de uso a nivel de subfunción son útiles cuando el comportamiento se reutiliza o es técnicamente complejo, pero no deben reemplazar los casos de uso orientados a objetivos del usuario.

6. Redacción de descripciones de casos de uso de alta calidad

Utilice un lenguaje centrado en el actor

Escriba desde la perspectiva del actor:

El cliente envía un pedido.

Evite una redacción centrada en la implementación:

OrderController invoca el servicio de pedidos.

Lo último pertenece a la documentación de diseño, no a un caso de uso empresarial.

Mantenga cada paso atómico

Evite combinar demasiadas acciones:

El cliente introduce los detalles, selecciona el pago, confirma el pedido y recibe un correo electrónico.

Mejórelo separando la interacción:

1. El cliente introduce la información de entrega.

2. El sistema valida la información.

3. El cliente selecciona un método de pago.

4. El cliente confirma el pedido.

5. El sistema envía una confirmación.

Describa el comportamiento observable

Un lector debería poder determinar si el requisito ha sido implementado.

Débil:

El sistema procesa la solicitud.

Más fuerte:

El sistema valida la solicitud, registra la reclamación, le asigna un número de reclamación y muestra el estado de la presentación.

Evite el diseño prematuro de la interfaz de usuario

Use:

El cliente proporciona la información de entrega.

En lugar de:

El cliente ingresa la dirección en el cuadro de texto y hace clic en el botón verde Continuar.

La segunda versión restringe innecesariamente la interfaz.

Mantenga el flujo principal exitoso

No llene el flujo básico con todos los errores posibles. Coloque los errores en los flujos de excepción.

Identifique las reglas de negocio por separado

Las reglas de negocio a menudo se aplican a múltiples casos de uso. Mantenerlas separadas evita texto repetido e inconsistente.

Haga explícito el comportamiento de fallo

Para cada fallo importante, especifique:

• Si los datos se guardan

• Si una transacción se revierte

• Si el actor puede reintentar

• Si se notifica a un administrador

• Si el caso de uso termina o se reanuda

7. De los requisitos a los casos de uso

Un flujo de trabajo práctico es:

1. Identifique el sistema que se está modelando.

2. Liste los actores externos.

3. Pregunte qué quiere lograr cada actor.

4. Convierta cada objetivo en un nombre de caso de uso.

5. Defina el límite del sistema.

6. Escriba el escenario principal de éxito.

7. Añada flujos alternativos y de excepción.

8. Añada reglas de negocio y requisitos especiales.

9. Dibuje el diagrama de casos de uso.

10. Revise el modelo con las partes interesadas.

11. Vincular los casos de uso con los requisitos, las pruebas y los artefactos de diseño.

Análisis de actor-objetivo

Una pregunta útil es:

¿Qué resultado empresarial necesita este actor del sistema?

8. Notación del diagrama de casos de uso

Los elementos más comunes son:

• Actor:Rol externo

• Caso de uso: Capacidad del sistema o objetivo del actor

• Límite del sistema: Alcance del sistema

• Asociación: El actor participa en un caso de uso

• Incluir: Comportamiento reutilizable requerido

• Extender: Comportamiento opcional o condicional

• Generalización: Actor o caso de uso especializado

Un diagrama de casos de uso no debe intentar mostrar:

• Cada paso del flujo de trabajo

• Tablas de base de datos

• Atributos de clase

• Reglas de negocio detalladas

• Diseños de pantalla

• Algoritmos internos

Esos pertenecen a diagramas de actividad, diagramas de clase, diagramas de secuencia o requisitos escritos.

9. Ejemplo de diagrama PlantUML

El siguiente ejemplo modela el Realizar pedido caso de uso y comportamiento relacionado.

@startuml
dirección de izquierda a derecha

skinparam packageStyle rectangle
skinparam shadowing false
skinparam usecase {
    BackgroundColor #F8FBFF
    BorderColor #2F5597
    ArrowColor #555555
}

actor Cliente
actor "Pasarela de pago" as Pago
actor "Servicio de inventario" as Inventario
actor "Servicio de correo electrónico" as Email
actor "Servicio de entrega" as Entrega

rectangle "Tienda en línea" {
    usecase "Navegar por productos" as Navegar
    usecase "Gestionar carrito" as Carrito
    usecase "Realizar pedido" as RealizarPedido
    usecase "Calcular total del pedido" as CalcularTotal
    usecase "Verificar disponibilidad del producto" as VerificarStock
    usecase "Autorizar pago" como AutorizarPago
    usecase "Reservar inventario" as ReservarInventario
    usecase "Enviar confirmación del pedido" as EnviarConfirmación
    usecase "Rastrear pedido" as RastrearPedido
    usecase "Aplicar código de descuento" as AplicarDescuento
}

Cliente --> Navegar
Cliente --> Carrito
Cliente --> RealizarPedido
Cliente --> RastrearPedido

Pago --> AutorizarPago
Inventario --> VerificarStock
Inventario --> ReservarInventario
Email --> EnviarConfirmación
Entrega --> RastrearPedido

RealizarPedido ..> CalcularTotal : <<incluir>>
RealizarPedido ..> VerificarStock : <<incluir>>
RealizarPedido ..> AutorizarPago : <<incluir>>
RealizarPedido ..> ReservarInventario : <<incluir>>
RealizarPedido ..> EnviarConfirmación : <<incluir>>

AplicarDescuento ..> RealizarPedido : <<extender>>

@enduml

Interpretación

• El Cliente inicia Realizar Pedido.

• Realizar Pedido siempre incluye cálculo, verificación de existencias, autorización de pago, reserva de inventario y confirmación.

• Aplicar Código de Descuento es opcional, por lo tanto extiende Realizar Pedido.

• Los servicios externos participan en comportamientos específicos del sistema.

• El límite del sistema es el Tienda en Línea rectángulo.

La colocación exacta de los elementos está controlada por el motor de renderizado. Las decisiones de modelado importantes son los actores, casos de uso, límites y relaciones.

10. Creación del diagrama en Visual Paradigm VPasCode

VPasCode es una plataforma basada en navegador de texto a diagrama que admite PlantUML, Mermaid, Graphviz y otros formatos de diagramas. Proporciona edición de código fuente y renderizado en vivo, permitiendo que el diagrama se actualice a medida que cambia el código.

Flujo de trabajo básico

1. Abra el editor de VPasCode.

2. Cree un nuevo diagrama PlantUML.

3. Pegue el código fuente de PlantUML.

4. Confirme que el editor reconoce la sintaxis de PlantUML.

5. Revise la vista previa en vivo.

6. Edite los actores, casos de uso, relaciones y estilos en el panel de código fuente.

7. Exporte o copie el diagrama renderizado.

8. Agregue el diagrama a la documentación del proyecto.

VPasCode admite diagramas de casos de uso de PlantUML y ofrece renderizado en tiempo real en el navegador. También proporciona ejemplos y opciones de estilo para diagramas de PlantUML.

Ejemplo de instrucción para generación asistida por IA

Si utiliza una función de generación de diagramas con IA, una instrucción útil es:

Cree un diagrama de casos de uso de PlantUML para una tienda en línea.

Actor principal:
- Cliente

Actores de soporte:
- Pasarela de pago
- Servicio de inventario
- Servicio de correo electrónico
- Servicio de entrega

Casos de uso principales:
- Explorar productos
- Gestionar carrito
- Realizar pedido
- Rastrear pedido

Realizar pedido debe incluir:
- Calcular el total del pedido
- Verificar la disponibilidad del producto
- Autorizar el pago
- Reservar inventario
- Enviar confirmación del pedido

Aplicar código de descuento debe extender Realizar pedido.

Utilice un límite del sistema llamado Tienda en Línea.

Trate el código generado como un punto de partida. Revise si:

• Los actores son genuinamente externos

• Los casos de uso representan los objetivos del usuario

• incluir y extender se utilizan correctamente

• El límite del sistema es preciso

• Las relaciones reflejan el comportamiento empresarial real

VPasCode también admite el cambio entre la edición de diagramas basada en texto y las herramientas de modelado gráfico de Visual Paradigm, lo cual puede ser útil cuando los equipos desean una edición basada en código fuente para el control de versiones y una edición visual para el refinamiento del diseño.

11. Mantenimiento de diagramas de casos de uso PlantUML

Utilice alias significativos

Los alias facilitan el mantenimiento de las relaciones:

usecase "Place Order" as PlaceOrder
Customer --> PlaceOrder

Añadir comentarios

' Transacción principal del cliente
usecase "Place Order" as PlaceOrder

Los comentarios ayudan a otros miembros del equipo a comprender el código fuente y mantener el diagrama.

Mantenga el diagrama enfocado

Si un diagrama contiene demasiados casos de uso:

• Cree un diagrama de contexto

• Cree diagramas separados por área de negocio

• Utilice agrupaciones por paquetes

• Enlace los diagramas relacionados mediante documentación

• Evite mostrar cada subfunción en el nivel más alto

Utilice una nomenclatura coherente

Elige una convención y aplícala de manera consistente:

• Realizar pedido

• Cancelar pedido

• Rastrear pedido

Evita mezclar estilos como:

• Realizar pedido

• Cancelación de pedido

• tracking_function

Almacena el código fuente con el proyecto

Una estructura típica del repositorio podría ser:

docs/
  use-cases/
    UC-001-place-order.md
    UC-002-track-order.md
  diagrams/
    online-store-use-cases.puml

Mantener el .puml fuente bajo control de versiones hace que los cambios sean revisables y reproducibles.

12. Trazabilidad

Un proceso de requisitos maduro conecta los casos de uso con otros artefactos del proyecto.

La trazabilidad ayuda a responder:

• ¿Qué requisitos están cubiertos?

• ¿Qué casos de uso no han sido probados?

• ¿Qué componentes de diseño apoyan un objetivo empresarial?

• ¿Qué se ve afectado si un requisito cambia?

13. Errores comunes

Modelar componentes internos como actores

Una base de datos o un servicio interno no suele ser un actor si está dentro del límite del sistema.

Un actor debe ser externo al sistema que se está modelando.

Tratar las pantallas como casos de uso

Una pantalla es un elemento de la interfaz de usuario, no necesariamente un objetivo del usuario.

Usar:

Presentar reclamación de gastos

En lugar de:

Pantalla de reclamación de gastos

Usar incluir para cada paso compartido

La redacción compartida por sí sola no justifica un caso de uso incluido. Usar incluir cuando el comportamiento es obligatorio y tiene significado independiente.

Usar extender para pasos normales

Si un comportamiento siempre ocurre, no debe modelarse como una extensión.

Escribir detalles de implementación

Evitar referencias a:

• Controladores

• Tablas de base de datos

• Puntos finales de la API

• Clases

• Métodos internos

a menos que el documento sea específicamente un diseño técnico.

Omitir el comportamiento de fallo

Un caso de uso está incompleto si solo explica el éxito. Se deben abordar el rechazo de pagos, datos inválidos, tiempos de espera agotados, fallos de autorización y recursos no disponibles.

Hacer que los casos de uso sean demasiado amplios

“Gestionar todo el negocio” no es accionable. Desglose los objetivos amplios en casos de uso a nivel de objetivo del usuario.

Hacer que los casos de uso sean demasiado pequeños

“Validar campo” y “Mostrar mensaje” son generalmente pasos del sistema, no objetivos independientes del actor.

14. Lista de verificación de revisión

Antes de aprobar una descripción de caso de uso, verifique:

Alcance y actores

• ¿Está claro el límite del sistema?

• ¿Están identificados todos los actores externos?

• ¿Son los actores roles en lugar de nombres individuales?

• ¿Se modelan los sistemas de soporte solo cuando son externos?

Calidad del objetivo

• ¿Proporciona el caso de uso valor al actor principal?

• ¿Es el nombre una frase clara de verbo–sustantivo?

• ¿Está el caso de uso en un nivel apropiado?

Calidad del flujo

• ¿Describe el escenario principal un resultado exitoso?

• ¿Es cada paso atómico y observable?

• ¿Están documentadas las rutas alternativas?

• ¿Están documentadas las rutas de excepción?

• ¿Está claro el comportamiento de recuperación?

Condiciones y resultados

• ¿Son comprobables las precondiciones?

• ¿Son explícitas las garantías de éxito?

• ¿Están definidas las garantías mínimas?

• ¿Están separadas las reglas de negocio de los pasos procedimentales?

Calidad del diagrama

• ¿Están todos los casos de uso dentro del límite correcto?

• ¿Son significativas las asociaciones de actores?

• ¿Son incluyen relaciones obligatorias?

• ¿Son extienden relaciones opcionales o condicionales?

• ¿Es el diagrama legible sin un detalle excesivo?

Calidad de los requisitos

• ¿Puede probarse cada paso importante?

• ¿Están incluidos los requisitos no funcionales?

• ¿Están registradas las preguntas sin resolver?

• ¿Está el caso de uso vinculado a los requisitos y casos de prueba?

15. Estructura recomendada de entregables

Para un paquete de proyecto completo, utilice la siguiente estructura:

1. Contexto del sistema
2. Catálogo de actores
3. Diagrama de casos de uso
4. Catálogo de casos de uso
5. Descripciones detalladas de casos de uso
6. Reglas de negocio
7. Requisitos no funcionales
8. Matriz de trazabilidad
9. Preguntas abiertas y suposiciones
10. Archivos fuente de PlantUML

Una descripción sólida de un caso de uso es lo suficientemente precisa para los analistas, comprensible para las partes interesadas y verificable por un equipo de aseguramiento de la calidad. El mejor flujo de trabajo es utilizar la descripción escrita para establecer el comportamiento, el diagrama de casos de uso para comunicar el alcance y las relaciones, y PlantUML en VPasCode para mantener el modelo visual fácil de editar y mantener.

Referencia