Now Reading: Guía completa sobre la elaboración de casos de uso: conceptos clave, métodos y ejemplos

1
  • 01

    Guía completa sobre la elaboración de casos de uso: conceptos clave, métodos y ejemplos

Read this post in: de_DEen_USfr_FRhi_INid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Guía completa sobre la elaboración de casos de uso: conceptos clave, métodos y ejemplos

UMLYesterday

Introducción

La elaboración de casos de uso es una fase crítica en el ciclo de vida del desarrollo de software, particularmente dentro del contexto de la ingeniería de requisitos y el análisis y diseño orientados a objetos. Cierra la brecha entre los casos de uso de alto nivel y las especificaciones detalladas del sistema, permitiendo a desarrolladores, analistas y partes interesadas comprendercómo se comporta un sistema en respuesta a objetivos específicos del usuario.

Esta guía ofrece una visión general completa dela elaboración de casos de uso, incluyendo su propósito, conceptos clave, metodología paso a paso, mejores prácticas y ejemplos del mundo real.

1. ¿Qué es la elaboración de casos de uso?

La elaboración de casos de uso es el proceso de refinar un caso de uso de alto nivel en una descripción detallada y accionable del comportamiento del sistema. Transforma una narrativa sencilla de interacción del usuario en una especificación precisa, verificable e implementable.

✅ Objetivo: Definirqué debe hacer el sistema,cómo debe hacerlo, ybajo qué condiciones, con suficiente detalle para el desarrollo y la prueba.

2. Por qué la elaboración de casos de uso es importante

  • Reduce la ambigüedad: Evita la interpretación errónea de los requisitos.

  • Mejora la trazabilidad: Enlaza los requisitos con el diseño, el código y los casos de prueba.

  • Apoya el diseño y la implementación: Proporciona una base para diagramas de clases, diagramas de secuencia y diseño de bases de datos.

  • Permite la prueba: Facilita la creación de escenarios de prueba y criterios de aceptación.

  • Mejora la colaboración: Garantiza un entendimiento compartido entre los interesados, desarrolladores y probadores.

3. Conceptos clave en la elaboración de casos de uso

3.1 Caso de uso (UC)

Un caso de uso describe una secuencia de acciones que un sistema realiza para obtener un resultado valioso para un actor (un usuario o sistema externo).

Ejemplo: “Retirar efectivo” de un cajero automático.

3.2 Actor

Una entidad externa que interactúa con el sistema. Puede ser un usuario humano, otro sistema o un desencadenante temporal.

Ejemplo: Cliente, máquina de cajero automático, pasarela de pagos.

3.3 Actores primarios y secundarios

  • Actor primario: Inicia el caso de uso.

  • Actor secundario: Apoya al actor primario (por ejemplo, un servidor bancario).

3.4 Precondiciones

Condiciones que deben ser verdaderas antes de que pueda comenzar el caso de uso.

Ejemplo: El usuario debe tener una tarjeta válida y un PIN correcto.

3.5 Postcondiciones

Condiciones que deben ser verdaderas después de que finalice el caso de uso.

Ejemplo: Se entrega efectivo, se actualiza el saldo de la cuenta.

3.6 Escenario principal de éxito (flujo básico)

El camino más común a través del caso de uso que conduce al éxito.

Ejemplo: Insertar tarjeta → Ingresar PIN → Seleccionar retiro → Ingresar monto → Recibir efectivo.

3.7 Flujos alternativos (flujos de excepción)

Ramificaciones en el caso de uso que manejan excepciones, errores o variaciones.

Ejemplo: PIN inválido → Volver a intentar o cancelar.

3.8 Extensiones

Puntos en el flujo principal donde se puede insertar un comportamiento alternativo (por ejemplo, mediante “<>” en UML).

Ejemplo: “<>: Notificar al banco sobre actividad sospechosa.”

3.9 Requisitos no funcionales (NFRs)

Restricciones sobre el comportamiento del sistema (por ejemplo, rendimiento, seguridad, usabilidad).

Ejemplo: “La transacción debe completarse en menos de 3 segundos.”

4. El proceso de elaboración del caso de uso (paso a paso)

Paso 1: Identificar el caso de uso

Comience con un caso de uso de alto nivel (por ejemplo, “Colocar pedido”).

