25. Reglas de negocio dentro de los casos de uso

25.1 Introducción

Las reglas de negocio son políticas, condiciones o restricciones propias del dominio que el sistema debe respetar. No son decisiones técnicas, sino normas que provienen del negocio, la organización, la ley, el proceso o los acuerdos con los usuarios.

En los casos de uso, las reglas de negocio ayudan a explicar por qué el sistema permite, bloquea, calcula, valida o deriva ciertas acciones. Si no se documentan, los flujos pueden parecer arbitrarios o incompletos.

Por ejemplo, en un sistema de turnos médicos, una regla puede indicar que un paciente solo puede cancelar un turno hasta 24 horas antes de la consulta. Esa regla afecta el flujo de Cancelar turno y también las pruebas.

25.2 Qué es una regla de negocio

Una regla de negocio es una afirmación que define o restringe el comportamiento permitido dentro del dominio. Expresa una condición que debe cumplirse independientemente de cómo se implemente el sistema.

Ejemplos:

• Un médico no puede tener dos turnos asignados en el mismo horario.
• Un paciente puede cancelar un turno hasta 24 horas antes.
• Una compra mayor a cierto monto requiere autorización adicional.
• Un usuario bloqueado no puede iniciar nuevas operaciones.
• Un cupo de inscripción no puede superar la capacidad del curso.

25.3 Regla de negocio no es requisito técnico

Una regla de negocio no debe confundirse con una decisión técnica. "La contraseña se guarda con hash seguro" es una decisión o requisito de seguridad técnico. "Un usuario bloqueado no puede iniciar sesión" es una regla de negocio o política de acceso.

Ambas pueden ser importantes, pero cumplen funciones diferentes en la especificación.

25.4 Reglas dentro del comportamiento del caso de uso

Una regla de negocio puede condicionar un paso del flujo principal, activar un flujo alternativo o generar una excepción. Por eso conviene identificarla y referenciarla claramente dentro de la especificación del caso de uso.

25.5 Dónde ubicar las reglas de negocio

Las reglas de negocio pueden documentarse de varias maneras:

• Dentro de la especificación del caso de uso, en una sección propia.
• En un catálogo separado de reglas de negocio.
• Como referencias desde los pasos del flujo.
• Como criterios de aceptación cuando el equipo usa historias de usuario.

En proyectos pequeños, puede alcanzar con incluirlas en el caso de uso. En proyectos grandes, suele convenir mantener un catálogo para evitar duplicación.

25.6 Identificador de reglas

Cuando hay muchas reglas, conviene identificarlas con códigos. Por ejemplo:

Luego, el caso de uso puede referenciar estas reglas sin repetirlas por completo en varios lugares.

25.7 Reglas que validan datos

Algunas reglas definen qué datos son válidos. Por ejemplo:

• La fecha del turno no puede ser anterior a la fecha actual.
• El documento del paciente debe tener un formato válido.
• El correo electrónico debe ser obligatorio para recibir confirmaciones digitales.
• El horario elegido debe pertenecer a la agenda del profesional.

Estas reglas suelen aparecer en pasos donde el sistema valida información ingresada o seleccionada.

25.8 Reglas que controlan permisos

Otras reglas definen quién puede hacer qué. Por ejemplo:

• Solo un administrador puede configurar horarios de atención.
• Un paciente solo puede consultar sus propios turnos.
• La recepción puede modificar turnos dentro del horario de atención.
• Un médico solo puede consultar su propia agenda, salvo autorización especial.

Estas reglas se relacionan con seguridad, privacidad y control de acceso.

25.9 Reglas que definen cálculos

Algunas reglas establecen cálculos o decisiones automáticas. Por ejemplo:

• El importe de una penalización por cancelación tardía se calcula según el tipo de consulta.
• La prioridad de atención se determina según urgencia y antigüedad de la solicitud.
• El descuento se aplica solo si el cliente cumple ciertas condiciones.

Cuando una regla define un cálculo importante, debe ser precisa para evitar interpretaciones diferentes.

25.10 Reglas y flujos alternativos

Una regla puede activar un flujo alternativo. Por ejemplo, si un paciente intenta cancelar un turno con menos de 24 horas de anticipación, el sistema puede mostrar una política especial o requerir intervención de recepción.

En ese caso, el flujo alternativo debe indicar qué regla lo activa y qué resultado se espera.

25.11 Reglas y excepciones

Una regla también puede generar una excepción cuando impide continuar el caso de uso. Por ejemplo, si el médico ya tiene un turno en el mismo horario, el sistema debe rechazar la reserva.

La excepción debe explicar qué informa el sistema, si existe recuperación y qué estado final queda garantizado.

25.12 Ejemplo aplicado: Solicitar turno

Para el caso de uso Solicitar turno, algunas reglas podrían ser:

25.13 Redacción clara de reglas

Una regla de negocio debe redactarse de forma precisa. Conviene evitar frases vagas como "se debe validar correctamente" o "se aplican las políticas habituales".

Mejor redacción:

Esta regla permite diseñar comportamiento y pruebas de manera más clara.

25.14 Reglas y trazabilidad

Las reglas de negocio deben poder rastrearse. Si una regla cambia, el equipo necesita saber qué casos de uso, pantallas, servicios y pruebas se ven afectados.

Por eso conviene asignar identificadores y referenciar las reglas desde los casos de uso donde se aplican.

25.15 Reglas y pruebas

Cada regla importante debe tener pruebas asociadas. Si la regla dice que un médico no puede tener dos turnos en el mismo horario, debe existir una prueba que intente generar esa situación y verifique que el sistema la rechaza.

Las reglas suelen ser una fuente directa de casos de prueba, especialmente en sistemas con muchas restricciones de negocio.

25.16 Errores frecuentes

Al documentar reglas de negocio, suelen aparecer estos errores:

• Confundir reglas de negocio con detalles técnicos.
• Escribir reglas vagas o ambiguas.
• Duplicar la misma regla en muchos casos de uso con textos diferentes.
• No indicar qué flujo o excepción se ve afectado.
• No asignar identificadores cuando hay muchas reglas.
• No validar las reglas con responsables del negocio.
• No crear pruebas para reglas importantes.

25.17 Lista de revisión

Antes de cerrar las reglas de negocio, conviene revisar:

• ¿La regla proviene del negocio y no de una decisión técnica interna?
• ¿Está redactada de forma precisa?
• ¿Se sabe en qué casos de uso aplica?
• ¿Afecta flujo principal, alternativas o excepciones?
• ¿Tiene identificador si debe rastrearse?
• ¿Fue validada con usuarios o responsables del negocio?
• ¿Puede probarse?

25.18 Qué debes recordar de este tema

• Las reglas de negocio son restricciones o políticas del dominio.
• No deben confundirse con detalles técnicos de implementación.
• Pueden afectar flujo principal, flujos alternativos y excepciones.
• Conviene redactarlas de forma clara y verificable.
• En proyectos grandes, es útil identificarlas con códigos.
• Las reglas deben validarse con responsables del negocio.
• Cada regla importante debe tener pruebas asociadas.

25.19 Conclusión

Las reglas de negocio explican restricciones esenciales del dominio y dan sentido a muchas decisiones del sistema. Sin ellas, los casos de uso pueden describir pasos, pero no las razones por las que el sistema permite o impide ciertas acciones.

Documentar reglas con claridad mejora la especificación, facilita pruebas y reduce ambigüedades. En el próximo tema estudiaremos datos de entrada, datos de salida y mensajes del sistema.