Cómo redactar un documento de requisitos de productos para aplicaciones móviles

En este artículo, hablaremos sobre el papel fundamental de los requisitos en el desarrollo de aplicaciones móviles. ¿Cuáles son los tipos de requisitos y cuál es la forma correcta de desarrollarlos? Desplácese hacia abajo y obtenga una muestra del documento de requisitos de la aplicación móvil para ayudarlo a comenzar.

Contenido:

1. ¿Por qué debería redactar un documento de requisitos de productos de aplicaciones móviles?
2. Tipos de requisitos
3. Requisitos comerciales
4. Requisitos de usuario
5. Requisitos del sistema
6. Formas de desarrollar y gestionar requisitos
7. Características de un buen documento de requisitos de desarrollo de aplicaciones móviles
8. Una plantilla de documento de requisitos de aplicaciones móviles

¿Por qué debería redactar un documento de requisitos de productos de aplicaciones móviles (PRD)?

Para convertir su idea en una aplicación móvil que se pueda enviar, necesita un equipo de desarrolladores. Pero encontrar el equipo adecuado no es la parte difícil. La parte difícil es explicar la visión de su aplicación móvil a los desarrolladores con tanta claridad que la conciban como usted.

Escribir un documento de requisitos de productos de aplicaciones móviles (PRD) lo ayuda a facilitar un encuentro de mentes entre usted y otras partes interesadas . No se niegue a invertir tiempo en los requisitos de los productos de ingeniería, porque la recompensa potencial es clara.

• Aumente su propia certeza. Discutir los requisitos para su aplicación móvil aclara todo. Objetivos, perspectivas, características, limitaciones: la visión de su producto comienza a tomar forma. La determinación de los requisitos del producto lo lleva de declaraciones borrosas a tareas tangibles con plazos, presupuestos y criterios de calidad detallados.

• Deja claras tus ideas a los desarrolladores. Los requisitos claros del producto reducen la brecha de expectativas entre la aplicación móvil que desea y lo que ofrecen los desarrolladores.

• Obtenga un desarrollo y una entrega rápidos. Con los requisitos documentados de las aplicaciones móviles a la vista, su equipo de desarrollo puede comprender mejor su proyecto, establecer prioridades y reducir la repetición de trabajos.

• Asegúrese de que la aplicación final cumpla con sus expectativas de calidad. Gracias a los criterios de aceptación establecidos en un PRD, su equipo puede determinar fácilmente si estará satisfecho con la aplicación entregada.

• Reducir la fluencia del alcance. Una especificación de requisitos de alta calidad evita que desarrolle funciones innecesarias, evita que su equipo de desarrolladores trabaje con propósitos cruzados y evita que todo su equipo de desarrollo se sobrecargue.

• Gastar menos. Dado que los requisitos bien pensados ​​contribuyen a centrarse en lo esencial, reducen la repetición de trabajos y aceleran el desarrollo, le permiten ahorrar dinero.

Según la investigación de Boehm, la reelaboración puede costar entre el 40% y el 50% del costo total de todo el desarrollo de software. Y una gran parte del reproceso se debe a errores de requisitos.

Otra ventaja de los requisitos claros es que permiten a su equipo detectar defectos poco después de la creación de un producto y solucionarlos a un costo menor que en el desarrollo tardío o después del lanzamiento de la aplicación. Por lo tanto, tome los requisitos de desarrollo no como un desperdicio y un asunto frustrante, sino como una inversión en su proyecto que dará sus frutos con creces .

Tipos de requisitos

Cuando tenga una idea para hacer una aplicación, debe hacerse tres preguntas principales:

• ¿Por qué? ¿Por qué necesitas una aplicación móvil? Para ayudar a las personas con su experiencia única, obtenga un flujo de ingresos adicional, como inversión, ¿cuál es su objetivo?
• ¿Quién? ¿Quién usará tu aplicación? Piense en los dolores, problemas, necesidades y preferencias de sus usuarios objetivo. ¿Qué solución esperan los usuarios obtener de su aplicación?
• ¿Cómo? ¿Cómo logrará los resultados comerciales deseados y cumplirá con las expectativas de los usuarios? Piense en la funcionalidad que debería proporcionar su aplicación.

