Cómo escribir requisitos técnicos para una licitación de software

Describe el problema antes que la solución

Unas bases que parten por la tecnología («un sistema web con base de datos relacional») obligan a todos los oferentes a resolver lo mismo del mismo modo. Parten mejor describiendo qué proceso se quiere resolver, quién lo usa, con qué volumen y qué pasa hoy.

Conviene incluir cuántas personas lo usarán y con qué roles, cuántos registros o solicitudes se manejan en un mes típico y en el peor mes, y qué errores o demoras son los más costosos. Con eso cada oferente puede dimensionar sin adivinar.

Define el alcance en entregables verificables

Un alcance escrito como lista de funciones sueltas se interpreta de tantas formas como oferentes hay. Es más útil enumerar entregables que se puedan revisar uno a uno:

• Módulos o funciones, cada una con el flujo que debe cubrir.
• Integraciones con otros sistemas, indicando cuáles son y qué datos intercambian.
• Migración de datos desde los sistemas actuales, con su estado y volumen.
• Capacitación de quienes lo operarán.
• Documentación técnica y manual de operación.

Lo que queda fuera del alcance también se escribe. Una exclusión explícita evita discusiones durante la ejecución.

Declara los sistemas y datos con los que debe convivir

La mayor parte de los sobrecostos de un software aparece en las conexiones con lo que ya existe. Conviene entregar un inventario simple: qué sistemas hay, qué datos tiene cada uno, quién lo opera, qué formatos de intercambio ofrece (API, archivos, acceso a base de datos) y quién es dueño de cada dato.

Si no hay API o la documentación es incompleta, se dice. Es una restricción real del proyecto y cambia el esfuerzo y el riesgo.

Escribe criterios de aceptación medibles

«El sistema debe ser rápido» no se puede aceptar ni rechazar. «Un usuario con el rol X completa la tarea Y en menos de N pasos» sí. Cada entregable debería tener una frase de este tipo, junto con la forma de comprobarla:

• Pruebas con datos reales anonimizados, no con datos de ejemplo.
• Casos de error definidos: qué pasa si un sistema externo no responde, si llegan datos incompletos o si un envío se repite.
• Quién revisa y firma la aceptación de cada etapa, y en qué plazo.

Exige propiedad y traspaso

Antes de adjudicar conviene dejar claro qué recibe la institución al terminar: el repositorio de código, los diagramas y la documentación técnica, los accesos a los servicios configurados y las licencias de terceros, si las hay. Sin eso, mantener o cambiar de proveedor se vuelve una nueva dependencia.

También ayuda pedir una sesión de traspaso con el equipo que operará el sistema y definirla como parte del último entregable.

Pide soporte con niveles definidos

El soporte se compara cuando está expresado en números: tiempo de primera respuesta, tiempo de resolución según la gravedad del problema, duración de la garantía y qué cubre. Conviene separar la garantía (corregir defectos de lo entregado) de la evolución (nuevas funciones), que se contrata aparte.

Qué conviene no escribir

• Marcas o productos específicos sin necesidad técnica: limitan la competencia y obligan a justificar la exigencia.
• Cifras de usuarios o volúmenes sin respaldo: es mejor indicar el rango real y su fuente.
• Plazos fijados antes de conocer el alcance: el plazo sale del trabajo, no al revés.

Cuando falta información para escribir las bases

Si la institución todavía no tiene claro el inventario de sistemas o el alcance, una evaluación técnica previa entrega justo eso: la arquitectura recomendada, las alternativas, los riesgos, los criterios de aceptación y una estimación por etapas, en un formato que puede usarse como base para una cotización o unas bases.