Un diagrama de casos de uso es una herramienta fundamental de modelado en ingeniería de requisitos utilizada para visualizar las interacciones entre actores (usuarios o sistemas externos) y el sistema (o sus funcionalidades). Ayuda a los interesados a comprender qué debe hacer el sistema desde una perspectiva funcional y sirve como puente de comunicación entre los equipos técnicos y los usuarios del negocio.
A pesar de su simplicidad, el diagrama de casos de uso es a menudo mal aplicado debido a una identificación deficiente de actores, casos de uso ambiguos o relaciones incorrectas. Esta guía busca aclarar los conceptos clave, proporcionar un metodología paso a paso, y destacar trampas comunes para evitar.
| Concepto | Explicación |
|---|---|
| Actor | Un usuario humano, organización o sistema externo que interactúa con el sistema. Actúa como un “usuario” en el contexto del sistema. Ejemplos: estudiante, profesor, administrador, pasarela de pagos. |
| Casos de uso | Una descripción de un objetivo o función específica que el sistema realiza para un actor. Define qué lo que hace el sistema, no cómo. Ejemplos: “Registrarse en un curso”, “Enviar calificaciones”, “Generar informe”. |
| Límite del sistema | El límite que separa el sistema de los actores y sistemas externos. Todo lo que está dentro del límite forma parte del sistema. |
| Asociación | Una línea que conecta un actor con un caso de uso, indicando que el actor puede realizar ese caso de uso. |
| Generalización | Una relación en la que un actor hereda comportamiento de otro (por ejemplo, “Estudiante” es un tipo de “Usuario”). |
| Dependencia | Una relación que indica que un caso de uso depende de otro (e |
| .g., “Generar informe” depende de “Obtener datos del estudiante”). | |
| Incluir | Un caso de uso que es requerido para que otro se ejecute (por ejemplo, “Enviar calificaciones” incluye “Validar el ID del estudiante”). |
| Extender | Un caso de uso que condicionalmente añade funcionalidad (por ejemplo, “Enviar notificación” extiende “Enviar calificaciones” cuando las calificaciones están por debajo del umbral). |
⚠️ Nota importante: Los casos de uso no tratan sobre características — sino sobre objetivos funcionales que satisfacen las necesidades del usuario.
Pregúntate estas preguntas fundamentales para identificar todos los actores relevantes:
| Pregunta | Por qué es importante |
|---|---|
| ¿Quién utiliza los casos de uso principales? | Identifica a los usuarios principales (por ejemplo, estudiantes, profesores). |
| ¿Quién necesita soporte para su trabajo diario? | Identifica los roles de soporte (por ejemplo, personal de RRHH, soporte técnico). |
| ¿Quién es responsable de la administración del sistema? | Identifica los roles de administración (por ejemplo, administrador del sistema, administrador de bases de datos). |
| ¿Qué dispositivos externos o sistemas de software interactúa el sistema? | Identifica los sistemas externos (por ejemplo, correo electrónico, pasarela de pagos, ERP). |
| ¿Quién tiene interés en los resultados del sistema? | Identifica a los interesados (por ejemplo, padres, miembros del consejo). |
📌 Consejo: Comience con el usuarios más críticos y expanda hacia afuera. Utilice escenarios del mundo real o entrevistas para validar la identificación de los actores.
💡 Ejemplo: En un sistema de gestión de estudiantes universitarios, los actores podrían incluir:
Estudiante
Miembro del personal académico
Asesor académico
Oficial administrativo
Pasarela de pagos
Sistema ERP
Una vez identificados los actores, haga las siguientes preguntas sobre cada uno:
| Pregunta | Propósito |
|---|---|
| ¿Cuáles son las tareas principales que debe realizar un actor? | Identifica los objetivos funcionales (por ejemplo, registrarse, inscribirse, ver calificaciones). |
| ¿El actor desea consultar o modificar datos en el sistema? | Indica operaciones de lectura/escritura (por ejemplo, ver registros, editar perfil). |
| ¿El actor desea informar al sistema sobre cambios en otros sistemas? | Sugiere desencadenantes basados en eventos (por ejemplo, notificar al sistema cuando se agrega un curso). |
| ¿Debería informarse al actor sobre eventos imprevistos? | Indica casos de uso de notificaciones (por ejemplo, “Alerta: Detección de sobrecarga de curso”). |
📌 Usa lenguaje simple y orientado a objetivos. Evita términos técnicos.
✅ Caso de uso adecuado: “Inscribirse en un curso”
❌ Caso de uso inadecuado: “Enviar formulario de inscripción con validación” → se vuelve demasiado técnico.
Los casos de uso pueden modelarse a diferentes niveles:
| Nivel | Descripción |
|---|---|
| Casos de uso de nivel superior | Objetivos funcionales amplios que reflejan metas empresariales (por ejemplo, “Gestionar registros de estudiantes”). |
| Casos de uso refinados | Acciones detalladas derivadas de los objetivos de nivel superior. |
🔁 Enfoque de desarrollo iterativo:
Comienza con objetivos empresariales de alto nivel.
Divídelos en submetas.
Refina cada caso de uso hasta que sea específico y accionable.
📌 Desglose de ejemplo:
Nivel superior: “Apoyar la administración de estudiantes”
Refinamiento:
El estudiante puede registrarse
El estudiante puede inscribirse en cursos
El sistema almacena calificaciones
El sistema envía la confirmación de inscripción
Esto garantiza que el sistema cumpla conobjetivos comercialesmientras se mantienepráctico y verificable.
Ahora, coloque actores y casos de uso en el diagrama y conéctelos adecuadamente.
[Actor] --> [Casos de uso]
↑
[Incluir] [Extender]
↓
[Dependencia]
Coloque los actores fuera del límite del sistema (típicamente a la izquierda/derecha/arriba).
Coloque los casos de uso dentro del límite del sistema (centro o abajo).
Uselíneas sólidaspara asociaciones.
Uselíneas punteadaspara dependencias.
Useflechas de inclusión (→)paraincluirrelaciones.
Useflechas de extensión (→)paraextender relaciones.
Evite casos de uso superpuestos; mantenga el diagrama limpio y legible.
📌 Ejemplo visual (basado en texto):
+------------------+
| Estudiante | --> Inscribirse en curso
+------------------+
|
v
+------------------+
| Sistema | --> Almacenar inscripciones en cursos
| (Límite) |
+------------------+
^
|
+------------------+
| Pasarela de pago| --> Procesar pago de cuota
+------------------+
🚨 Error común: Dibujar actores dentro del límite del sistema — esto implica que forman parte del sistema, lo cual no es cierto.

