Cómo preparar los requisitos de un software a medida

Empieza por el problema, no por las pantallas

Es tentador empezar con una lista de funciones o con capturas de otras aplicaciones. Resulta más útil describir qué ocurre hoy: quién hace la tarea, con qué herramientas, cuánto tarda y dónde se producen los errores o las esperas.

A partir de ese relato se pueden proponer soluciones distintas, y a menudo más sencillas, que las que surgen al copiar otra herramienta. También permite comprobar después si el software ha mejorado lo que tenía que mejorar.

• Qué tarea o proceso quieres mejorar.
• Quién la realiza hoy y con qué herramientas.
• Qué falla: errores, duplicados, esperas o falta de visibilidad.
• Qué resultado considerarías un éxito.

Usuarios, perfiles y permisos

Enumera los perfiles que usarán el sistema: administración, técnicos, comerciales, clientes o proveedores. Para cada uno, describe qué necesita ver y qué puede hacer. Los permisos influyen en la estructura de datos y en la seguridad, y son difíciles de añadir bien al final.

Indica también cuántas personas usarán cada perfil, aproximadamente, y desde dónde: la oficina, el móvil en la calle o el ordenador del cliente.

Datos: qué existe y qué debe conservarse

Reúne ejemplos reales de la información con la que trabajas: hojas de cálculo, formularios, documentos y exportaciones de otros programas. Con ellos se diseña un modelo de datos que refleje cómo se relacionan clientes, operaciones, documentos y estados.

Si hay información histórica, indica si debe migrarse y en qué estado está. En nuestro proyecto de gestión de alquileres, incorporar la información de una base de datos heredada formaba parte del alcance desde el principio, porque propietarios, inmuebles, contratos y movimientos tenían que relacionarse en un modelo común.

Integraciones con las herramientas actuales

Haz una lista de los programas con los que debe comunicarse el nuevo sistema: facturación, ERP, CRM, banca, correo, web o pasarela de pago. Para cada uno, indica qué datos deben ir o venir y con qué frecuencia.

La viabilidad de una integración depende de lo que ofrezca cada proveedor. Conviene comprobarla antes de cerrar el alcance, porque a veces la alternativa es una exportación periódica o un proceso semiautomático.

Las excepciones también son requisitos

Los procesos casi nunca son lineales: hay devoluciones, cancelaciones, datos incompletos, clientes con condiciones especiales o tareas que alguien debe aprobar. Son la parte que más tiempo consume en el día a día y la que más suele faltar en una primera descripción.

No hace falta listarlas todas. Basta con recordar los casos que generan más llamadas, correos o correcciones y explicar cómo se resuelven hoy.

• ¿Qué pasa si falta un dato o llega mal?
• ¿Qué operaciones pueden anularse o corregirse, y quién lo decide?
• ¿Hay clientes, tarifas o casos con reglas propias?
• ¿Qué debe quedar registrado para poder revisarlo después?

Separa la primera versión de todo lo demás

Con la información anterior, marca qué es imprescindible para que el sistema resulte útil desde el primer día y qué puede esperar. Una primera versión acotada se entrega antes, se prueba con usuarios reales y orienta las siguientes fases con datos.

Añade una fecha objetivo y, si es posible, un rango de inversión. No compromete nada y permite proponer un alcance realista en lugar de una lista de deseos difícil de cumplir.

Una estructura sencilla para tu documento

Dos o tres páginas bastan para empezar. Puedes seguir este orden y adjuntar ejemplos reales de documentos y hojas de cálculo:

• Contexto: qué hace la empresa y qué proceso quiere mejorar.
• Situación actual: herramientas, personas implicadas y problemas.
• Usuarios y permisos: perfiles y qué puede hacer cada uno.
• Datos: qué información existe, qué debe migrarse y ejemplos.
• Integraciones: programas con los que debe conectarse.
• Excepciones: los casos especiales más frecuentes.
• Prioridades: primera versión, fases posteriores, fecha y rango de inversión.