Documento de requisitos de software (Lastenheft): estructura, ejemplo y checklist

Un documento de requisitos (Lastenheft) describe, desde el punto de vista del cliente, qué debe hacer un software y por qué: objetivos, requisitos y condiciones marco en un documento que el cliente, el proveedor y los futuros usuarios entienden por igual. Para muchos proyectos de pymes bastan pocas páginas bien estructuradas. La recompensa: los presupuestos se vuelven comparables, los precios cerrados son posibles y la aceptación puede apoyarse en criterios verificables.

Tres presupuestos para el mismo proyecto de software y los precios están muy alejados entre sí. Rara vez se debe a proveedores poco serios; casi siempre es porque cada uno ha entendido algo distinto. Un buen documento de requisitos resuelve precisamente ese problema. Este artículo explica la diferencia con la especificación técnica, muestra la estructura que ha demostrado su eficacia, ofrece ejemplos de formulación y termina con una checklist.

Documento de requisitos y especifica­ción técnica: la diferencia

El documento de requisitos (Lastenheft) describe qué debe hacer el software y para qué. La norma alemana DIN 69901-5 lo define como el conjunto de requisitos establecidos por el cliente para los suministros y servicios de un contratista. La especificación técnica (Pflichtenheft) es la respuesta del proveedor: describe cómo se implementarán los requisitos, con qué arquitectura, qué tecnologías y qué enfoques. A nivel internacional se habla de una especificación de requisitos de software; el estándar ISO/IEC/IEEE 29148 aborda la ingeniería de requisitos en su conjunto.

Aspecto	Documento de requisitos	Especificación técnica
Autor	cliente	proveedor, acordada con el cliente
Pregunta clave	¿qué debe hacer el software y para qué?	¿cómo se va a implementar?
Contenido	objetivos, requisitos, condiciones marco	arquitectura, tecnologías, enfoques, plan de implementación
Momento	antes de solicitar presupuestos	tras el encargo o como parte del presupuesto
Utilidad	los presupuestos se vuelven comparables	base vinculante para la implementación y la aceptación

En proyectos pequeños, ambos documentos suelen reunirse en un único concepto. Lo importante no es el nombre del documento, sino que los requisitos y la propuesta de implementación estén claramente separados y relacionados entre sí.

Por qué compensa un buen documento de requisitos

• Presupuestos comparables: todos los proveedores calculan sobre la misma base.
• El precio cerrado se hace posible: cuanto más claro sea el alcance, más fiable será el cálculo de un precio cerrado.
• Menos trabajos adicionales: lo que está descrito no se convierte después en una sorpresa.
• Aceptación clara: puede comprobar si el resultado cumple los requisitos.
• Claridad interna: el simple hecho de redactarlo obliga a resolver las dudas dentro de la propia empresa.

Si el documento de requisitos, o la especificación técnica que se deriva de él, pasa a formar parte del contrato, sirve de criterio en la aceptación. Eso protege a ambas partes, sobre todo en proyectos a precio cerrado, que jurídicamente suelen calificarse como contrato de obra (Werkvertrag). Cómo debe valorarse su contrato en el caso concreto lo aclara su asesoría jurídica.

La estructura de un documento de requisitos

Un documento de requisitos no tiene por qué ser voluminoso. Esta estructura ha demostrado su eficacia:

Capítulo	Pregunta clave	Contenidos habituales
1. Situación de partida y objetivos	¿Cómo funciona hoy el proceso y qué debe cambiar?	problemas, objetivos verificables, por ejemplo “los presupuestos se crean sin reescritura manual”
2. Grupos de usuarios y roles	¿Quién trabaja con el software y quién puede hacer qué?	servicio interno, servicio externo, clientes, administradores
3. Requisitos funcionales	¿Qué debe poder hacer el software en concreto?	historias de usuario con finalidad, criterios de aceptación
4. Requisitos no funcionales	¿Qué calidad debe tener el software?	tiempos de respuesta, disponibilidad, seguridad, protección de datos, accesibilidad, dispositivos y navegadores
5. Interfaces y datos	¿Con qué sistemas se intercambian datos?	ERP, CRM, contabilidad, tienda; formato y volumen de los datos antiguos
6. Volúmenes	¿Qué volumen cabe esperar hoy y dentro de unos años?	usuarios, registros, documentos, transacciones
7. Condiciones marco	¿Qué condicionantes rigen en cuanto a plazo, presupuesto y recursos?	fecha deseada, marco presupuestario, personas de contacto, tiempo para pruebas, requisitos técnicos
8. Alcance de la entrega y operación	¿Qué incluye la entrega y cómo continúa todo después?	documentación, derechos de uso y código fuente, formación, alojamiento, mantenimiento y soporte
9. Criterios de aceptación	¿Cómo sabe que se ha cumplido un requisito?	criterios verificables, idealmente con casos de prueba concretos

Muchos clientes dudan en indicar un marco presupuestario por temor a que se agote por completo. Sin embargo, un marco ayuda a todos los implicados: los proveedores pueden proponer soluciones acordes en lugar de calcular a ciegas. Y usted recibe presupuestos realistas en lugar de maquillados.

Cómo formular los requisitos para que sean verificables

Requisitos funcionales: describir la finalidad y el comporta­miento

