Requerimientos de Software: Guía Completa con Plantilla Descargable

Los requerimientos de software son las condiciones y capacidades que un sistema debe cumplir, escritas una por línea, con un ID, una prioridad y una forma de verificar que se cumplieron. Sin ese documento, los proyectos fallan por la vía cara: sobrecostos, retrabajos y entregas que el cliente rechaza porque cada quien entendió algo distinto.

Esta guía es para dueños de negocio, gerentes de operación y líderes de proyecto que van a contratar o construir un sistema. Al terminar te llevas tres cosas: una plantilla editable lista para copiar a Excel o Google Sheets, un ejemplo completo llenado para un e-commerce y criterios de aceptación verificables en formato Given/When/Then. Copia la plantilla de la sección 5, compárala con el ejemplo de la sección 6 y valida tu documento con el checklist final antes de firmar nada.

Un requerimiento de software es una condición o capacidad que el sistema debe cumplir y que alguien puede comprobar. La prueba es simple: si nadie puede verificar que el sistema la cumple, no es un requerimiento, es un deseo. "El sistema debe ser rápido" es un deseo. "La búsqueda responde en menos de 2 segundos con 100 usuarios concurrentes" es un requerimiento.

Hay dos grandes familias. Los funcionales describen qué hace el sistema, acción por acción ("el sistema genera un folio único al confirmar la orden"). Los no funcionales describen con qué calidad lo hace: rendimiento, seguridad, disponibilidad, usabilidad.

También conviene distinguir los documentos. El BRD (Business Requirements Document) lo escribe el negocio con su proveedor y responde qué necesita la empresa y cómo sabrá que lo obtuvo. El SRS (Software Requirements Specification) lo detalla el equipo técnico: interfaces, datos, estados y casos de error. Para la mayoría de los proyectos empresariales, un BRD bien hecho basta; el SRS solo hace falta cuando hay una entrega formal entre equipos, como explica esta guía de plantillas de documento de requerimientos (consultada en septiembre de 2026).

Omitirlos tiene un costo concreto: el mismo malentendido detectado en el documento cuesta una conversación; detectado en la entrega, implica rehacer diseño, código y pruebas. Ahí nacen los sobrecostos, los retrabajos y el rechazo en las pruebas de aceptación (UAT).

Un documento sano mezcla cuatro tipos. La falla más común es documentar solo los funcionales y descubrir los otros tres en producción, cuando ya son cambios urgentes.

Los requerimientos de usuario suelen escribirse como historias con criterios de aceptación en formato Given/When/Then, una práctica que detalla esta referencia de criterios de aceptación para analistas de negocio (consultada en septiembre de 2026). Los no funcionales son los que más se omiten: nadie escribe "el sistema debe aguantar el Buen Fin" hasta que el Buen Fin tira el sistema.

La regla de oro: todo criterio de aceptación debe ser observable, medible y tener una evidencia acordada antes de programar. Si dos personas lo leen y llegan a conclusiones distintas, todavía está ambiguo.

El formato más útil es Gherkin: Given (contexto inicial), When (evento o acción), Then (resultado observable). Escribe siempre el escenario positivo y al menos uno negativo:

• Positivo: Dado un cliente con productos en el carrito, cuando confirma el pago con tarjeta, entonces el sistema genera el folio y envía la confirmación por correo en menos de 2 minutos.
• Negativo: Dado un pago rechazado por el banco, cuando el cliente intenta confirmar, entonces el sistema muestra el motivo del rechazo, no genera folio y conserva el carrito intacto.

Antes de dar por terminado un criterio, pásalo por este checklist de 8 puntos, basado en la guía de criterios de aceptación de Leeonex (consultada en septiembre de 2026):

• Nombra el propósito del usuario o la regla de negocio.
• Define el contexto: estado inicial, rol, datos y permisos.
• Establece el evento: acción del usuario o evento del sistema.
• Describe el resultado observable, sin detalles de implementación.
• Cubre las excepciones: datos inválidos, duplicados, tiempos de espera, accesos denegados.
• Fija el límite de calidad que aplica: rendimiento, seguridad o accesibilidad con número.
• Acuerda la evidencia: método de prueba, ambiente, datos y resultado que se conserva.
• Nombra al owner: quién verifica y quién acepta o rechaza.

Cuando auditamos documentos de clientes, el patrón que más retrasa la entrega es el criterio sin escenario negativo: el equipo programa el camino feliz y el primer pago rechazado en producción se convierte en junta de emergencia.

Esta es la tabla que usamos como registro de requerimientos. Es una tabla lista para copiar a Excel o Google Sheets: selecciona las columnas, pégala en tu hoja y agrega una fila por requerimiento. La estructura sigue la misma lógica de la plantilla de Rock (consultada en septiembre de 2026): ID, prioridad MoSCoW, criterio ejecutable y evidencia.

Cómo llenar cada columna:

• ID: un código único por línea (REQ-01, REQ-02...). Nunca lo reutilices, aunque el requerimiento se cancele.
• Requerimiento: una sola necesidad por fila, en la forma "el sistema + verbo + condición medible".
• Tipo: funcional, no funcional, de negocio o de usuario.
• Prioridad (MoSCoW): Must (sin esto no se lanza), Should (importante, no bloqueante), Could (deseable), Won't (fuera de esta versión).
• Criterio de aceptación: la prueba que alguien ejecutará, con número o resultado observable.
• Evidencia requerida: qué se archiva al pasar la prueba: log, reporte, captura o acta firmada.
• Owner: la persona que verifica y acepta. Un nombre, no un departamento.

La columna que vale el documento es la del criterio de aceptación. Léela tapada y la tabla es una lista de deseos; léela visible y es un plan de pruebas.

Contexto del proyecto: una tienda de materiales con 320 SKUs migra su catálogo a una tienda en línea. Hay 3 roles de usuario (cliente, administrador de catálogo y gerente de ventas) y la fecha de lanzamiento es inamovible por una campaña ya contratada. Los datos son ilustrativos; úsalos como modelo de redacción, no como alcance de tu proyecto.

Requerimientos funcionales. Diez líneas, cada una con prioridad MoSCoW y criterio ejecutable:

Requerimientos no funcionales. Los cinco que más pesan en un e-commerce: rendimiento, capacidad, seguridad, respaldos y compatibilidad.

Matriz de trazabilidad. Liga cada requerimiento con su caso de prueba y la evidencia que lo cierra. Sin esta tabla, la aceptación se negocia de memoria:

En los proyectos que revisamos antes de cotizar, la tabla de trazabilidad es la pieza que casi nunca existe: hay lista de funciones, pero nadie puede decir qué prueba cierra cada una. Es el primer documento que pedimos.

Los tres errores que más vemos al revisar documentos que llegan de proyectos anteriores:

• Requerimientos ambiguos. "Debe ser rápido" no se puede probar. La corrección: "carga en menos de 2 segundos con 100 usuarios concurrentes". Toda palabra como rápido, fácil o amigable es un número que aún no se escribe.
• Falta de priorización MoSCoW. Si los 40 requerimientos son indispensables, ninguno lo es. El equipo priorizará por su cuenta, en silencio, y te enterarás en el lanzamiento de cuáles no entraron. Taller MoSCoW con el cliente sosteniendo las tarjetas, y la columna Won't no puede quedar vacía.
• Criterios sin evidencia acordada. Un criterio que el desarrollador escribió es una prueba que el desarrollador pasará. El criterio y su evidencia los define quien pidió el requerimiento, antes de programar, como insiste la guía de Leeonex (consultada en septiembre de 2026).

Antes de firmar el alcance o soltar el primer pago, verifica que tu documento cumpla estos cinco puntos. Si falta uno, el documento todavía no está listo:

• Cada requerimiento tiene ID único que nunca se reutiliza.
• Cada línea tiene prioridad MoSCoW asignada (Must, Should, Could o Won't).
• Cada criterio de aceptación está en formato Given/When/Then, con escenario positivo y negativo.
• Cada requerimiento tiene evidencia definida: prueba, log, reporte o captura.
• Cada requerimiento tiene un owner de aceptación nombrado por su nombre.

Un documento que pasa los cinco filtros se puede cotizar con precisión. Eso cambia el precio que te dan: con el alcance verificable, ningún proveedor serio necesita inflar la propuesta para cubrirse de lo que no se dijo. Puedes comparar escenarios en nuestra guía de cuánto cuesta un software a medida.

¿Cuántos requerimientos son necesarios para un MVP? Entre 10 y 25 funcionales bien escritos, cada uno con su criterio y su prioridad. El ejemplo de esta página arranca con 10 y cubre el lanzamiento completo. Si tu lista pasa de 40, el proyecto necesita dividirse en fases, no un documento más largo.

¿Quién debe escribirlos: BA, PM o desarrolladores? Quien entienda el negocio y sepa escribir condiciones verificables, con acceso directo a los usuarios. En la práctica funciona mejor cuando el proveedor redacta y el cliente valida línea por línea contra su operación. Los criterios de aceptación siempre los define quien pidió el requerimiento; si los escribe quien lo construye, la prueba está arreglada desde el inicio.

¿Cómo manejar cambios durante el desarrollo? Los cambios son normales al ver el sistema funcionando. Lo que no debe cambiar gratis es el acuerdo: cada modificación entra por escrito a la tabla de trazabilidad, se evalúa su impacto en tiempo y costo, y el owner la aprueba. El problema nunca es el cambio; es el cambio verbal que nadie registró.

Copia la plantilla a Excel o Google Sheets, llénala con tu equipo y compárala contra el ejemplo del e-commerce. Valida el resultado con el checklist de cinco puntos antes de firmar cualquier alcance.

Si tu proceso cruza varios sistemas o tiene excepciones que nadie documentó, una consultoría de software hace el levantamiento contigo: entrevistas, observación del proceso y revisión de tus sistemas actuales. Y cuando el documento esté listo, nuestro servicio de desarrollo de software a medida lo convierte en un sistema con criterios de aceptación escritos antes de programar, revisiones semanales y código y datos de tu propiedad.

Para una propuesta sobre tu caso, envíanos el proceso a sistematizar, los usuarios y roles, y los sistemas existentes. Solicitar una cotización de desarrollo de software.