Cómo documentar los requisitos de una app (con plantilla)

Saber cómo documentar los requisitos de una app es lo que separa un presupuesto comparable de una cotización a ciegas. Un documento de requisitos no tiene por qué ser largo ni técnico: es una descripción ordenada de qué tiene que hacer la app, para quién y cómo se va a saber que está bien hecha. Esta guía incluye una plantilla simple que podés copiar y completar.

Para qué sirve documentar

• Para que varios proveedores coticen lo mismo y puedas comparar (por qué varía el costo).
• Para evitar malentendidos entre lo que imaginaste y lo que se construye.
• Para decidir qué entra en la primera versión y qué espera.
• Para tener una base objetiva al momento de aceptar el trabajo.

No hace falta que esté perfecto antes de hablar con un desarrollador. Un buen borrador ya ahorra mucho tiempo, y puede mejorarse en conjunto.

Los bloques de un buen documento

1. Contexto y objetivo

Una o dos frases: qué problema resuelve la app y para quién. Si no lo podés explicar en pocas líneas, probablemente haga falta pensarlo más (ver validar una idea de app).

2. Tipos de usuario

Quiénes usan la app y qué los diferencia: clientes, empleados, administradores. Cada uno suele necesitar permisos y pantallas distintas.

3. Historias de usuario

Son frases cortas con un formato fijo que describen una necesidad desde la mirada de quien la tiene: «Como [tipo de usuario], quiero [acción] para [beneficio]». Por ejemplo: «Como cliente, quiero ver los horarios libres para elegir el que me queda cómodo». Obligan a pensar en el valor de cada función y no solo en la función.

4. Criterios de aceptación

Para cada historia, una lista de condiciones verificables. Responden a «¿cómo sabemos que está lista?». Por ejemplo: el usuario puede cancelar hasta cierto momento; si ya pasó, ve un mensaje que lo explica. Son la base de las pruebas de calidad.

5. Alcance: lo que entra y lo que no

Dejar escrito lo que queda fuera es tan útil como lo que entra. Evita suposiciones del tipo «pensé que eso venía incluido». Para decidir el recorte, la guía de qué es un MVP ayuda.

6. Prioridades

Marcá cada historia como imprescindible, deseable o para más adelante. Si hay que ajustar presupuesto o tiempo, ya sabés dónde recortar.

7. Restricciones y supuestos

Plataformas (Android, iOS, web), integraciones con sistemas que ya usás, requisitos legales o de facturación, datos que hay que migrar, fechas importantes para tu negocio.

Plantilla para copiar

Copiá este esquema en un documento de texto y completalo con tus datos. Los corchetes indican lo que hay que reemplazar.

1. Nombre del proyecto: [nombre provisorio]
2. Objetivo: [qué problema resuelve y para quién, en dos frases]
3. Usuarios: [lista de tipos de usuario y qué hace cada uno]
4. Funciones, por prioridad:

• Historia 1 (imprescindible): Como [usuario], quiero [acción] para [beneficio]. Criterios de aceptación: [condición 1]; [condición 2]; [qué pasa si algo falla].
• Historia 2 (deseable): Como [usuario], quiero [acción] para [beneficio]. Criterios de aceptación: [condiciones].
• Historia 3 (para más adelante): [descripción breve].

5. Fuera de alcance: [lo que no se hace en esta versión]
6. Plataformas: [Android / iOS / web / a definir]
7. Integraciones y datos existentes: [sistemas, planillas, medios de pago, correo, etc.]
8. Aspectos legales o de datos personales: [qué datos se guardan, de quién]
9. Referencias: [apps o pantallas que te gustan, y por qué]
10. Preguntas abiertas: [lo que todavía no sabés]

Consejos para que el documento sea útil

1. Describí el problema, no solo la solución. Si decís «necesito un botón verde», se pierde la razón; si decís «necesito que el cliente confirme rápido», se abren mejores opciones.
2. Usá tus palabras. Es mejor un texto simple y honesto que uno técnico mal usado.
3. Incluí ejemplos reales: una planilla actual, un formulario en papel, un mensaje que hoy mandás a mano.
4. Anotá las excepciones: descuentos, cancelaciones, clientes especiales. Ahí suelen estar los costos escondidos.
5. Pedí que te lo devuelvan reformulado. Si el proveedor lo explica con otras palabras y coincide, entendió.
6. Tratalo como un documento vivo, con fecha y versión, y con los cambios acordados por escrito.

Errores comunes

• Escribir una lista de funciones sin decir para quién ni por qué.
• Palabras vagas como «rápida», «moderna» o «intuitiva» sin criterio de cómo comprobarlas.
• Querer definir todo al detalle antes de empezar: alcanza con detallar bien lo primero y dejar lo demás como lista de ideas.
• No hablar de lo que pasa cuando algo sale mal.

Un documento claro también es la base del contrato; los puntos legales aparecen en propiedad del código y contrato, y las etapas siguientes en cómo crear una app. Si preferís armarlo con alguien, en nuestro proceso de trabajo la definición del alcance es el primer paso, y podés empezar desde el formulario de contacto.