Utilice una plantilla:
Nombre del caso de uso: Colocar pedido
Actor principal: Cliente
Partes interesadas: Cliente, Sistema de gestión de pedidos, Pasarela de pago

Paso 2: Definir condiciones previas

Enumere todas las condiciones que deben cumplirse antes de que comience el caso de uso.

  • El cliente ha iniciado sesión.

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

  • El método de pago está guardado.

Paso 3: Definir condiciones posteriores

Indique lo que debe ser verdadero después de que finalice el caso de uso.

  • El pedido se crea en el sistema.

  • El inventario se actualiza.

  • El pago se procesa.

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

Paso 4: Escribir el escenario principal de éxito (flujo básico)

Detalle el camino ideal y exitoso.

  1. El cliente selecciona “Pagar” desde el carrito de compras.

  2. El sistema muestra el resumen del pedido.

  3. El cliente confirma la dirección de envío.

  4. El cliente selecciona el método de pago.

  5. El sistema procesa el pago.

  6. El pago se confirma.

  7. El sistema crea el pedido y genera la confirmación.

  8. Se muestra la confirmación y se envía un correo electrónico.

Paso 5: Identificar flujos alternativos (flujos de excepción)

Liste las posibles desviaciones del flujo principal.

Flujo alternativo A: Stock insuficiente

  1. El sistema verifica el inventario.

  2. El artículo está agotado.

  3. El sistema muestra el mensaje: «El artículo no está disponible».

  4. El cliente puede eliminar el artículo o continuar sin él.

Flujo alternativo B: Pago rechazado

  1. El pago es rechazado.

  2. El sistema muestra el error: «Pago rechazado».

  3. El cliente puede intentarlo de nuevo o elegir otro método.

Flujo alternativo C: Dirección de envío inválida

  1. El sistema valida la dirección.

  2. La dirección es inválida.

  3. El sistema solicita al cliente que la corrija.

Paso 6: Definir extensiones (relaciones <>)

Utilice extensiones de estilo UML para mostrar comportamiento opcional.

  • <>: Notificar al sistema de inventario

    • Disparador: Cuando un artículo se agota durante el proceso de pago.

    • Propósito: Alertar al almacén para reabastecer.

  • <>: Aplicar cupón de descuento

    • Disparador: El cliente ingresa un código de cupón válido.

    • Propósito: Reducir el costo total.

Paso 7: Agregar requisitos no funcionales (RNF)

Incluya las restricciones del sistema.

  • El pedido debe procesarse dentro de 5 segundos.

  • El pago debe cifrarse utilizando TLS 1.3.

  • El sistema debe soportar 10,000 usuarios concurrentes.

Paso 8: Revisar y validar

Colaborar con los interesados para garantizar la completitud y precisión.

  • Pregunte: “¿Cubre esto todos los objetivos del usuario?”

  • Pregunte: “¿Se han considerado todos los casos extremos?”

  • Pregunte: “¿Puede un desarrollador construir a partir de esto?”

5. Herramientas y técnicas para la elaboración

Herramienta/Técnica Propósito
Diagrama de casos de uso (UML) Visualizar actores y casos de uso.
Diagrama de secuencia Mostrar el flujo de mensajes entre objetos durante el caso de uso.
Diagrama de actividad Modelar flujos de trabajo complejos y puntos de decisión.
Mapa de historias de usuario Vincular casos de uso con el recorrido del usuario y prioridades.
Tablas de decisión Aclarar lógica compleja (por ejemplo, reglas de descuento).

6. Mejores prácticas

  1. Mantenga los casos de uso centrados en el usuario: Enfóquese en los objetivos del usuario, no en las características del sistema.

  2. Use una nomenclatura consistente: Use el formato verbo-nombre (por ejemplo, “Actualizar perfil”).

  3. Evite el jergón técnico: Escríbalo para interesados no técnicos.

  4. Use un lenguaje claro: Sea claro y conciso.

  5. Iterar: Perfecciona los casos de uso a medida que crece el entendimiento.

  6. Enlazar con otros artefactos: Conecta los casos de uso con diagramas de clases, casos de prueba y historias de usuarios.

  7. Priorizar: Enfócate primero en los casos de uso de alto valor o alto riesgo.

7. Ejemplo del mundo real: Banca en línea – Transferir dinero

Casos de uso: Transferir dinero

Actor principal: Cliente
Actor secundario: Servidor del banco, Sistema de detección de fraudes

