Definir el alcance de un software no es enumerar pantallas. Es acordar qué problema se resuelve, para quién, qué recorrido debe funcionar, qué queda fuera y qué evidencia permitirá aceptar el resultado.
Un alcance útil no pretende anticipar cada decisión futura. Deja suficiente claridad para comparar alternativas, pedir propuestas y detectar un cambio sin convertir cualquier aprendizaje en conflicto.
Empieza por el problema, no por la solución pedida
“Necesitamos una app” describe un formato, no una necesidad. Antes de hablar de tecnología, registra:
- qué ocurre hoy;
- quién sufre o gestiona el problema;
- qué intenta conseguir esa persona;
- qué consecuencia merece cambiarse;
- qué restricciones ya existen;
- qué alternativa se usa ahora.
GOV.UK recomienda cuestionar una solución predefinida y reformularla como problema antes de construir (GOV.UK, observada el 29/08/2026). Su contexto es el servicio público británico; aquí se usa como disciplina de definición, no como método contractual.
Una formulación útil podría ser: “Las solicitudes llegan por varios canales, no tienen owner visible y el equipo no sabe cuál requiere respuesta”. Todavía no decide si la salida es configurar, integrar o desarrollar.
Define usuario, disparador y resultado
Para cada recorrido principal responde:
| Campo | Pregunta |
|---|---|
| Actor | ¿Quién inicia o completa el trabajo? |
| Disparador | ¿Qué hecho pone el proceso en marcha? |
| Objetivo | ¿Qué intenta conseguir el actor? |
| Salida | ¿Qué resultado debe existir al terminar? |
| Evidencia | ¿Cómo sabremos que terminó correctamente? |
| Excepción | ¿Qué caso necesita otra decisión? |
No confundas comprador, usuario y responsable operativo. Pueden ser personas diferentes y tener necesidades distintas.
La guía de GOV.UK sobre historias de usuario separa actor, necesidad y objetivo, y plantea criterios de aceptación como resultados comprobables (GOV.UK, observada el 29/08/2026). Una historia ayuda a conversar; no sustituye el mapa completo del proceso.
Dibuja el flujo antes de listar funciones
Recorre un caso real desde la entrada hasta el cierre:
- qué dato entra y desde dónde;
- qué validación necesita;
- quién decide o actúa;
- qué estados atraviesa;
- qué excepción puede aparecer;
- qué persona o sistema recibe la salida.
Las funciones deben responder a pasos o decisiones de ese flujo. Si una pantalla no cambia el trabajo, quizá sea una preferencia de interfaz, no un requisito.
GOV.UK define el alcance de una transacción como decidir qué hace, qué no hace y qué problema resuelve para el usuario (GOV.UK, observada el 29/08/2026). El principio útil es no dejar que la estructura interna o una elección técnica dicten el recorrido.
Escribe dentro, fuera y pendiente
Un alcance defendible necesita tres listas:
Dentro
Flujos, usuarios, datos, integraciones y entregables necesarios para resolver el trabajo acordado.
Fuera
Necesidades reales que no pertenecen a esta fase. Excluir no significa negar su valor: evita que una expectativa implícita aparezca al final.
Pendiente de decisión
Supuestos que deben comprobarse: acceso a una API, calidad de datos, permiso, compatibilidad, volumen o responsable. No los conviertas en compromisos silenciosos.
Separa entregable de resultado
“Entregar un panel” describe un objeto. “El responsable puede ver casos sin owner y asignarlos” describe un resultado comprobable.
Para cada entregable registra:
- comportamiento visible;
- datos y permisos necesarios;
- estados y errores;
- dependencia externa;
- documentación o traspaso;
- criterio de aceptación.
El marco Configurar → Integrar → Desarrollar se aplica después de entender este trabajo. El alcance no debe forzar una solución antes de comparar alternativas.
Convierte expectativas en criterios de aceptación
Un criterio útil describe una condición observable, no “funciona bien”. Incluye:
- contexto o dato de partida;
- acción o evento;
- resultado esperado;
- excepción relevante;
- evidencia que se revisará;
- persona que decide si pasa.
Ejemplo ilustrativo: “Dada una solicitud válida sin owner, cuando entra por el formulario, se crea una única solicitud pendiente y queda visible para asignación. Si falta el correo, se registra el motivo y no se envía confirmación”. No es un caso real ni un diseño obligatorio.
Un criterio de aceptación no es toda la estrategia de pruebas ni una garantía de ausencia de defectos. Define qué resultado acordado se comprobará; la prueba concreta se diseña después.
Añade requisitos no funcionales solo cuando cambien la decisión
Privacidad, permisos, accesibilidad, rendimiento, disponibilidad, compatibilidad, seguridad, auditoría y recuperación pueden ser esenciales. Evita palabras como “rápido”, “seguro” o “escalable” sin contexto comprobable.
Pregunta qué operación debe protegerse, quién necesita acceso, qué dependencia limita la respuesta y qué evidencia será suficiente. Si no existe todavía una base o umbral válido, déjalo pendiente en vez de inventarlo.
Gestiona cambios sobre una referencia común
Guarda una versión aceptada del alcance. Cuando aparezca un cambio, registra:
- qué problema o criterio cambia;
- qué sección y entregable afecta;
- qué dependencia añade o elimina;
- qué queda desplazado;
- quién decide incorporarlo.
Aprender durante el proyecto es normal. Lo peligroso es que el aprendizaje cambie compromisos sin quedar visible.
Checklist antes de pedir propuestas
- El problema está descrito sin imponer tecnología.
- Usuarios, disparador y resultado están identificados.
- El flujo principal incluye excepciones.
- Dentro, fuera y pendiente están separados.
- Cada entregable responde a un trabajo.
- Los criterios son observables y tienen responsable.
- Las dependencias y supuestos están visibles.
- Los requisitos no funcionales tienen contexto.
- Existe una referencia para gestionar cambios.
Con este mapa puedes preparar un presupuesto de software a medida o comparar propuestas sin obligar a cada proveedor a interpretar una necesidad distinta.