Requisitos de producto: [Nombre del producto]
Sustituye todo lo que está entre [corchetes] y borra cada línea de ayuda cuando termines su sección. El documento está listo cuando alguien ajeno al equipo podría construir la primera versión con él, y otra persona podría comprobar que lo hizo.
01Resumen
Dos o tres líneas. Si no puedes decir así de breve qué es y para quién, el resto del documento no lo arreglará.
- Producto: [Nombre]
- Responsable: [Quien decide las dudas de alcance]
- Estado: [Borrador / En revisión / Acordado]
- Última actualización: [Fecha]
- En una frase: [Qué es, para quién y qué sustituye]
02Problema
Describe el problema tal como lo vive el usuario, no como una funcionalidad que falta. Cuenta qué hace hoy en su lugar y cómo lo sabes.
Hoy, [quién] [recurre a qué solución improvisada] cuando necesita [lograr algo]. Le cuesta [tiempo, dinero o riesgo que hayas observado de verdad].
Evidencia: [Entrevistas, tickets de soporte, llamadas de venta, uso propio. Indica cuáles y cuántas.]
03Usuario objetivo
Un usuario principal. Indica el momento en que empieza a buscar una solución y para quién no es.
- Usuario principal: [Rol, tamaño de empresa, contexto]
- Detonante: [Lo que le hace buscar algo nuevo]
- Alternativa actual: [Hoja de cálculo, otra herramienta, una persona, nada]
- No es para: [A quién no sirve a propósito, y por qué]
04Trabajos por hacer
Lo que el usuario intenta conseguir, con sus palabras. De tres a cinco, el más importante primero.
- Trabajo 1: Cuando [situación], quiero [acción] para poder [resultado].
- Trabajo 2: Cuando [situación], quiero [acción] para poder [resultado].
- Trabajo 3: Cuando [situación], quiero [acción] para poder [resultado].
05Alcance del MVP
Lo que hace la primera versión. Cada línea debe ser algo que una persona pueda ver funcionando.
- [Primera capacidad sin la que no se puede lanzar]
- [Segunda capacidad]
- [Tercera capacidad]
06Requisitos
Una afirmación verificable por fila. La aceptación explica cómo comprobarlo en el producto en marcha; un requisito sin ella no se puede auditar. La prioridad es MoSCoW: Must, Should, Could, Won't. El tipo es funcional (comportamiento), no funcional (velocidad, disponibilidad, accesibilidad) o restricción (una normativa, una plataforma o un presupuesto).
Las claves son permanentes. No las renumeres ni las reutilices: tareas, commits y auditorías se refieren a ellas.
| Clave | Requisito | Aceptación | Prioridad | Tipo |
|---|---|---|---|---|
| REQ-001 | Los usuarios pueden [hacer algo observable] | [Pasos que lo demuestran en un sistema en marcha] | Must | Funcional |
| REQ-002 | [Página o acción] responde en menos de [tiempo] con [carga] | [Cómo y dónde se mide] | Should | No funcional |
| REQ-003 | [Límite normativo, de plataforma o de presupuesto] | [Prueba de que se respeta] | Must | Restricción |
| REQ-004 | [Algo mencionado pero aplazado] | [Cómo se comprobaría más adelante] | Won't | Funcional |
07Métricas de éxito
Cómo sabrás que la versión funcionó. Nombra la métrica, dónde se mide y el objetivo. Deja el objetivo en blanco antes que inventarlo.
- Métrica principal: [Qué] medido en [herramienta], objetivo [valor, o se fija tras una línea base]
- Métrica secundaria: [Qué] medido en [herramienta], objetivo [valor]
- Límite de control: [Un número que no debe empeorar, como errores o reembolsos]
08No-objetivos
Lo que esta versión no hace a propósito. Esta sección evita más discusiones que ninguna otra.
- [Algo que la gente dará por incluido, y por qué no lo está]
- [Un segundo no-objetivo]
09Preguntas abiertas
Todo lo que sigue sin decidir, con una persona y una fecha. Una pregunta sin responsable sigue abierta.
- [Pregunta] (responsable: [nombre], para el: [fecha])
- [Pregunta] (responsable: [nombre], para el: [fecha])
10Aprobación
Quién aprobó esta versión. A partir de aquí, los cambios de alcance se proponen y se registran; no se cuelan.
- Aprobado por: [Nombres]
- Fecha: [Fecha]
- Cambios de alcance: [Cómo se propone un cambio y dónde se registra]