Si pides presupuesto para un software a medida con una frase como "necesito un sistema para gestionar mis clientes", cada proveedor va a imaginar algo distinto, y vas a recibir precios imposibles de comparar. Un documento de requerimientos resuelve eso: describe qué necesitas con el detalle suficiente para que todos coticen lo mismo.
No hace falta ser técnico para escribirlo. Tú conoces tu negocio; el documento tiene que explicar qué debe hacer el software y para quién. El cómo lo propone quien lo va a construir.
Qué ganas con escribirlo
- Presupuestos comparables: todos los proveedores responden a lo mismo.
- Menos sorpresas: lo que no está escrito suele aparecer después como "eso no estaba incluido".
- Decisiones internas más claras: obliga a tu equipo a ponerse de acuerdo antes de gastar.
- Un punto de referencia para la entrega: al final se revisa contra lo que se pidió.
Plantilla por secciones
Copia esta estructura y complétala con tus palabras. No todas las secciones aplican a todo proyecto; si una no corresponde, escribe "no aplica" en vez de borrarla, para que quede claro que lo pensaste.
1. Contexto y objetivo 2. Cómo se hace hoy 3. Usuarios y permisos 4. Funciones, con prioridad 5. Datos e información 6. Integraciones 7. Plataformas 8. Seguridad y datos personales 9. Volumen y disponibilidad 10. Restricciones: plazo y presupuesto 11. Anexos
1. Contexto y objetivo
Qué hace tu empresa, qué problema quieres resolver y cómo vas a saber que el software funcionó. Un objetivo medible ayuda: "reducir de dos días a dos horas la preparación del informe mensual" dice mucho más que "ser más eficientes".
2. Cómo se hace hoy
Describe el proceso actual paso a paso, aunque sea con planillas, papel o WhatsApp. Indica quién hace cada paso y dónde se producen los errores o las demoras. Esta sección suele ser la más útil para quien cotiza.
3. Usuarios y permisos
Qué tipos de personas usarán el sistema (administración, vendedores, técnicos, clientes) y qué puede ver o hacer cada uno. Agrega cuántas personas hay de cada tipo.
4. Funciones, con prioridad
Lista lo que el sistema debe hacer. Un formato simple y muy claro es escribir cada función desde el punto de vista de quien la usa:
[imprescindible] Como vendedor, quiero crear una cotización desde la ficha del cliente y enviarla en PDF. [importante] Como administración, quiero ver las cotizaciones vencidas de la semana. [deseable] Como cliente, quiero aceptar la cotización con un clic.
Clasifica cada función como imprescindible, importante o deseable. Si todo es imprescindible, nada lo es: la prioridad permite armar una primera versión que puedas usar pronto y dejar el resto para una segunda etapa.
5. Datos e información
Qué información maneja el sistema (clientes, productos, órdenes, documentos), de dónde viene y aproximadamente cuánta hay. Si existe información en planillas o en un sistema anterior que hay que traspasar, dilo y adjunta una muestra: la migración de datos es una de las partes que más varía el presupuesto.
6. Integraciones
Con qué otros sistemas debe conectarse: facturación electrónica, medios de pago, correo, tu ERP, planillas compartidas u otro software de la empresa. Si conoces el nombre del sistema y si tiene API, mejor.
7. Plataformas
Desde dónde se va a usar: navegador en computador, celular, app Android o iOS. Indica si alguna parte debe funcionar sin conexión a internet, porque eso cambia bastante el desarrollo.
8. Seguridad y datos personales
Si el sistema guarda datos de personas, especialmente datos de salud, financieros o de menores, indícalo. Desde la Ley 21.719 eso implica obligaciones concretas de seguridad, conservación y respuesta a solicitudes, y deben quedar consideradas desde el diseño.
9. Volumen y disponibilidad
Cuántas personas lo usarán al mismo tiempo, en qué horario, y qué pasa si el sistema se detiene una hora. No es lo mismo un sistema interno de oficina que una plataforma para clientes que funciona todo el día.
10. Restricciones: plazo y presupuesto
Si hay una fecha límite real (una temporada, una licitación, una auditoría), escríbela. Y si tienes un rango de presupuesto, compartirlo no te pone en desventaja: permite que te propongan la mejor solución dentro de ese marco, en vez de una que nunca podrías pagar.
11. Anexos
Planillas actuales, formularios en papel, capturas del sistema que usas hoy, informes que necesitas obtener y ejemplos de otros sistemas que te gustan. Un ejemplo vale más que un párrafo de descripción.
Errores comunes
- Describir la solución en vez del problema. "Necesito una base de datos en tal tecnología" limita las opciones; "necesito que tres sucursales vean el mismo inventario en tiempo real" deja espacio para proponer.
- Olvidar los casos poco frecuentes. Devoluciones, anulaciones, clientes con dos sucursales: lo excepcional suele ser lo que más cuesta.
- Escribir solo desde la gerencia. Quien usa el proceso todos los días sabe dónde está el problema real; inclúyelo al escribir.
- Un documento de 80 páginas. Es mejor uno corto, claro y priorizado que uno exhaustivo que nadie termina de leer.
- No decir quién lo va a mantener. Si tu equipo hará cambios después, indícalo: influye en la tecnología que conviene usar.
¿Y si no tienes tiempo de escribirlo?
Es lo más común, y no es un problema. En nuestro proceso de software a medida partimos con una o más reuniones y luego te enviamos un formulario de preguntas adaptado a tu proyecto, que cubre estas mismas secciones. Si ya tienes un documento como el que describe esta guía, lo recibimos directamente, sin formulario.