Documento de requisitos de una app móvil: ¿qué debe definir una pequeña empresa antes de desarrollar?

Un documento de requisitos convierte una idea de negocio en un acuerdo con versiones sobre usuarios, flujos de trabajo, alcance, calidad, datos, integraciones, propiedad y aceptación. Le da al dueño del negocio y al equipo que desarrolla una base común para cotizar, priorizar, probar, decidir cambios y hacer un traspaso responsable después del lanzamiento.

Esta guía se centra en el documento de requisitos en sí. Complementa a los materiales de Le Website sobre alcance de la primera versión, calendario, roles del equipo, requisitos de backend y preparación del lanzamiento, sin sustituir esas decisiones.

¿Qué debe incluir el documento de requisitos de una app móvil?

Debe incluir el resultado de negocio, los usuarios objetivo, los recorridos principales, los requisitos funcionales, las reglas de datos e integraciones, las necesidades de seguridad y privacidad, la accesibilidad, el rendimiento, la analítica, las expectativas de soporte, la propiedad, las restricciones, las prioridades, los supuestos, las exclusiones, los criterios de aceptación, quién aprueba y cómo se gestionan los cambios. Cada afirmación importante debe ser lo bastante concreta como para cotizarla, construirla, probarla o rechazarla.

Un documento útil no es una lista de nombres de pantallas ni una maqueta bonita. Conecta el valor del negocio con comportamientos observables. Cada requisito debería responder por qué importa esa capacidad, quién la necesita, qué debe ocurrir, qué puede fallar, cómo se demostrará que está terminada y quién acepta esa evidencia.

Escriba decisiones, no aspiraciones

«La app debe ser fácil de usar» es una aspiración. «Un cliente que vuelve puede repetir un pedido anterior en tres pasos sin volver a escribir la dirección de entrega» se puede probar. Cambie los adjetivos vagos por usuarios, condiciones, acciones, límites, umbrales medibles y evidencia que el dueño del negocio pueda revisar.

Deje a la vista los supuestos y las exclusiones

Las cotizaciones suelen depender de supuestos sobre contenido, dispositivos, idiomas, integraciones, migración, cumplimiento y disponibilidad del personal. Anótelos junto a las exclusiones explícitas. Un supuesto callado se convierte en una solicitud de cambio inesperada; uno visible se puede verificar antes de que el precio o el calendario dependan de él.

¿Quién es dueño del documento, quién lo aprueba y quién lo mantiene?

Un responsable de producto del lado del negocio debe ser dueño de las prioridades y los resultados; los expertos en la materia validan los flujos; diseño, ingeniería, seguridad, analítica y operación revisan lo que les toca; y una sola persona con nombre aprueba el alcance. El documento debe seguir versionado, trazable y accesible aunque se vaya la agencia o el empleado que lo escribió.

Ser dueño no significa escribir cada línea. Significa que una persona responsable resuelve los conflictos, protege el resultado y deja registradas las decisiones. Una empresa pequeña puede trabajar con un equipo reducido, pero no puede repartir la responsabilidad hasta el punto de que nadie pueda aprobar un requisito ni frenar un atajo peligroso.

Use un mapa simple de responsabilidades

Para cada sección, nombre a quien decide, a quienes aportan, a quienes revisan y a quien aprueba al final. La guía de roles del equipo de desarrollo móvil explica cómo mantener explícitas las responsabilidades de producto, diseño, ingeniería, calidad, seguridad y operación aunque varias recaigan en la misma persona.

Versione el documento junto con el producto

Registre número de versión, fecha, quién editó, estado de aprobación, prototipo enlazado, preguntas abiertas e historial de decisiones. Los requisitos deben cambiar de forma deliberada a medida que el equipo aprende. Un archivo estático enviado por correo antes de empezar deja de ser confiable muy rápido frente al código, el backlog y las conversaciones que lo reemplazaron.

¿Cómo se definen los usuarios, los roles y sus tareas?

Describa grupos de usuarios reales, sus objetivos, su contexto de trabajo, con qué frecuencia lo hacen, con qué dispositivos, con qué conectividad, en qué idioma, con qué necesidades de accesibilidad, con qué permisos y qué pasa si se equivocan. Separe clientes, personal, encargados, administradores, agentes de soporte y socios externos cuando sus capacidades difieran. Priorice según tareas valiosas y limitaciones observadas, no solo por etiquetas demográficas.