Las respuestas a estas preguntas forman tres niveles principales de requisitos para el desarrollo de aplicaciones móviles: requisitos comerciales, requisitos del usuario y requisitos del sistema.

Cada nivel también tiene una variedad de requisitos funcionales y no funcionales.

Los requisitos funcionales se relacionan con el funcionamiento de su aplicación y las características que va a implementar.

Los requisitos no funcionales definen características y limitaciones que no están relacionadas con los requisitos funcionales. En la mayoría de los casos, los requisitos no funcionales se relacionan con:

• Atributos del producto desarrollado como rendimiento, confiabilidad, disponibilidad y usabilidad.
• El proceso de desarrollo , describiendo metodologías de desarrollo, estándares, lenguajes de codificación, restricciones de tiempo, seguridad, etc.
• El entorno externo , teniendo en cuenta la conexión de su aplicación con otros sistemas y componentes de hardware, la alineación con la política corporativa, las regulaciones gubernamentales, etc.

Si le preocupa cómo escribir especificaciones para el desarrollo de aplicaciones móviles, comience por obtener los requisitos de su negocio.

Requisitos comerciales

Al redactar los requisitos de su negocio, concéntrese en las razones por las que la creación de una aplicación móvil es esencial para su negocio, los cambios que implicará la aplicación y los resultados que espera que produzca. Para mantener clara la visión de su producto para su empresa de desarrollo, debe registrar sus requisitos comerciales en un documento de requisitos comerciales de aplicaciones móviles (BRD) .

Tenga en cuenta que, aunque utilizamos el término "documento", no es necesario que sea una hoja de papel impresa o un documento de Google. Puede almacenar sus requisitos mediante diagramas, bases de datos, hojas de cálculo o herramientas de gestión de requisitos, o puede combinarlos con un documento de texto tradicional.

Con base en el documento de visión y alcance propuesto por Karl Wiegers en la tercera edición de Requisitos de software , hemos preparado la siguiente estructura BRD:

Puede representar el alcance de su proyecto utilizando diferentes herramientas. El más completo es un lienzo magro . Representa los segmentos de un plan de negocios cruciales para desarrollar documentación para todas las aplicaciones móviles: grupos de usuarios y sus principales problemas, soluciones que brindará su aplicación junto con una propuesta de valor única (UVP) y otras ventajas. En el modelo de lienzo ajustado, puede describir los canales que utilizará para atraer usuarios objetivo y métricas clave que le dirán cómo le está yendo a su negocio. Un lienzo ajustado también lo ayuda a determinar el modelo de monetización para su aplicación móvil junto con otras posibles fuentes de ingresos.

Para fomentar una comunicación clara entre todas las partes interesadas del proyecto, en Mind Studios, también utilizamos un mapa mental . Esta herramienta refleja la lógica de una aplicación móvil y las interconexiones entre sus componentes principales.

Aquí hay un ejemplo simple de un mapa mental para una aplicación de meditación como Headspace:

Recuerde que la redacción de requisitos comerciales involucra a todos los actores del proyecto. Siempre es un esfuerzo conjunto.

Requisitos de usuario

Después de identificar los requisitos de su negocio, es hora de centrarse en las necesidades de sus usuarios. Debe describir los posibles objetivos con los que los usuarios acceden a su aplicación y las acciones que llevarán a cabo para alcanzarlos. Pero, ¿qué opinión debería tener en cuenta al redactar los requisitos de los usuarios?

El problema es que no existe un único tipo de usuario de la aplicación. Por el contrario, hay muchos tipos de usuarios que piden diferentes cosas: inversores, empresarios, usuarios finales, desarrolladores, distribuidores, reguladores, personal de marketing y otros. Su tarea es escuchar a todos y encontrar el equilibrio entre las necesidades de los diferentes grupos de usuarios.

