Las restricciones son condiciones que limitan la solución de software. No siempre describen una función que el sistema debe ofrecer, pero sí establecen límites que el proyecto debe respetar.
Una restricción puede indicar qué tecnología debe usarse, qué norma legal debe cumplirse, en qué horario debe operar el sistema, qué presupuesto existe o con qué sistema externo debe integrarse.
Identificar restricciones temprano es fundamental. Si aparecen tarde, pueden obligar a cambiar diseño, arquitectura, alcance, pruebas, costos o fechas de entrega.
Una restricción es una condición externa o interna que reduce las alternativas posibles para construir, desplegar, operar o mantener el sistema.
Ejemplos:
Restricciones, reglas de negocio y requerimientos están relacionados, pero conviene distinguirlos.
| Concepto | Qué expresa | Ejemplo |
|---|---|---|
| Regla de negocio | Condición propia del dominio o forma de operar de la organización. | Un cliente con deuda vencida no puede comprar a crédito. |
| Restricción | Límite que condiciona cómo debe construirse, operar o entregarse la solución. | El sistema debe integrarse con la base de clientes existente. |
| Requerimiento | Condición o comportamiento que el sistema debe cumplir. | El sistema debe validar deuda vencida antes de confirmar una venta a crédito. |
Una restricción puede generar requerimientos funcionales o no funcionales, pero su origen suele ser un límite del contexto.
En requerimientos es común clasificar restricciones en varias categorías. Las más frecuentes son técnicas, legales, operativas y comerciales.
| Tipo | Qué limita | Ejemplo |
|---|---|---|
| Técnica | Tecnologías, arquitectura, integraciones, plataformas o infraestructura. | La aplicación debe usar el proveedor de autenticación corporativo. |
| Legal | Normas, leyes, contratos, regulaciones o cumplimiento obligatorio. | Los datos personales deben conservarse y eliminarse según la normativa aplicable. |
| Operativa | Forma de trabajo, horarios, disponibilidad de usuarios, soporte o procesos. | El sistema no puede interrumpir la operación durante horario de atención. |
| Comercial | Presupuesto, plazos, licencias, proveedores, contratos o mercado. | La primera versión debe entregarse antes de una fecha contractual. |
Las restricciones técnicas condicionan decisiones de tecnología, integración, infraestructura, arquitectura o compatibilidad.
Ejemplos:
Estas restricciones deben revisarse con el equipo técnico para evaluar factibilidad, riesgos e impacto.
Las restricciones legales provienen de leyes, normas, contratos, regulaciones sectoriales o políticas obligatorias. Son especialmente importantes cuando el sistema maneja datos personales, información financiera, salud, educación, contratos o registros auditables.
Ejemplos:
Para este tipo de restricciones conviene involucrar a áreas legales, auditoría o cumplimiento normativo.
Las restricciones operativas surgen de la forma en que la organización trabaja. Afectan horarios, procesos, soporte, capacitación, disponibilidad de usuarios, ambientes y procedimientos.
Ejemplos:
Ignorar restricciones operativas puede hacer que una solución técnicamente correcta sea difícil de implementar en la práctica.
Las restricciones comerciales se relacionan con presupuesto, fechas, contratos, licencias, proveedores, acuerdos de servicio o condiciones del mercado.
Ejemplos:
Estas restricciones pueden afectar alcance, tecnología, prioridades y estrategia de versiones.
Además de las categorías principales, muchos proyectos tienen restricciones relacionadas con datos: origen, calidad, conservación, migración, propiedad, privacidad y disponibilidad.
Ejemplos:
Estas restricciones suelen afectar diseño de base de datos, seguridad, migración y pruebas.
Cuando el sistema debe comunicarse con otros sistemas, aparecen restricciones específicas de integración.
Ejemplos:
Las integraciones son una fuente frecuente de dependencias y riesgos, por lo que deben aclararse temprano.
Para identificar restricciones, conviene hacer preguntas específicas durante la elicitación:
Estas preguntas ayudan a descubrir límites que no siempre aparecen en pedidos funcionales.
Una restricción debe documentarse de manera clara y con suficiente contexto. Puede incluir:
Esta información facilita evaluar consecuencias y tomar decisiones informadas.
| Campo | Ejemplo |
|---|---|
| Identificador | RT-001 |
| Tipo | Técnica |
| Descripción | La autenticación de usuarios debe realizarse mediante el proveedor corporativo existente. |
| Fuente | Área de tecnología. |
| Impacto | Condiciona el diseño de inicio de sesión, permisos e integración de usuarios. |
| Riesgo | Si el proveedor no está disponible para pruebas, se retrasa la validación de acceso. |
| Requerimientos afectados | Inicio de sesión, gestión de roles, cierre de sesión, auditoría de accesos. |
Las restricciones influyen en decisiones de diseño, arquitectura y planificación. Algunas limitan alternativas; otras obligan a elegir un camino específico.
Por ejemplo, si la organización exige usar una base de datos existente, el diseño de datos debe considerar su estructura, rendimiento y limitaciones. Si una norma exige auditoría, el sistema debe registrar eventos relevantes desde el inicio.
Por eso, las restricciones deben comunicarse al equipo técnico antes de comprometer una solución.
Muchas restricciones introducen riesgos. Un proveedor externo puede no entregar documentación a tiempo, una migración puede encontrar datos incompletos, una norma puede requerir interpretación legal o una fecha comercial puede obligar a reducir alcance.
Al analizar una restricción conviene preguntar:
Registrar estos riesgos ayuda a planificar mejor.
No todas las restricciones tienen el mismo grado de flexibilidad. Algunas son obligatorias; otras pueden negociarse.
| Tipo | Descripción | Ejemplo |
|---|---|---|
| No negociable | Debe cumplirse por ley, contrato, seguridad crítica o decisión firme. | Los datos fiscales deben cumplir el formato exigido por normativa. |
| Negociable | Puede modificarse si se evalúan costos, beneficios y alternativas. | Usar una herramienta específica para reportes si existe una alternativa aprobada. |
| Condicional | Aplica solo bajo ciertas condiciones o para una etapa determinada. | La primera versión no incluirá integración en tiempo real, solo sincronización nocturna. |
Conocer el grado de flexibilidad evita discusiones innecesarias y ayuda a priorizar.
Supongamos que se construirá un sistema de reclamos para una empresa de servicios. Durante el relevamiento aparecen estas restricciones:
Cada restricción afecta decisiones: alcance de la primera versión, integración, migración, reportes, horarios de soporte y pruebas.
Al trabajar con restricciones, suelen aparecer estos errores:
Algunas buenas prácticas son:
Las restricciones técnicas, legales, operativas y comerciales son parte esencial del contexto de los requerimientos. Definen límites que la solución debe respetar y pueden influir fuertemente en decisiones de diseño, arquitectura, planificación y aceptación.
Trabajarlas correctamente permite evitar sorpresas, evaluar riesgos y construir una solución viable dentro de las condiciones reales del proyecto.
En el próximo tema estudiaremos interfaces externas y dependencias con otros sistemas, un tipo de restricción y requerimiento especialmente importante cuando el software debe comunicarse con aplicaciones, servicios o dispositivos externos.