Para definir buenos requerimientos no alcanza con preguntar qué pantallas o funciones se desean. Es necesario comprender el contexto del negocio y el dominio donde el sistema funcionará.
El contexto explica la situación organizacional, los objetivos, las personas, los procesos, las restricciones y los problemas que rodean al sistema. El dominio es el área de conocimiento del problema: ventas, salud, educación, banca, logística, seguros, administración pública u otra actividad.
Cuando el equipo no entiende el dominio, puede usar palabras incorrectas, ignorar reglas importantes, diseñar flujos poco realistas o construir funcionalidades que no encajan con el trabajo real.
El contexto del negocio es el entorno en el que existe la necesidad que se quiere resolver. Incluye objetivos de la organización, procesos actuales, personas involucradas, normas, restricciones, herramientas existentes y condiciones operativas.
Comprender el contexto permite responder preguntas como:
Sin este contexto, los requerimientos pueden quedar desconectados de la realidad.
El dominio es el conjunto de conceptos, reglas, procesos, vocabulario y conocimientos propios del área donde se aplica el sistema. Cada dominio tiene términos y relaciones que deben entenderse correctamente.
Por ejemplo, en una biblioteca aparecen conceptos como libro, ejemplar, socio, préstamo, devolución, reserva, multa y renovación. En una clínica aparecen paciente, turno, profesional, historia clínica, cobertura, autorización y diagnóstico.
Comprender el dominio permite formular requerimientos con palabras adecuadas y evitar interpretaciones equivocadas.
El negocio se refiere a la organización, sus objetivos, procesos y decisiones. El dominio se refiere al área de conocimiento sobre la cual trabaja el sistema.
| Aspecto | Contexto del negocio | Dominio |
|---|---|---|
| Pregunta principal | ¿Cómo trabaja esta organización y qué quiere lograr? | ¿Qué conceptos y reglas existen en esta área de conocimiento? |
| Ejemplo | La empresa quiere reducir demoras en la preparación de pedidos. | Pedido, stock, depósito, remito, entrega, lote y reposición. |
| Enfoque | Objetivos, procesos, áreas, restricciones y prioridades. | Conceptos, términos, reglas y relaciones propias del problema. |
Ambos aspectos están conectados. Para definir requerimientos sólidos, el equipo necesita comprender los dos.
Un proceso de negocio es una secuencia de actividades que la organización realiza para obtener un resultado. Los sistemas de software suelen automatizar, apoyar, controlar o mejorar partes de esos procesos.
Ejemplos de procesos:
Antes de definir requerimientos, conviene entender cómo se realiza el proceso actualmente, qué problemas tiene y qué cambios se esperan con el nuevo sistema.
Las reglas de negocio son condiciones, políticas o decisiones que la organización aplica en sus procesos. Muchas reglas se convierten en requerimientos o restricciones del sistema.
Ejemplos de reglas de negocio:
Si estas reglas no se descubren a tiempo, el sistema puede permitir operaciones incorrectas o bloquear operaciones válidas.
Cada dominio tiene palabras que parecen simples, pero que pueden tener significado específico. Entender el vocabulario evita confusiones en los requerimientos.
Por ejemplo, en una empresa comercial, "cliente", "cuenta", "pedido", "venta", "reserva" y "entrega" pueden tener definiciones precisas. En una institución educativa, "curso", "materia", "comisión", "inscripción" y "regularidad" pueden no significar lo mismo en todas las organizaciones.
El nuevo sistema rara vez aparece en un vacío. Muchas organizaciones ya usan planillas, formularios, sistemas antiguos, correos, documentos compartidos, bases de datos o aplicaciones externas.
Comprender esas herramientas ayuda a identificar:
Ignorar el entorno existente puede producir requerimientos incompletos o soluciones difíciles de adoptar.
El contexto del negocio también incluye restricciones que limitan la solución. Algunas restricciones provienen de la organización, otras de leyes, contratos, tecnología o condiciones operativas.
| Tipo de restricción | Ejemplo |
|---|---|
| Legal | Los datos personales deben tratarse según la normativa vigente de protección de datos. |
| Técnica | El sistema debe integrarse con una base de datos existente. |
| Operativa | El sistema debe funcionar durante el horario de atención sin interrumpir la operación. |
| Organizacional | Solo ciertos roles pueden aprobar operaciones de alto importe. |
| Comercial | La primera versión debe estar disponible antes del inicio de temporada alta. |
Para comprender el contexto y el dominio, conviene relevar información como:
Esta información no siempre se obtiene en una sola reunión. Suele descubrirse progresivamente.
Algunas técnicas útiles para comprender el dominio y el contexto son:
La técnica adecuada depende del tipo de proyecto, la disponibilidad de los interesados y la complejidad del dominio.
Supongamos que se debe construir un sistema de reservas para un hotel. Si el equipo no comprende el dominio, podría pensar que una reserva es simplemente una fecha y una habitación. Pero el dominio puede incluir muchas reglas adicionales.
Al analizar el contexto aparecen conceptos y reglas como:
Sin esta comprensión, los requerimientos quedarían demasiado simples y el sistema no serviría para la operación real del hotel.
Cuando el equipo no comprende el contexto del negocio, pueden aparecer problemas como:
Estos riesgos afectan alcance, costos, tiempos, calidad y aceptación del producto.
El contexto y el dominio influyen en todos los tipos de requerimientos.
| Elemento del contexto | Cómo puede convertirse en requerimiento |
|---|---|
| Proceso de negocio | Define funciones, pasos, estados y responsabilidades que el sistema debe soportar. |
| Regla de negocio | Se convierte en validación, cálculo, restricción o flujo obligatorio. |
| Normativa | Genera requerimientos de seguridad, auditoría, conservación de datos o privacidad. |
| Sistema existente | Genera requerimientos de integración, migración o compatibilidad. |
| Indicador de negocio | Puede originar reportes, mediciones o metas de rendimiento. |
Por eso, estudiar el contexto no es una actividad separada de los requerimientos: es una fuente directa de ellos.
Para comprender mejor el contexto y el dominio, el analista puede formular preguntas como:
Al estudiar el contexto y el dominio, suelen aparecer estos errores:
Evitar estos errores mejora la precisión de los requerimientos y reduce retrabajo.
Algunas buenas prácticas para comprender el contexto son:
Los requerimientos de software solo tienen sentido dentro de un contexto. Para definirlos correctamente, el equipo debe comprender cómo trabaja la organización, qué conceptos usa, qué reglas aplica, qué restricciones existen y qué objetivos busca alcanzar.
Cuando el contexto del negocio y el dominio se comprenden bien, los requerimientos dejan de ser una lista aislada de funciones y se convierten en una descripción más precisa de lo que el sistema debe aportar.
En el próximo tema estudiaremos el alcance del sistema y los límites de la solución, una actividad necesaria para definir qué se construirá, qué queda fuera y cómo evitar expectativas desordenadas.