Cómo definir los requisitos de un software a medida para pedir presupuestos comparables

Para recibir presupuestos comparables de software a medida, todos los proveedores deben valorar el mismo problema, alcance, contexto y condiciones de respuesta. No basta con pedir «una app para gestionar pedidos»: hay que explicar qué proceso debe resolverse, quién la utilizará, qué datos e integraciones intervienen, qué queda fuera y cómo se comprobará que la entrega cumple lo acordado.

El objetivo no es redactar un documento técnico perfecto antes de hablar con nadie. Es reducir interpretaciones distintas para poder distinguir una oferta orientativa, una propuesta cerrada y una fase previa de descubrimiento. Un briefing bien preparado también evita que una cifra inicial baja oculte exclusiones relevantes, costes recurrentes o dependencias que aparecerán más adelante.

Qué debe conseguir un buen briefing de software a medida

Un documento de requisitos debe permitir que varias empresas entiendan el objeto del trabajo, preparen una propuesta y compartan una interpretación razonablemente común de lo que se solicita. Esa es la función de una especificación técnica: describir con precisión suficiente la necesidad, sin convertir el documento en una lista de decisiones técnicas prematuras. La guía británica sobre especificaciones técnicas plantea este mismo principio para que los licitadores comprendan el objeto de la contratación y puedan preparar propuestas sobre una base común.

Como referencia metodológica, la norma ISO/IEC/IEEE 29148 aborda la ingeniería de requisitos y contempla funciones, rendimiento, restricciones de diseño y atributos de calidad. Para una pyme no es una obligación legal general ni una plantilla que elimine la incertidumbre, pero su enfoque ayuda a ordenar el análisis.

• Entrega a todos los proveedores la misma versión del briefing, anexos, fecha límite y formato de respuesta.
• Explica qué decisión empresarial debe mejorar el proyecto, no solo las pantallas o funciones imaginadas.
• Distingue entre requisitos cerrados, puntos pendientes de validar y opciones que deben presupuestarse por separado.
• Define qué información debe incluir cada propuesta para que la comparación sea posible.

Si existen integraciones complejas, datos de calidad desconocida o procesos que todavía no están claros, una oferta cerrada puede basarse en muchas hipótesis. En ese escenario puede ser más útil pedir primero una fase de análisis o descubrimiento con entregables definidos.

Las referencias de contratación citadas en este artículo son buenas prácticas de preparación de requisitos, principalmente procedentes del contexto británico; no constituyen asesoramiento jurídico aplicable automáticamente en España. En contratación pública española deben revisarse la Ley de Contratos del Sector Público, los pliegos y los procedimientos internos con asesoramiento especializado.

Empieza por el problema, no por la tecnología

Describe primero cómo funciona hoy el proceso y qué resultado esperas conseguir. Una buena investigación de necesidades puede combinar entrevistas con las personas usuarias, observación del trabajo real, revisión de incidencias y análisis de datos disponibles, tal como plantea la guía de investigación de necesidades de usuarios del Government Digital Service.

Por ejemplo, en vez de exigir «una aplicación en una tecnología concreta», plantea la necesidad: «El equipo comercial debe consultar el catálogo y registrar pedidos con los datos actualizados del ERP, evitando volver a introducir información». La tecnología propuesta puede depender después de requisitos justificados, como dispositivos disponibles, conectividad, sistemas existentes o competencias internas.

Contexto mínimo que conviene explicar

• Problema actual: tareas manuales, errores, esperas, duplicidades o falta de trazabilidad.
• Objetivo: qué debe poder hacer mejor la empresa o la persona usuaria.
• Personas usuarias: roles, número aproximado, permisos, frecuencia y lugar de uso.
• Proceso actual: pasos, excepciones, aprobaciones y sistemas implicados.
• Restricciones reales: sistemas que deben mantenerse, requisitos de acceso, plazos condicionados o canales necesarios.

Antes de asumir que el desarrollo a medida es la única vía, compara también si un software estándar o la configuración de una plataforma existente puede cubrir el proceso sin forzar excesivamente el trabajo. Una solución a medida suele tener más sentido cuando el proceso, las integraciones, los permisos o los datos son específicos y una herramienta generalista crea fricción relevante.

Si necesitas valorar esta decisión, puede ayudarte esta guía sobre aplicaciones personalizadas para pymes y digitalización del negocio.

La estructura mínima del documento de requisitos

Un briefing útil puede ser un documento compartido, una hoja de cálculo con anexos o una combinación de ambos. Lo importante es que cada apartado permita a los proveedores estimar el trabajo y declarar qué cubren.