Cuando se trata de los requisitos del usuario, es sensato comenzar con estos tres pasos:

Paso 1: clasifica a los usuarios. Agrupe a todas las partes interesadas en clases de usuarios. Puede ordenarlos según los siguientes criterios:

• Nivel de acceso (invitado, usuario habitual, usuario de pago, proveedor, administrador)
• Tareas que realizan (buscar, ver, leer, seleccionar, comprar, compartir, comentar)
• Las funciones de la aplicación que utilizan (búsqueda, mapeo, clasificación, comparación, pago, etc.)
• Frecuencia de visitas (diaria, mensual)
• Plataformas utilizadas (iOS o Android)
• Idioma nativo (u otros datos demográficos como ubicación, género, educación y estado familiar).

Paso 2 : identifica a los campeones del producto. Elija personas que puedan representar a cada grupo de usuarios y comunicar los requisitos de los usuarios a su gerente de proyecto. Ser un buen campeón de productos significa tener una visión clara de los beneficios que su aplicación brindará a los usuarios. A su vez, los campeones del producto deben ser usuarios reales para comprender perfectamente los dolores y las necesidades urgentes de los usuarios.

Paso 3 - Acuerde los requisitos de los tomadores de decisiones para su proyecto. Acordar representantes de cada grupo de usuarios con las partes interesadas. Tenga cuidado de no pasar por alto a ninguna parte interesada para evitar quejas de que la aplicación final no cumple con las expectativas de una parte interesada.

Después de identificar a los representantes de los usuarios elegibles, obtenga su opinión sobre dos tipos de requisitos de los usuarios.

Registre los comentarios de los usuarios en un documento de requisitos de usuario (URD) . Para hacer esto, puede utilizar las siguientes técnicas:

Una persona de usuario es una herramienta útil que le permite visualizar a sus usuarios objetivo. Para cada persona de usuario, elija un nombre y una foto, luego enumere las necesidades, deseos y objetivos del usuario. Escribe las razones clave por las que la persona usará tu aplicación. Aquí hay un ejemplo de una persona de usuario que creamos para una aplicación de redes sociales como LinkedIn:

Historias de usuarios. Detallar las acciones que los usuarios realizarán dentro de su aplicación para alcanzar sus objetivos. Luego, organice estas acciones en una secuencia natural para determinar el viaje típico del usuario a través de su aplicación. Dependiendo del alcance de su proyecto, puede describir principalmente épicas: acciones de usuario intrincadas que puede descomponer en pasos más pequeños que los usuarios tomarán mientras usan su aplicación. Las epopeyas son historias de usuarios que tienden a escribirse de la siguiente manera: Como <tipo de usuario>, quiero <algún objetivo> para que <algún motivo>.

En el desarrollo ágil, las historias de usuario a menudo se incluyen en una cartera de productos. Al negociar el alcance del desarrollo de software para la primera versión y las posteriores, usted y su equipo de desarrollo considerarán las historias de los usuarios de la lista de trabajos pendientes y seleccionarán las más relevantes. Al organizar las historias de usuario, puede crear una hoja de ruta del producto que defina claramente qué funciones de la aplicación debe implementar y cuándo. El siguiente ejemplo está relacionado con las dos epopeyas básicas más comunes para cualquier aplicación móvil:

Requisitos del sistema

Un documento completo de requisitos de producto para una aplicación móvil debe contener requisitos sobre cómo debe funcionar su aplicación. Resista la tentación de escribir apresuradamente los requisitos del sistema basándose únicamente en los deseos de los usuarios y las necesidades comerciales. Habla con los desarrolladores. Le darán comentarios sobre si es técnicamente posible realizar sus planes originales para la funcionalidad de la aplicación. Al hablar con los desarrolladores, revelará las amenazas potenciales al desarrollo de su proyecto y podrá establecer colectivamente un plan B para eludirlas.

Después de un diálogo constructivo con su equipo, escriba los requisitos acordados en una especificación de requisitos de software (SRS) que contenga los siguientes bloques:

Requisitos del sistema
Requerimientos funcionales	Enumere las funciones que los desarrolladores pueden crear para permitir a los usuarios completar tareas de acuerdo con los requisitos de su negocio. Para hacer esto, use mapas mentales o historias de usuarios existentes. Después de definir lo que hará su aplicación, asigne un nombre y número únicos a cada requisito funcional junto con una breve descripción, justificación y estado.
Requisitos del subsistema	Describa los requisitos de su aplicación móvil desde la perspectiva de los subsistemas de software y hardware. Por ejemplo, si va a crear una aplicación de seguimiento de la actividad física, deberá escribir requisitos para los rastreadores portátiles que se sincronizarán con la aplicación.
Reglas del negocio	Dado que todas las empresas están sujetas a leyes, políticas y estándares de la industria, estas serán fuentes obvias de requisitos para un SRS. Aquí hay una lista corta de fuentes de requisitos: Política corporativa Regulaciones gubernamentales Estándares de la industria Roles de usuario y calificaciones de permisos Modelos si-entonces de comportamiento del usuario Algoritmos computacionales, si los hay
Requerimientos de datos	Al desarrollar una aplicación móvil, debe crear, almacenar, modificar, mostrar, eliminar, procesar y utilizar cantidades masivas de datos. Para administrar los flujos de datos, debe: esbozar un modelo lógico de interacciones entre entidades de datos definir entidades en el diccionario de datos especificar cómo el sistema debe hacer cumplir el análisis, la retención o la eliminación de datos elegir tipos de informes de datos (hojas de cálculo, gráficos, cuadros de mando, etc.)
Atributos de calidad	Escribir criterios de calidad claros asegura que los desarrolladores cumplirán sus expectativas con el producto final. Debe considerar los atributos de calidad que son importantes para: su empresa y usuarios, como usabilidad, rendimiento y seguridad ( atributos externos ) desarrolladores, como eficiencia, modificabilidad y portabilidad ( atributos internos ) Analice qué atributos son fundamentales para el éxito de su aplicación con otras partes interesadas y déles prioridad. Escriba expectativas específicas para cada atributo utilizando criterios de ajuste : una cuantificación del requisito que describe el estándar que debe alcanzar su aplicación. Traduzca los atributos de calidad en especificaciones técnicas y escriba pruebas de aceptación para su equipo que les permitan verificar los resultados.
Interfaces externas	Esta parte de un documento de requisitos funcionales para una aplicación móvil es necesaria para garantizar que su aplicación se comunique correctamente con los usuarios y los sistemas de hardware o software externos. En un SRS, debe anotar los requisitos para: Interfaces de usuario. Especifique el diseño de las pantallas de su aplicación móvil (estándares para fuentes, íconos, esquemas de color, imágenes, tamaño de pantalla, diseño, resolución, etc.) Interfaces de software. Describa las interacciones entre su aplicación y otros componentes de software, incluidas otras aplicaciones, sitios web, bibliotecas, bases de datos y herramientas. Interfaces de hardware. Describa cada uno de los tipos de dispositivos admitidos, las interacciones de control y datos entre el software y el hardware, y los protocolos de comunicación que se utilizarán. Interfaces de comunicaciones. En un SRS para su aplicación móvil, indique los requisitos para las funciones de comunicación que utilizará su aplicación, incluidos los mensajes dentro de la aplicación, las notificaciones automáticas, los correos electrónicos y los protocolos de red.
Restricciones	Registre las restricciones que restringen el diseño, el funcionamiento y la implementación de su aplicación móvil. En primer lugar, compruebe si la especificación de requisitos de su aplicación móvil se alinea con los requisitos de Apple App Store y Google Play Store. Además, especifique otras restricciones del sistema impuestas, por ejemplo, por el lenguaje de programación utilizado o las reglas de uso de API o contenido de terceros.
Requisitos de localización	Si desea que su aplicación se use en países, culturas y ubicaciones geográficas que difieren de aquellos en los que se creó, debe establecer requisitos para cambiar: Divisa Formatos de fecha, número, dirección y número de teléfono Idioma (incluidas las convenciones ortográficas nacionales, dialectos locales, direcciones) Funcionalidad para cumplir con regulaciones y leyes. Contenido en consideración de cuestiones culturales y políticas Zonas horarias Pesos y medidas Otras variables

