Las reglas de negocio y las políticas de la organización son una fuente fundamental de requerimientos. Definen condiciones, decisiones, límites y formas de trabajo que el sistema debe respetar.
Muchas funciones de software parecen simples hasta que aparecen sus reglas. Por ejemplo, "registrar una venta" puede depender de stock disponible, estado del cliente, límite de crédito, descuentos autorizados, impuestos, promociones y forma de pago.
Si estas reglas no se identifican y documentan, el sistema puede permitir operaciones incorrectas o bloquear acciones que deberían ser válidas.
Una regla de negocio es una condición, restricción, cálculo, decisión o definición que pertenece al dominio de la organización y que guía cómo debe realizarse una actividad.
Ejemplos:
Una política de la organización es una directriz más general que expresa criterios, normas internas o decisiones institucionales. Las políticas orientan comportamientos y pueden originar varias reglas de negocio.
Ejemplos de políticas:
Una política puede ser amplia. Para implementarla en software, normalmente se transforma en reglas más concretas.
Estos conceptos están relacionados, pero no son equivalentes.
| Concepto | Qué expresa | Ejemplo |
|---|---|---|
| Política | Directriz general de la organización. | Las operaciones sensibles deben estar protegidas contra accesos no autorizados. |
| Regla de negocio | Condición o decisión concreta del negocio. | Solo usuarios con rol supervisor pueden aprobar descuentos superiores al 20%. |
| Requerimiento | Comportamiento o condición que el sistema debe cumplir. | El sistema debe solicitar aprobación de un supervisor cuando el descuento ingresado supere el 20%. |
La política orienta, la regla define una condición y el requerimiento especifica cómo el sistema debe respetarla.
Las reglas de negocio pueden tomar distintas formas.
| Tipo | Descripción | Ejemplo |
|---|---|---|
| Restricción | Impide o limita una operación. | No se puede confirmar una venta sin stock suficiente. |
| Cálculo | Define cómo obtener un valor. | El total de la factura se calcula sumando subtotal, impuestos y recargos. |
| Derivación | Obtiene un estado o dato a partir de otros datos. | Un reclamo es urgente si su prioridad es alta y lleva más de 4 horas sin asignación. |
| Autorización | Define quién puede realizar una acción. | Solo el responsable de caja puede anular un pago registrado. |
| Obligación | Indica una acción que debe realizarse bajo cierta condición. | Todo cambio de estado de un reclamo debe registrar fecha, hora y usuario. |
| Clasificación | Define categorías o estados. | Un cliente se considera moroso si tiene facturas vencidas por más de 30 días. |
Algunas reglas están escritas en manuales, normas, contratos o procedimientos. Otras son implícitas: los usuarios las aplican todos los días, pero no están documentadas formalmente.
Las reglas implícitas son peligrosas para los proyectos porque pueden descubrirse tarde. Por ejemplo, un empleado puede saber por experiencia que ciertos pedidos siempre requieren revisión manual, aunque esa regla no aparezca en ningún documento.
Por eso, durante la elicitación conviene preguntar por excepciones, decisiones habituales y casos que "todos saben" cómo resolver.
Las reglas pueden surgir de muchas fuentes:
Comparar varias fuentes ayuda a detectar contradicciones o reglas incompletas.
Muchas reglas de negocio se incorporan dentro de requerimientos funcionales porque afectan lo que el sistema debe permitir, impedir, calcular o registrar.
Ejemplo:
La regla pertenece al negocio; el requerimiento indica cómo debe comportarse el sistema frente a esa regla.
Algunas políticas y reglas se relacionan con atributos de calidad, especialmente seguridad, auditoría, disponibilidad, cumplimiento normativo y trazabilidad.
Ejemplos:
Por eso, las políticas de la organización pueden influir en varios tipos de requerimientos.
Una regla de negocio debe documentarse de forma clara, separando la regla de su implementación. Una estructura simple puede incluir:
Este nivel de documentación es especialmente útil cuando las reglas son críticas, numerosas o cambian con frecuencia.
| Campo | Ejemplo |
|---|---|
| Identificador | RN-001 |
| Nombre | Límite de descuento sin aprobación |
| Regla | Un vendedor no puede aplicar descuentos superiores al 20% sin aprobación de un supervisor. |
| Condición | Aplica cuando se registra o modifica una venta con descuento. |
| Resultado esperado | Si el descuento supera el 20%, la venta queda pendiente de aprobación. |
| Responsable | Gerencia comercial. |
| Requerimientos relacionados | Registrar venta, aprobar descuento, notificar supervisor. |
Muchas reglas tienen excepciones. Ignorarlas puede generar requerimientos incompletos.
Ejemplo:
Las excepciones deben analizarse con cuidado porque suelen afectar permisos, flujos, auditoría y criterios de aceptación.
Las reglas de negocio pueden cambiar por nuevas estrategias, leyes, políticas internas, condiciones comerciales o decisiones de la organización.
Algunas reglas cambian rara vez, como una definición legal. Otras pueden cambiar con frecuencia, como promociones, límites de descuento, plazos de vencimiento o criterios de clasificación.
Cuando una regla cambia con frecuencia, conviene evaluar si debe ser configurable. Por ejemplo, un porcentaje de descuento máximo podría administrarse desde una configuración autorizada en lugar de quedar fijo en el código.
Una regla configurable es una regla cuyo valor o condición puede cambiarse sin modificar el código fuente. Esto puede ser útil cuando la organización necesita ajustar parámetros con cierta frecuencia.
Ejemplos de reglas configurables:
No todo debe ser configurable. La configurabilidad agrega complejidad y también requiere permisos, validaciones y auditoría.
Las reglas de negocio deben validarse con las personas correctas. No siempre alcanza con preguntarle a un solo usuario, porque una regla puede afectar varias áreas.
Para validar reglas conviene revisar:
Una regla mal validada puede producir errores operativos importantes.
En un sistema de inscripción a cursos, podrían existir reglas como:
Estas reglas afectan validaciones, estados, permisos, mensajes al usuario y pruebas de aceptación.
Las reglas de negocio deben convertirse en casos de prueba. Cada regla importante debería tener escenarios que confirmen cuándo se cumple, cuándo se rechaza una operación y qué excepciones existen.
Ejemplo:
Si una regla no puede probarse, probablemente está redactada con poca claridad.
Al trabajar con reglas de negocio y políticas, suelen aparecer estos errores:
Algunas buenas prácticas son:
Las reglas de negocio y las políticas de la organización son una parte esencial de los requerimientos. Definen cómo debe comportarse el sistema para respetar decisiones, restricciones y formas de trabajo propias del dominio.
Identificarlas, documentarlas y validarlas correctamente reduce errores, evita interpretaciones ambiguas y mejora la relación entre necesidades del negocio, comportamiento del sistema y pruebas.
En el próximo tema estudiaremos restricciones técnicas, legales, operativas y comerciales, que también condicionan la solución pero tienen una naturaleza distinta a las reglas de negocio.