12. Alcance, objetivos y restricciones de un sistema

12.1 Introducción

Antes de construir un sistema de software, el equipo necesita comprender qué se quiere lograr, qué se incluirá, qué quedará fuera y bajo qué condiciones deberá funcionar. Estas decisiones se expresan mediante objetivos, alcance y restricciones.

Si estos elementos no están claros, cada persona puede imaginar un producto distinto. El cliente puede esperar una solución completa, los usuarios pueden pedir funcionalidades no previstas y el equipo técnico puede construir algo que no coincide con las prioridades reales.

Definir objetivos, alcance y restricciones no elimina todos los cambios, pero crea una base para discutirlos con claridad.

12.2 Objetivos del sistema

Los objetivos explican para qué existe el sistema. Deben responder qué necesidad se busca resolver y qué resultado se espera obtener. Un objetivo bien definido orienta decisiones de diseño, prioridad, validación y aceptación.

Un objetivo débil suele describir una solución sin explicar el valor:

Crear un sistema web para la empresa.

Un objetivo más claro conecta necesidad, usuarios y resultado:

Permitir que el área de ventas registre pedidos en línea y consulte el estado de entrega, reduciendo errores de carga manual y demoras de comunicación.

El segundo objetivo permite entender qué problema se ataca y cómo podría evaluarse si la solución aporta valor.

12.3 Características de un buen objetivo

Un buen objetivo de sistema debería ser claro, relevante y verificable. No siempre necesita tener una métrica exacta, pero sí debe permitir evaluar si el sistema se orienta en la dirección correcta.

  • Claro: se entiende sin interpretaciones ambiguas.
  • Orientado a valor: explica qué mejora o necesidad atiende.
  • Relacionado con usuarios o negocio: no se queda solo en tecnología.
  • Verificable: permite observar si se alcanzó o no.
  • Realista: considera recursos, tiempo y restricciones.
  • Acotado: no intenta resolver todos los problemas de la organización.
Idea clave: un objetivo no debe decir solamente qué se construirá, sino por qué vale la pena construirlo.

12.4 Alcance del sistema

El alcance define los límites del sistema. Indica qué funciones, procesos, usuarios, datos, integraciones y responsabilidades estarán incluidos. También debe aclarar qué queda fuera.

Definir alcance sirve para:

  • Evitar expectativas implícitas.
  • Priorizar funcionalidades.
  • Estimar esfuerzo con mayor criterio.
  • Organizar versiones o entregas.
  • Detectar dependencias e integraciones.
  • Discutir cambios de manera ordenada.

El alcance no es una lista rígida que jamás cambia. Puede evolucionar, pero cualquier cambio debería analizarse por su impacto en tiempo, costo, calidad y riesgos.

12.5 Qué puede incluir el alcance

El alcance puede describirse desde distintas dimensiones. No conviene limitarlo a una lista de pantallas, porque el sistema incluye reglas, datos, procesos e integraciones.

Dimensión Qué define Ejemplo
Funcionalidades Qué acciones permitirá realizar el sistema. Registrar pedidos, cancelar reservas, emitir reportes.
Usuarios o roles Quiénes usarán el sistema y con qué permisos. Administrador, vendedor, cliente, supervisor.
Procesos Qué flujos de trabajo serán cubiertos. Inscripción, aprobación, facturación, seguimiento.
Datos Qué información se gestionará. Clientes, productos, turnos, pagos, documentos.
Integraciones Con qué sistemas externos se comunicará. Pasarela de pagos, facturación, correo, identidad.
Ambientes Dónde funcionará el sistema. Web, móvil, red interna, nube, sucursales.

12.6 Fuera de alcance

Una parte fundamental del alcance es declarar qué no se incluirá. Muchas discusiones en proyectos ocurren porque algo nunca fue prometido, pero alguien lo suponía incluido.

Ejemplos de elementos fuera de alcance:

  • La primera versión permitirá registrar pedidos, pero no integrará pagos en línea.
  • El sistema funcionará en navegadores modernos, pero no se garantizará compatibilidad con versiones obsoletas.
  • Se migrarán clientes activos, pero no el historial completo de diez años.
  • Se generarán reportes básicos, pero no tableros analíticos avanzados.
  • El sistema enviará correos, pero no mensajes por WhatsApp en la primera etapa.