La forma de las historias de usuario ha demostrado su eficacia: “Como planificador, quiero asignar pedidos a un técnico arrastrando y soltando, para elaborar más rápido la planificación diaria”. Así no solo queda clara la función, sino también su finalidad. Complete las historias importantes con criterios de aceptación en la forma “Dado – Cuando – Entonces”: “Dado un pedido sin técnico, cuando el planificador lo asigna, entonces aparece en el calendario del técnico”. Una comparación muestra lo concreto que debe ser un requisito. Mal formulado: “El sistema debe gestionar pedidos”. Bien formulado:

El servicio interno crea los pedidos con cliente, servicio, fecha deseada y archivos adjuntos. Cada pedido tiene un estado: nuevo, planificado, completado, facturado. Al pasar a “completado”, contabilidad recibe automáticamente una tarea para emitir la factura.

La segunda versión es más larga, pero cualquier desarrollador la entiende igual. Ahí está precisamente su valor: los malentendidos se aclaran antes del proyecto, no después.

Hacer medibles los requisitos no funcionales

Términos como “rápido”, “sencillo” o “moderno” no se pueden verificar sin un criterio de medida. Fije en su lugar valores y límites:

• Rendimiento: en lugar de “rápido”, por ejemplo, “La lista de pedidos se carga en menos de dos segundos con 10.000 registros”.
• Disponibilidad: horarios de operación, tiempos de inactividad tolerables y ventanas de mantenimiento
• Seguridad y protección de datos: concepto de roles, ubicación del alojamiento, plazos de supresión, registro de actividad
• Accesibilidad: en las ofertas dirigidas a consumidores puede aplicarse la BFSG, vigente desde el 28 de junio de 2025.
• Dispositivos y navegadores: sistemas operativos y navegadores compatibles, tamaños de pantalla, capacidad sin conexión
• Operación: monitorización, copias de seguridad, horarios de soporte y tiempos de respuesta

Priorizar con obligatorio, deseable y opcional

No todos los requisitos son igual de importantes. Marque cada requisito como obligatorio, deseable u opcional. Los obligatorios forman la primera versión, los deseables siguen si hay presupuesto disponible y los opcionales son ideas para más adelante. Resulta útil un cuarto grupo: lo que deliberadamente no entra en esta versión se indica de forma expresa, lo que evita expectativas tácitas. Esta clasificación hace flexibles los presupuestos y protege de una primera versión sobrecargada.

Documento de requisitos, forma de contrato y desarrollo ágil

El desarrollo ágil se basa en ir afinando los requisitos durante el proyecto. Un documento de requisitos no lo impide. Describe objetivos, marco y los requisitos más importantes; los detalles se elaboran después en común, en etapas cortas. Así combina seguridad de planificación con la libertad de reaccionar ante nuevos conocimientos.

La forma de contrato también depende de con qué precisión pueda describir los requisitos de antemano. Si el alcance está claro, encaja un precio cerrado con una aceptación definida. Si queda mucho abierto, suele ser más honesto trabajar según el esfuerzo, por etapas y con resultados periódicos. El documento de requisitos muestra en cuál de las dos situaciones se encuentra.

Errores típicos y checklist

Errores típicos en un documento de requisitos

• Soluciones en lugar de requisitos: “Necesitamos una tabla con doce columnas” en lugar de “Debemos poder filtrar pedidos por estado”.
• Términos imprecisos: “rápido”, “sencillo”, “moderno”: sin un criterio de medida no se pueden verificar.
• Casos especiales ausentes: ¿qué ocurre con las anulaciones, las entregas parciales o las sustituciones?
• No consultar a los usuarios: quien usa el software a diario conoce mejor que nadie los escollos.
• Todo es obligatorio: sin prioridades, la primera versión se hace demasiado grande.
• Olvidar interfaces y datos antiguos: a menudo elevan el esfuerzo y el riesgo más que la interfaz de usuario.
• Nunca actualizado: un documento de requisitos que no se mantiene tras el inicio del proyecto pierde su valor como criterio de medida.

Checklist: ¿está completo su documento de requisitos?

• situación de partida y objetivos verificables descritos
• todos los grupos de usuarios y roles identificados
• requisitos funcionales formulados como historias de usuario con criterios de aceptación
• requisitos no funcionales definidos de forma medible
• interfaces y migración de datos descritas
• volúmenes indicados para hoy y para el futuro
• marco temporal y presupuestario indicado
• alcance de la entrega, operación y derechos de uso aclarados
• requisitos priorizados como obligatorios, deseables y opcionales
• criterios de aceptación verificables definidos

¿Sin documento de requisitos? Cómo le ayuda Nano Concepts

Muchas empresas no tienen ni el tiempo ni la experiencia para redactar un documento de requisitos completo. No es un obstáculo. En la primera consulta gratuita y, si lo desea, en un taller posterior, elaboramos los requisitos junto con usted y los recogemos en un concepto claro. Esta consultoría tecnológica suele ser la forma más rentable de empezar, porque evita malentendidos posteriores.

Tanto si llega con un documento terminado como con una primera idea, traducimos sus requisitos en un concepto realizable y le acompañamos en el desarrollo de software hasta el sistema en funcionamiento. Para proyectos que deben encajar exactamente con sus procesos, lea más sobre nuestro software a medida. Con un alcance claramente definido, preferimos elaborar un presupuesto a precio cerrado.

Este artículo no sustituye el asesoramiento jurídico.