Un perfil de usuario ayuda a recordar el contexto, pero no debe volverse decoración ficticia. Acompañe cada rol con tareas concretas, los apaños que usan hoy, la información que necesitan, los errores de alto riesgo y la evidencia de éxito. Un técnico en campo, un encargado de tienda, un paciente, un repartidor y un cliente pueden exigir comportamientos muy distintos en cuanto a trabajo sin conexión, privacidad, velocidad y soporte.

Defina los permisos junto a los objetivos

Para cada rol, liste qué registros puede ver, crear, modificar, aprobar, exportar o eliminar. Incluya los límites por organización, sucursal, equipo y propiedad del registro. Los requisitos deben describir qué ocurre cuando cambian los accesos, cuando alguien deja la empresa, cuando se pierde un dispositivo o cuando una acción privilegiada necesita revisión.

Documente pronto los contextos difíciles

Identifique conectividad baja, dispositivos compartidos, pantallas pequeñas, sistemas operativos antiguos, uso a pleno sol, tecnología de apoyo, sesiones interrumpidas y trabajo con plazos ajustados, según corresponda. Esas condiciones cambian la navegación, el almacenamiento, la sincronización, la autenticación, las notificaciones y las pruebas. Son requisitos de producto, no ajustes estéticos de última hora.

¿Cómo se describen los recorridos y el alcance de las funciones?

Trace cada recorrido prioritario desde el disparador hasta el resultado confirmado, incluidos requisitos previos, decisiones, caminos alternativos, errores, recuperación, notificaciones y registros que se generan después. Luego conecte las funciones a esos recorridos en lugar de mantener una lista de deseos suelta. Una función entra en el alcance solo cuando sostiene un resultado con nombre o una obligación operativa.

Empiece por el flujo completo más pequeño que ya entregue valor. Una función de reservas puede necesitar disponibilidad, identidad, confirmación, cancelación, recordatorios, visibilidad para el personal y conciliación; una sola pantalla de calendario no es la capacidad completa. Los mapas de recorrido sacan a la luz dependencias que un simple inventario de pantallas esconde.

Separe el alcance de esta entrega de la visión del producto

Mantenga en secciones distintas la visión a largo plazo, la primera entrega, los candidatos posteriores y las ideas descartadas. La guía de planificación de la primera versión muestra cómo elegir un flujo estrecho pero completo en lugar de entregar fragmentos sueltos de muchas funciones futuras.

Que cada pantalla se pueda rastrear hasta un recorrido

Toda pantalla propuesta debe sostener uno o más pasos del recorrido, estados del sistema, permisos o acciones de recuperación. Una pantalla sin propósito rastreable probablemente sobra. Un recorrido sin pantalla, mensaje, acción en segundo plano o proceso del personal suele revelar un requisito que falta, no un problema de diseño.

¿Cómo se escriben los requisitos funcionales y los criterios de aceptación?

Escriba los requisitos funcionales como comportamientos observables bajo condiciones definidas, y añada criterios de aceptación que cubran el éxito, la validación, los permisos, los errores, los reintentos, los estados vacíos, las acciones duplicadas y la recuperación. Use identificadores consistentes para que los requisitos se conecten con diseños, tareas, pruebas, versiones y decisiones. Evite imponer la implementación salvo que una restricción real lo exija.

Un patrón útil es: dado un estado inicial conocido, cuando un usuario concreto realiza una acción, entonces el sistema produce un resultado específico. Añada ejemplos para los límites y los fallos. Los requisitos no necesitan formalidad teatral; necesitan la precisión suficiente para que dos revisores capacitados lleguen a la misma conclusión.

Defina qué significa «terminado», con evidencia

Especifique qué dispositivos, entornos, cuentas, conjuntos de datos, integraciones y revisores hacen falta para aceptar. La evidencia puede ser pruebas automáticas, demostraciones grabadas, resultados de accesibilidad, respuestas de la API, eventos de analítica, compilaciones de tienda, simulacros de restauración o reportes conciliados. «El desarrollador dice que está listo» no es un método de aceptación independiente.

Incluya validación y recuperación

Documente campos obligatorios, formatos, rangos, duplicados, conflictos, zonas horarias, permisos y mensajes visibles para el usuario. Indique qué queda guardado si se interrumpe la sesión y cómo continúa la persona. El camino feliz suele consumir el mínimo de soporte; lo que genera incidentes caros después del lanzamiento es un comportamiento ambiguo ante el fallo.

¿Qué requisitos no funcionales debe definir una pequeña empresa?