Precondiciones

  • El cliente ha iniciado sesión.

  • La cuenta de origen tiene fondos suficientes.

  • No se ha superado el límite de transferencia.

Postcondiciones

  • Los fondos se transfieren desde la cuenta de origen a la de destino.

  • La transacción se registra en ambas cuentas.

  • Se envía una notificación a ambas partes.

Escenario principal de éxito

  1. El cliente selecciona «Transferir dinero» desde el panel de control.

  2. El sistema muestra el formulario de transferencia.

  3. El cliente ingresa la cuenta de destino y la cantidad.

  4. El sistema valida la cuenta y la cantidad.

  5. El cliente confirma la transferencia.

  6. El sistema verifica las reglas de detección de fraudes.

  7. La transacción es aprobada y ejecutada.

  8. Se muestra un mensaje de confirmación.

Flujos alternativos

  • A1: Fondos insuficientes
    → El sistema muestra: «Fondos insuficientes.»
    → El cliente puede cancelar o ajustar la cantidad.

  • A2: Fraude detectado
    → El sistema bloquea la transferencia y envía una alerta.
    → El cliente debe verificar mediante 2FA o contactar al soporte.

  • A3: Cuenta de destino inválida
    → El sistema muestra: «Cuenta no encontrada.»
    → El cliente puede volver a ingresarla o usar la búsqueda de cuenta.

Extensiones

  • <>: Enviar notificación al destinatario

    • Disparador: Transferencia completada.

    • Propósito: Informar al destinatario.

  • <>: Aplicar tarifa de transferencia

    • Disparador: Monto de transferencia > $1.000.

    • Propósito: Descontar tarifa de $5.

Requisitos no funcionales

  • Todas las transferencias deben registrarse y ser auditables.

  • Tiempo de respuesta ≤ 2 segundos.

  • Los datos están cifrados durante la transmisión y en reposo.

8. Errores comunes y cómo evitarlos

Error común Solución
Demasiado vago (por ejemplo, «El sistema debe procesar pedidos») Use acciones específicas y medibles.
Lenguaje demasiado técnico Use un lenguaje natural; evite términos de código o bases de datos.
Faltan rutas de excepción Use flujos alternativos para cubrir fallos.
Criterios de éxito no claros Define claramente las postcondiciones.
Sin revisión por parte de los interesados Involucra a usuarios, testers y analistas de negocio.

9. Conclusión

La elaboración de casos de uso no es solo un ejercicio de documentación: es un proceso estratégico que garantiza que el sistema satisfaga las necesidades reales de los usuarios con claridad, precisión y completitud. Al expandir sistemáticamente los casos de uso de alto nivel en especificaciones detalladas y accionables, los equipos reducen riesgos, mejoran la comunicación y establecen una base sólida para la entrega exitosa de software.

✅ Consejo final: Trata la elaboración de casos de uso como una conversación iterativa, no como una tarea única. Mejórala a medida que aprendas más sobre el sistema y sus usuarios.

Apéndice: Plantilla para la elaboración de casos de uso

# Nombre del caso de uso: [por ejemplo, Actualizar perfil]

**Actor principal**: [por ejemplo, Cliente]  
**Actores secundarios**: [por ejemplo, Base de datos, Servicio de correo electrónico]  
**Interesados**: [por ejemplo, Cliente, Equipo de soporte]

### Precondiciones
- [Lista de condiciones]

### Postcondiciones
- [Lista de resultados]

### Escenario principal de éxito (flujo básico)
1. [Paso 1]  
2. [Paso 2]  
...

### Flujos alternativos
- **A1: [Nombre]**  
  1. [Paso]  
  2. [Paso]  
- **A2: [Nombre]**  
  ...

### Extensiones (<<extend>>)
- **<<extend>>: [Nombre]**  
  - Disparador: [Cuándo]  
  - Propósito: [Por qué]

### Requisitos no funcionales
- [Rendimiento, Seguridad, Usabilidad, etc.]

### Notas
- [Contexto adicional o supuestos]

Siguiendo esta guía, los equipos pueden dominar el arte de la elaboración de casos de uso y construir sistemas que no solo sean funcionales, sino verdaderamente alineados con las expectativas de los usuarios.

Apéndice – Descripción del caso de uso para retirar efectivo de un cajero automático:

Nombre del caso de uso

Retirar efectivo

