En ingeniería de software, particularmente dentro de la metodología de desarrollo impulsada por casos de uso, identificaractoreses un paso fundamental y crítico. Los actores sirven como puente entre el sistema en desarrollo y las entidades externas que interactúan con él. Identificar y comprender adecuadamente a los actores permite a los equipos diseñar sistemas centrados en el usuario, funcionalmente completos y alineados con las necesidades del mundo real.

Este artículo completo explora elpropósito de identificar actores, eltipo de actores (humanos y no humanos), susroles y responsabilidades, cómo este proceso apoya diversas áreas del desarrollo de software, y proporcionaconceptos clave, directrices y consejos prácticospara tener éxito.
Identificar actores no es solo una tarea preliminar: es una actividad estratégica que moldea todo el ciclo de vida del desarrollo. Los propósitos principales incluyen:
Los actores ayudan a establecer qué está dentro del sistema (el software) y qué está fuera. Esta claridad evita el aumento de alcance y asegura que el equipo se enfoque en el dominio correcto.
Ejemplo:En un sistema bancario, el cliente es un actor fuera del sistema, mientras que el módulo de procesamiento de transacciones forma parte del sistema.
Los actores representan usuarios reales o sistemas que interactúan con el software. Al identificarlos, los equipos modelan casos de uso reales que reflejan cómo se utilizará el sistema en la práctica.
Cada caso de uso generalmente implica uno o más actores. Conocer a los actores ayuda a descubrir el conjunto completo de requisitos funcionales. Si no sabes quién está usando el sistema, no puedes definir lo que necesitan hacer.
Los actores proporcionan un lenguaje común para los interesados, desarrolladores, testers y analistas de negocios. Facilitan la discusión de características, la validación de requisitos y la alineación de expectativas.
Los probadores pueden usar roles de actores para diseñar escenarios de prueba. Por ejemplo, un actor «Cliente» puede necesitar realizar «Iniciar sesión», «Transferir fondos» y «Ver estado» — cada uno convirtiéndose en un caso de prueba.
Los actores se categorizan ampliamente en dos tipos: Actores humanos y Actores no humanos.
Son individuos que interactúan directamente con el sistema.
Cliente
Administrador
Empleado
Gerente
Agente de soporte
Paciente (en sistemas de salud)
Tienen objetivos e intenciones.
Interactúan mediante interfaces de usuario, formularios o comandos de voz.
Pueden tener roles con diferentes permisos (por ejemplo, administrador frente a usuario regular).
✅ Consejo: Utilice nombres basados en roles (por ejemplo, «Cliente registrado» en lugar de «Usuario») para evitar ambigüedades.
Son sistemas externos, dispositivos o procesos automatizados que interactúan con el software.
Máquina de cajero automático
Pasarela de pago (por ejemplo, Stripe, PayPal)
Servidor de correo electrónico
API del Servicio de Clima
Sensor IoT
Sistema heredado (por ejemplo, base de datos antigua)
No son personas, pero inician o responden a acciones del sistema.
A menudo representan puntos de integración o servicios externos.
Pueden desencadenar casos de uso automáticamente.
✅ Ejemplo:En un sistema de comercio electrónico, la “Pasarela de Pagos” es un actor que procesa pagos y envía confirmación de vuelta al sistema.
⚠️ Error común:Tratar un componente del sistema como parte del sistema en lugar de un actor externo. Siempre pregúntese: ¿Esta entidad inicia un caso de uso?
Comprender el rol del actorrol y responsabilidadesprofundiza la comprensión sobre cómo utilizan el sistema y qué esperan.
Describe a la persona o sistema en contexto.
A menudo vinculado a una función laboral o tipo de sistema.
Ejemplo:“Oficial de préstamos” frente a “Cliente”
Las acciones que realiza el actor en el sistema.
Los objetivos que buscan alcanzar.
Los datos que proporcionan o reciben.
| Responsabilidad | Descripción |
|---|---|
| Explorar productos | Ver listados y detalles de productos |
| Agregar al carrito | Seleccionar artículos y agregarlos a una cesta de compras |
| Pagar | Ingresar información de envío y pago |
| Rastrear pedido | Ver el estado del pedido y actualizaciones de entrega |
✅ Mejor práctica:Documente las responsabilidades del actor en una tabla o leyenda del diagrama de casos de uso para mejorar la claridad.
Una identificación adecuada de los actores afecta múltiples fases del ciclo de vida del desarrollo de software:
Ayuda a identificar todos los grupos de usuarios y sistemas externos.
Evita omitir necesidades críticas de los usuarios.
Fomenta la participación temprana de los interesados.
Cada caso de uso es desencadenado por un actor.
Permite el descubrimiento sistemático de requisitos funcionales.
Ayuda a evitar casos de uso redundantes o superpuestos.
Guía el diseño de la interfaz (diseño de experiencia de usuario).
Influye en la seguridad y el control de acceso (por ejemplo, administrador frente a invitado).
Determina los puntos de integración (por ejemplo, APIs de terceros).
Los probadores utilizan roles de actores para crear escenarios de prueba.
Asegura que se cubran todos los caminos del usuario.
Apoya la creación de scripts de prueba automatizados.
Las definiciones claras de actores ayudan a redactar manuales de usuario y materiales de capacitación.
Explica quién puede hacer qué en el sistema.
En Agile, los actores ayudan a definir historias de usuario (por ejemplo, “Como cliente, quiero restablecer mi contraseña”).
Facilita la priorización del backlog basada en las necesidades del usuario.
Un usuario es una persona que utiliza el sistema.
Un actor es cualquier entidad que interactúa con el sistema.
Un usuario puede desempeñar múltiples roles (por ejemplo, un gerente que también es cliente).
❌ Incorrecto: “Usuario” como único actor.
✅ Correcto: “Cliente,” “Gerente,” “Administrador del sistema”
Los actores están fuera del límite del sistema.
No incluyas componentes internos (por ejemplo, “Base de datos” no es un actor, a menos que sea un sistema externo).
Un solo actor puede estar involucrado en muchos casos de uso.
Ejemplo: Un “cliente” puede “Navegar”, “Agregar al carrito”, “Finalizar compra” y “Calificar producto”.
El caso de uso describe una acción o objetivo.
El actor desencadena o participa en el caso de uso.
✅ Caso de uso: “Procesar pago”
✅ Actor: “Cliente” y “Pasarela de pago”
Siga estas mejores prácticas para garantizar una identificación precisa y significativa de los actores:
Hable con analistas de negocios, usuarios finales y propietarios del sistema.
Pregunte: “¿Quién utiliza este sistema? ¿Quién envía datos a él? ¿Quién recibe la salida?”
Para cada caso de uso potencial, pregunte: “¿Quién inicia esta interacción?”
La respuesta probablemente sea el actor.
No use términos vagos como “Usuario”, “Sistema” o “Persona”.
Sea específico: “Cliente registrado”, “API de terceros”, “Dispositivo móvil”.
Piense más allá de los usuarios directos: sensores, trabajos programados, servicios externos.
Ejemplo: Un sensor meteorológico podría desencadenar un caso de uso de “Enviar alerta”.
Si no es una persona, pregunte: “¿Envía o recibe mensajes al sistema?”
Si sí → es un actor no humano.
Dibuje diagramas de casos de uso y verifique si todos los actores están representados.
Asegúrese de que ningún caso de uso sea “sin actor”.
| Consejo | Explicación |
|---|---|
| Utiliza nombres basados en roles | En lugar de “Usuario”, utiliza “Cliente”, “Administrador”, “Proveedor” — más claro y más accionable. |
| Agrupa a los actores por rol | Crea una “Lista de actores” con descripciones, responsabilidades y permisos. |
| Aprovecha las personas | Crea personas para los actores clave para empatizar con sus objetivos y puntos de dolor. |
| Verifica si faltan actores | Pregunta: “¿Qué sucede si el sistema falla? ¿Quién recibe notificaciones?” → A menudo revela actores ocultos. |
| Utiliza la regla “Fuera del sistema” | Si algo está dentro del sistema, no es un actor. |
| Itera y refina | Revisa a los actores durante cada fase de desarrollo. Las nuevas funciones pueden introducir nuevos actores. |
| Documenta a los actores en una tabla de referencia | Mantén un documento vivo con los detalles de los actores para futuras referencias. |
Cliente – visualiza la cuenta, realiza transferencias
Cajero bancario – procesa solicitudes de préstamos
Máquina ATM – envía solicitudes de retiro
Sistema de detección de fraudes – monitorea las transacciones y marca actividades sospechosas
Pasarela de pago – procesa pagos con tarjeta de crédito
Actor: Cliente y máquina de cajero automático
Interacción: El cliente introduce la tarjeta → el cajero envía la solicitud → el sistema verifica → se liberan los fondos
✅ El cajero automático es un actor porque inicia la interacción.
| Error | Por qué es malo | Cómo solucionarlo |
|---|---|---|
| Tratar los módulos internos como actores | Violación del concepto de límite del sistema | Pregunta: “¿Esto está dentro o fuera del sistema?” |
| Usar términos vagos como “Usuario” | Conduce a ambigüedad y a requisitos faltantes | Usa roles específicos: “Cliente”, “Proveedor” |
| Olvidar los actores no humanos | Pierde integraciones y automatizaciones | Piensa en APIs, sensores, trabajos programados |
| Suponer un actor por caso de uso | Ignora interacciones complejas | Permite múltiples actores por caso de uso |
| No revisar los actores durante el desarrollo | Los actores pueden evolucionar con nuevas funciones | Revisa los actores en la planificación de sprints y en las retrospectivas |
Identificar actores en un enfoque centrado en casos de uso va mucho más allá de una formalidad: es un pilar estratégico del desarrollo de software exitoso. Al definir claramente quién interactúa con el sistema (tanto humanos como no humanos), los equipos obtienen:
Una comprensión más profunda de las necesidades del usuario
Requisitos más completos y precisos
Mejor diseño y arquitectura del sistema
Pruebas y documentación mejoradas
Mayor alineación con los interesados
Cuando se hace bien, la identificación de actores transforma ideas abstractas en insights concretos y accionables. Garantiza que el software no solo funcione, sino que tambiénresuelva problemas reales para personas y sistemas reales.
Libros:
Modelado de casos de uso por Alistair Cockburn
Escribir casos de uso efectivos por Alistair Cockburn
Herramientas:
Visual Paradigm (para diagramas de casos de uso)
Lucidchart / Draw.io (diagramación)
Jira + Confluence (para documentación de actores y casos de uso)
Metodologías:
Ágil (historias de usuario derivadas de actores)
Diseño Orientado al Dominio (DDD) – actores como parte del modelo de dominio
🌟 Pensamiento final:
“No construyes software para sistemas, sino para personas y los sistemas que las sirven. Los actores son el primer paso para comprender quiénes son esas personas y sistemas.”
Al dominar la identificación de actores, estableces la base para un sistema que no solo funcione, sino que sea verdaderamente valioso.