Llega la tercera cotización y no se parece en nada a las otras dos. Una dice 8 semanas, otra 5 meses, la última pide "una reunión de levantamiento" antes de dar cualquier número. Revisas lo que enviaste a los tres proveedores: un correo de cuatro líneas que decía "necesitamos un sistema para gestionar los pedidos de nuestros clientes, con app y reportes". Cada uno imaginó un sistema distinto y cotizó lo que imaginó.
En diseño y desarrollo de software, la calidad de la cotización depende casi entera de la calidad del requerimiento que la empresa entrega. Un proveedor serio no puede adivinar cuántos usuarios tendrás, con qué ERP hay que conversar ni qué significa "reportes" para tu gerencia. Si no lo sabe, va a suponer, y cada suposición se convierte en un rango de precio más amplio o en un cambio de alcance a mitad del proyecto.
Esta guía es para el lado del cliente: qué poner en un requerimiento de software antes de pedir precio, con una plantilla que puedes copiar. Si buscas cómo se ordena el proyecto una vez que arranca, eso lo tratamos en las etapas y entregables del diseño y desarrollo de software. Y si tu duda es cuánto puede costar, revisa qué explica el costo de una aplicación a medida.
Por qué un buen requerimiento baja el precio (o al menos el riesgo)
Quien cotiza un proyecto mal definido tiene dos opciones. Puede inflar la estimación para cubrirse, o puede dar un número bajo y recuperarlo después con órdenes de cambio. Ninguna te conviene.
Un requerimiento claro no garantiza que el proyecto salga barato. Lo que sí logra es que las cotizaciones se puedan comparar. Si tres proveedores leen el mismo documento y uno cotiza el triple, ya tienes una conversación concreta: qué vio ese proveedor que los otros no.
No hace falta escribir una especificación formal de 80 páginas. La norma ISO/IEC/IEEE 29148:2018, la referencia internacional sobre ingeniería de requisitos, define qué caracteriza a un buen requisito. Resumido: cada requisito debe expresar una necesidad de forma precisa, sin ambigüedad y de manera que se pueda verificar. Con eso en mente, un documento de 4 a 8 páginas suele bastar para una primera ronda de cotización.
Qué debe incluir un requerimiento de software
Estos son los bloques que, en nuestra experiencia, más mueven una estimación. Puedes ordenarlos como quieras, pero conviene que estén todos.
El problema, no la solución
Parte por lo que hoy duele y cuánto cuesta. "Los vendedores pierden dos horas al día armando cotizaciones en Excel y el 15% sale con precios desactualizados" le dice mucho más a un proveedor que "queremos un portal de ventas". Si describes la solución antes que el problema, limitas las alternativas: a veces la respuesta correcta es una integración o una app en Power Platform, y no un sistema completo.
Agrega también qué significa que el proyecto salió bien. Una o dos métricas bastan: tiempo de respuesta al cliente, errores de facturación, horas de digitación.
Usuarios y volumen
¿Quiénes van a usar el sistema? Vendedores en terreno, bodega, clientes externos, jefaturas que solo miran reportes. Para cada grupo indica cuántas personas son, desde qué dispositivo trabajan y si necesitan operar sin conexión. Una app para 12 supervisores es un proyecto distinto de un portal para 4.000 clientes.
Procesos que el sistema debe cubrir
Describe el flujo real, con sus excepciones. ¿Qué pasa cuando un pedido llega incompleto? ¿Quién aprueba un descuento sobre cierto monto? Las excepciones son las que se comen las horas de desarrollo, y casi nunca aparecen en el primer correo.
Integraciones y datos
Lista los sistemas con los que hay que conversar (ERP, CRM, facturación electrónica, Microsoft 365, sistemas legados en AS/400) y, si lo sabes, cómo: API, archivos planos, acceso directo a base de datos. Si no lo sabes, dilo. Un "no sabemos si el ERP tiene API" es información valiosa para quien cotiza.
Incluye además qué datos va a manejar el sistema y de dónde vienen. Si hay datos que hay que migrar, indica el volumen aproximado y en qué estado están.
Datos personales
Si el sistema va a tratar RUT, direcciones, datos de salud o de trabajadores, menciónalo de entrada. La Ley 21.719 exige protección de datos desde el diseño (artículo 14 quáter) y, cuando un proveedor trata datos por cuenta de tu empresa, un contrato que fije el objeto, la duración, la finalidad, los tipos de datos y las categorías de titulares (artículo 15 bis). Hoy su entrada en vigencia está fijada para el 1 de diciembre de 2026; el Senado aprobó el 28 de octubre un proyecto que la movería al 15 de octubre de 2027, pero sigue en trámite en la Cámara. Sea cual sea la fecha final, el sistema que cotizas ahora va a operar con la ley vigente, así que conviene que el proveedor lo considere desde el diseño.
Restricciones
Presupuesto disponible (aunque sea un rango), fecha límite y su motivo, tecnologías obligatorias o prohibidas, dónde debe alojarse (por ejemplo, en tu suscripción de Azure) y quién lo va a mantener después. Mucha gente omite el rango de presupuesto por miedo a que el proveedor "lo ocupe entero". En la práctica pasa lo contrario: sin rango, recibes propuestas para un proyecto que no puedes pagar.
Criterios de aceptación: cómo vas a decir "esto está listo"
Un requisito que no se puede verificar termina en discusión. "El sistema debe ser rápido" no sirve. "La búsqueda de un cliente por RUT responde en menos de 2 segundos con 50 usuarios conectados" sí.
Para las funcionalidades más importantes, escribe el criterio con la estructura Dado / Cuando / Entonces, que viene del formato Gherkin usado en pruebas: un contexto inicial, una acción y un resultado esperado que se pueda observar.
Dado que un vendedor tiene un cliente con deuda vencida
Cuando intenta ingresar un pedido nuevo para ese cliente
Entonces el sistema bloquea el pedido y muestra el monto adeudado
No necesitas hacerlo para cada pantalla. Con 5 a 10 escenarios de los procesos críticos, el proveedor entiende las reglas de negocio y tú tienes con qué revisar las entregas.
Plantilla de requerimiento para pedir cotización
Copia esta lista y complétala. Donde no tengas la respuesta, escribe "por definir" en vez de dejarlo en blanco: así el proveedor sabe que debe preguntar.
- Contexto: qué hace la empresa y qué área pide el sistema.
- Problema actual y su costo (horas, errores, ventas perdidas).
- Objetivo y cómo se medirá el éxito.
- Usuarios: tipos, cantidad, dispositivos, uso sin conexión.
- Procesos a cubrir, con sus excepciones.
- Funcionalidades ordenadas en "imprescindible", "deseable" y "para después".
- Integraciones: sistema, dirección del dato y mecanismo conocido.
- Datos: qué datos, origen, volumen a migrar, datos personales involucrados.
- Requisitos no funcionales: disponibilidad, tiempos de respuesta, seguridad, accesibilidad.
- Criterios de aceptación de los procesos críticos.
- Restricciones: presupuesto (rango), plazo y su motivo, tecnología, alojamiento.
- Operación posterior: quién da soporte y quién administra el sistema.
- Contacto y quién toma las decisiones en tu empresa.
El punto 6 es el que más ayuda a ajustar precio. Si el presupuesto no alcanza para todo, una lista priorizada permite que el proveedor proponga una primera versión con lo imprescindible en vez de descartar el proyecto.
Errores comunes al pedir una cotización
| Error | Qué provoca | Cómo evitarlo |
|---|---|---|
| Describir la solución ("queremos una app") | Propuestas que no atacan el problema real | Partir por el problema y su costo |
| Omitir integraciones | Cambios de alcance caros a mitad del proyecto | Listar cada sistema, aunque no sepas cómo se conecta |
| Mandar documentos distintos a cada proveedor | Cotizaciones imposibles de comparar | Un solo documento, mismas preguntas respondidas a todos |
| Pedir precio cerrado con alcance abierto | Estimaciones infladas por riesgo | Fase de descubrimiento pagada o alcance acotado |
| Esconder el presupuesto | Propuestas fuera de rango | Compartir un rango referencial |
Sobre el cuarto punto: cuando el proyecto todavía tiene muchas preguntas abiertas, lo más sano suele ser contratar primero una fase corta de descubrimiento, con un entregable concreto, y cotizar el desarrollo con esa información. Cuesta un poco al inicio y te ahorra el sobrecosto de un precio cerrado mal estimado.
Preguntas frecuentes
¿Cuánto debe medir un requerimiento de software para cotizar?
Para una primera cotización, entre 4 y 8 páginas suele ser suficiente si cubre problema, usuarios, procesos, integraciones, restricciones y criterios de aceptación. Más largo no es mejor si queda ambiguo.
¿Tengo que saber de tecnología para escribirlo?
No. El requerimiento describe el negocio: qué pasa hoy, qué debe pasar y cómo vas a comprobarlo. La elección de tecnología es trabajo del proveedor, salvo que tu empresa tenga restricciones (por ejemplo, usar Azure o Microsoft 365).
¿Qué hago si no puedo definir todo antes de cotizar?
Marca lo pendiente como "por definir" y pide una fase de descubrimiento acotada. Un buen proveedor te dirá qué información le falta y cómo cambia la estimación según cada supuesto.
Siguiente paso
Si ya tienes un borrador de requerimiento, o solo el problema y unas cuantas notas, podemos revisarlo contigo y ayudarte a convertirlo en un alcance cotizable. En Disrupsoft partimos cada proyecto entendiendo tus requerimientos y procesos antes de diseñar la solución. Conoce nuestro servicio de desarrollo de software a medida y conversemos.
