Qué incluir en un documento de requisitos para una empresa de desarrollo de aplicaciones en el RGV

Por Noe Guerrero III

Un documento útil de requisitos para una aplicación explica quién necesita el producto, qué necesita lograr y cómo decidirás que la primera versión funciona. No tienes que llegar a una reunión de desarrollo con un diagrama de base de datos. Sí necesitas algo más específico que una lista de funciones de aplicaciones que te gustan.

Cuando te acerques a una empresa de desarrollo de aplicaciones en el RGV, incorpora desde el principio el proceso del negocio en la conversación. La persona que solicita un servicio, el empleado que lo organiza y el gerente que lo revisa pueden necesitar cosas diferentes de la misma aplicación. Anotar esas diferencias les da a los desarrolladores un mejor punto de partida para hacer preguntas y preparar una estimación.

Describe la tarea que la aplicación debe ayudar a terminar

Empieza por el problema tal como ocurre hoy. Explica quién hace el trabajo, qué herramientas usa y dónde se pierde o se repite la información. Incluye lo que ya funciona y debe conservarse.

Imagina un negocio de renta de equipo que atiende a Rio Grande Valley. Su primer objetivo podría ser permitir que los clientes soliciten un artículo para fechas específicas y que el personal acepte o rechace la solicitud. Ese objetivo hipotético es más útil que “crear una aplicación de rentas”, porque el equipo puede seguirlo desde la solicitud hasta la decisión.

La guía de historias de usuario del Service Manual de GOV.UK organiza los requisitos en torno a la persona, lo que necesita hacer y por qué. Para tu documento basta el lenguaje cotidiano: un miembro del personal necesita ver las fechas solicitadas para comprobar la disponibilidad antes de prometerle equipo a un cliente.

Identifica quién usa cada parte

Enumera a las personas involucradas y la información que necesita cada una. En el ejemplo de la renta, un cliente podría ver sus propias solicitudes, un miembro del personal podría administrar las reservaciones y un administrador podría gestionar los listados de equipo y el acceso del personal.

Incluye las excepciones. ¿El personal temporal puede cambiar un precio? ¿Quién puede cancelar una reservación aceptada? ¿Qué pasa cuando un empleado se va? Son decisiones que deben discutirse antes de tratar todas las cuentas como intercambiables.

Nuestro proyecto Go Belle muestra por qué importan los distintos lados de un producto. RGV Web Design creó su aplicación y sitio web para conectar a clientes con profesionales de belleza y bienestar, incluidos el descubrimiento de servicios y la planeación de citas. Tu aplicación puede atender roles distintos, pero el documento de requisitos sigue necesitando identificarlos.

Delimita la primera versión

Separa lo que el negocio necesita para empezar a usar la aplicación de las ideas que pueden esperar. Para el negocio hipotético de renta, aceptar solicitudes y registrar las decisiones del personal podría pertenecer a la primera versión. Un programa de lealtad o la planificación automática de rutas de entrega podría venir después.

Anota las exclusiones junto al trabajo incluido. “Los pagos se manejan mediante nuestro proceso actual” le comunica al desarrollador algo que una sección vacía de pagos no dice. También plantea una pregunta útil sobre cómo registrará el personal el estado del pago.

Marca como preguntas las decisiones sin resolver. Si aún no decides si los clientes deben pagar un depósito en línea, dilo. Pide al desarrollador que explique las opciones y qué cambia cada una en el alcance propuesto. El documento debe hacer visibles las incertidumbres mientras todavía haya tiempo de resolverlas.

Describe dónde y cómo la gente la usará

Indica los dispositivos que tu personal ya usa y los que esperas admitir para los clientes. Explica si la gente necesita acceso por navegador, una aplicación móvil instalada o ayuda para elegir entre ambas. Pide al desarrollador que relacione esa recomendación con el flujo de trabajo.

Si el personal necesita trabajar sin conexión, identifica la tarea específica. Nuestra guía para planear aplicaciones sin conexión cubre las decisiones detrás del guardado local y las actualizaciones posteriores. Tu documento puede empezar con una pregunta sencilla sobre si un trabajador debe abrir una reservación fuera de la oficina.

Para un negocio del RGV que atiende a clientes en inglés y español, especifica los idiomas que realmente necesita el producto, incluidos los mensajes al personal y el contenido de ayuda. Indica quién revisará los textos. No supongas que la estimación del desarrollador incluye traducir todas las pantallas.

Incluye las expectativas de accesibilidad y el presupuesto para revisarlas. Para una aplicación web, la guía de planeación del W3C recomienda definir objetivos, responsabilidades y recursos. Pregunta qué usuarios y tareas cubrirá la revisión y cómo se resolverán los hallazgos.

Lleva detalles de los sistemas existentes

Enumera el calendario, el sistema contable, el servicio de pagos, la herramienta de inventario o la base de datos de clientes con los que la aplicación quizá deba conectarse. Identifica cuál mantiene actualmente el registro oficial para cada tipo de información.

“Conectarse a nuestro inventario” deja abiertas preguntas importantes. ¿Eso significa consultar existencias, reservar un artículo, cambiar cantidades o las tres cosas? ¿Quién puede confirmar qué permite el sistema actual? Lleva su documentación y el nombre de la persona que lo administra.

Usa ejemplos inventados o debidamente anonimizados para mostrar la forma de los registros y formularios. Mantén las contraseñas, las claves privadas de acceso y los registros reales de clientes fuera de un documento general del proyecto. El equipo de desarrollo puede organizar el acceso apropiado cuando se necesite.

Explica cómo revisarás el resultado

Describe qué quieres ver funcionando en cada revisión. Para el ejemplo de la renta, una demostración útil seguiría una solicitud hasta la aceptación del personal y mostraría al cliente el estado resultante. Incluye lo que ve el cliente cuando se rechaza la solicitud.

La misma guía de GOV.UK describe los criterios de aceptación como resultados que se usan para comprobar si se satisfizo una necesidad del usuario. Escribe algunos de los tuyos antes de pedir un precio final: el personal puede identificar el equipo y las fechas solicitadas; los clientes pueden ver la decisión; y cambiar una solicitud no modifica otra.

Comparte el rango de presupuesto, cualquier fecha límite real y qué hace importante esa fecha. Pregunta también qué cubre la estimación después de la entrega: acceso a cuentas, instrucciones, capacitación del personal, soporte y costos continuos de servicios. Asigna a alguien de tu lado que pueda responder preguntas y aprobar decisiones.

Envía un documento que la gente pueda discutir

Antes de la primera reunión, comprueba que tu documento responda estas preguntas:

• ¿Para quién es la aplicación y qué tarea debe ayudarle a terminar?

• ¿Qué pertenece a la primera versión y qué queda excluido?

• ¿Qué dispositivos, idiomas y sistemas existentes importan?

• ¿Qué decisiones siguen abiertas y quién puede resolverlas?

• ¿Qué revisarás antes de aceptar el trabajo?

Un flujo de trabajo aproximado y un conjunto claro de preguntas bastan para iniciar una conversación productiva. Llévalos al equipo de desarrollo de software de RGV Web Design y usa la reunión para convertir la necesidad del negocio en un alcance que ambas partes entiendan.