Actor principal

Cliente (titular de cuenta bancaria)

Actores secundarios

  • Máquina de cajero automático

  • Servidor del banco (Sistema de banca central)

  • Pasarela de pagos (para procesamiento de transacciones)

  • Sistema de detección de fraudes

  • Impresora (para generación de comprobantes)

Interesados y sus intereses

  • Cliente: Quiere retirar efectivo de forma segura y eficiente.

  • Banco: Garantiza la integridad de las transacciones, la prevención de fraudes y la actualización precisa de las cuentas.

  • Operador del cajero automático: Mantiene la disponibilidad de la máquina y el inventario de efectivo.

  • Equipo de Seguridad: Monitorea comportamientos sospechosos y previene el fraude.

Precondiciones

  1. El cliente tiene una tarjeta bancaria válida insertada en el ATM.

  2. El cliente se ha autenticado correctamente (ingresó el PIN correcto).

  3. La cuenta del cliente está activa y no está bloqueada.

  4. El ATM tiene efectivo suficiente en el depósito.

  5. La cuenta del cliente tiene un saldo disponible suficiente.

  6. No se ha superado el límite diario de retiro.

Postcondiciones

  1. Se entrega al cliente la cantidad solicitada de efectivo.

  2. El saldo de la cuenta del cliente se reduce por la cantidad retirada.

  3. Se crea un registro de transacción en el sistema del banco.

  4. Se imprime un comprobante (si se solicita).

  5. El ATM registra la transacción para auditoría y reconciliación.

Escenario principal de éxito (flujo básico)

Paso Acción del sistema Respuesta del actor
1 ATM solicita: “Por favor ingrese su PIN.” El cliente ingresa el PIN.
2 El ATM valida el PIN con el servidor del banco. El sistema confirma que el PIN es correcto.
3 El ATM muestra el menú principal: “Retirar efectivo, Consultar saldo, Transferir, Salir.” El cliente selecciona “Retirar efectivo.”
4 El ATM solicita: “Ingrese la cantidad a retirar.” El cliente ingresa la cantidad (por ejemplo, $100).
5 El ATM valida:

  • La cantidad está dentro del límite diario.

  • La cuenta tiene fondos suficientes.

  • El ATM tiene efectivo suficiente. | El sistema confirma la validez. |
    | 6 | El ATM solicita autorización al servidor del banco. | El servidor del banco aprueba la transacción. |
    | 7 | El ATM dispensa efectivo desde el depósito. | El cliente recibe el efectivo. |
    | 8 | El ATM muestra: “¿Desea un comprobante?” | El cliente selecciona “Sí” o “No”. |
    | 9 | Si “Sí”: el ATM imprime el comprobante con:

  • Fecha/hora

  • Monto retirado

  • Saldo restante

  • ID de transacción | El cliente recoge el comprobante. |
    | 10 | El ATM muestra: “Gracias. Por favor retire su tarjeta.” | El cliente retira la tarjeta. |
    | 11 | El ATM regresa al estado de espera. | El sistema se reinicia. |

✅ Resultado exitoso: El cliente recibe efectivo y (opcionalmente) un comprobante. La cuenta se actualiza.

Flujos alternativos (escenarios de excepción)

A1: Se ingresó un PIN inválido (3 intentos)

  • Disparador: El cliente ingresa un PIN incorrecto tres veces.

  • Acción del sistema: El ATM bloquea la tarjeta y muestra: “Tarjeta bloqueada. Comuníquese con su banco.”

  • Acción del actor: El cliente sale y contacta al banco.

  • Postcondición: La tarjeta está bloqueada temporalmente; la transacción se registra.

⚠️ Nota: Esta es una medida de seguridad para evitar el acceso no autorizado.

A2: Fondos insuficientes

  • Disparador: El cliente ingresa una cantidad superior al saldo disponible.

  • Acción del sistema: El ATM muestra: “Fondos insuficientes. Saldo actual: $X.”

  • Acción del actor: El cliente selecciona “Cancelar” o ingresa una cantidad menor.

  • Postcondición: No se entrega efectivo; no hay cambio en la cuenta.

A3: Efectivo insuficiente en el ATM

  • Disparador: El cliente ingresa una cantidad válida, pero el cajero automático está vacío o por debajo del mínimo.

  • Acción del sistema: El ATM muestra: “Efectivo no disponible. Por favor intente más tarde.”

  • Acción del actor: El cliente cancela o regresa más tarde.

  • Postcondición: La transacción no se procesa; no hay cambio en la cuenta.