Este diagrama fue generado por el chatbot de Visual Paradigm AI:

| Error común | Por qué está mal | Cómo corregirlo |
|---|---|---|
| 🚫 Sobrecargar los actores | Crear demasiados actores (por ejemplo, “Juan Pérez”, “María Gómez”) en lugar de agrupar roles | Agrupe roles similares (por ejemplo, “Estudiante”, “Personal académico”) |
| 🚫 Usar casos de uso ambiguos | Frases como “gestionar datos”, “hacer algo” | Reemplace por frases específicas y orientadas a objetivos (por ejemplo, “Enviar inscripción al curso”) |
| 🚫 Falta de dependencias | No mostrar cómo un caso de uso depende de otro | Agregue incluir o extender relaciones cuando sea necesario |
| 🚫 Uso incorrecto de ‘extender’ | Usando extenderpara flujos de trabajo normales |
Usar incluirpara pasos obligatorios; usar extendersolo para los opcionales y condicionales |
| 🚫 Ignorar los sistemas externos | Sin incluir pasarelas de pago, correo electrónico, etc. | Identificar todos los sistemas externos y mostrar sus interacciones |
| 🚫 Usar solo un actor | Suponiendo que solo un usuario utiliza el sistema | Identificar a todos los interesados y sus necesidades |
| 🚫 Usar jerga técnica | por ejemplo, “actualizar base de datos”, “llamar a la API” | Manténgase en comportamientos funcionales — “Enviar una solicitud” es mejor |
| Práctica | Explicación |
|---|---|
| ✅ Comience con los objetivos del negocio | Modelar desde arriba hacia abajo — alinee con los objetivos estratégicos. |
| ✅ Involucre a los interesados desde el principio | Entreviste a usuarios finales o expertos del dominio para validar los casos de uso. |
| ✅ Mantenga los casos de uso independientes | Cada caso de uso debe representar un objetivo único y claro. |
| ✅ Use escenarios del mundo real | Base los casos de uso en actividades reales de los usuarios (por ejemplo, un estudiante inscribiéndose en una clase). |
| ✅ Validar con el equipo | Revisar el diagrama con desarrolladores, testers y analistas de negocio. |
| ✅ Actualizar de forma iterativa | A medida que evolucionan los requisitos, perfeccionar el diagrama en ciclos más pequeños. |
| ✅ Documentar los casos de uso en detalle | Incluir condiciones previas, condiciones posteriores y criterios de éxito/fallo en un documento separado. |
[30] Ingeniería de requisitos – Texto fundamental sobre modelado de casos de uso.
[27] Identificación de casos de uso en los requisitos de software – Métodos prácticos para derivar casos de uso a partir de actores.
[16, 40] – Literatura completa sobre ingeniería de requisitos y diseño de sistemas.
Estándares IEEE/ISO: ISO/IEC 29148 – Guías para la especificación de casos de uso.
Libros recomendados:
Requisitos de software: Hacerlo bien desde el principio por Ian Sproul
El proceso de desarrollo de software unificado (RUP) – Introduce el modelado de casos de uso en UML
Miembro
Bibliotecario
Administrador
Sistema de catálogo en línea
Pasarela de pago
Miembro:
Pedir un libro
Devolver un libro
Buscar libros
Ver el estado de membresía
Bibliotecario:
Sacar libros
Devolver libros
Actualizar registros de libros
Generar lista de libros vencidos
Administrador:
Agregar nuevos libros
Gestionar cuentas de usuarios
Generar informe anual
Sistema de catálogo en línea:
Buscar libros
Notificar al miembro sobre nuevos llegados
Pasarela de pago:
Procesar multas
Procesar cuotas de renovación
Miembro → Pedir → Incluir → Devolver
Bibliotecario → Sacar → Extender → Enviar recordatorio (si está vencido)
Administrador → Agregar libro → Incluir → Actualizar catálogo
Este diagrama muestra claramente quién hace qué, qué pueden hacer y cómo interactúan los sistemas.
✅ ¿Identifiqué a todos los actores relevantes?
✅ ¿Los casos de uso son descriptivos y orientados a objetivos?
✅ ¿Todos los actores están conectados a al menos un caso de uso?
✅ ¿Las dependencias (incluir/extendido) están correctamente modeladas?
✅ ¿Faltan actores o casos de uso?
✅ ¿Es el diagrama fácil de leer y entender?
✅ ¿Lo he revisado con los interesados?
Crear un diagrama de casos de uso es más que dibujar líneas y cuadros — es un proceso estratégico que requiere profundo entendimiento de las necesidades del usuario, claridad en el lenguaje, y atención al detalle.
Aunque el diagrama parece sencillo, mal uso de actores y casos de uso conduce a un mal diseño del sistema, requisitos omitidos y usuarios frustrados. Al seguir los pasos de esta guía — identificar actores mediante preguntas del mundo real, derivar casos de uso de las necesidades del actor y evitar los errores comunes — puedes crear diagramas de casos de uso precisos, accionables y alineados con los interesados.
✅ Recuerda: Un buen diagrama de casos de uso cuenta una historia — la historia de cómo los usuarios interactúan con el sistema para alcanzar sus objetivos.