Software y sistemas

Cómo definir requisitos y alcance de software antes de cotizar

Un alcance útil no empieza con una lista extensa de funciones. Conecta necesidades, comportamiento observable, límites y evidencia para cotizar y decidir con menos ambigüedad.

Por Internal Organic30 de julio de 2026

Una empresa puede pedir “un sistema con usuarios, reportes, notificaciones e inteligencia artificial” y seguir sin haber definido qué problema necesita resolver. La lista parece concreta, pero no explica quién hará qué, con cuáles datos, bajo qué reglas ni cómo se comprobará que la solución funciona.

Definir requisitos de software consiste en convertir una necesidad operativa en comportamientos, límites y resultados verificables. El alcance organiza esa definición para que la empresa pueda comparar alternativas, recibir una cotización entendible y controlar cambios sin depender de interpretaciones.

Esta guía prepara el brief y el alcance desde el lado de la empresa compradora. Evaluar a quien diseñará o desarrollará la solución es una decisión posterior.

No hace falta escribir un documento de cientos de páginas. Sí hace falta dejar suficiente evidencia para distinguir lo obligatorio, lo supuesto y lo que todavía debe investigarse.

Brief de alcance

Ocho capas antes de pedir una cotización

Problema y resultado
Usuarios y contexto
Proceso y fronteras
Casos, reglas y excepciones
Datos e integraciones
Calidad y seguridad
Aceptación
Prioridades y exclusiones

Empieza por el problema y el resultado esperado

Describe la situación actual con hechos observables. Por ejemplo:

las solicitudes se copian entre tres archivos;
dos áreas usan identificadores diferentes para el mismo cliente;
nadie puede reconstruir quién aprobó un cambio;
el reporte semanal exige combinar datos manualmente;
una excepción detiene el proceso y solo una persona sabe resolverla.

Después formula el resultado operativo: “cada solicitud válida debe quedar registrada una sola vez, asignada a un responsable y disponible para seguimiento con historial”. Esa frase todavía no prescribe una plataforma, pero ya permite evaluar si una solución sirve.

La guía de servicios digitales de GOV.UK recomienda investigar primero qué intentan lograr las personas, cómo lo hacen actualmente y qué dificultades encuentran. También distingue la necesidad de la solución propuesta: necesitar una confirmación no equivale necesariamente a necesitar un correo.

Separa cuatro elementos:

problema: qué fricción o riesgo existe;
resultado: qué debe poder ocurrir;
evidencia: cómo sabrás que cambió;
restricción: qué condición no puede ignorarse.

“Modernizar la operación” no es verificable. “Reducir la doble captura y conservar el historial de asignación” sí orienta decisiones, aunque la meta cuantitativa se defina después de levantar una línea base.

Describe usuarios, tareas y contexto

Un rol no es solo un nivel de permiso. Representa a una persona que intenta completar una tarea bajo condiciones reales.

Para cada tipo de usuario registra:

objetivo y tareas frecuentes;
información que necesita para decidir;
acciones que puede ejecutar;
decisiones que requieren autorización;
volumen y frecuencia de uso;
dispositivo, ubicación o conectividad relevantes;
conocimiento esperado y necesidad de apoyo;
datos que puede consultar o modificar;
situaciones excepcionales que debe atender.

Incluye a quienes operan, supervisan, administran, reciben resultados y mantienen el sistema. Un panel cómodo para dirección puede aumentar el trabajo de captura del equipo. Una pantalla eficaz en escritorio puede fallar para quien registra una visita desde el teléfono.

Observa tareas reales y utiliza datos de ejemplo sanitizados. Las opiniones internas sirven para plantear supuestos; no sustituyen la evidencia de las personas que hacen el trabajo.

Delimita el proceso y las fronteras del sistema

Antes de describir pantallas, dibuja el tramo operativo que la solución debe sostener.

Define:

evento que inicia el proceso;
condición de entrada;
pasos y decisiones principales;
responsables y traspasos;
resultado que marca el final;
sistemas que participan;
información que entra y sale;
actividades que continuarán fuera de la solución.

La frontera evita que “integrar ventas” termine incluyendo sin decisión inventario, facturación, soporte y analítica avanzada. También revela dependencias: quizá el sistema puede registrar una orden, pero no confirmar el pago si el proveedor externo no entrega ese estado.

Cuando el proceso todavía cambia cada semana o nadie puede explicarlo de principio a fin, conviene resolver ese descubrimiento antes de prometer un alcance fijo. La comparación entre software a medida, SaaS e integración ayuda a decidir si realmente hace falta construir.

Convierte necesidades en comportamientos verificables

