Ejemplos de PRD y contratos de aceptación
[!TIP] Usa esta página antes de pedir implementación. Elige un ejemplo, adapta el usuario y el alcance, y convierte sus filas de aceptación en comprobaciones. No pegues todo el documento en instrucciones del repositorio siempre activas.
| Si tu situación es… | Usa… | Practica después |
|---|---|---|
| No existe una aplicación en funcionamiento | Ejemplo A: nuevo comportamiento de suscripción | Laboratorio greenfield |
| El comportamiento existente debe seguir funcionando mientras se añade una función | Ejemplo B: delta de metadatos | Laboratorio brownfield |
| Cambia la implementación técnica, no el contrato de usuario | Ejemplo C: modernización de almacenamiento | Laboratorio de modernización |
Un documento de requisitos del producto describe por qué y qué. Un plan técnico describe cómo. Las pruebas y las observaciones registradas establecen si el resultado cumple los requisitos; ninguno de los documentos establece el éxito por sí solo.
Trabaja un requisito a la vez
Considera “permitir que los lectores agreguen feeds”. Es demasiado amplio para implementarlo o revisarlo de forma fiable.
- Nombra al usuario y el resultado: un lector quiere curar una lista local de suscripciones.
- Delimita el comportamiento: agregar y listar URL; sin obtención de red, cuentas ni sondeo.
- Elige un caso de aceptación: agregar dos veces la misma URL normalizada debe rechazarse.
- Indica la evidencia observable: la segunda operación devuelve un error y la lista sigue conteniendo una sola entrada.
- Identifica una elección sin resolver: si los fragmentos de URL participan en la unicidad.
- Resuelve esa elección antes de escribir el plan y las pruebas.
| Requisito débil | Reemplazo comprobable |
|---|---|
| La app debería ser inteligente y rápida | Nombra un flujo de trabajo específico y una restricción medida, o omite la afirmación de velocidad no admitida |
| Manejar todos los errores | Enumera los casos de vacío, malformado, duplicado y de propietario incorrecto que importen para este alcance |
| Agregar cargas seguras | Separa validación de archivos, propiedad, almacenamiento y manejo de malware; no llames “carga segura” al registro de metadatos |
| Modernizar sin romper nada | Nombra el resultado exacto, el orden, la precisión entera y los contratos de reversión que se deben preservar |
Plantilla mínima
| Sección | Contenido requerido |
|---|---|
| Problema y usuario | Quién necesita la capacidad y por qué |
| Alcance | Un flujo de trabajo principal y exclusiones explícitas |
| Aceptación | IDs, casos dado/cuando/entonces, observables esperados |
| Restricciones | Límites de datos, accesibilidad, compatibilidad, límites de recursos |
| Riesgos y preguntas | Incógnitas que deben resolverse antes de implementar |
| Evidencia | Comprobaciones y artefactos exactos; deja en blanco los resultados no ejecutados |
| Control de cambios | Quién acepta un cambio de alcance y cómo actualiza las pruebas |
Ejemplo A - Suscripciones RSS en un proyecto nuevo
Usuario: una persona que selecciona una pequeña lista local de suscripciones. Objetivo: añadir y listar URL de feeds sin recuperar contenido remoto. Excluido: autenticación, análisis de feeds, consultas periódicas, datos reales de usuarios y almacenamiento persistente.
| ID | Dado / cuando | Entonces |
|---|---|---|
| RSS-1 | Se añade una URL HTTPS válida de un feed | Devuelve un ID estable y lo conserva en el proceso actual |
| RSS-2 | Se añade dos veces la misma URL normalizada | Rechaza el duplicado; no crea otro registro silenciosamente |
| RSS-3 | Se añade una URL vacía, mal formada o que no sea HTTP(S) | La rechaza sin modificar la lista |
| RSS-4 | Se modifica la lista devuelta a quien llama | El almacén interno permanece sin cambios |
Ejemplo B - Metadatos de documentos en un proyecto existente
Usuario: un miembro del personal que busca documentos de proyectos en un panel existente. Objetivo: registrar primero los metadatos, preservando el contrato de estado de salud y proyectos. Excluido: cargas binarias, uso compartido público, análisis de malware y datos reales de empleados.
| ID | Dado / cuando | Entonces |
|---|---|---|
| DOC-1 | Se solicita el listado existente de proyectos | Conserva los IDs y la estructura de la respuesta |
| DOC-2 | Se registran metadatos válidos de un proyecto conocido | Devuelve un ID y permite listarlos para ese proyecto |
| DOC-3 | Se envía un proyecto inexistente o un título no válido | Devuelve un error documentado sin estado parcial |
| DOC-4 | Quien llama modifica los resultados del listado | Los metadatos almacenados no se modifican |
Ejemplo C - Modernizar un registro de pedidos
Usuario: un operador que depende de la salida JSON existente de la CLI. Objetivo: sustituir las lecturas de CSV por SQLite preservando el comportamiento observable. Excluido: nuevos precios, reglas de estado, endpoints HTTP, cuentas o datos de producción.
| ID | Dado / cuando | Entonces |
|---|---|---|
| MOD-1 | El almacenamiento antiguo y el nuevo leen el mismo fixture | Registros ordenados idénticos y totales en centavos enteros |
| MOD-2 | Se migra una fila no válida o duplicada | Fallo con código distinto de cero; ninguna base de datos parcial considerada exitosa |
| MOD-3 | Se vuelve a ejecutar la migración contra un destino existente | Rechaza la sobrescritura y conserva el archivo existente |
| MOD-4 | La reversión selecciona el lector CSV | El archivo y la salida originales siguen disponibles |
Elegir la pila tecnológica es una decisión de planificación
Mantén los mismos criterios de aceptación mientras comparas:
- .NET Minimal API y una pequeña interfaz de Blazor;
- Node/TypeScript y HTML/CSS nativo del navegador;
- Python y sus herramientas de almacenamiento de la biblioteca estándar;
net/httpde Go para una implementación independiente.
No afirmes que se ejecutaron todas las alternativas. Registra la pila elegida y las pruebas realmente ejecutadas. Consulta los laboratorios de Spec Kit para los flujos de implementación y modernización.
¿Listo para planificar?
- Se nombran un usuario y un flujo principal.
- Los no objetivos evitan generación no relacionada.
- Los IDs de aceptación describen resultados observables, no preferencias de implementación.
- Las entradas inválidas y los efectos secundarios de fallo son explícitos.
- La compatibilidad existente queda congelada donde corresponda.
- Las preguntas abiertas están resueltas o bloquean visiblemente la implementación.
- Los campos de evidencia permanecen en blanco hasta que las comprobaciones realmente se ejecuten.
Estos ejemplos son contratos iniciales compactos. Los laboratorios completos añaden sus propios requisitos y pruebas; no asumas que las cuatro filas de esta página los agotan.
| Anterior | Siguiente |
|---|---|
| Delimita un ejercicio | Elige un kit de laboratorio |