Echemos un vistazo más de cerca a las herramientas que puede utilizar para representar los requisitos del sistema en la especificación de requisitos de software para una aplicación móvil.
Las hojas de cálculo ofrecen una presentación tradicional en filas y columnas de la funcionalidad de la aplicación que desea crear. Revisemos un fragmento de la hoja de cálculo de requisitos funcionales que redactamos como parte de un documento de desarrollo de aplicaciones móviles inmobiliarias:

Un diagrama entidad-relación (ERD) representa cómo las entidades de datos se relacionan entre sí dentro de un sistema y las conexiones entre elementos dentro de esas entidades. El siguiente es un ejemplo de un diagrama que usamos en un documento de especificación de requisitos para una aplicación móvil de entrega de alimentos:

Formas de desarrollar y gestionar requisitos

A medida que su proyecto evoluciona, los cambios en los requisitos de software para su aplicación móvil son inevitables. Los nuevos requisitos pueden venir de cualquier parte: sus inversores pueden insistir en obtener un retorno de la inversión más rápido de lo planeado; los usuarios pueden ir a la aplicación de un competidor porque su aplicación no proporciona una función que les guste; Las actualizaciones de software posteriores pueden imponer restricciones adicionales en el desarrollo de su aplicación móvil.

Es tentador describir de una vez por todas los requisitos de software para el desarrollo de aplicaciones móviles, pero hacerlo puede llevarlo al fracaso del proyecto. Averigüemos por qué el desarrollo de requisitos es un proceso iterativo .

La redacción de requisitos para su proyecto de aplicación móvil se trata generalmente de realizar cuatro actividades:

1. Obtener o preguntar qué esperan los usuarios de un nuevo producto, escuchar lo que dicen y observar lo que hacen
2. Análisis o procesamiento de los comentarios de los usuarios para comprender, clasificar y relacionar esta información con los posibles requisitos de la aplicación móvil.
3. Recopilación de especificaciones, que implica convertir la entrada vaga del usuario en documentos de requisitos escritos, estructurados y reflexivos con ilustraciones visuales.
4. Validación, que consiste en obtener la confirmación de las partes interesadas de que la especificación de requisitos que ha creado es precisa y completa.

Mientras realiza el análisis, puede darse cuenta de algunas inexactitudes que lo hacen volver a la elicitación. Y mientras escribe un documento de requisitos de productos de aplicaciones móviles, puede encontrarse con algunas lagunas que requieren que realice más análisis. Si las partes interesadas señalan errores en su documento de requisitos, tendrá que volver a escribir algunas declaraciones, realizar un nuevo análisis o incluso realizar una encuesta de seguimiento. Solo entretejiendo e iterando estas actividades puede proporcionar a las partes interesadas los requisitos relevantes de la aplicación móvil a lo largo de todo el ciclo de desarrollo.

En Mind Studios , definimos y acordamos los requisitos iniciales del producto en la etapa de descubrimiento y validación de ideas siguiendo los siguientes pasos:

En nombre del éxito de su proyecto, debe controlar la volatilidad de los requisitos con una gestión sólida. Un gerente de proyecto y / o un analista de negocios pueden asumir esta responsabilidad. Los gerentes de proyectos y los analistas comerciales tienen diferentes herramientas de gestión de requisitos para:

• Seguimiento de la necesidad de cambiar los requisitos
• Realizar un análisis de impacto para determinar qué traerán estos cambios al desarrollo del proyecto.
• Mantenimiento de requisitos de seguimiento
• Seguimiento del estado de cada requisito
• Seguimiento de problemas de requisitos
• Mantener un historial de cambios de requisitos

Características de un buen documento de requisitos de desarrollo de aplicaciones móviles