Defina expectativas medibles de rendimiento, disponibilidad, fiabilidad, trabajo sin conexión, escalabilidad, compatibilidad, accesibilidad, idiomas, seguridad, privacidad, mantenibilidad, observabilidad, respaldo, recuperación y soporte. Aplique umbrales a los recorridos críticos y a dispositivos y redes realistas. Palabras genéricas como rápido, escalable, seguro o intuitivo no se pueden aceptar ni cotizar de forma consistente.

No toda app necesita metas extremas. Un lector de códigos en bodega, un marketplace público, una herramienta interna de aprobaciones y una app de citas tienen consecuencias distintas cuando van lentas o se caen. Elija los umbrales según el impacto en el negocio y el uso real, e identifique quién los mide y bajo qué condiciones de carga, dispositivo, conectividad y dependencias.

• Fije tiempos de respuesta objetivo para las acciones más valiosas.
• Defina qué versiones de sistema operativo, tamaños de pantalla y capacidades de dispositivo se soportan.
• Indique qué flujos siguen disponibles sin conexión y cómo se resuelven los conflictos.
• Exprese en términos de negocio las expectativas de respaldo, restauración y recuperación del servicio.
• Defina la evidencia de mantenibilidad: pruebas, documentación, despliegue automatizado y registro de dependencias.

Las guías de calidad de apps de Android recogen las expectativas vigentes de Google en valor para el usuario, calidad técnica, privacidad y seguridad. La guía de plataforma es un piso mínimo, no un sustituto de los umbrales y la evidencia propios de su producto.

Priorice la calidad según la consecuencia

Clasifique los flujos como críticos, importantes o convenientes. Una imagen promocional que tarda y un cobro duplicado no merecen la misma respuesta. Esa clasificación guía la profundidad de las pruebas, el monitoreo, la reversión, la redundancia, el escalamiento de soporte y la inversión, sin fingir que cada función necesita infraestructura de misión crítica.

¿Cómo se conectan los requisitos de datos, backend e integraciones?

Liste las entidades importantes, los sistemas que mandan sobre ellas, los campos, las relaciones, los estados del ciclo de vida, la retención, el borrado, la exportación, la sincronización y las necesidades de auditoría. Para cada integración defina propósito, propiedad, autenticación, límites, webhooks, reintentos, manejo de duplicados, conciliación, comportamiento en entorno de prueba, mensajes de fallo y plan de salida. Las pantallas, las reglas del servidor y las plataformas conectadas tienen que coincidir.

El documento debe identificar las interfaces y el comportamiento del negocio sin cerrar prematuramente cada decisión técnica. La guía de requisitos del backend de una app móvil profundiza en contratos de API, sistema que manda sobre cada dato, autenticación, fiabilidad, despliegue, monitoreo y recuperación.

Defina la fuente de verdad

Indique si manda el backend de la app, el CRM, el ERP, la pasarela de pagos, la plataforma de citas u otro sistema sobre cada registro. Documente las reglas de conflicto y los tiempos. Sin una fuente autorizada, el mismo cliente, pedido, artículo de inventario o cita puede terminar con estados contradictorios entre la app y las herramientas del personal.

Describa el fallo de una integración como un estado visible

Cuando un proveedor de pagos, mapas, mensajería, identidad o CRM va lento, defina el comportamiento en los estados pendiente, confirmado, fallido, revertido y desconocido. Especifique qué ve el usuario, si es seguro reintentar, quién recibe las alertas y cómo la conciliación resuelve la incertidumbre. «Conectado a la API» no completa el requisito.

¿Qué requisitos de seguridad, privacidad y accesibilidad van en el documento?

Documente clasificación de datos, permisos mínimos, autenticación, autorización, cifrado, gestión de secretos, registros, retención, borrado, respuesta a incidentes, acceso de proveedores, desarrollo seguro y verificación. Añada las obligaciones legales o contractuales que apliquen y los criterios de accesibilidad de los recorridos soportados. Los requisitos deben reflejar los datos, usuarios, geografía, sector y riesgo reales, no etiquetas de cumplimiento copiadas.

El marco de desarrollo de software seguro del NIST organiza las prácticas de preparación, protección, producción segura y respuesta a vulnerabilidades. Úselo como insumo de planificación y evidencia, e involucre a especialistas legales, de privacidad, accesibilidad o seguridad cuando el riesgo del producto lo justifique.

Las Pautas de Accesibilidad para el Contenido Web 2.2 ofrecen criterios verificables que sirven de referencia también en móvil, y la guía de accesibilidad de Apple describe las consideraciones propias de la plataforma. Defina qué criterios aplican, cómo se probarán los controles nativos y las tecnologías de apoyo, y quién acepta los resultados.

Conecte cada dato sensible con un propósito

