Cómo escribir los requerimientos de un sistema (sin ser técnico)

Hay una asimetría incómoda en cualquier proyecto de software a medida: la persona que sabe qué necesita el negocio no sabe de tecnología, y la que sabe de tecnología no conoce el negocio. Los requerimientos son el puente, y suelen estar mal construidos de los dos lados.

Esta guía es para el lado del negocio.

La regla que cambia todo: describí el problema, no la solución

Es el error más frecuente y el más caro.

Solución: "Necesito una app para que los vendedores carguen los pedidos."

Problema: "Los vendedores toman pedidos en papel durante la visita, los mandan por WhatsApp a la tarde y administración los carga al otro día. Se pierden pedidos, hay errores de transcripción y el cliente se entera dos días después si no hay stock."

La segunda versión permite descubrir cosas que la primera cierra de entrada. Quizá no haga falta una app: quizá con un formulario web que funcione offline alcanza, y sale la cuarta parte. Quizá el problema real es el stock, no la carga.

Cuando escribís la solución, ya decidiste. Y decidiste sin la información técnica para hacerlo.

Lo que sí conviene escribir

1. El proceso como es hoy, incluidas las excepciones

Contá el circuito completo, paso por paso, con nombres de roles reales. Y después —esto es lo que separa un buen documento de uno inútil— listá las excepciones:

• "A los clientes de la lista mayorista se les factura a 30 días."
• "Cuando el pedido es urgente, el vendedor llama al depósito directo."
• "En diciembre se maneja distinto porque hay tres turnos."

Las excepciones son el proceso real. Un sistema diseñado sólo con el caso feliz termina con una planilla al lado, y volviste al principio.

2. Quiénes lo van a usar, y qué puede hacer cada uno

No hace falta un organigrama. Alcanza con algo así:

Rol	Qué necesita hacer	Qué NO debería poder ver
Vendedor	Cargar pedidos, ver sus clientes	Los clientes de otros vendedores, los costos
Administración	Facturar, ver todos los pedidos	—
Dirección	Ver reportes consolidados	—

Los permisos son de las cosas que más cambian el costo si aparecen tarde. Definirlos temprano es barato.

3. Los números de hoy

• Cuántas operaciones por día, semana o mes.
• Cuántas personas usándolo al mismo tiempo.
• Cuánto crece eso en dos años.

Un sistema para 50 pedidos diarios y uno para 5.000 no se parecen. Sin este dato, el proveedor asume, y las suposiciones se pagan.

4. Qué sistemas ya existen y cuáles no se tocan

Listá lo que usás, aunque parezca irrelevante: facturación, contabilidad, e-commerce, la planilla de comisiones. Y marcá cuáles no están en discusión —"el sistema contable no se cambia"— porque eso define qué integraciones hacen falta.

5. Los datos históricos

Qué información hay que conservar, dónde está y desde cuándo. Y sé honesto sobre su estado: si sabés que hay clientes duplicados y fechas en formatos distintos, decilo. Se va a descubrir igual, y es mucho mejor que se descubra antes de cerrar el precio.

6. Qué sería el éxito

Una frase concreta: "que el pedido llegue a administración en el momento en que se toma", "que cerrar el mes lleve un día en vez de una semana".

Sirve para dos cosas: alinea el alcance, y al final permite saber si el proyecto sirvió.

Lo que conviene NO escribir

La tecnología. "Que sea en React con MongoDB" no es un requerimiento salvo que tengas una razón de negocio real —un equipo interno que ya la usa, por ejemplo—. Si no, estás limitando opciones sin ganar nada.

El diseño de las pantallas. Salvo que tengas una restricción concreta, dejá que lo propongan. Vas a recibir algo mejor que lo que dibujarías.

Una lista de funcionalidades sin contexto. "Login, dashboard, reportes, notificaciones" no dice nada. Cualquiera de esas palabras puede significar una semana o tres meses.

Cosas que no vas a usar el primer año. El deseo de "dejarlo preparado para el futuro" es el principal motor del alcance inflado. Lo que sí conviene aclarar es hacia dónde puede crecer, para que la arquitectura no lo impida.

Una estructura que funciona

Si querés algo para copiar, esto alcanza y sobra:

1. Qué hace la empresa — dos párrafos, para dar contexto.
2. El problema — qué proceso duele, cuántas horas se come, qué errores genera.
3. El proceso hoy — paso a paso, con las excepciones.
4. Quiénes lo usan — roles y permisos.
5. Volumen — operaciones y usuarios, hoy y en dos años.
6. Sistemas existentes — cuáles hay, cuáles no se tocan.
7. Datos históricos — qué hay que migrar y en qué estado está.
8. Qué sería el éxito — una o dos frases medibles.
9. Restricciones — presupuesto, fecha límite, normativa.

Tres o cuatro páginas. Más que eso, en general, es adorno.

Sobre el presupuesto: decilo

Hay una idea instalada de que decir el presupuesto es debilidad negociadora. En software a medida es al revés: sin un rango, el proveedor no puede proponer un alcance.

El mismo problema se puede resolver con USD 4.000 o con USD 40.000, y las dos soluciones son legítimas para contextos distintos. Si no decís el rango, vas a recibir propuestas que no podés pagar o propuestas que no resuelven nada, y en los dos casos perdiste tiempo.

Decir "tenemos entre 8 y 12 mil dólares" hace que la conversación empiece en el lugar correcto.

Si no sabés lo que necesitás

Es la situación más común y no es un problema. Nadie que dirige una empresa tiene por qué saber traducir su operación a un alcance de software.

Para eso está el relevamiento: alguien se sienta con tu equipo, mira cómo trabajan, mapea los procesos y arma el documento por vos. Un diagnóstico con hoja de ruta arranca desde USD 2.000 y suele evitar gastos mucho mayores, porque impide que se digitalice el proceso equivocado.

Lo que sí conviene tener claro antes de esa conversación es qué te duele. Eso no lo puede averiguar nadie de afuera.

---

Si querés escribirlo vos, usá la estructura de arriba. Y si preferís que lo armemos juntos, la primera reunión de análisis es gratuita: contanos qué proceso te está costando y salimos de ahí con un alcance.