Un sistema de software no existe aislado. Siempre está relacionado con personas, áreas, equipos, procesos, reglas y objetivos de una organización. Por eso, antes de diseñar o programar, es necesario comprender quiénes tienen interés en el sistema y cómo serán afectados por él.
En Ingeniería de Software se suele llamar actores interesados o stakeholders a las personas, grupos u organizaciones que influyen en el proyecto, usan el sistema, financian su construcción, lo mantienen, lo regulan o reciben sus consecuencias.
Identificar correctamente a los interesados ayuda a entender requisitos, evitar malentendidos, priorizar funcionalidades, descubrir restricciones y construir una solución que realmente genere valor.
Un actor interesado es cualquier persona, grupo o entidad que tiene relación con el sistema o con el proyecto. Puede participar directamente en el desarrollo, usar el producto final, tomar decisiones, financiarlo, administrarlo o verse afectado por sus resultados.
Algunos interesados son fáciles de reconocer, como los usuarios finales. Otros son menos visibles, pero igual de importantes: soporte técnico, responsables de seguridad, auditores, administradores, proveedores externos, áreas legales o equipos que consumirán una API.
Los usuarios son las personas que interactúan con el sistema para realizar tareas. Pueden usar una pantalla, una aplicación móvil, una terminal, una API, un reporte o una herramienta administrativa.
Es común hablar de "el usuario" como si fuera una sola persona, pero en la práctica puede haber muchos tipos de usuarios con objetivos distintos. En un sistema de turnos médicos, por ejemplo, no usan el sistema de la misma manera un paciente, una recepcionista, un médico y un administrador.
Para comprender a los usuarios conviene preguntar:
El cliente es quien solicita, financia, compra o acepta el sistema. A veces coincide con el usuario final, pero muchas veces no. Una empresa puede contratar un sistema para sus empleados; en ese caso, la empresa es cliente y los empleados son usuarios.
El cliente suele preocuparse por objetivos de negocio, costos, plazos, retorno de inversión, cumplimiento de contratos, alcance y resultados esperados. Sus prioridades pueden ser distintas a las de los usuarios.
Por ejemplo, el cliente puede pedir reducir costos operativos, mientras que los usuarios necesitan que la interfaz sea clara y rápida. Ambas necesidades importan, pero deben analizarse y equilibrarse.
El equipo de desarrollo también es un actor interesado. Sus integrantes construyen, prueban, despliegan y mantienen el sistema. Necesitan comprender el objetivo del producto, contar con requisitos claros, tomar decisiones técnicas y trabajar de forma coordinada.
Dentro del equipo pueden participar distintos roles:
Si el equipo no recibe información suficiente o trabaja con prioridades confusas, la calidad del producto se verá afectada.
La organización es el contexto donde el software se construye, se usa o genera impacto. Puede ser una empresa, una institución educativa, un organismo público, una clínica, una tienda, una fábrica o una comunidad.
La organización aporta objetivos, restricciones, procesos, reglas, cultura, presupuesto, infraestructura y políticas. Un sistema no debería diseñarse ignorando ese contexto.
Algunas preguntas útiles son:
Además de usuarios, clientes, equipo y organización, pueden existir otros interesados importantes:
| Interesado | Interés principal | Ejemplo |
|---|---|---|
| Soporte técnico | Resolver consultas e incidentes. | Necesita paneles, registros y procedimientos claros. |
| Seguridad informática | Proteger accesos, datos y operaciones sensibles. | Define políticas de autenticación y permisos. |
| Área legal | Cumplir normas, contratos y protección de datos. | Revisa términos de uso y requisitos regulatorios. |
| Auditoría | Verificar trazabilidad y control de operaciones. | Solicita registros de acciones importantes. |
| Proveedores externos | Integrarse correctamente con el sistema. | Una pasarela de pagos o servicio de facturación. |
| Administradores del sistema | Configurar, monitorear y operar la solución. | Necesitan herramientas para gestionar usuarios y parámetros. |
Es importante distinguir algunos conceptos que suelen confundirse:
| Concepto | Significado | Ejemplo |
|---|---|---|
| Usuario | Persona que interactúa directamente con el sistema. | Un empleado que carga pedidos en una aplicación. |
| Cliente | Persona u organización que solicita, compra o acepta el sistema. | La empresa que contrata el desarrollo de la aplicación. |
| Beneficiario | Persona o grupo que recibe valor del sistema, aunque no lo use directamente. | Un gerente que recibe mejores reportes gracias a datos cargados por otros. |
Un buen análisis debe considerar estas diferencias porque cada grupo puede tener expectativas distintas.
Los actores interesados no siempre quieren lo mismo. Un usuario puede pedir menos pasos para completar una tarea, mientras que auditoría pide más controles. El cliente puede priorizar fecha de entrega, mientras que el equipo técnico advierte riesgos de mantenimiento. Seguridad puede exigir autenticación fuerte, mientras que los usuarios piden acceso más rápido.
Estas diferencias no deben verse como obstáculos personales, sino como señales de que el sistema debe equilibrar necesidades reales. La Ingeniería de Software ayuda a hacer explícitos estos intereses para discutirlos de forma ordenada.
Los requisitos de software nacen, en gran medida, de las necesidades de los actores interesados. Si se identifica mal a los interesados, es probable que falten requisitos importantes o que se prioricen funciones equivocadas.
Por ejemplo, en un sistema de comercio electrónico:
Todos estos requisitos pertenecen al mismo sistema, aunque provengan de actores distintos.
Como los recursos son limitados, no todo puede hacerse al mismo tiempo. Priorizar significa decidir qué se construye primero, qué se posterga y qué queda fuera del alcance inicial.
Los conflictos entre interesados son normales. Algunos ejemplos:
La solución no consiste en aceptar todo sin análisis. Se deben evaluar valor, riesgo, costo, urgencia, impacto y dependencia entre funcionalidades.
La comunicación es una de las tareas más importantes en Ingeniería de Software. No basta con preguntar una vez qué se necesita. Muchas necesidades aparecen cuando los interesados ven ejemplos, prototipos, versiones parciales o consecuencias de una decisión.
Algunas prácticas útiles son:
La comunicación debe adaptarse al público. No se habla igual con un usuario final, con una gerencia, con un auditor o con un desarrollador.
Una forma sencilla de organizar interesados es registrar quiénes son, qué necesitan, qué influencia tienen y cómo se comunicará el equipo con ellos.
| Actor interesado | Necesidad principal | Influencia | Comunicación recomendada |
|---|---|---|---|
| Usuarios finales | Realizar tareas de forma clara y eficiente. | Alta en usabilidad y validación funcional. | Entrevistas, pruebas con prototipos y demostraciones. |
| Cliente | Lograr objetivos de negocio dentro de restricciones. | Alta en prioridades y aceptación. | Reuniones de avance, alcance y decisiones. |
| Equipo técnico | Construir una solución viable y mantenible. | Alta en diseño e implementación. | Reuniones técnicas, documentación y revisión de código. |
| Soporte | Atender incidentes y consultas. | Media en operación y posentrega. | Guías, capacitación y acceso a registros. |
| Seguridad | Proteger información y accesos. | Alta en restricciones y controles. | Revisión de riesgos, políticas y pruebas específicas. |
Imaginemos un sistema académico para una institución educativa. Si solo hablamos con directivos, podríamos pensar que el sistema debe concentrarse en reportes, estadísticas y control administrativo. Pero otros actores también tienen necesidades importantes.
Si uno de estos grupos no se considera, el sistema puede quedar incompleto aunque técnicamente funcione.
Al trabajar con actores interesados suelen aparecer errores como los siguientes:
Evitar estos errores mejora la calidad del análisis y reduce retrabajo durante el desarrollo.
Comprender a los actores interesados es una base de la Ingeniería de Software. Un sistema no se construye solo para ejecutar instrucciones, sino para resolver necesidades dentro de un contexto humano y organizacional.
Para quien comienza, la idea principal es esta: antes de definir qué debe hacer un sistema, debemos entender quiénes se relacionan con él, qué necesitan, qué esperan y qué restricciones aportan.
En el próximo tema veremos los roles habituales en un equipo de software, profundizando en las responsabilidades de quienes participan directamente en la construcción, validación y evolución del producto.