Declarar exclusiones no significa rechazarlas para siempre. Muchas pueden planificarse para versiones futuras.

12.7 Restricciones del sistema

Las restricciones son condiciones que limitan o condicionan la solución. Pueden venir del negocio, la tecnología, la ley, la organización, la operación o la seguridad.

Algunas restricciones típicas son:

  • Debe integrarse con un sistema existente.
  • Debe funcionar en determinados navegadores o dispositivos.
  • Debe cumplir una normativa de protección de datos.
  • Debe estar disponible en cierto horario.
  • Debe usarse una tecnología definida por la organización.
  • Debe desplegarse en una infraestructura ya contratada.
  • Debe entregar una primera versión antes de una fecha fija.

Las restricciones influyen en diseño, arquitectura, pruebas, planificación y mantenimiento.

12.8 Tipos de restricciones

Tipo Descripción Ejemplo
Técnica Condiciona tecnologías, plataformas o integraciones. Debe usar la base de datos corporativa existente.
Temporal Impone fechas o ventanas de entrega. Debe estar operativo antes del inicio de inscripciones.
Económica Limita presupuesto, licencias o infraestructura. No se podrán contratar servicios pagos adicionales.
Legal Obliga a cumplir normas o regulaciones. Debe conservar registros por cinco años.
Operativa Condiciona uso, soporte, horarios o procedimientos. No se puede detener el sistema durante horario comercial.
Organizacional Surge de políticas, estructura o decisiones internas. Todo usuario debe autenticarse con la cuenta institucional.
Seguridad Define protección de datos, accesos y trazabilidad. Las acciones administrativas deben quedar auditadas.

12.9 Diferencia entre requisito y restricción

Un requisito describe algo que el sistema debe cumplir. Una restricción limita cómo puede construirse, entregarse u operarse la solución. En la práctica, ambos conceptos están relacionados y a veces se expresan juntos.

Elemento Pregunta que responde Ejemplo
Requisito ¿Qué debe hacer o cumplir el sistema? El usuario debe poder cancelar una reserva hasta dos horas antes.
Restricción ¿Qué condición limita la solución? El sistema debe integrarse con el calendario corporativo existente.

Ambos deben documentarse porque afectan decisiones y expectativas.

12.10 Supuestos y dependencias

Además de objetivos, alcance y restricciones, conviene registrar supuestos y dependencias.

Un supuesto es algo que se cree verdadero, pero que debe confirmarse. Una dependencia es algo externo que el proyecto necesita para avanzar.

Concepto Ejemplo Riesgo si falla
Supuesto Los usuarios conocen el proceso actual y podrán explicarlo. El análisis puede demorar más de lo esperado.
Dependencia El equipo de infraestructura debe crear el ambiente de pruebas. La validación se retrasa aunque el desarrollo avance.

Registrar supuestos y dependencias permite anticipar bloqueos y evitar sorpresas.

12.11 Límites del sistema

Definir límites significa aclarar dónde empieza y dónde termina la responsabilidad del sistema. Esto es especialmente importante cuando existen integraciones con otros sistemas o procesos manuales.

Por ejemplo, en un sistema de compras en línea:

  • El sistema puede registrar el pedido, pero el procesamiento del pago puede depender de una pasarela externa.
  • Puede calcular el costo de envío, pero la entrega física depende de una empresa logística.
  • Puede enviar una factura, pero la autorización fiscal puede depender de un organismo externo.
  • Puede mostrar stock, pero la actualización real puede venir de un sistema de depósito.

Estos límites ayudan a definir responsabilidades, errores posibles, pruebas e integraciones.

12.12 Criterios de éxito

Los criterios de éxito ayudan a saber si el sistema cumplió sus objetivos. No siempre se limitan a "la funcionalidad está implementada"; pueden incluir uso real, reducción de errores, tiempos de respuesta, satisfacción de usuarios o cumplimiento normativo.

Ejemplos de criterios de éxito:

  • El 80% de las reservas se realiza sin intervención telefónica.
  • Los usuarios pueden completar una inscripción en menos de cinco minutos.
  • El sistema reduce errores de carga de pedidos en un 50%.
  • Las operaciones administrativas quedan auditadas.
  • La primera versión permite operar el proceso principal de punta a punta.