A4: El monto de retiro excede el límite diario

  • Disparador: El cliente intenta retirar más del límite diario (por ejemplo, $1,000).

  • Acción del sistema: El ATM muestra: “Excede el límite diario de retiro. Intente con una cantidad menor.”

  • Acción del actor: El cliente reduce la cantidad o cancela.

  • Postcondición: La transacción no se procesa.

A5: Transacción rechazada por el servidor del banco

  • Disparador: El servidor del banco rechaza la transacción (por ejemplo, debido a una alerta de fraude, congelación de cuenta).

  • Acción del sistema: El cajero automático muestra: “Transacción rechazada. Por favor, contacte con su banco.”

  • Acción del actor: El cliente cancela y contacta con el banco.

  • Postcondición: No se entrega efectivo; no hay cambio en la cuenta.

Extensiones (relaciones <>)

Extensión Disparador Propósito
<>: Notificar al sistema de detección de fraudes Cuando se realiza un retiro en un país extranjero o supera el comportamiento típico Marcar la actividad sospechosa para su revisión
<>: Enviar alerta por SMS al cliente Después del retiro exitoso Notificar al cliente sobre la transacción (seguridad mejorada)
<>: Aplicar tarifa de retiro Para titulares de cuentas no primarias o ciertos tipos de cuentas Cobrar tarifa por servicios específicos
<>: Imprimir el historial de transacciones Si el cliente selecciona “Imprimir historial” en el menú Proporcionar un resumen impreso de las transacciones recientes

Requisitos no funcionales (NFRs)

Categoría Requisito
Rendimiento La transacción debe procesarse en menos de 3 segundos.
Seguridad Toda la comunicación está cifrada (TLS 1.3). El PIN nunca se almacena ni se transmite en texto plano.
Fiabilidad El cajero automático no debe dispensar efectivo a menos que el servidor del banco confirme la autorización.
Usabilidad La interfaz debe ser accesible (por ejemplo, botones grandes, guía por voz para personas con discapacidad visual).
Disponibilidad El cajero automático debe estar operativo el 99,9 % del tiempo.
Auditoría y cumplimiento Todas las transacciones deben registrarse y ser rastreables durante 7 años (según las regulaciones bancarias).

Notas

  • El cajero automático debe mantenerse regularmente para garantizar la disponibilidad de efectivo y la fiabilidad del hardware.

  • Si la tarjeta no se retira dentro de los 30 segundos después de la transacción, se retendrá automáticamente (función antirobo).

  • El sistema admite múltiples monedas y cálculos de tipo de cambio (si aplica).

Diagrama de casos de uso (Resumen UML)

[Cliente] --(Retirar efectivo)--> [Cajero automático]
[Cajero automático] --(Autenticar PIN)--> [Servidor del banco]
[Cajero automático] --(Verificar fondos)--> [Servidor del banco]
[Cajero automático] --(Dispensar efectivo)--> [Caja fuerte]
[Cajero automático] --(Imprimir comprobante)--> [Impresora]
[Cajero automático] --(Notificar al sistema de fraude)--> [Sistema de detección de fraude]

(Nota: En un diagrama UML completo, se mostrarían relaciones de casos de uso como <> y <>.)

✅ Resumen

Este caso de uso detallado para “Retirar efectivo” proporciona una especificación clara, estructurada y verificable que:

  • Captura los objetivos del usuario y el comportamiento del sistema.

  • Maneja excepciones del mundo real.

  • Apoya la seguridad, el cumplimiento y la usabilidad.

  • Sirve como base para el diseño, la prueba y la implementación.

Es adecuado para su uso en sprints ágiles, documentos de diseño de sistemas o especificaciones formales de requisitos.

📘 Próximos pasos:

  • Convierta esto en un diagrama de secuencia para mostrar las interacciones entre objetos.

  • Crear casos de prueba basado en cada flujo (principal y alternativo).

  • Enlace a diagramas de clases (por ejemplo, Cuenta, Transacción, ATM, Detector de Fraude).

Related Posts

Recent Comments

No hay comentarios que mostrar.
Sidebar Search
Loading

Signing-in 3 seconds...

Signing-up 3 seconds...