Por Thomas Cohen, fundador de Maestro
Documento de requisitos de una aplicación: guía, ejemplo y plantilla gratuita
Describe tu necesidad sin vocabulario técnico: usuarios, recorridos, reglas, datos y criterios de validación. Un ejemplo de reservas y una plantilla de texto gratuita para adaptar a tu proyecto.
El documento de requisitos de una aplicación describe el problema que hay que resolver, las personas implicadas y los resultados esperados. Ayuda a comparar propuestas y a comprobar lo construido. Puedes escribirlo sin conocer lenguajes de programación: tu primer trabajo consiste en explicar los usos, las reglas del negocio y lo que haría fracasar el proyecto.
Descarga o copia la plantilla gratuita del documento de requisitos. Este archivo de texto se abre en un navegador o editor y se puede copiar en Word o Google Docs. Incluye los apartados que hay que completar, una tabla de validación y un ejemplo ficticio. No se pide ningún email.
Empieza por el problema, no por las pantallas
Escribe la necesidad en una frase desde el punto de vista de quien la tiene. «Mis clientes deben poder reservar una hora sin llamarme» ofrece un objetivo más claro que «quiero un calendario moderno». Añade la situación actual: quién atiende las llamadas, dónde se apuntan las citas y qué errores se producen.
Define después cómo reconocerás una mejora. Para nuestro ejemplo ficticio de reservas, el objetivo podría ser que los clientes elijan entre los horarios publicados y que el responsable encuentre todas las reservas en un solo lugar. Los posibles objetivos numéricos deben partir de tu situación medida, no de una promesa encontrada en otra parte.
Describe los usuarios y sus recorridos
Nombra cada rol con sus permisos. El cliente consulta los horarios y reserva. El responsable abre disponibilidades y cancela una reserva. Un compañero puede consultar la agenda sin cambiar los horarios. Especifica si hace falta una cuenta y cómo recupera una persona su acceso.
Cuenta después el recorrido completo: una clienta abre la página, elige una hora, introduce sus datos de contacto, confirma y recibe un resumen. Plantea las preguntas que faltan: ¿qué ocurre si otra persona acaba de reservar? ¿Si falla el email? ¿Si quiere cancelar? Estas excepciones forman parte de la necesidad; no deberían descubrirse únicamente después de la entrega.
Escribe las reglas y los límites de la primera versión
En este ejemplo, cada franja admite una sola reserva y dura treinta minutos. El cliente puede cancelar hasta veinticuatro horas antes de la cita; después debe contactar con el responsable. Son decisiones ficticias para ilustrar el método, que debes sustituir por tus propias reglas.
Enumera también lo que quedará para más adelante: pago en línea, recordatorios por SMS, suscripción y aplicación móvil. Un sitio que funcione en el teléfono puede cubrir la primera necesidad. Cada idea nueva entra en una lista separada, con el motivo para añadirla. Así, el alcance sigue siendo comprensible tanto para ti como para quien construye.
Haz que cada requisito sea verificable
Un criterio de aceptación describe una situación inicial, una acción y el resultado observable. Para la reserva: dado un horario libre, cuando una clienta confirma con datos válidos, aparece una única reserva en la agenda y ese horario deja de ofrecerse.
Segundo criterio: cuando dos clientes intentan confirmar el mismo horario, solo uno obtiene la reserva; el otro recibe una explicación y puede elegir otra hora. Tercer criterio: un compañero autorizado solo para consultar no puede modificar la disponibilidad, ni siquiera intentando acceder directamente a la acción correspondiente.
Para un requisito de velocidad, indica la página, el dispositivo, la conexión y las condiciones de medición acordadas con quien realiza el proyecto. «Rápido» no se puede verificar; un umbral sin condiciones de prueba genera discusiones interminables. Asocia a cada criterio la persona que lo comprobará y una prueba esperada: ensayo descrito, captura o resultado registrado.
No olvides los datos y la operación
Describe la información que debe conservarse, su origen, quién puede consultarla y cuándo debe eliminarse. Indica los archivos que hay que recuperar y las conexiones necesarias. Si partes de un libro de cálculo, identifica las reglas ocultas en las columnas antes de sustituir Excel por una aplicación.
Especifica también quién será propietario de las cuentas de alojamiento, el dominio y el repositorio de código, quién recibirá las alertas y quién corregirá los incidentes. Pregunta cómo exportar los datos, restaurar una copia de seguridad y transferir el mantenimiento. Estas cuestiones influyen en el coste del proyecto tanto como las funcionalidades visibles.
Mantén vivo el documento sin complicarlo
Pon fecha a cada versión, anota las decisiones y mantén visibles las preguntas sin resolver. Antes de un cambio importante, pregunta por su efecto sobre los plazos, el presupuesto y los criterios de validación. Pide a quienes usarán realmente la aplicación que revisen los recorridos.
Puedes empezar con unas pocas páginas y completar la plantilla descargable a medida que lleguen las respuestas. Con un proveedor o dentro del recorrido de Maestro, este documento se convierte en una base para conversar y validar. Describe lo que quieres obtener; las decisiones técnicas vienen después para hacerlo posible.