Cómo escribir un documento de requisitos de software para una aplicación de kiosco iPad / Android

Esta es una gran pregunta sobre la cual se han escrito múltiples libros. Esbozaré en esta respuesta la estrategia que uso para escribir tal especificación hoy.

Es diferente de la forma en que lo hago en Microsoft, ya que descubrí que las especificaciones de Microsoft tienen un defecto fatal. Carecían del contexto de la característica / producto.

Cuando comienza este proceso por primera vez, es probable que cada sección contenga más preguntas que respuestas. Está bien, te ayuda a hacer un seguimiento de las incógnitas.

Si desea ver una versión más detallada de este artículo, diríjase a este artículo.

¿Qué problema estamos resolviendo?

Demasiadas veces, a medida que avanza el diseño de la aplicación, se pierde el problema original a resolver.

Luego, las características no relacionadas con el problema original se agregan al producto porque alguien pensó que era una buena idea. La aplicación termina perdiendo el foco y se vuelve menos atractiva para los usuarios.

Por lo tanto, asegurarse de documentar el problema en cuestión es muy útil.

¿Para quién estamos creando esto?

Debe recordar que no crea aplicaciones para usted. Está creando una aplicación para otra persona que puede tener una necesidad diferente a la suya, diferentes habilidades informáticas, diferente cultura y más.
Así que asegúrese de tener una persona clara para la que está diseñando su aplicación. En realidad, cuando crea su aplicación por primera vez, tener una sola persona para quien está creando esta aplicación podría ser la mejor opción.

Factores diferenciadores?

La AppStore y PlayStore tienen una asombrosa cantidad de aplicaciones hoy. Así que tenga la seguridad de que lo más probable es que su gran idea de aplicación se haya hecho antes.

Entonces, ¿cuál es su factor diferenciador? Se específico.

¿Cuáles son nuestros objetivos comerciales?

¿Qué es lo que estás tratando de lograr? ¿Estás buscando reemplazar Facebook? ¿Estás buscando crear una aplicación que te permita vivir una vida cómoda? ¿Es esta aplicación un líder de pérdidas para un servicio más grande? ¿Es este un servicio complementario a algo que su usuario ya compró?
Sea claro en esto, porque eso lo ayudará a responder muchas preguntas que vendrán más adelante en la fase de diseño.

Fechas importantes

Un proyecto nunca sucede en el vacío. Es posible que esté tratando de estar listo para una convención anual específica para poder anunciar su producto allí.

Puede que tenga que llegar a una fecha determinada para que otro equipo pueda completar su parte del proyecto a tiempo.

Es posible que sepa que su principal competidor se lanzará en una fecha determinada y desea vencerlos en el mercado.

RAT (suposiciones de riesgo para probar)

Cuando crea una aplicación, nunca está seguro de si va a tener éxito o no. Y esto está bien. Aunque debe enumerar cuáles son las cosas que aún no se han validado.

A continuación, enumere cómo los validará. De esta manera, puede asegurarse de que tiene todo lo que necesita validar lo antes posible. Se puede enviar una versión alfa temprana de la aplicación a los primeros usuarios, por ejemplo, para ver si la usan.

Historias de usuarios / escenarios

Recuerda a María de nuestra audiencia. ¿Qué está tratando de hacer con tu aplicación? ¿Qué quieres capacitarla para que haga con tu aplicación?

De historias de usuarios y ejemplos de historias de usuario de Mike Cohn

Las historias de usuarios son descripciones cortas y simples de una característica contada desde la perspectiva de la persona que desea la nueva capacidad, generalmente un usuario o cliente del sistema. Suelen seguir una plantilla simple:
Como , quiero para que .
Las historias de los usuarios a menudo se escriben en tarjetas o notas adhesivas, se almacenan en una caja de zapatos y se organizan en paredes o mesas para facilitar la planificación y el debate. Como tal, cambian fuertemente el enfoque de escribir sobre características a discutirlas. De hecho, estas discusiones son más importantes que cualquier texto escrito.

Así que haga una lista de esas historias y priorícelas.

Caracteristicas

Cada escenario requerirá un cierto conjunto de características para permitir que su usuario las complete. La razón principal por la que incluyo todo el contexto anterior es que, para un escenario de usuario, hay muchas formas diferentes de implementarlo. Por lo tanto, querrá usar ese contexto (objetivos comerciales, perfil de usuario, presupuesto, problema resuelto) para elegir el conjunto de características correcto.

Use sus objetivos comerciales, su perfil de usuario, sus fechas objetivo y su presupuesto para decidir sobre su conjunto de características.

OS soportado

Dependiendo de su audiencia (y su presupuesto), es posible que decida que solo desea admitir la última versión del iOS. O puede descubrir que su audiencia no ha actualizado su teléfono en los últimos 4 años, por lo que debe admitir 1 o 2 versiones anteriores y esperar que su aplicación se ejecute en pantallas más pequeñas (y olvidarse de ARKit).

BackEnd

No todas las aplicaciones requieren un back-end, pero si lo hace, entonces tiene mucho que documentar. Aunque lo guardaré para otro momento.

Servicios de terceros

En la aplicación de hoy, siempre tienes algunos servicios de terceros. Hay algunas cosas que es mejor dejar a otros. Aquí hay una lista típica que tengo para aplicaciones móviles:

Riesgos

Esto es algo que con frecuencia queda fuera de las especificaciones y creo que esta podría ser una de las secciones más importantes. Enumere todas las cosas que pueda pensar que podrían ir de lado y cuál es su plan de mitigación para cada una de ellas. Es mucho más fácil encontrar una solución cuando no está bajo presión y tiene que encontrar una solución a esa violación de seguridad que nadie vio venir.

Esto es generalmente donde termina la especificación. A partir de ahí, te dirigirás al diseño UX de la aplicación. He incluido las tres partes de diseño que son las más importantes, pero no suelen ir en la especificación.

Arquitectura de la información de la aplicación

¿Cuál será la estructura de su aplicación? ¿Cómo se agrupará la información?

Estructura metálica

Con la arquitectura de la información en su lugar, puede comenzar a diseñar cada pantalla y mostrar cómo se representa la funcionalidad. Mantenlo simple, sin necesidad de gráficos sofisticados todavía. Pero tenga en cuenta la transición de pantalla para que pueda tener una buena idea de cómo se comportará la aplicación.

Diseño visual

Es hora de crear un gran diseño visual. Use lo que sabe sobre su público objetivo para crear un diseño visual que resuene con ellos.
Dependiendo de su proyecto, puede simplemente reutilizar el control base del sistema operativo, o puede crear controles personalizados para todo.
Si sigue la ruta de control personalizada y su proyecto es bastante grande, le recomiendo crear un libro de diseño visual que defina:

  • colores para usar en toda la aplicación
  • estilos de texto para usar en toda la aplicación
  • El estilo visual de los controles (con animación).

El objetivo aquí es tener un solo lugar donde se documenten los componentes reutilizables. De esta manera, su desarrollador puede hacer fácilmente una experiencia de usuario consistente al saber que todos esos controles son los mismos. Esto le ahorrará tiempo en el camino.

Me gustó este artículo, pero ¿quieres aún más detalles? Pásate por este artículo.