10. Nivel de detalle: casos de uso de negocio, usuario y sistema
10.1 Introducción
Un caso de uso puede describirse con distintos niveles de detalle. A veces interesa comprender un proceso amplio de la organización; otras veces interesa describir el objetivo de un usuario; y en otras situaciones se necesita precisar la interacción exacta con un sistema de software.
Si mezclamos estos niveles, el modelo se vuelve confuso. Un caso de uso llamado Atender paciente puede referirse a un proceso de negocio completo, mientras que Solicitar turno describe una interacción más concreta con un sistema.
En este tema estudiaremos tres niveles útiles: casos de uso de negocio, casos de uso de usuario y casos de uso de sistema.
10.2 Por qué importa el nivel de detalle
El nivel de detalle define qué se está analizando. Si el equipo no acuerda el nivel, pueden aparecer casos de uso demasiado amplios mezclados con acciones muy pequeñas.
Por ejemplo, en una misma lista no conviene mezclar sin aclaración Gestionar atención médica, Solicitar turno y Ingresar número de documento. El primero es demasiado amplio, el segundo puede ser un caso de uso adecuado y el tercero probablemente sea solo un paso.
10.3 Tres niveles habituales
Los casos de uso pueden analizarse en diferentes niveles. Los tres más útiles para comenzar son: negocio, usuario y sistema. Cada nivel responde una pregunta distinta y sirve para una etapa diferente del análisis.
10.4 Caso de uso de negocio
Un caso de uso de negocio describe un proceso o servicio de la organización, no necesariamente limitado a un sistema informático. Puede incluir personas, tareas manuales, documentos, reglas, decisiones y varios sistemas.
Ejemplos:
- Atender paciente.
- Gestionar reclamo de cliente.
- Procesar pedido de compra.
- Inscribir alumno a un curso.
Este nivel es útil para comprender cómo trabaja la organización y dónde podría intervenir el software.
10.5 Caso de uso de usuario
Un caso de uso de usuario describe un objetivo que un actor quiere lograr con apoyo del sistema. Se enfoca en el valor para el usuario y suele tener un alcance adecuado para conversar con usuarios y responsables del negocio.
Ejemplos:
- Solicitar turno.
- Cancelar reserva.
- Consultar agenda diaria.
- Registrar paciente.
Este nivel suele ser el más útil para construir diagramas y especificaciones funcionales de un sistema.
10.6 Caso de uso de sistema
Un caso de uso de sistema describe una interacción más precisa entre un actor externo y el sistema de software. Se concentra en qué recibe el sistema, qué valida, qué responde y qué resultado observable produce.
Por ejemplo, dentro de Solicitar turno, se pueden detallar interacciones como buscar disponibilidad, confirmar selección y registrar reserva. Hay que tener cuidado: si se baja demasiado el nivel, pueden aparecer pasos que no son casos de uso independientes.
10.7 Comparación aplicada
En un sistema de turnos médicos, los niveles podrían verse así:
| Nivel | Ejemplo | Qué describe |
|---|---|---|
| Negocio | Atender paciente | Proceso amplio de la clínica, con tareas manuales y sistemas. |
| Usuario | Solicitar turno | Objetivo del paciente al usar el sistema. |
| Sistema | Registrar reserva de turno | Interacción concreta donde el sistema guarda la reserva confirmada. |
10.8 Elegir el nivel correcto
El nivel correcto depende del propósito del trabajo. Si se quiere comprender el contexto de la organización, conviene comenzar por casos de uso de negocio. Si se quiere definir funcionalidades de un producto, conviene trabajar con casos de uso de usuario. Si se necesita precisar comportamiento verificable, se puede bajar a un nivel más cercano al sistema.
La clave es no mezclar niveles sin aclaración. Cada modelo debe ser coherente con la pregunta que intenta responder.
10.9 Señales de que el nivel es demasiado alto
Un caso de uso probablemente tiene un nivel demasiado alto cuando:
- Incluye muchos objetivos diferentes.
- No queda claro quién es el actor principal.
- Necesita varios días, áreas o sistemas para completarse.
- Es difícil definir un flujo principal único.
- Su nombre usa verbos demasiado amplios como gestionar o administrar.
En esos casos, conviene dividirlo en casos de uso más específicos.
10.10 Señales de que el nivel es demasiado bajo
Un caso de uso probablemente tiene un nivel demasiado bajo cuando:
- Describe un clic, un campo o una validación aislada.
- No entrega valor propio al actor.
- No puede explicarse como objetivo de usuario.
- Depende demasiado de una pantalla específica.
- Solo tiene sentido como paso dentro de otro caso de uso.
En esos casos, conviene incorporarlo como paso, regla o validación dentro de un caso de uso mayor.
10.11 Refinar de arriba hacia abajo
Una forma práctica de trabajar es comenzar con una visión amplia y luego refinar. Primero se entiende el proceso de negocio, luego se identifican objetivos de usuario y finalmente se detallan interacciones del sistema.
Ejemplo:
Caso de uso de usuario: Solicitar turno
Detalle del sistema: validar disponibilidad, registrar reserva y enviar confirmación.
10.12 Relación con diagramas UML
Un diagrama de casos de uso puede mostrar distintos niveles, pero conviene no mezclarlos sin criterio. Si el diagrama representa un sistema de software, los casos de uso deberían expresar objetivos que ese sistema permite cumplir.
Si se desea mostrar procesos de negocio completos, puede ser mejor usar otro diagrama o dejar explícito que se trata de una vista de negocio. La claridad del límite del sistema es fundamental para elegir el nivel correcto.
10.13 Relación con la especificación textual
La especificación textual también cambia según el nivel. Un caso de uso de negocio puede describir tareas de varias áreas. Un caso de uso de usuario describe la interacción orientada al objetivo. Un caso de uso de sistema puede precisar respuestas, validaciones y datos intercambiados.
Por eso, antes de escribir mucho detalle, conviene preguntarse qué nivel se está documentando.
10.14 Errores frecuentes
Al trabajar con niveles de detalle, suelen aparecer estos errores:
- Mezclar procesos de negocio con pasos de interfaz en el mismo diagrama.
- Crear casos de uso demasiado grandes que no se pueden validar fácilmente.
- Crear casos de uso demasiado pequeños que no entregan valor.
- No aclarar el límite del sistema antes de modelar.
- Confundir tareas internas del software con objetivos de actores.
- Usar el mismo nivel para todos los documentos aunque el propósito sea distinto.
10.15 Qué debes recordar de este tema
- El nivel de detalle define qué tipo de realidad se está describiendo.
- Un caso de uso de negocio describe un proceso amplio de la organización.
- Un caso de uso de usuario describe un objetivo con valor para un actor.
- Un caso de uso de sistema precisa interacciones con el software.
- Mezclar niveles sin aclaración produce modelos confusos.
- Los casos demasiado altos deben dividirse.
- Los casos demasiado bajos suelen convertirse en pasos dentro de otro caso de uso.
10.16 Conclusión
Los casos de uso pueden analizarse en diferentes niveles. Elegir el nivel adecuado permite construir modelos más claros y útiles. Para un curso centrado en casos de uso de software, el nivel de usuario y el nivel de sistema suelen ser los más usados, siempre manteniendo claro el límite del sistema.
En el próximo tema comenzaremos con el diagrama de casos de uso UML y sus elementos básicos.