32. Plantillas y estructura de un documento de requerimientos
Un documento de requerimientos organiza la información necesaria para comprender qué debe hacer un sistema, qué restricciones debe respetar y cómo se comprobará que satisface las necesidades acordadas.
La plantilla no debe ser un formulario rígido que se completa por obligación. Debe ser una guía práctica para registrar decisiones, reducir ambigüedades y facilitar la comunicación entre usuarios, analistas, desarrolladores, testers y responsables del proyecto.
32.1 Introducción
Después de aprender a redactar requerimientos claros, precisos y verificables, necesitamos ubicarlos dentro de una estructura documental ordenada. Esa estructura permite encontrar información, revisar cambios, validar acuerdos y mantener trazabilidad.
En este tema veremos las partes habituales de un documento de requerimientos y cómo adaptar una plantilla según el tamaño y la complejidad del proyecto.
32.2 Qué es un documento de requerimientos
Es un artefacto que describe las necesidades, funcionalidades, restricciones, reglas y criterios que debe cumplir un producto de software. Puede llamarse especificación de requerimientos, documento SRS, backlog detallado, catálogo de requerimientos o documento funcional, según el contexto.
Lo importante no es el nombre, sino que el documento permita entender qué se va a construir y bajo qué condiciones será aceptado.
32.3 Propósito del documento
El propósito explica para qué existe el documento. Puede servir para alinear expectativas, obtener aprobación, guiar el diseño, estimar esfuerzo, preparar pruebas, controlar cambios o documentar acuerdos contractuales.
Definir el propósito ayuda a decidir el nivel de detalle necesario. Un documento contractual suele requerir más formalidad que una especificación interna de un equipo pequeño.
32.4 Alcance del producto
El alcance delimita qué incluye y qué no incluye el sistema. Esta sección debe describir los objetivos principales, los procesos cubiertos, los usuarios afectados y los límites del producto.
También conviene registrar exclusiones explícitas. Muchas discusiones surgen porque una parte asumió que cierta funcionalidad estaba incluida y otra parte asumió lo contrario.
32.5 Contexto y antecedentes
El contexto presenta la situación actual, los problemas que motivan el proyecto, los sistemas existentes, las limitaciones conocidas y las razones por las cuales se necesita una solución.
Esta sección ayuda a que nuevos integrantes del equipo comprendan el origen de los requerimientos y evita analizar cada necesidad de forma aislada.
32.6 Definiciones, siglas y glosario
El glosario define términos del dominio, siglas, abreviaturas y conceptos que podrían interpretarse de distintas formas. Es una sección especialmente importante cuando participan áreas con vocabularios diferentes.
Un buen glosario reduce ambigüedad. Por ejemplo, términos como cliente, usuario, cuenta, solicitud, caso, pedido o contrato pueden tener significados específicos dentro de cada organización.
32.7 Interesados y usuarios
Esta sección identifica a los interesados relevantes: usuarios finales, responsables del negocio, administradores, áreas técnicas, áreas legales, soporte, seguridad, proveedores y otros sistemas.
También puede describir perfiles de usuario, responsabilidades, permisos generales y necesidades particulares de cada grupo.
32.8 Descripción general del sistema
La descripción general resume qué hará el sistema y cómo se relaciona con su entorno. Puede incluir una visión de alto nivel, módulos principales, procesos cubiertos e interfaces externas.
Esta sección no reemplaza el detalle de los requerimientos, pero ofrece una mirada inicial para entender el producto antes de entrar en cada funcionalidad.
32.9 Supuestos y dependencias
Los supuestos son condiciones que se consideran verdaderas mientras se planifica el proyecto, pero que podrían cambiar. Las dependencias son elementos externos que influyen en la solución, como servicios de terceros, datos, equipos, permisos o decisiones pendientes.
Documentarlos permite controlar riesgos. Si un supuesto deja de cumplirse, el impacto sobre los requerimientos puede evaluarse con mayor claridad.
32.10 Restricciones
Las restricciones limitan las alternativas de solución. Pueden ser tecnológicas, legales, presupuestarias, operativas, de seguridad, de infraestructura, de integración o de calendario.
Una restricción debe estar justificada. No es lo mismo una preferencia técnica que una obligación real del proyecto.
32.11 Requerimientos funcionales
Esta sección describe las funciones que el sistema debe ofrecer. Cada requerimiento funcional debería tener un identificador, descripción, actor, prioridad, reglas asociadas, criterios de aceptación y referencias relacionadas.
La organización puede hacerse por módulo, proceso de negocio, actor, caso de uso, épica, historia de usuario o área funcional.
32.12 Requerimientos no funcionales
Los requerimientos no funcionales definen atributos de calidad y condiciones generales del sistema, como rendimiento, seguridad, disponibilidad, usabilidad, mantenibilidad, compatibilidad, escalabilidad y accesibilidad.
Deben redactarse con métricas o criterios verificables. Si se escriben de forma genérica, resultan difíciles de probar y negociar.
32.13 Reglas de negocio
Las reglas de negocio establecen políticas, cálculos, validaciones, límites y decisiones propias del dominio. Algunas reglas pueden aplicarse a muchos requerimientos funcionales.
Separar las reglas de negocio ayuda a evitar duplicación y facilita su mantenimiento cuando cambian.
32.14 Interfaces externas
El documento debe registrar las interacciones con otros sistemas, dispositivos, servicios, usuarios o canales. Esto puede incluir APIs, archivos, mensajes, reportes, sistemas legados, pasarelas de pago o servicios de autenticación.
Para cada interfaz conviene indicar datos intercambiados, formato, frecuencia, responsables, errores posibles y restricciones de seguridad.
32.15 Datos y entidades principales
Una sección de datos puede describir entidades importantes, atributos relevantes, identificadores, relaciones, estados y reglas de validación.
No siempre es necesario incluir un modelo de datos completo, pero sí conviene documentar aquellos conceptos que son esenciales para comprender los requerimientos.
32.16 Criterios de aceptación
Los criterios de aceptación indican cómo se determinará si un requerimiento fue cumplido. Pueden estar asociados a cada requerimiento o agruparse por funcionalidad.
Deben ser claros, observables y verificables. Funcionan como puente entre requerimientos, pruebas y aceptación del producto.
32.17 Matriz de trazabilidad
La matriz de trazabilidad relaciona requerimientos con objetivos, interesados, casos de uso, historias, diseños, código, pruebas, defectos y cambios.
Esta matriz es útil para analizar impacto, verificar cobertura de pruebas y justificar por qué existe cada requerimiento.
32.18 Priorización y estado
Cada requerimiento debe tener prioridad y estado. La prioridad ayuda a decidir el orden de implementación; el estado permite saber si está propuesto, en análisis, aprobado, implementado, probado, rechazado o modificado.
Estos datos convierten el documento en una herramienta de gestión, no solo en un repositorio de texto.
32.19 Control de cambios
El control de cambios registra modificaciones importantes realizadas sobre los requerimientos. Puede incluir fecha, autor, motivo, descripción del cambio, versión afectada y aprobación correspondiente.
Sin control de cambios, es difícil reconstruir decisiones y entender por qué el documento evolucionó de determinada manera.
32.20 Anexos
Los anexos pueden incluir prototipos, diagramas, actas de reunión, normativas, ejemplos de reportes, archivos de referencia, decisiones de arquitectura, estudios previos o documentación de sistemas externos.
Deben usarse para complementar el documento, no para esconder información esencial que debería estar en el cuerpo principal.
32.21 Plantilla sugerida
Una plantilla básica puede incluir:
- Portada, versión, responsables y fecha.
- Propósito, alcance, contexto y exclusiones.
- Glosario, interesados y perfiles de usuario.
- Descripción general del sistema.
- Supuestos, dependencias y restricciones.
- Requerimientos funcionales y no funcionales.
- Reglas de negocio, interfaces y datos relevantes.
- Criterios de aceptación, trazabilidad y control de cambios.
32.22 Adaptación según el proyecto
No todos los proyectos necesitan el mismo nivel de documentación. Un proyecto pequeño puede usar una plantilla breve, mientras que un sistema crítico, regulado o contratado externamente puede requerir una especificación más formal.
La regla práctica es documentar lo suficiente para reducir riesgos, facilitar acuerdos y permitir mantenimiento, sin generar una carga burocrática innecesaria.
32.23 Errores frecuentes
Algunos errores comunes son copiar plantillas sin adaptarlas, llenar secciones sin contenido útil, mezclar requerimientos con decisiones de implementación, omitir criterios de aceptación y no mantener actualizado el documento.
También es un error tratar el documento como algo que se escribe una vez y luego se abandona. Los requerimientos evolucionan y la documentación debe acompañar esa evolución.
32.24 Buenas prácticas
Conviene usar identificadores únicos, mantener una estructura consistente, escribir secciones breves, vincular información relacionada, registrar versiones y revisar el documento con las personas que lo usarán.
También es útil combinar texto con tablas, listas, diagramas y ejemplos cuando ayuden a comprender mejor el contenido.
32.25 Qué debes recordar
Una plantilla de requerimientos debe facilitar claridad, trazabilidad, validación y mantenimiento. No debe convertirse en una formalidad vacía ni en un obstáculo para el trabajo del equipo.
La estructura adecuada depende del proyecto, pero siempre debe ayudar a responder qué se necesita, por qué, para quién, con qué restricciones y cómo se verificará.
32.26 Conclusión
Un documento de requerimientos bien estructurado convierte información dispersa en acuerdos organizados y utilizables. Permite comunicar mejor, controlar cambios, preparar pruebas y mantener una visión compartida del producto.
En el siguiente tema estudiaremos las historias de usuario y cómo se utilizan para expresar necesidades en contextos ágiles.