Del catálogo de requisitos al paquete de evidencias
Un mismo camino que tu equipo sigue en cada proyecto, desde la primera reunión hasta un cambio pedido meses después.
Catálogo
Escribe una sola vez las funcionalidades estándar de tu producto, con sus opciones y cuánto puede ajustar el cliente cada una. Lo haces una vez por producto, no por cliente.
FRD
Crea un proyecto y recoge sus requisitos en un FRD estructurado: no un archivo de Word, sino funcionalidades con un tipo y un identificador estable, activadas o desactivadas y rellenadas a partir de tu plantilla, más todo lo que sea específico del cliente.
Revisión y aprobación
Primero tu equipo lo aprueba internamente; después el cliente revisa la versión congelada exacta a través de un enlace seguro, sin necesidad de cuenta ni de puesto por su parte. Su decisión, junto con su identidad verificada con un código de un solo uso, pasa a ser el registro de aprobación de la aplicación.
Línea base y solicitudes de cambio
La versión aprobada queda fijada como línea base: el estado acordado, registrado. Cuando el cliente pide algo nuevo, abres una solicitud de cambio sobre esa línea base: un antes y un después claros, revisado y aprobado por separado, que luego se aplica para crear la siguiente línea base. Nada sobrescribe el historial.
Evidencias, siempre que las necesites
Cada versión tiene una huella de su contenido, cada aprobación es un registro de aprobación de la aplicación y cada paso queda en un registro de actividad encadenado con huellas que permite detectar cualquier alteración. En los planes que lo incluyen, exporta un paquete de evidencias —un único PDF— con la versión, su huella y las aprobaciones que la respaldan, para una auditoría del cliente, una disputa o tus propios archivos.
¿Prefieres una guía paso a paso? Lee las guías →