Los requerimientos de software no aparecen aislados. Surgen de personas y organizaciones que tienen necesidades, responsabilidades, expectativas, restricciones e intereses distintos. A estas personas u organizaciones se las llama interesados del sistema.
Identificar correctamente a los interesados es una actividad fundamental. Si se consulta solo a una parte de ellos, el sistema puede quedar incompleto, resolver el problema de un grupo pero crear dificultades para otro, o ignorar restricciones importantes.
En este tema estudiaremos quiénes son los interesados, por qué importan y cómo influyen en la definición de requerimientos.
Un interesado, también llamado stakeholder, es toda persona, grupo, área u organización que afecta al sistema, es afectada por el sistema o tiene capacidad de influir en sus decisiones.
Por ejemplo, en un sistema de facturación, los interesados pueden incluir vendedores, administrativos, clientes, gerentes, contadores, soporte técnico, responsables de seguridad, organismos fiscales y desarrolladores.
Los interesados son importantes porque aportan información distinta. Cada uno observa el sistema desde su propio rol y conoce problemas que otros tal vez no ven.
Consultar a los interesados adecuados permite:
Un proyecto con interesados mal identificados suele tener requerimientos incompletos.
Los usuarios son las personas que interactúan directa o indirectamente con el sistema para realizar tareas. Pueden ser usuarios finales, administradores, operadores, supervisores o usuarios externos.
Los usuarios conocen detalles concretos del trabajo real: pasos habituales, excepciones, problemas frecuentes, información necesaria, tiempos, errores y dificultades de uso.
Es importante no tratar a todos los usuarios como si fueran iguales. Un sistema puede tener perfiles muy distintos. Por ejemplo, en un sistema de cursos, no tienen las mismas necesidades un alumno, un docente, un administrador académico y un responsable de pagos.
El cliente es quien solicita el producto o servicio de software. Puede ser una persona, una empresa, un área interna de una organización o una entidad externa.
El cliente suele definir necesidades generales, restricciones de presupuesto, plazos, objetivos de negocio y criterios de aceptación. Sin embargo, el cliente no siempre conoce todos los detalles operativos del trabajo diario.
Por eso, escuchar al cliente es necesario, pero no suficiente. También deben participar usuarios y otros interesados que conozcan procesos, reglas, datos y restricciones específicas.
El patrocinador es la persona o área que impulsa el proyecto, lo financia o tiene autoridad para aprobar decisiones importantes. En algunos casos coincide con el cliente; en otros, es un rol diferente.
El patrocinador suele estar interesado en resultados de negocio: reducción de costos, aumento de ventas, cumplimiento normativo, mejora de tiempos, mayor control o ventaja competitiva.
Este rol es clave para resolver prioridades y conflictos. Cuando dos áreas solicitan funciones incompatibles o cuando el alcance crece demasiado, el patrocinador puede ayudar a decidir qué es más importante para el proyecto.
El equipo técnico incluye desarrolladores, arquitectos, administradores de base de datos, especialistas en infraestructura, seguridad, operaciones, soporte y otros perfiles relacionados con la construcción y mantenimiento del sistema.
Su participación es importante porque permite evaluar factibilidad, riesgos, dependencias, restricciones tecnológicas, integración con otros sistemas, rendimiento, seguridad y mantenibilidad.
Un requerimiento puede ser deseable desde el negocio, pero tener alto costo técnico o depender de servicios externos. El equipo técnico ayuda a detectar estos aspectos antes de comprometer plazos o soluciones.
El analista de requerimientos facilita la comunicación entre interesados. Su trabajo consiste en obtener información, hacer preguntas, detectar ambigüedades, organizar necesidades, documentar requerimientos y validar acuerdos.
Este rol no debe limitarse a transcribir lo que otros dicen. Debe comprender el contexto, distinguir problemas de soluciones propuestas, identificar contradicciones y ayudar a transformar información dispersa en requerimientos claros.
En equipos pequeños, esta responsabilidad puede estar distribuida entre varias personas. Lo importante es que alguien se ocupe explícitamente de cuidar la calidad de los requerimientos.
Además de usuarios, cliente, patrocinador y equipo técnico, pueden existir otros interesados relevantes según el sistema:
Ignorar a estos interesados puede generar omisiones importantes, especialmente en sistemas empresariales o regulados.
Una forma útil de ordenar interesados es clasificarlos según su relación con el sistema.
| Tipo | Descripción | Ejemplo |
|---|---|---|
| Directos | Usan el sistema o participan en sus operaciones principales. | Vendedor que registra pedidos. |
| Indirectos | No lo usan de forma habitual, pero reciben resultados o son afectados por sus decisiones. | Gerente que consulta reportes generados por el sistema. |
| Decisores | Tienen autoridad para aprobar alcance, presupuesto o prioridades. | Director del área que financia el proyecto. |
| Técnicos | Construyen, integran, operan o mantienen el sistema. | Desarrollador, administrador de base de datos o responsable de infraestructura. |
| Reguladores o de control | Establecen normas, restricciones o controles obligatorios. | Área legal, auditoría o entidad gubernamental. |
Cada interesado puede tener intereses y preocupaciones diferentes. Comprenderlas ayuda a formular requerimientos más completos.
| Interesado | Puede preocuparse por... |
|---|---|
| Usuario operativo | Rapidez, facilidad de uso, reducción de pasos, claridad de mensajes y manejo de excepciones. |
| Cliente | Que el sistema resuelva el problema solicitado y se entregue dentro del presupuesto acordado. |
| Patrocinador | Retorno de la inversión, cumplimiento de objetivos y alineación con prioridades del negocio. |
| Equipo técnico | Factibilidad, arquitectura, integraciones, seguridad, mantenimiento y deuda técnica. |
| Auditoría | Registros, permisos, trazabilidad, evidencias y controles. |
Estas preocupaciones pueden convertirse en requerimientos funcionales, no funcionales o restricciones.
Es normal que los interesados tengan necesidades diferentes o incluso contradictorias. Por ejemplo, un área puede pedir máxima seguridad mediante controles estrictos, mientras otra necesita rapidez en la operación diaria.
Algunos conflictos frecuentes son:
La ingeniería de requerimientos debe hacer visibles estos conflictos para analizarlos, negociarlos y registrar decisiones.
Para identificar interesados, conviene comenzar con preguntas simples:
La lista inicial de interesados puede cambiar durante el proyecto. Es común descubrir nuevos participantes a medida que se comprende mejor el contexto.
Un mapa de interesados ayuda a organizar quién participa, qué necesita y cómo se relaciona con los requerimientos.
| Interesado | Información que aporta | Participación esperada |
|---|---|---|
| Usuarios finales | Tareas reales, problemas diarios, excepciones y necesidades de uso. | Entrevistas, observación, validación de flujos y pruebas de aceptación. |
| Cliente | Objetivos generales, alcance esperado y restricciones del proyecto. | Definición inicial, revisión de prioridades y aprobación. |
| Patrocinador | Prioridades estratégicas, presupuesto y criterios de éxito. | Resolución de conflictos y toma de decisiones importantes. |
| Equipo técnico | Factibilidad, dependencias, riesgos técnicos e impacto de cambios. | Revisión técnica y estimación. |
| Seguridad o auditoría | Controles, permisos, registros y restricciones obligatorias. | Revisión de requerimientos críticos y validación de cumplimiento. |
Supongamos que se construirá un sistema para gestionar pedidos en una empresa distribuidora. Si solo se habla con el gerente comercial, podrían definirse requerimientos orientados a ventas, pero quedarían fuera necesidades importantes.
Al identificar más interesados, aparecen distintas perspectivas:
Este ejemplo muestra que un sistema aparentemente simple puede involucrar muchas necesidades conectadas.
Al trabajar con interesados, suelen aparecer estos errores:
Estos errores pueden producir requerimientos incompletos, expectativas distintas y cambios costosos.
Algunas buenas prácticas para trabajar con interesados son:
Los requerimientos dependen de las personas y organizaciones que necesitan, usan, financian, controlan, construyen o mantienen el sistema. Por eso, identificar interesados es una tarea esencial dentro de la ingeniería de requerimientos.
Un buen análisis de interesados permite reunir información más completa, comprender prioridades, detectar restricciones y validar mejor las decisiones. También ayuda a evitar que el sistema refleje solo una parte de la realidad.
En el próximo tema estudiaremos el contexto del negocio y la comprensión del dominio, porque para definir buenos requerimientos no basta con conocer personas: también hay que entender el entorno donde el sistema funcionará.