Un requisito útil describe qué debe ocurrir y en cuáles condiciones. Evita adjetivos como “intuitivo”, “robusto”, “rápido” o “completo” sin una forma acordada de comprobarlos.

Ejemplos de requisitos de software ambiguos y verificables
Ambiguo	Más verificable
El sistema tendrá permisos seguros.	Solo el rol de supervisión puede reasignar una oportunidad y cada cambio conserva responsable, fecha, valor anterior y valor nuevo.
Habrá notificaciones automáticas.	Cuando una solicitud válida quede sin responsable, el sistema crea una alerta para la cola comercial y registra su estado de entrega.
El reporte será rápido.	El reporte mensual acordado debe completarse dentro del umbral definido con el volumen de prueba establecido.
La plataforma se integrará con el CRM.	Al confirmar un registro, envía los campos acordados al CRM, conserva el identificador remoto y dirige los errores a una cola de reintento.

La NASA propone revisar que cada requisito sea claro, correcto, factible, necesario, no ambiguo y verificable. El contexto es distinto al de una PyME, pero el criterio es útil: si dos personas pueden entender resultados diferentes, todavía falta definición.

Conserva una relación entre necesidad, requisito y prueba. Esa trazabilidad permite preguntar por qué existe una función y qué se afecta cuando cambia.

Separa funciones de cualidades operativas

Los requisitos funcionales explican acciones: registrar, validar, calcular, asignar, consultar, aprobar, exportar o notificar. No describen por sí solos la calidad necesaria para operar.

Revisa también:

seguridad: autenticación, permisos, sesiones, auditoría y manejo de secretos;
privacidad: datos necesarios, consentimiento, retención, acceso y eliminación;
rendimiento: tareas críticas, volumen de prueba y tiempos aceptables;
disponibilidad y recuperación: respaldo, restauración y tolerancia a fallas;
accesibilidad: uso por teclado, foco, etiquetas, contraste y mensajes;
compatibilidad: dispositivos, navegadores, formatos o versiones requeridas;
mantenibilidad: observabilidad, documentación, despliegue y responsables;
portabilidad: exportación de datos y condiciones de salida.

No copies una lista genérica. Define cada calidad según el riesgo de la operación. Un portal público, una herramienta interna y un sistema que procesa datos sensibles no necesitan exactamente el mismo nivel de control.

NIST recomienda integrar prácticas de seguridad al ciclo de desarrollo y documentar los requisitos aplicables. OWASP ASVS puede servir como base verificable para controles de seguridad en aplicaciones web, mientras que WCAG 2.2 expresa criterios de accesibilidad comprobables y neutrales respecto a la tecnología. La revisión especializada sigue siendo necesaria cuando existen obligaciones legales, sectoriales o riesgos altos.

Define datos, reglas e integraciones

Las pantallas cambian; los contratos de información suelen afectar toda la solución.

Para cada entidad —por ejemplo, contacto, empresa, solicitud, oportunidad o tarea— registra:

identificador estable;
campos necesarios y propósito;
formato y catálogo permitido;
dato obligatorio por estado;
relaciones con otras entidades;
fuente de verdad;
regla de duplicado;
historial necesario;
permisos;
retención y salida.

Después documenta las reglas de negocio con condición, acción y excepción. “Asignar automáticamente” necesita explicar qué ocurre según zona, oferta, capacidad, horario y ausencia de responsable.

Para cada integración define origen, destino, dirección, frecuencia, autenticación, campos, identificador común, límites, reintentos, reconciliación y dueño. “Existe una API” no demuestra que el flujo pueda conservar contexto ni recuperarse de una falla.

Documenta excepciones y estados de falla

El camino ideal rara vez representa todo el trabajo. Pregunta:

¿Qué pasa si falta un dato?
¿Qué pasa si llegan dos registros de la misma persona?
¿Qué pasa si el servicio externo no responde?
¿Qué pasa si una aprobación se rechaza?
¿Qué pasa si la notificación no se entrega?
¿Qué pasa si cambia el responsable?
¿Qué puede corregirse y quién puede hacerlo?
¿Cómo se detecta que el flujo quedó detenido?

Cada excepción importante necesita un estado visible, una acción de recuperación, un responsable y evidencia. Ocultar el error detrás de un mensaje genérico puede hacer que la interfaz parezca limpia mientras la operación pierde solicitudes.

Escribe criterios de aceptación antes de cotizar

El criterio de aceptación describe la evidencia que permitirá aprobar un resultado. Puede ser una prueba, demostración, inspección, medición o revisión documental.

Para un flujo de asignación, los casos podrían incluir:

solicitud válida con responsable disponible;
solicitud válida sin coincidencia de regla;
registro duplicado con contexto nuevo;
dato obligatorio ausente;
CRM temporalmente fuera de servicio;
reintento exitoso;
reintentos agotados y atención manual;
consulta del historial por un rol autorizado.

