Cómo escribir los requisitos de tu software (sin ser técnico)
"Hazme un sistema para gestionar el negocio" es la frase más cara que existe en desarrollo de software: cada palabra difusa se convierte en suposiciones del programador, cotizaciones incomparables y sorpresas de entrega. Los buenos requisitos no exigen saber programar — exigen contar tu operación con una estructura simple. Esta guía te la da, con ejemplos.
21 de octubre de 20256 min de lecturaEn este artículo
"Hazme un sistema para gestionar el negocio" es la frase más cara que existe en desarrollo de software. No porque el sistema sea caro — sino porque cada palabra difusa se convierte en una suposición del programador, y las suposiciones se descubren tarde: en la entrega, cuando "gestionar" resultó significar una cosa para ti y otra para él, y corregirlo cuesta diez veces más que haberlo escrito claro.
La buena noticia: escribir buenos requisitos no exige saber programar — exige contar tu operación con una estructura simple que cualquier dueño de negocio domina en una tarde. El premio es triple: cotizaciones comparables entre proveedores, un desarrollo sin sorpresas y un documento que te protege si algo se disputa. Esta guía te da la estructura, los ejemplos de vago a útil, y el uso correcto del documento.
Por qué los requisitos difusos cuestan tanto
Tres mecanismos convierten la vaguedad en dinero perdido. Las suposiciones: donde tu documento calla, el desarrollador decide — con la mejor intención y sin conocer tu operación; el resultado técnico puede ser correcto y comercialmente inútil. El costo del cambio tardío: mover una pared en el plano es gratis; moverla con la casa construida, no — cada requisito que aparece a mitad del desarrollo paga esa tarifa. Las cotizaciones incomparables: ante un pedido difuso, un proveedor cotiza el mínimo que le suena y otro el máximo que imagina — los presupuestos que recibes no describen el mismo proyecto, y elegir entre ellos es una lotería.
La estructura simple que funciona
- El problema y el objetivo medible: qué duele hoy y cómo se verá el éxito — "los pedidos se pierden entre WhatsApp y papel; éxito = cero pedidos perdidos y estado consultable de cada uno".
- Los usuarios y sus roles: quiénes usarán el sistema y qué puede hacer cada uno — la recepcionista, el bodeguero, el administrador; quién ve qué, quién aprueba qué.
- Los flujos principales, contados como historias: los 3-6 caminos que el sistema debe cubrir, narrados de principio a fin como ocurren en la realidad — con sus excepciones ("¿y si el cliente cancela a mitad?").
- Los datos que se manejan: qué información entra, se guarda y sale — la ficha del cliente con sus campos, el pedido con los suyos; ejemplos reales (inventados pero realistas) valen oro.
- Lo que queda FUERA: la lista explícita de lo que la versión 1 NO hará — tan importante como todo lo anterior, y el tema de su propia sección.
Escribe historias, no listas de funciones
De vago a útil: la tabla de traducción
| Frase vaga | Requisito útil |
|---|---|
| "Que sea fácil de usar" | "Una persona nueva registra una venta sin capacitación, en menos de un minuto" |
| "Que tenga reportes" | "Ver ventas por día, semana y mes, filtradas por sucursal y por producto, exportables" |
| "Que sea seguro" | "La cajera ve solo sus ventas del día; el administrador ve todo; cada acción queda registrada con quién y cuándo" |
| "Que sea rápido" | "La búsqueda de clientes responde en menos de 2 segundos con 10.000 registros" |
Lo que queda fuera vale tanto como lo que entra
La sección más difícil de escribir — y la que más dinero ahorra — es la lista de exclusiones: "la versión 1 NO incluye": la app móvil, la integración contable, los reportes avanzados, el segundo idioma. Sin ella, cada conversación del proyecto reabre el alcance ("ya que estamos, ¿podría también…?") y el presupuesto muere por mil cortes. La disciplina para trazar esa línea viene de pensar en versiones: la 1 resuelve el dolor central y sale a producción; lo demás compite por la versión 2 con evidencia de uso real — exactamente la lógica del MVP.
Cómo usar el documento (y mantenerlo vivo)
Con 2 a 4 páginas basta — el documento perfecto que nadie termina pierde contra el bueno que existe. Su primer uso: mándalo idéntico a cada proveedor candidato — por primera vez las cotizaciones describirán el mismo proyecto y podrás compararlas de verdad, junto con las respuestas a las preguntas de tecnología. Su segundo uso: vivir durante el proyecto — los cambios se anotan, se cotizan y se deciden por escrito, no se deslizan en llamadas. Y el tercero: ser el árbitro de la entrega — "terminado" significa que las historias del documento funcionan, no otra cosa. El marco completo del proyecto alrededor de este documento está en la guía de crear tu app.
Preguntas frecuentes
¿Qué tan largo debe ser el documento de requisitos?
Para un sistema de pyme típico: de 2 a 4 páginas siguiendo la estructura de esta guía. Menos de una página suele significar que las decisiones quedaron sin tomar (las tomará el desarrollador); más de diez, que estás especificando detalles de implementación que no te corresponden — o posponiendo el proyecto vía documentación infinita. La medida real no son las páginas sino la prueba: ¿dos proveedores que lo lean cotizarían el mismo proyecto?
¿Y si no sé exactamente lo que necesito?
Nadie lo sabe del todo al inicio — por eso el documento empieza por el problema, no por la solución: describir con precisión qué duele hoy (con ejemplos reales de la semana pasada) ya es media especificación, y un buen proveedor propone soluciones sobre ese material. Las dos herramientas que más despejan: observar la operación real un día anotando cada paso del proceso que quieres digitalizar, y recortar sin piedad a versión 1 — sobre lo incierto, decide el uso real, no la imaginación.
¿No debería escribir los requisitos el proveedor, que es el experto?
Es un trabajo a cuatro manos con roles claros: tú aportas lo que él no puede saber — tu operación, tus reglas, tus prioridades — y él aporta estructura, preguntas y opciones técnicas. El borrador inicial conviene que sea tuyo (aunque sea imperfecto): quien escribe el primer documento fija el marco, y un proveedor que redacta requisitos desde cero sin conocerte tiende a especificar lo que le conviene construir. La señal de un buen proveedor: recibe tu documento y lo devuelve lleno de preguntas — eso es exactamente lo que quieres.
¿Qué pasa si cambio de opinión a mitad del desarrollo?
Pasará — y está bien si se gestiona: el cambio se escribe, el proveedor lo cotiza en tiempo y dinero, y decides con números si entra ahora, va a la versión 2 o se descarta. Lo que arruina proyectos no es cambiar de opinión sino el cambio informal: el "ya que estamos" dicho en una llamada, que nadie cotizó y todos recuerdan distinto. Regla práctica: si el cambio nace de algo aprendido (usuarios reales, datos), suele merecer entrar; si nace de una ocurrencia, suele merecer la lista de la versión 2.