1. Resumen del proyecto: contexto, problema, objetivos y resultados esperados.
2. Alcance general: qué procesos, departamentos, canales y ubicaciones incluye.
3. Usuarios y permisos: perfiles, acciones permitidas y responsables de validación.
4. Procesos actuales y futuros: diagramas sencillos, pasos, excepciones y aprobaciones.
5. Funcionalidades: agrupadas por módulos o procesos de negocio.
6. Integraciones: ERP, CRM, servicios externos, dispositivos, API o ficheros; indica qué sabes de cada conexión.
7. Datos: origen, responsables, calidad conocida, importaciones, migración, conservación y exportación.
8. Experiencia de usuario: dispositivos, canales, idiomas, prototipos disponibles y necesidades de accesibilidad cuando proceda.
9. Calidad y requisitos técnicos: rendimiento, disponibilidad, compatibilidad, mantenibilidad, registros y monitorización.
10. Seguridad y privacidad: controles acordes al riesgo, accesos, copias, recuperación, auditoría y tratamiento de datos.
11. Entrega y operación: pruebas, despliegue, formación, soporte, mantenimiento y documentación.
12. Propiedad y salida: código fuente, repositorios, cuentas cloud, licencias, datos, subcontratación y transición a otro proveedor.

En interoperabilidad, conviene describir resultados y formatos necesarios antes que imponer productos concretos. Cuando sea viable, los estándares abiertos pueden facilitar integraciones y reducir dependencias innecesarias.

Plantilla breve para enviar con la solicitud

Puedes pedir a todos los proveedores que respondan al mismo documento con esta estructura:

1. Contexto y objetivo: problema, proceso afectado y resultado esperado.
2. Alcance: requisitos obligatorios, deseables, opcionales y fuera de alcance.
3. Usuarios y procesos: roles, permisos, frecuencia de uso, excepciones y aprobaciones.
4. Datos e integraciones: sistemas implicados, responsables, accesos disponibles, calidad conocida y migraciones previstas.
5. Calidad, seguridad y operación: requisitos de rendimiento, disponibilidad, accesibilidad cuando proceda, copias, registros y soporte.
6. Formato de la propuesta: cobertura de requisitos, supuestos, exclusiones, fases, entregables, costes iniciales y recurrentes, calendario estimado, riesgos y condiciones de salida.

Cómo redactar requisitos que se puedan verificar

Una lista de deseos no es suficiente para pedir un presupuesto comparable. Cada requisito relevante necesita una redacción homogénea y una forma de comprobarlo. Las historias de usuario pueden ayudar a expresar quién necesita una capacidad, qué quiere conseguir y para qué; los criterios de aceptación permiten verificar la entrega, como explica la guía sobre historias de usuario.

Ejemplo hipotético

RF-012 — Obligatorio. Como responsable de administración, necesito revisar los pedidos importados antes de enviarlos al ERP para detectar datos incompletos.

Criterios de aceptación: la aplicación muestra los pedidos con campos obligatorios pendientes; permite corregirlos a una persona autorizada; deja registro de la revisión; y no envía al ERP un pedido marcado como incompleto.

En cambio, expresiones como «debe ser rápida», «intuitiva» o «segura» necesitan concretarse. Identifica la operación, el volumen, el contexto de uso y la evidencia esperada. Para aplicaciones web, WCAG 2.2 ofrece criterios de éxito verificables y tecnológicamente neutrales de accesibilidad; su pertinencia y el nivel exigible dependen del servicio y de la normativa aplicable. Para seguridad, OWASP ASVS puede servir como referencia técnica para definir y verificar controles, pero no sustituye el análisis de riesgos ni garantiza por sí solo el cumplimiento o la seguridad.

Separa alcance, fases y entregables

Pide que la propuesta diferencie el producto inicial, las evoluciones posteriores y las opciones. Así evitas comparar como equivalentes dos presupuestos en los que uno incluye migración, pruebas, formación y despliegue, mientras otro solo contempla el desarrollo básico.

• MVP o primera entrega: capacidades mínimas que deben quedar operativas.
• Fases posteriores: módulos o mejoras que pueden posponerse.
• Opcionales: elementos que quieres valorar sin incorporarlos necesariamente al contrato inicial.
• Fuera de alcance: lo que no se incluye expresamente para prevenir interpretaciones.
• Descubrimiento: trabajo previo necesario para cerrar incertidumbres sobre procesos, datos, integraciones o diseño.

Solicita también una relación expresa de entregables: código y repositorio si así se acuerda, documentación funcional y técnica, configuración, pruebas, manuales, formación, despliegue y accesos. La entrega no debería quedar reducida a que la aplicación funcione un día en producción. Revisa con detalle qué debe entregar un desarrollador de software a medida antes de cerrar condiciones.

