Definir el alcance de un sistema significa aclarar qué incluirá la solución, qué quedará fuera y hasta dónde llegan sus responsabilidades. Esta definición es esencial para evitar expectativas confusas y crecimiento desordenado del proyecto.
Un proyecto de software siempre tiene límites. No puede resolver todos los problemas de una organización, automatizar todos los procesos ni satisfacer todas las ideas al mismo tiempo. Por eso, el alcance ayuda a concentrar el trabajo en lo que realmente se decidió construir.
En este tema veremos cómo definir alcance, límites, exclusiones, supuestos y dependencias dentro del trabajo de requerimientos.
El alcance describe el conjunto de funciones, procesos, datos, usuarios, integraciones y restricciones que serán considerados dentro del sistema o de una versión específica del sistema.
También puede expresar el nivel de profundidad con que se resolverá un problema. Por ejemplo, un sistema puede permitir registrar pedidos, pero no necesariamente incluir facturación, despacho, cobranzas y seguimiento logístico en la primera versión.
Los límites permiten saber dónde termina la responsabilidad del sistema y dónde comienzan otros procesos, personas, herramientas o sistemas externos.
Definir límites ayuda a:
Un alcance ambiguo suele producir conflictos, demoras y retrabajo.
Conviene distinguir entre alcance del producto y alcance del proyecto. Están relacionados, pero no significan lo mismo.
| Tipo de alcance | Qué describe | Ejemplo |
|---|---|---|
| Alcance del producto | Características, funciones y condiciones que tendrá el sistema. | Registrar pedidos, consultar stock y emitir reportes de ventas. |
| Alcance del proyecto | Trabajo necesario para construir, entregar o implementar el producto. | Relevamiento, diseño, desarrollo, pruebas, capacitación y despliegue. |
En requerimientos nos concentramos especialmente en el alcance del producto, aunque las decisiones también impactan el alcance del proyecto.
Definir qué está dentro del alcance implica describir las capacidades y responsabilidades que el sistema asumirá.
Algunos elementos que pueden incluirse son:
Cuanto más claro sea lo incluido, más fácil será analizar requerimientos y validar entregas.
Definir exclusiones es tan importante como definir inclusiones. Decir explícitamente qué no se construirá evita malentendidos.
Ejemplos de exclusiones:
Las exclusiones deben comunicarse con cuidado. No significan que algo nunca se hará, sino que no forma parte del acuerdo actual.
Los límites del sistema indican qué queda dentro del sistema y qué queda fuera como actor, proceso manual, sistema externo o responsabilidad de otra área.
Por ejemplo, en un sistema de pedidos, el sistema puede registrar el pedido y consultar stock, pero el despacho físico de productos ocurre fuera del sistema. Sin embargo, el sistema podría registrar el estado del despacho si recibe esa información.
Para definir límites conviene identificar:
Supongamos que una empresa quiere un sistema para gestionar reclamos de clientes. Una definición inicial de alcance podría ser:
| Dentro del alcance | Fuera del alcance |
|---|---|
| Registrar reclamos recibidos por teléfono, correo o formulario web. | Atención automática mediante chatbot. |
| Asignar reclamos a un responsable interno. | Integración con redes sociales. |
| Consultar estado e historial de cada reclamo. | Aplicación móvil nativa para clientes. |
| Enviar notificaciones por correo ante cambios de estado. | Integración con sistemas externos de logística. |
| Generar reportes mensuales de reclamos por tipo y estado. | Tablero avanzado de análisis predictivo. |
Esta tabla no reemplaza a los requerimientos detallados, pero ayuda a ubicar la solución dentro de límites acordados.
Un supuesto es una condición que se considera verdadera para planificar o definir requerimientos, aunque todavía no esté completamente confirmada.
Ejemplos de supuestos:
Los supuestos deben registrarse porque, si resultan falsos, pueden cambiar alcance, costo o tiempo.
Una dependencia es algo externo o previo que condiciona la construcción o funcionamiento del sistema.
Algunas dependencias comunes son:
Identificar dependencias ayuda a planificar riesgos y a evitar bloqueos inesperados.
No todo debe construirse en una única entrega. Muchas veces conviene dividir el alcance en versiones o incrementos.
Por ejemplo:
| Versión | Alcance principal |
|---|---|
| Versión 1 | Registro de clientes, registro de pedidos y consulta básica de stock. |
| Versión 2 | Notificaciones, reportes de ventas y validaciones avanzadas. |
| Versión 3 | Integración con sistema contable y seguimiento de entregas. |
Definir alcance por versiones permite entregar valor antes y aprender con el uso real del sistema.
El crecimiento del alcance ocurre cuando se agregan funcionalidades, cambios o responsabilidades sin revisar impacto. A veces se lo llama "scope creep".
Puede ocurrir por varias razones:
No todo crecimiento del alcance es malo. El problema aparece cuando se incorpora sin análisis, prioridad ni acuerdo.
Controlar el alcance no significa rechazar todos los cambios. Significa analizarlos y decidir con información suficiente.
Ante una solicitud nueva conviene preguntar:
El alcance no se limita a funciones. También debe considerar requerimientos no funcionales, como seguridad, rendimiento, disponibilidad, accesibilidad, usabilidad, auditoría y compatibilidad.
Por ejemplo, decir que un sistema "permitirá consultar facturas" no alcanza si no se aclara quién puede consultarlas, cuánto tiempo debe tardar la consulta, desde qué dispositivos se usará, qué datos deben protegerse y qué registros de auditoría deben guardarse.
Si los requerimientos no funcionales quedan fuera de la definición de alcance, pueden aparecer tarde y producir cambios costosos.
En muchos proyectos conviene registrar un documento o sección breve de alcance. No necesita ser complejo, pero sí claro.
Puede incluir:
Este registro ayuda a mantener conversaciones ordenadas con los interesados.
Un alcance puede redactarse de forma simple y concreta:
Este texto no detalla todos los requerimientos, pero establece una frontera inicial comprensible.
Al definir alcance, suelen cometerse errores como:
Estos errores pueden volver inestable el proyecto y dificultar la aceptación del producto.
Algunas buenas prácticas para definir alcance son:
Definir el alcance del sistema y los límites de la solución permite ordenar expectativas y concentrar el esfuerzo en lo que realmente se decidió construir. Sin esta definición, el proyecto puede crecer de manera descontrolada o generar desacuerdos sobre lo que debía entregarse.
Un buen alcance no impide que el producto evolucione. Al contrario, permite decidir cambios con mayor claridad y planificar versiones futuras con sentido.
En el próximo tema estudiaremos la visión del producto y los objetivos medibles, dos elementos que ayudan a conectar el alcance con el valor que se espera obtener.