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.
Un mismo requisito puede necesitar varias comprobaciones
Imagina Cuaderno de equipo, una aplicación ficticia para registrar decisiones de proyectos. El requisito «gestionar permisos» todavía deja muchas interpretaciones. Una forma de concretarlo es separar acciones permitidas y denegadas:
| Escenario | Punto de partida y acción | Resultado que se quiere comprobar |
|---|---|---|
| La editora corrige una decisión | Existe una decisión guardada; una editora cambia el motivo y guarda | La corrección queda asociada a esa decisión y permanece al volver a abrirla |
| La lectora intenta cambiarla | La misma decisión; una lectora intenta enviar una modificación | El cambio se rechaza y el contenido anterior permanece |
| El guardado falla | La editora ha escrito una corrección; el sistema no puede guardarla | Se informa del fallo, no se presenta como guardado y se conserva el texto para corregir o reintentar |
Ocultar un botón a la lectora no demuestra por sí solo que el permiso se cumpla. En una aplicación con servidor, el equipo técnico debe comprobar también la acción en la capa que guarda el dato. La persona que acepta necesita una explicación y una evidencia comprensibles de ese resultado, sin tener que construir la prueba por su cuenta.
Ficha de un escenario completo
| Campo | Ejemplo preparado |
|---|---|
| ID | PERM-02 |
| Resultado del alcance | La lectora consulta sin modificar decisiones |
| Preparación | Proyecto y decisión de prueba existentes; rol de lectora |
| Acción | Intentar modificar la decisión por el mecanismo que utiliza la aplicación |
| Resultado esperado | Respuesta de permiso denegado; ningún campo de la decisión cambia |
| Método | Prueba funcional de la acción y lectura posterior del dato |
| Entorno y versión | Identificar el entorno de prueba y la versión cuando se ejecute |
| Evidencia | Resultado de la petición y comprobación de que el contenido se conserva, sin secretos ni datos personales |
| Revisión | Persona designada por el cliente, con explicación del responsable técnico |
| Estado inicial | Por comprobar |
La ficha prepara una comprobación; no afirma que un programa la haya superado. Cuando se ejecute, se añaden fecha, versión y evidencia. Si el resultado no coincide, se registra qué ha fallado y qué falta para aceptar, en lugar de marcar una casilla por haber visto una demo general.
Exportar y recuperar son condiciones distintas
«Permitir salir con los datos» puede esconder dos trabajos. Uno es descargar un archivo que conserve los campos y relaciones acordados. Otro es recuperar una copia para continuar el trabajo.
En Cuaderno, la exportación JSON debería permitir identificar el proyecto al que pertenece cada decisión y conservar motivos y estados. Una comprobación puede crear un conjunto pequeño conocido, exportarlo y comparar campos y relaciones. Que el archivo exista no demuestra que esté completo.
La recuperación exige otra prueba: preparar un entorno controlado, restaurar la copia y abrir una decisión conocida. No se hace sobre datos reales que puedan sobrescribirse. Si el acuerdo solo incluye exportación y no incluye una función de importación, esa diferencia debe quedar explícita; no se añade como obligación silenciosa al final.
La guía de aceptación de NASA trata los criterios, responsables y evidencias por entrega, incluyendo software y datos. Su formalidad responde a otro contexto; la idea aprovechable aquí es acordar qué se revisará antes de construirlo.
Cuánto detalle necesita el criterio
Un criterio necesita el detalle que permite distinguir el resultado esperado de uno incorrecto. No exige inventar tolerancias para todas las funciones.
«Se conserva el identificador del proyecto» es una condición exacta. «La búsqueda responde rápido» necesita un contexto y un límite acordados: cantidad de datos, dispositivo, conexión, operación y forma de medir. Si todavía no existe una base para decidir ese límite, queda como pregunta pendiente. Un número elegido por rellenar el documento no mejora la prueba.
El recurso de criterios de aceptación contiene una plantilla y estos escenarios preparados. El mapa de alcance permite relacionarlos con lo incluido y lo pospuesto. Cuando ya exista una entrega, la guía para probar y aceptar software a medida ayuda a organizar su revisión.
Puedes volver al recorrido completo en Encargar software a medida.
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
Con este mapa puedes preparar un presupuesto de software a medida o comparar propuestas sin obligar a cada proveedor a interpretar una necesidad distinta.