Cómo pedir presupuestos realmente comparables

Incluye un formato de respuesta obligatorio. No limita la capacidad del proveedor para aportar criterio: le obliga a declarar sus supuestos y permite comparar la misma información. Este artículo se centra en preparar el documento antes de solicitar ofertas; la evaluación de las propuestas recibidas requiere una revisión posterior de alcance, condiciones y coste total.

Pide a todos los proveedores que indiquen

• Requisitos cubiertos, parcialmente cubiertos, excluidos o pendientes de validación.
• Desglose por fase, módulo, integración y opción adicional.
• Supuestos, dependencias del cliente y datos que necesitan para empezar.
• Riesgos identificados y circunstancias que obligarían a revisar la estimación.
• Calendario estimado, hitos, metodología y equipo previsto.
• Pruebas y criterios de aceptación propuestos antes de cada entrega.
• Costes iniciales y recurrentes separados: infraestructura, licencias, servicios de terceros, soporte, mantenimiento y evolutivos.
• Condiciones de garantía, soporte, actualizaciones, subcontratación y gestión de incidencias.
• Acceso al código, repositorios, cuentas, documentación y datos, además de las condiciones de salida.

No existe un plazo, precio ni porcentaje de mantenimiento universal. Dependen del alcance, la calidad de los datos, las integraciones, el riesgo, la disponibilidad del equipo y las condiciones operativas. Por eso, no compares solo el total inicial: compara primero el alcance equivalente y el coste total previsto bajo los supuestos declarados.

Para evaluar las ofertas una vez recibidas, consulta Cómo comparar presupuestos de software a medida sin fijarse solo en el precio.

Matriz para comparar las propuestas

Crea una tabla con una columna por proveedor y conserva en ella todas las preguntas y aclaraciones. La puntuación puede ser útil si se apoya en evidencias de la oferta, pero no hay ponderaciones universales: cada empresa debe decidir qué factores son críticos para su caso.

Cuando el proyecto justifique un control más formal, utiliza una matriz de trazabilidad para relacionar objetivos, requisitos, implementación y pruebas. Su valor no está en rellenar una tabla, sino en detectar requisitos sin prueba, funcionalidades sin objetivo o decisiones que nadie ha validado.

Preguntas que todos los proveedores deben responder

1. ¿Qué requisitos no están incluidos, se cubren parcialmente o requieren análisis adicional?
2. ¿Qué supuestos y dependencias del cliente sustentan la propuesta?
3. ¿Cómo se tratarán las integraciones, la migración y la calidad de los datos?
4. ¿Qué pruebas y criterios de aceptación se aplicarán antes de cada entrega?
5. ¿Qué parte del trabajo se subcontratará y quién asume la responsabilidad de cada entrega?
6. ¿Cómo se gestionarán accesos, copias, incidencias, continuidad y actualizaciones?
7. ¿Qué soporte, mantenimiento y garantía están incluidos y qué se factura aparte?
8. ¿Quién tendrá acceso al código, repositorios, cuentas cloud, documentación y datos?
9. ¿Cómo podrá exportarse la información y finalizar la relación sin una dependencia innecesaria?

Si el proyecto procesa datos personales, pagos, información sanitaria, recursos humanos u otra información sensible, adapta los requisitos de seguridad, privacidad, continuidad y conservación al tratamiento real. Las condiciones contractuales y de protección de datos requieren revisión especializada; no deben resolverse con una frase genérica dentro del briefing.

Revisión final antes de enviar la solicitud

• Comprueba que cada requisito tiene prioridad y criterio de aceptación, o indica que debe descubrirse.
• Revisa contradicciones entre alcance, integraciones, datos, seguridad, calendario y presupuesto disponible.
• Define anexos, versiones y canal para comunicar aclaraciones a todos los proveedores por igual.
• Decide qué información sensible es necesaria compartir y bajo qué medidas de protección.
• Fija fecha límite, formato de respuesta y personas autorizadas para resolver dudas.
• Valora una fase de descubrimiento si faltan datos críticos para una oferta cerrada.

Convierte el briefing en una solicitud de ofertas coherente

Completa primero el documento con el problema, los usuarios, el proceso actual, los requisitos priorizados, las integraciones, los criterios de aceptación y las condiciones de operación posteriores. Después pide a todos los proveedores una respuesta con el mismo formato y registra cualquier aclaración que cambie el alcance.

Un briefing no elimina toda la incertidumbre, especialmente en proyectos complejos. Sí permite decidir qué incertidumbres deben analizarse antes, cuáles pueden presupuestarse como opción y qué propuesta responde de forma más clara a la necesidad real de la empresa.