Define datos sintéticos, estado inicial, acción, resultado esperado y evidencia. Incluye casos normales, límites, errores, permisos y recuperación.

Los criterios también mejoran una cotización: el proveedor puede estimar lo que debe demostrar, no solo lo que debe programar. La guía para elegir una empresa de desarrollo de software explica cómo revisar descubrimiento, entrega, propiedad y soporte.

Prioriza y declara lo que queda fuera

Clasifica cada necesidad por valor, riesgo y dependencia. Una estructura sencilla puede ser:

obligatorio para operar: sin ello el resultado no existe o el riesgo es inaceptable;
necesario para la primera mejora: aporta valor, pero puede entrar después del flujo mínimo;
posterior: requiere aprendizaje, volumen o dependencias todavía no disponibles;
fuera de alcance: no pertenece a esta fase o será atendido por otro sistema.

Evita llamar “mínimo” a una solución que elimina seguridad, respaldo o manejo de errores. El alcance inicial puede tener menos casos de uso, pero los que incluya deben poder operarse.

Anota exclusiones de manera explícita: migración histórica, compra de licencias, contenido, hardware, soporte, capacitación, integraciones futuras o disponibilidad fuera de horario. Una cotización corta puede parecer menor porque trasladó trabajo a una lista implícita.

Haz visibles supuestos, dependencias y decisiones

Un supuesto es algo que todavía no está confirmado: volumen, calidad de datos, acceso a API, disponibilidad del equipo o capacidad de un proveedor. Registra:

enunciado;
impacto si es falso;
responsable de confirmarlo;
evidencia necesaria;
fecha límite;
decisión relacionada.

Mantén también un registro breve de decisiones: alternativa evaluada, criterio, resolución y consecuencia. Así el proyecto puede aprender sin reabrir cada conversación ni convertir una preferencia antigua en una regla invisible.

Controla cambios sin congelar el aprendizaje

Los requisitos evolucionan cuando aparecen usuarios, excepciones o restricciones que no se conocían. El problema no es cambiar; es hacerlo sin entender impacto.

Establece una versión de referencia para cotizar y, después, un flujo de cambio:

describir necesidad y motivo;
relacionarla con el alcance vigente;
evaluar impacto en datos, seguridad, pruebas, costo y calendario;
decidir si sustituye, amplía o se pospone;
actualizar requisito, aceptación y trazabilidad;
comunicar la decisión a quienes operan y entregan.

No uses el documento como una promesa rígida cuando todavía existe descubrimiento. Separa lo confirmado de las preguntas abiertas y cotiza fases cuando la incertidumbre es material.

Qué entregar a un proveedor para cotizar

Un brief útil puede contener:

contexto del negocio y problema;
resultado esperado y evidencia actual;
usuarios, tareas y permisos;
mapa del proceso y frontera;
casos de uso prioritarios;
reglas y excepciones;
modelo inicial de datos;
integraciones y dependencias;
requisitos de calidad, seguridad y accesibilidad;
criterios de aceptación;
alcance, exclusiones y fases;
materiales disponibles y preguntas abiertas;
responsables de decisión y validación.

No necesitas diseñar la arquitectura técnica por el proveedor. Sí necesitas ofrecer el contexto suficiente para que explique alternativas, riesgos y supuestos. Si dos propuestas interpretan alcances distintos, comparar solo el precio producirá una decisión falsa.

Señales de un alcance débil

Empieza por pantallas y funciones, no por el problema.
Usa adjetivos sin criterio de prueba.
Ignora usuarios internos, permisos o excepciones.
Dice “integración” sin contrato de datos.
No separa requisito confirmado de supuesto.
Omite seguridad, accesibilidad y recuperación.
Deja migración y calidad de datos para el final.
No incluye aceptación ni datos de prueba.
No declara exclusiones.
Trata cada cambio como una conversación sin registro.

Un buen alcance permite decidir antes de construir

Definir requisitos no elimina toda incertidumbre. La vuelve visible y permite administrarla. Una empresa puede descubrir que basta con configurar una herramienta, que necesita integrar sistemas existentes o que sí existe una particularidad estable que justifica desarrollo propio.

El documento útil no es el más largo. Es el que conecta problema, usuario, comportamiento, datos, riesgo y evidencia con suficiente claridad para comparar opciones y construir por etapas.

Internal Organic diseña software y sistemas conectados con la operación. El diagnóstico inicial ayuda a ordenar necesidades, delimitar el alcance y decidir qué conviene configurar, integrar o desarrollar antes de comprometer una implementación.