19. Interesados, necesidades y garantías del caso de uso
19.1 Introducción
Un caso de uso no solo describe lo que hace un actor principal. También debe considerar a otras personas, áreas o sistemas que tienen interés en el resultado. Estas partes se conocen como interesados o stakeholders.
Los interesados pueden tener necesidades, expectativas, restricciones y preocupaciones diferentes. Si no se identifican, el caso de uso puede parecer correcto para el actor principal, pero incompleto para la organización.
Por eso algunas plantillas de casos de uso incluyen campos como interesados, necesidades, garantía mínima y garantía de éxito. Estos campos ayudan a pensar qué debe proteger el sistema y qué resultado debe asegurar.
19.2 Qué es un interesado
Un interesado es una persona, grupo, área, organización o sistema que se ve afectado por el caso de uso o tiene expectativas sobre su resultado. No siempre interactúa directamente con el sistema.
Por ejemplo, en el caso de uso Solicitar turno, el actor principal puede ser el Paciente, pero también hay otros interesados: la clínica, el médico, la recepción, administración y quizá una obra social.
19.3 Necesidades de los interesados
Las necesidades describen qué espera cada interesado del caso de uso. Estas necesidades pueden referirse a información, control, seguridad, disponibilidad, cumplimiento de reglas, rapidez o trazabilidad.
En un sistema de turnos, el Paciente necesita obtener una reserva clara. El Médico necesita que su agenda no tenga superposiciones. La clínica necesita que los turnos queden registrados correctamente. La recepción necesita poder consultar y corregir datos si corresponde.
19.4 Interesados, necesidades y garantías
Para escribir un caso de uso sólido conviene relacionar cada interesado con su necesidad y con las garantías que el sistema debe ofrecer. La garantía mínima protege condiciones básicas aun cuando el caso no termine con éxito. La garantía de éxito describe qué debe quedar cumplido cuando el caso finaliza correctamente.
19.5 Garantía mínima
La garantía mínima indica qué debe asegurar el sistema incluso si el caso de uso no logra completarse. Se relaciona con protección de datos, consistencia, seguridad y ausencia de efectos indeseados.
Por ejemplo, si un paciente intenta solicitar un turno pero la operación falla, la garantía mínima podría ser:
Esta garantía es importante porque un caso de uso puede fallar, pero no debería dejar el sistema en un estado incoherente.
19.6 Garantía de éxito
La garantía de éxito describe qué debe quedar verdadero cuando el caso de uso termina correctamente. Es el resultado observable que confirma que el objetivo fue cumplido.
Para Solicitar turno, una garantía de éxito podría ser:
La garantía de éxito debe ser verificable. Si no se puede comprobar, probablemente está redactada de manera demasiado vaga.
19.7 Diferencia entre postcondición y garantía
La garantía de éxito se parece a una postcondición, porque ambas describen el estado esperado al finalizar correctamente. La diferencia es que la garantía se redacta pensando en los compromisos hacia interesados, mientras que la postcondición puede expresarse como estado del sistema.
En la práctica, muchas plantillas combinan estos conceptos. Lo importante es que quede claro qué resultado debe asegurar el sistema.
19.8 Ejemplo de interesados en Solicitar turno
La siguiente tabla muestra posibles interesados y necesidades para el caso de uso Solicitar turno:
| Interesado | Necesidad | Garantía relacionada |
|---|---|---|
| Paciente | Reservar una consulta en un horario disponible. | Recibe confirmación del turno reservado. |
| Médico | No tener turnos superpuestos. | El sistema bloquea el horario reservado. |
| Clínica | Mantener la agenda ordenada y confiable. | La reserva queda registrada con datos completos. |
| Recepción | Poder consultar la reserva cuando el paciente llega. | El turno queda disponible para consulta administrativa. |
| Obra social | Validar cobertura cuando corresponde. | El sistema registra el resultado de la validación si aplica. |
19.9 Cómo descubrir interesados
Para descubrir interesados, conviene preguntar:
- ¿Quién usa directamente el resultado del caso de uso?
- ¿Quién se ve afectado si el caso de uso falla?
- ¿Qué área necesita controlar o auditar esta operación?
- ¿Qué sistema externo recibe o entrega información?
- ¿Quién define reglas o restricciones sobre esta funcionalidad?
- ¿Quién necesita reportes, comprobantes o trazabilidad?
19.10 Necesidades funcionales y no funcionales
Las necesidades de interesados pueden ser funcionales o no funcionales. Una necesidad funcional se refiere a algo que el sistema debe hacer. Una necesidad no funcional se refiere a una cualidad o restricción.
Ejemplos:
- Funcional: el sistema debe registrar la reserva del turno.
- Funcional: el sistema debe enviar una confirmación.
- No funcional: la operación debe responder en pocos segundos.
- No funcional: solo usuarios autorizados deben consultar datos sensibles.
19.11 Conflictos entre interesados
A veces los interesados tienen necesidades que entran en tensión. El paciente puede querer cancelar un turno en cualquier momento, mientras que la clínica puede querer impedir cancelaciones tardías para evitar pérdida de disponibilidad.
Estos conflictos deben resolverse mediante reglas de negocio claras. Por ejemplo: "El paciente puede cancelar el turno hasta 24 horas antes de la consulta".
19.12 Garantías y reglas de negocio
Las garantías suelen apoyarse en reglas de negocio. Si una regla indica que no puede haber dos turnos para el mismo profesional en el mismo horario, la garantía de éxito debe asegurar que la reserva respete esa restricción.
Por eso, al escribir garantías, conviene revisar las reglas de negocio relacionadas.
19.13 Garantías y pruebas
Las garantías deben poder verificarse mediante pruebas. Si la garantía de éxito dice que el turno queda reservado y el horario deja de estar disponible, una prueba debe comprobar ambas cosas.
La garantía mínima también debe probarse. Por ejemplo, si ocurre un error durante la confirmación, se debe verificar que no haya quedado una reserva incompleta.
19.14 Redacción clara de garantías
Una buena garantía debe ser concreta, observable y verificable. Conviene evitar frases vagas como "el sistema funciona correctamente" o "los datos quedan bien".
Mejor redacción:
19.15 Errores frecuentes
Al documentar interesados, necesidades y garantías, suelen aparecer estos errores:
- Considerar solo al actor principal y olvidar otros interesados.
- Confundir interesado con actor.
- Redactar necesidades demasiado generales.
- No registrar conflictos entre interesados.
- Escribir garantías vagas o imposibles de verificar.
- Olvidar la garantía mínima ante fallos.
- No relacionar garantías con reglas de negocio y pruebas.
19.16 Lista de revisión
Antes de cerrar esta parte de la especificación, conviene revisar:
- ¿Están identificados los interesados principales?
- ¿Cada interesado tiene una necesidad clara?
- ¿Existen conflictos entre necesidades?
- ¿La garantía mínima protege el estado del sistema ante fallos?
- ¿La garantía de éxito describe un resultado verificable?
- ¿Las garantías respetan las reglas de negocio?
- ¿Las garantías pueden convertirse en pruebas?
19.17 Qué debes recordar de este tema
- Un interesado puede verse afectado por el caso de uso aunque no interactúe directamente.
- Las necesidades explican qué espera cada interesado.
- La garantía mínima protege condiciones básicas incluso si el caso falla.
- La garantía de éxito describe qué debe cumplirse cuando el caso termina correctamente.
- Las garantías deben ser observables y verificables.
- Los conflictos entre interesados deben resolverse con reglas claras.
- Estos campos ayudan a validar el caso de uso más allá del actor principal.
19.18 Conclusión
Los interesados, necesidades y garantías amplían la mirada del caso de uso. Permiten entender no solo qué quiere el actor principal, sino también qué espera la organización y qué condiciones debe proteger el sistema.
Una especificación que incluye garantías claras es más fácil de validar y probar. En el próximo tema estudiaremos precondiciones y disparadores, dos elementos que ayudan a definir cuándo puede comenzar un caso de uso.