Los criterios de éxito conectan el trabajo técnico con resultados observables.

12.13 Cambios de alcance

El alcance puede cambiar. Esto es normal en muchos proyectos. Lo importante es que los cambios se gestionen de manera explícita.

Antes de aceptar un cambio, conviene analizar:

  • Qué valor aporta.
  • Qué esfuerzo requiere.
  • Qué funcionalidades desplaza o retrasa.
  • Qué riesgos introduce.
  • Qué partes del sistema afecta.
  • Si modifica fechas, presupuesto o calidad esperada.
  • Si corresponde a la versión actual o a una futura.

Gestionar cambios no significa bloquearlos. Significa tomar decisiones conscientes sobre sus consecuencias.

12.14 Ejemplo: sistema de turnos para una clínica

Supongamos que una clínica necesita un sistema de turnos.

Objetivo Permitir que pacientes soliciten turnos en línea y reducir la carga manual del personal administrativo.
Incluido en alcance Registro de pacientes, consulta de disponibilidad, solicitud de turnos, cancelación y panel administrativo.
Fuera de alcance inicial Pago en línea, historia clínica electrónica e integración con laboratorios externos.
Restricciones Debe proteger datos personales, funcionar en navegadores modernos y usar autenticación institucional para administradores.
Supuestos La clínica entregará horarios de profesionales actualizados antes del inicio del desarrollo.
Dependencias El equipo de infraestructura debe habilitar el servidor de pruebas.
Criterio de éxito La primera versión permite gestionar turnos de dos especialidades sin intervención telefónica para casos simples.

12.15 Errores comunes

Al definir objetivos, alcance y restricciones suelen aparecer errores como:

  • Redactar objetivos demasiado generales.
  • Confundir una tecnología con el objetivo del sistema.
  • No declarar qué queda fuera del alcance.
  • Considerar solo pantallas y olvidar datos, reglas e integraciones.
  • Ignorar restricciones legales, operativas o de seguridad.
  • No registrar supuestos importantes.
  • Aceptar cambios sin analizar impacto.
  • No definir criterios de éxito observables.

12.16 Plantilla simple

Una forma práctica de comenzar es completar una plantilla breve:

Objetivo del sistema ¿Qué necesidad resuelve y qué resultado se espera?
Usuarios principales ¿Quiénes usarán el sistema y con qué propósito?
Funcionalidades incluidas ¿Qué acciones permitirá realizar?
Fuera de alcance ¿Qué no se incluirá en esta etapa?
Restricciones ¿Qué condiciones limitan la solución?
Supuestos ¿Qué se considera verdadero pero debe confirmarse?
Dependencias ¿Qué necesita el proyecto de otras personas, sistemas o áreas?
Criterios de éxito ¿Cómo sabremos que el sistema logró su propósito?

12.17 Qué debes recordar de este tema

  • Los objetivos explican para qué existe el sistema y qué valor debe aportar.
  • El alcance define qué incluye y qué excluye una solución en una etapa determinada.
  • Las restricciones condicionan cómo puede construirse, entregarse u operarse el sistema.
  • Declarar lo que queda fuera de alcance evita expectativas implícitas.
  • Supuestos y dependencias deben registrarse porque pueden convertirse en riesgos.
  • Los criterios de éxito permiten evaluar resultados observables.
  • Los cambios de alcance deben analizarse por su impacto en valor, tiempo, costo, riesgo y calidad.

12.18 Conclusión

Definir alcance, objetivos y restricciones es una actividad esencial para orientar el desarrollo de software. Estos elementos ayudan a establecer límites, priorizar decisiones, coordinar expectativas y evaluar si el sistema realmente cumple su propósito.

Para quien comienza, la idea principal es esta: un sistema bien definido no solo dice qué se construirá, sino también por qué se construye, hasta dónde llega y bajo qué condiciones debe funcionar.

En el próximo tema veremos una introducción a los requerimientos de software, donde profundizaremos en cómo expresar necesidades y condiciones que el sistema debe cumplir.

Volver al índice