Para cada campo personal o confidencial, registre por qué se necesita, de dónde viene, por dónde viaja, quién puede verlo, cuánto tiempo se queda y cómo funcionan el borrado y la exportación. Incluya registros del sistema, analítica, reportes de fallos, exportaciones de soporte, respaldos y copias de prueba.

Pruebe la accesibilidad en recorridos completos

El contraste y las etiquetas importan, pero la aceptación debe cubrir tareas completas con teclado o conmutador cuando aplique, lectores de pantalla, escalado de texto, orden de foco, ajustes de movimiento, identificación de errores y lenguaje claro. Pruebe en dispositivos y sistemas representativos, no solo dentro de un archivo de diseño estático.

¿Cómo se especifican la analítica, la operación y el soporte?

Defina qué decisiones debe sostener la analítica, los nombres de los eventos, sus propiedades, el comportamiento del consentimiento, los límites de identidad, la validación, la propiedad, la retención y los reportes. Por separado, defina el monitoreo operativo, los registros, las alertas, la severidad, el escalamiento, el mantenimiento, quién publica versiones, los canales de soporte, los tiempos de respuesta y la comunicación de incidentes. Medir el producto y vigilar la salud del sistema resuelven problemas distintos y necesitan evidencias distintas.

Empiece con un plan de medición corto, atado al resultado de negocio. Registre inicios de recorrido, avances significativos, finalizaciones, abandonos, estados de error y resultados posteriores cuando sea lícito y útil. Evite registrar cada toque sin un responsable que use ese dato; el ruido aumenta la exposición de privacidad y rara vez mejora el producto.

Defina el soporte antes de lanzar

Documente quién recibe los reportes de los usuarios, qué detalles de diagnóstico hacen falta, las categorías de triaje, los tiempos de respuesta esperados, las rutas de escalamiento, la vigilancia de reseñas en las tiendas y los límites fuera de horario. La lista de verificación para lanzar una app móvil conecta la preparación del soporte con la privacidad, la analítica, el envío a tiendas y el monitoreo posterior.

Que cada alerta lleve a una acción

Toda alerta necesita un umbral, un responsable, un canal, una severidad, un manual de respuesta y una señal de resolución. Vigile los flujos de negocio completados, las colas de integración, los fallos de autorización, los cierres inesperados, la latencia, la conciliación de datos, los respaldos y las publicaciones. Un buzón lleno de avisos sin leer no es un control operativo.

¿Cómo se priorizan los requisitos y se controlan los cambios?

Priorice por valor para el usuario, impacto en el negocio, riesgo, dependencias, confianza y esfuerzo; luego marque qué entra en la versión comprometida, qué queda como candidato y qué se excluye. Canalice los cambios a través de un responsable que registre el motivo, el impacto en la estimación, los tiempos, los cambios de aceptación y la aprobación. El documento debe permitir aprender sin dejar que el alcance crezca a escondidas.

Etiquetas simples como imprescindible, deseable, opcional y ahora no funcionan bien si el equipo las define de forma consistente. La disciplina crítica es hacer visible el intercambio. Agregar una función puede afectar datos, permisos, pantallas, integraciones, pruebas, analítica, capacitación, soporte, calendario y costo; no es «una tarjeta más» en el tablero.

Exija un análisis de impacto antes de aprobar

Para cada cambio propuesto, identifique el resultado para el usuario y qué requisitos, diseños, datos, integraciones, riesgos, pruebas, documentación, calendario y precio se ven afectados. Así el responsable de producto puede aceptar, aplazar, intercambiar o rechazar con la foto completa, en vez de aprobar desde una captura de pantalla o un mensaje de chat.

Lleve una bitácora de decisiones

Registre las decisiones importantes, la fecha, el responsable, las alternativas, el motivo, los requisitos afectados y el seguimiento. Una bitácora breve evita que el equipo reabra debates ya cerrados y ayuda a quien opere el producto en el futuro a entender por qué se comporta así. También distingue un cambio aprobado de una sugerencia informal.

¿Cómo ayuda el documento a cotizar y a comparar propuestas?

Entregue a todos los que coticen los mismos resultados aprobados, recorridos, alcance, supuestos, restricciones, metas de calidad, integraciones, entregables, evidencia de aceptación, condiciones de propiedad y preguntas abiertas. Pídales que declaren exclusiones, dependencias, roles del equipo, lógica del calendario, proceso de cambios, modelo de soporte y base del precio. Con insumos comparables las propuestas son más útiles y la incertidumbre sale a la luz temprano.

