PLANTILLA DE DOCUMENTO DE REQUISITOS DE UNA APLICACIÓN Maestro · Versión de la plantilla: 6 de septiembre de 2026 Guía: https://www.bemaestro.fr/es/journal/cahier-des-charges-non-technique USO Copia este documento en el editor que prefieras. Sustituye los campos entre corchetes. Escribe «por decidir» cuando falte una respuesta, con un responsable y una fecha de decisión. Elimina el ejemplo ficticio antes de compartir tu versión. Esta plantilla describe una necesidad de producto; no sustituye a un contrato de servicios. 1. IDENTIDAD Y DECISIONES Nombre del proyecto: [nombre] Responsable del proyecto: [nombre y función] Versión del documento y fecha: [versión / fecha] Persona que valida el alcance: [nombre] Personas consultadas: [usuarios, operaciones, proveedor] Estado: [borrador / por revisar / validado] Registro de decisiones: - [fecha] [decisión] [motivo] [persona que valida] [consecuencias] 2. PROBLEMA Y OBJETIVO Actualmente, [persona] debe [tarea], pero [obstáculo observable]. Consecuencia: [error, doble introducción de datos, espera, coste observado]. ¿Cómo se resuelve el problema hoy? [herramienta y pasos] ¿Qué pruebas tenemos? [ejemplos, observaciones fechadas, mediciones disponibles] Resultado esperado: [lo que debe ser posible] Indicador de éxito: [medición, situación actual, objetivo que justificar] ¿Cuándo y cómo se medirá? [método y responsable] Alternativas examinadas: [mejorar lo existente / software del mercado / construir] ¿Por qué este proyecto? [razones y límites de las alternativas] 3. USUARIOS Y PERMISOS Completar para cada rol: - Rol: [nombre comprensible] - Tareas realizadas: [lista] - Información que puede consultar: [lista] - Acciones permitidas: [crear / modificar / validar / eliminar / exportar] - Acciones prohibidas: [lista] - Alcance de los datos: [los suyos / su equipo / toda la organización] - Acceso: [sin cuenta / cuenta personal / invitación / otro] - Retirada o recuperación del acceso: [procedimiento esperado] No supongas que ocultar una pantalla basta para impedir una acción: especifica las pruebas que deben hacerse con cada rol. 4. ALCANCE DE LA PRIMERA VERSIÓN Imprescindible para el primer uso: - [función]: [necesidad cubierta y persona afectada] Útil más adelante: - [función]: [motivo para posponerla] Excluido expresamente: - [función, plataforma o conexión no prevista] Dependencias antes de empezar: [accesos, contenidos, datos, decisiones] Criterio para posponer o abandonar el proyecto: [condición concreta] 5. RECORRIDOS QUE CONSTRUIR Identificador: [P-01] Nombre: [acción realizada por una persona] Usuario: [rol] Situación inicial: [información y estado ya disponibles] Pasos: 1. [acción del usuario] 2. [respuesta esperada de la aplicación] 3. [acción siguiente] Resultado final: [lo que obtiene la persona] Casos que tratar: - Datos ausentes o inválidos: [comportamiento] - Acción simultánea de otra persona: [comportamiento] - Conexión interrumpida o servicio no disponible: [comportamiento] - Cancelación o corrección: [comportamiento] - Permisos insuficientes: [comportamiento] Duplica esta sección para cada recorrido imprescindible. 6. REGLAS DEL NEGOCIO Identificador: [R-01] Regla en una frase: [cuando..., entonces...] Ejemplo permitido: [valores y resultado] Ejemplo rechazado: [valores y explicación esperada] Excepciones: [cuáles y quién puede autorizarlas] ¿Quién confirma esta regla? [nombre] Recorridos afectados: [identificadores] Describe también las reglas presentes en las fórmulas, los colores, los comentarios y los hábitos de trabajo de la herramienta anterior. 7. DATOS Y DOCUMENTOS Para cada información: - Nombre y significado: [p. ej., identificador de pedido] - ¿Obligatoria? [sí / no / bajo qué condición] - Formato y valores permitidos: [texto, fecha, lista, importe y moneda] - Origen: [introducción manual, importación, servicio externo] - ¿Quién puede verla o modificarla? [roles] - Conservación y eliminación: [regla que validar] - Exportación necesaria: [formato, contenido, permisos] Datos confidenciales que proteger: [categorías, sin ejemplos reales sensibles] Datos ficticios utilizables en las pruebas: [conjunto de prueba] Responsable de las cuestiones de privacidad: [nombre o rol] Servicios que recibirán los datos: [por confirmar con quien lo construya] 8. MIGRACIÓN DE LO EXISTENTE Fuentes que migrar: [archivos, bases de datos, documentos] Volumen conocido y fecha de la medición: [número de elementos y tamaño] Identificadores estables: [cómo encontrar un elemento sin ambigüedad] Duplicados y campos ausentes: [reglas de tratamiento] Muestra de primera importación: [casos habituales y excepciones] Comprobaciones: [número de elementos, totales, relaciones, fechas, excepciones] Responsable de validación: [nombre] Copia inicial conservada: [ubicación y responsable] Fecha prevista de cambio: [fecha y condiciones previas] Fuente de referencia durante la transición: [herramienta y reglas de modificación] Condición para volver a la herramienta anterior: [anomalía y quién decide] Recuperación de cambios desde la copia: [procedimiento] Herramienta anterior tras el cambio: [solo lectura / archivo / otro] 9. CONEXIONES, DISPOSITIVOS Y CALIDAD DE USO Conexiones externas: [servicio, operación, datos intercambiados, titular de la cuenta] Comportamiento si falla una conexión: [mensaje, recuperación, alerta] Dispositivos y navegadores compatibles: [lista priorizada] Uso del teclado, legibilidad y accesibilidad: [situaciones que comprobar] Rendimiento esperado: [acción, umbral acordado, dispositivo, conexión y condiciones] Disponibilidad necesaria: [horarios y consecuencias de una interrupción] Idiomas y formatos: [idiomas, fechas, números, zonas horarias] 10. CRITERIOS DE ACEPTACIÓN Identificador: [CA-01] Recorrido y regla relacionados: [P-01 / R-01] Dado: [situación inicial y datos de prueba] Cuando: [acción] Entonces: [resultado observable y ausencia de efectos no deseados] Verificado por: [persona] Prueba: [escenario ejecutado, captura, resultado de prueba] Estado: [por probar / superado / por corregir] Fecha y versión probada: [fecha / versión] Incluye criterios para errores, permisos y acciones simultáneas, no solo para el recorrido en el que todo sale bien. 11. ENTREGA, OPERACIÓN Y SALIDA Entregables esperados: [aplicación, código, documentación, exportaciones, formación] Titular de las cuentas: [dominio, alojamiento, repositorio de código, servicios] Accesos que entregar al responsable: [lista, sin contraseñas en este documento] Copias de seguridad: [contenido, frecuencia acordada, responsable, prueba de restauración] Incidentes: [canal de contacto, responsable, plazo acordado] Mantenimiento: [correcciones, actualizaciones, alcance, coste por especificar] Salida o cambio de proveedor: [código, datos, documentos y accesos que recuperar] Limitaciones conocidas en la entrega: [lista y decisión de aceptación] 12. PRESUPUESTO, CALENDARIO Y VALIDACIÓN Presupuesto de construcción: [límite o rango por confirmar] Costes recurrentes que estimar por separado: [alojamiento, servicios, mantenimiento, uso de IA] Primer recorrido que entregar: [identificador] Etapas y personas que validan: [etapa / fecha objetivo / responsable] Disponibilidad de usuarios para las pruebas: [franjas horarias] Procedimiento ante una nueva solicitud: [descripción, impacto, acuerdo previo a la ejecución] Preguntas abiertas: [pregunta / responsable / fecha prevista] Validación del documento: [nombre / fecha / versión / posibles reservas] EJEMPLO FICTICIO QUE SUSTITUIR: RESERVA DE CITAS Problema: los clientes llaman para reservar y el responsable copia las citas en una agenda. Quiere publicar su disponibilidad y recibir las reservas en un mismo lugar. Primera versión: consulta de horarios, reserva, confirmación, cancelación y agenda del responsable. Sin pagos en línea ni SMS. Roles: el cliente reserva; el responsable abre los horarios; un compañero consulta la agenda sin modificar la disponibilidad. R-01: una franja de treinta minutos admite una sola reserva. R-02: el cliente puede cancelar hasta veinticuatro horas antes de la cita. Después, la aplicación le indica que contacte con el responsable. Estas duraciones ilustran una decisión de negocio, no una regla universal. P-01: la clienta consulta los horarios libres, elige uno, introduce sus datos de contacto y confirma. La reserva aparece en la agenda. La franja ya no se ofrece. Se prepara una confirmación para la clienta; un fallo de envío debe ser visible para el responsable sin eliminar la reserva. CA-01: dada una franja libre, cuando una clienta confirma con datos de contacto válidos, aparece una única reserva en la agenda y la franja deja de ofrecerse. CA-02: cuando dos clientes confirman simultáneamente la misma franja, solo se acepta una reserva. La otra persona recibe una explicación y puede elegir otro horario. CA-03: cuando un compañero con acceso de solo lectura intenta modificar una franja, se rechaza la acción y la disponibilidad no cambia, incluso si intenta acceder directamente a la acción sin pasar por su pantalla. Preguntas abiertas: ¿qué datos de contacto son necesarios? ¿Cuánto tiempo se conservan? ¿Quién recibe el aviso si no se envía una confirmación? ¿Cómo se corrige un error de reserva pasado el plazo de cancelación?