Respuesta.
Las reglas de negocio son normativas formales o informales establecidas por la empresa que definen el orden de trabajo, la toma de decisiones, los cálculos, las comunicaciones y el procesamiento de la información.
El analista de negocio identifica, analiza y documenta estas reglas para asegurar que el futuro sistema o proceso cumpla con los requisitos de la empresa y la ley. Las reglas pueden ser simples (por ejemplo, "se otorga un descuento solo a los clientes habituales") o complejas ("la concesión automática de bonificaciones ocurre solo al cumplirse una serie de condiciones").
Una descripción correcta de las reglas de negocio garantiza:
- La coincidencia de la lógica de negocio del sistema con los procesos reales.
- La coherencia de los requisitos entre diferentes sistemas y departamentos.
- La simplificación de la modernización, la prueba y el soporte del software.
Características clave:
- No todos los requisitos son reglas de negocio. Algunas son restricciones de implementación o integración.
- Las reglas de negocio cambian con frecuencia, por lo que es importante distinguirlas del código y mantenerlas en la documentación.
- El lenguaje de las formulaciones debe ser claro y comprensible tanto para el negocio como para los especialistas técnicos.
Preguntas engañosas.
¿Las reglas de negocio son siempre lo mismo que los requisitos de negocio?
No, los requisitos de negocio definen el objetivo que se debe alcanzar, mientras que las reglas de negocio son las restricciones o formas de alcanzar ese objetivo. Por ejemplo, un requisito podría ser "aumentar las ventas en un 10%", mientras que una regla de negocio podría ser "dar un descuento no mayor al 5% a nuevos clientes".
¿Se puede implementar la lógica de negocio sin analizar y formalizar las reglas de negocio?
No, ya que las reglas no formalizadas conducen a ambigüedades, errores en la automatización de procesos y violaciones de las normativas de la empresa.
¿Dónde deben almacenarse las descripciones de las reglas de negocio: solo en el documento de requisitos o también en el código del sistema?
La descripción de las reglas de negocio debe estar en la documentación del proyecto (por ejemplo, en los requisitos o un registro separado de reglas) y también debe reflejarse en la lógica de negocio del sistema, pero la fuente principal debe ser el documento, no el código.
Errores comunes y anti-patrones
- Formulación de las reglas de negocio con términos demasiado generales o vagos.
- Duplicación de reglas de negocio en diferentes secciones de la documentación.
- Insuficiente nivel de detalle, donde una regla abarca involuntariamente diferentes casos.
- Dejar las reglas de negocio "por defecto" sin una descripción explícita (conocimiento silencioso).
Ejemplo de la vida real
Caso negativo:
- En un proyecto de automatización de solicitudes de crédito, los gerentes duplicaron las reglas de negocio solo verbalmente, sin reflejarlas en la especificación, explicando a diferentes desarrolladores de manera verbal - resultaron 3 variantes diferentes de implementación de un mismo escenario.
Ventajas: Lanzamiento rápido del MVP; minimización del tiempo de coordinación.
Desventajas: Inconsistencias en la lógica en diferentes escenarios, problemas en la automatización, conflicto entre departamentos.
Caso positivo:
- Para la tarea de aprobación de créditos, el analista de negocio creó un registro de reglas de negocio para todos los tipos de solicitudes, coordinándolo con un abogado y TI. La implementación tomó un poco más de tiempo, sin embargo, las reglas eran claras para todos.
Ventajas: Claridad en la lógica de negocio, minimización de errores en la automatización.
Desventajas: Más tiempo dedicado a preparar la documentación inicial.