Un documento detallado no garantiza un precio cerrado cuando el descubrimiento sigue incompleto. Lo que hace es volver visible la incertidumbre. Los proveedores pueden separar alcance confirmado, trabajo de validación, opciones, provisiones y riesgos, en vez de esconder supuestos dentro de un total atractivo. Compare razonamiento y evidencia, no solo horas o una cifra final.

Pida los entregables operativos

Incluya código fuente, repositorios, diseños, contenido, esquemas de datos, documentación de la API, registros de infraestructura, pruebas, plan de analítica, instrucciones de publicación, acceso a las tiendas, cuentas de proveedores, manuales de operación, limitaciones conocidas y capacitación cuando aplique. La entrega está incompleta si el negocio recibe una app pero no puede operarla ni transferirla.

Conecte el alcance con un calendario realista

El calendario de desarrollo de una app móvil explica cómo los requisitos, el diseño, la implementación, las pruebas, la revisión de las tiendas y las dependencias del lanzamiento afectan la entrega. Una estimación debe mostrar fases, fechas límite de decisión, insumos del cliente, ventanas de validación e incertidumbre, en lugar de una única fecha sin explicación.

Preguntas frecuentes sobre el documento de requisitos de una app móvil

Las dudas más comunes son quién escribe el documento, qué extensión debe tener, si un prototipo puede sustituirlo, cuándo se vuelve confiable una estimación y si los requisitos pueden cambiar. La respuesta práctica es documentar suficientes decisiones verificables para el riesgo del producto, manteniendo explícitos la propiedad, las versiones, la evidencia y los intercambios.

¿Quién escribe el documento de requisitos?

Normalmente lo posee un responsable de producto, mientras que usuarios, expertos en la materia, diseñadores, ingenieros, especialistas de calidad, revisores de seguridad, responsables de analítica y personal de operación aportan las decisiones que les competen. Una agencia puede facilitar y redactar el documento, pero el negocio debe validar los flujos, las prioridades, las restricciones y las responsabilidades de aceptación.

¿Qué extensión debe tener?

No existe un número correcto de páginas. Un flujo interno acotado puede necesitar un documento breve con diagramas y criterios de aceptación; un producto regulado con varios roles necesita más detalle. Juzgue la integridad por la cobertura de decisiones, la trazabilidad, la verificabilidad y el traspaso operativo, no por el largo, las secciones de la plantilla ni la cantidad de capturas.

¿Un prototipo puede sustituir a los requisitos escritos?

No. Un prototipo aclara distribución, navegación, contenido e interacciones, pero rara vez define permisos, validaciones, autoridad sobre los datos, integraciones, trabajo sin conexión, seguridad, analítica, rendimiento, recuperación, propiedad o soporte. Enlace los prototipos con los requisitos escritos y sus criterios de aceptación para que la intención visual y el comportamiento del sistema no se separen.

¿Cuándo es confiable una estimación?

Cuando se entienden los recorridos prioritarios, el alcance, los supuestos, las integraciones, las metas de calidad, la evidencia de aceptación, las responsabilidades del cliente y los riesgos abiertos. Las estimaciones tempranas deben ser rangos con incertidumbre declarada. Una cifra precisa construida sobre requisitos sin resolver no es más confiable por tener menos decimales.

¿Pueden cambiar los requisitos una vez iniciado el desarrollo?

Sí. El descubrimiento, las pruebas, la reacción del mercado, las reglas de las plataformas y las restricciones técnicas pueden justificar un cambio. Registre la decisión y evalúe sus efectos en alcance, diseño, datos, integraciones, seguridad, pruebas, calendario y precio. El cambio controlado mejora el producto; el cambio no documentado esconde los intercambios y vuelve arbitraria la aceptación.

¿Cuál es el siguiente paso para crear el documento?

Haga un taller acotado de requisitos, valide con personas reales los recorridos de mayor valor, registre supuestos y exclusiones, defina la evidencia de aceptación y resuelva las preguntas más riesgosas antes de pedir propuestas finales. Después versione el documento aprobado, asigne su propiedad, conéctelo con los entregables y mantenga una bitácora de decisiones durante todo el desarrollo.

Si su negocio necesita un documento de producto, un taller de requisitos, un prototipo, un plan de arquitectura o una estimación, revise el servicio de desarrollo de aplicaciones a medida de Le Website y escríbanos. Podemos convertir la idea en un alcance con responsables antes de que unos requisitos ambiguos se traduzcan en retrabajo caro.

Revisado el 22 de agosto de 2026. Próxima revisión de contenido prevista: 22 de febrero de 2027.