Dado que en ningún lugar más que en los requisitos del producto se cruzan los intereses de todas las partes interesadas, debe asegurarse de que sus requisitos sean igualmente claros y comprensibles para los inversores, usuarios y desarrolladores. ¿Cómo crear un documento de requisitos de aplicaciones móviles para satisfacer las necesidades de todos? No solo el contenido de un documento de requisitos, sino también el tono de voz pueden ayudarlo con esto.

Vaya más allá para obtener un documento de requisitos de productos de alta calidad. Discuta el nivel de detalle, las técnicas de representación y el estilo de redacción que son mejores para las partes interesadas.

En un mundo perfecto, los requisitos de su aplicación móvil establecidos en un PRD deberían ser:

• Completo. Por ejemplo, cada requisito funcional debe contener suficiente información para que los desarrolladores puedan implementarlo correctamente. Si tiene algunas lagunas, márquelas como por determinar (por determinar) y déles seguimiento más adelante.
• Correcto. Tanto usted como su equipo de desarrollo deben verificar la exactitud del documento de requisitos del producto de su aplicación móvil. Puede considerar que los requisitos son correctos si se ajustan a las especificaciones técnicas, las reglas comerciales, los estándares de la industria y las leyes pertinentes.
• Consistente. Esto significa que ningún requisito en un PRD debe contradecir otros requisitos en el mismo PRD.
• Factible. Debe ser posible cumplir con los requisitos de cada producto dentro del entorno operativo disponible, dadas las capacidades, el tiempo y el presupuesto conocidos del personal. La metodología de desarrollo ágil y los prototipos de prueba de concepto le ayudan a evaluar la viabilidad de los requisitos.
• Priorizado. Cada requisito, ya sea un requisito funcional o un requisito del usuario, debe clasificarse según la importancia que se implementará para una versión en particular.
• Modificable. Dado que los requisitos pueden cambiar durante el desarrollo, la estructura del documento de requisitos del producto debe ser flexible.
• Verifiable. Los requisitos del producto deben ser medibles y específicos para que los probadores puedan verificarlos con pruebas y determinar si un requisito en particular se implementa correctamente.
• Inequívoco. Una de las principales razones para escribir un documento de requisitos de productos de aplicaciones móviles es reducir la falta de comunicación. Debe escribir todos los requisitos para que solo se puedan interpretar de una manera posible.

Recomendamos encarecidamente crear un glosario de términos desde el principio del desarrollo . El hecho es que los desarrolladores no están familiarizados con su lenguaje comercial y probablemente no sea competente en programación. La falta de comprensión de los términos puede llevar a reelaboración, incumplimiento de plazos, sobrecostos y debates innecesarios.

Una plantilla de documento de requisitos de aplicaciones móviles

Algunas empresas exigen una lista detallada de requisitos respaldada por una especificación técnica bien pensada, mientras que otras se contentan con un enfoque superficial. No importa a qué grupo pertenezcas, tienes que empezar por algún lado.

Como guía para desarrollar los requisitos iniciales, puede completar nuestra plantilla de requisitos de productos de aplicaciones móviles . Proporciona suficiente información básica para facilitar y acelerar la entrada de los desarrolladores en su proyecto y, por lo tanto, para ahorrarle tiempo y dinero.

Resumen del documento de requisitos del producto de la aplicación móvil elaborado por Mind Studios

After you complete this brief, email it to us and one of our managers will respond promptly. This brief will provide a solid basis for creating a detailed mobile app product requirements document with the help of our team.

Have any questions about your mobile app project? Escríbanos.

Palabra final

Even for the smallest projects, it's critical to have a shared understanding of initial requirements. In some cases, ready-made product requirements document templates can help you out. But more often, they're only illustrative. Since no two apps are alike, there's no chance that someone else's PRD will suit your project.

To perfectly meet your specific tasks, you need to create an original mobile app requirements document , which can be a time-consuming and tedious process. The good news is that you can leave it to experts. Especially since they're just one call away.