Cómo Escribir un Documento de Especificación de Requerimientos de Software (SRS)
Adaptación maestra y traducción técnica del estándar de ingeniería de requerimientos de Perforce Software, enriquecida con metodología para levantamientos remotos a más de 2,500 km de distancia, sintaxis EARS, criterios BDD y herramientas interactivas.
¿Qué es un Documento SRS y Por Qué es Vital?
Imagina el SRS como el plano arquitectónico o la hoja de ruta definitiva del software que vas a construir. Es la fuente única de verdad (*Single Source of Truth*) que alinea a los interesados del negocio con los equipos de ingeniería, independientemente de si el proyecto se gestiona bajo metodologías Ágiles (Scrum, Kanban), Cascada (*Waterfall*) o híbridas.
Los 5 Elementos Fundamentales de un SRS
Propósito
Establece por qué se construye el software, qué objetivo estratégico persigue la organización y cuál es su alcance delimitado.
Descripción General
Define qué hará la solución a alto nivel, el contexto operativo, los usuarios objetivo y los supuestos tecnológicos.
Requerimientos Específicos
Detalla cada funcionalidad concreta, restricciones técnicas, interfaces externas y atributos no funcionales de calidad.
Trazabilidad (Links)
Conecta historias de usuario y tareas de desarrollo con requerimientos y casos de prueba de QA de extremo a extremo.
Proceso de Aprobación
Garantiza el acuerdo formal y las firmas de todas las partes interesadas antes de invertir horas de programación.
¿Quiénes Usan el SRS en la Organización?
| Rol en el Equipo | Cómo Interactúa con el SRS |
|---|---|
| Product Owners & Analistas de Negocio | Definen, documentan y priorizan las necesidades del cliente y las reglas de negocio. |
| Desarrolladores & Arquitectos de Software | Entienden con exactitud matemática qué construir, qué APIs diseñar y qué datos almacenar. |
| Ingenieros de Calidad & Testing (QA) | Diseñan los casos de prueba de aceptación y validan que el código cumpla con los criterios definidos. |
| Líderes de Proyecto & Scrum Masters | Monitorean el alcance (*scope*), gestionan riesgos y controlan los tiempos de entrega. |
| Clientes & Patrocinadores (*Stakeholders*) | Revisan y aprueban las funcionalidades esperadas, garantizando el retorno de inversión. |
Beneficios Clave de Redactar un SRS Riguroso
Elimina ambigüedades mediante el uso de lenguaje técnico controlado.
Define con precisión matemática qué significa que una funcionalidad sea exitosa.
Vincula cada requerimiento con su diseño, líneas de código y pruebas automatizadas.
Asegura que cada característica sea verificable empíricamente desde el día 1.
Evita que el cliente agregue cambios infinitos que destruyan el presupuesto.
Vital para industrias reguladas (médica, financiera, automotriz) y auditorías.
Cómo Redactar un SRS: El Proceso en 7 Pasos
Crear un Esquema Base o Usar una Plantilla Estándar
El primer paso es estructurar el documento bajo el estándar internacional (ISO/IEC/IEEE 29148 o IEEE 830). La estructura típica incluye:
Definir con Claridad el Propósito del Producto
Establece por qué se construye el software, quién tendrá acceso a este documento (desarrolladores, QA, directiva) y delimita el alcance del producto (qué problemas resuelve para la empresa y cómo se alinea a sus metas estratégicas). Define todos los acrónimos en un glosario para evitar malentendidos técnicos.
Describir Qué Estás Construyendo a Alto Nivel
Ofrece una perspectiva panorámica del software respondiendo preguntas clave: ¿Por qué se necesita? ¿Para quién es? ¿Es un sistema nuevo o una extensión de un ERP existente? ¿Qué dependencias externas tiene (servidores, APIs de mapas, bases de datos)?
Detallar Requerimientos Específicos (Funcionales y No Funcionales)
Para que el equipo de desarrollo no tenga dudas, clasifica los requerimientos en:
- Requisitos Funcionales: Comportamientos concretos usando sintaxis estructurada (EARS o formato BDD Gherkin).
- Interfaces Externas: Interfaz de usuario (UI), hardware (escáneres, impresoras), software/APIs y protocolos de red.
- Requisitos No Funcionales: Métricas cuantitativas de rendimiento, seguridad, disponibilidad y usabilidad.
Evaluar el Riesgo con la Matriz FMEA
Aplica el Failure Mode and Effects Analysis para anticipar fallas críticas. Calcula el Risk Priority Number (RPN) multiplicando Severidad (1-10) × Ocurrencia (1-10) × Detección (1-10). Los puntajes altos exigen diseñar mecanismos de mitigación inmediatos en el software (ej. modo offline o bloqueos transaccionales).
Vincular Historias de Usuario con Requerimientos (Trazabilidad)
Conecta cada User Story y tarea técnica con su respectivo ID de requerimiento en el SRS. Esto garantiza que no existan funciones huérfanas y que el equipo de testing pueda rastrear cada caso de prueba hasta la especificación original.
Entregar, Revisar, Aprobar y Refinar
El SRS es un documento vivo. Distribúyelo entre los interesados, obtén las firmas formales de aprobación y mantén un control de versiones riguroso conforme el sistema evolucione a lo largo del ciclo de vida del producto.
10 Mejores Prácticas para Definir Requerimientos
Principios de Perforce ALM para transformar un SRS en un documento ejecutable y libre de fricción.
Utiliza lenguaje conciso y sin ambigüedades para que todos entiendan lo mismo.
Incluye escenarios realistas para ilustrar exactamente cómo debe actuar el sistema.
Enfócate en requerimientos esenciales y elimina detalles superfluos o irrelevantes.
Mapea cada requisito hacia el diseño, el código fuente y las suites de prueba.
Establece condiciones medibles y objetivas para certificar cuándo una tarea está terminada.
Organiza por importancia y criticidad para entregar valor de alto impacto primero.
Diagramas de flujo, tablas y esquemas conceptuales simplifican ideas complejas.
Usa la misma estructura, terminología y formato en todo el documento.
Itera con los interesados para asegurar que el documento refleje la realidad cambiante.
Utiliza herramientas colaborativas o plataformas ALM para evitar conflictos de versiones.
Aunque redactar un SRS en Word o Google Docs es fácil al inicio, en proyectos de gran escala los documentos estáticos provocan desincronización de versiones, pérdida de trazabilidad y retrabajo masivo. Plataformas dedicadas de ALM (como Perforce Helix ALM o repositorios versionados en Git/Markdown) permiten trazabilidad en tiempo real, aprobaciones instantáneas y conexión directa con pipelines de pruebas.
El Analista como Puente entre Negocio y Código
Cómo compensar la distancia física y transformar quejas de oficina en lógica de ingeniería.
Cliente / Negocio
Habla en lenguaje de oficina, quejas, prisas y hojas de Excel caóticas.
Analista Informático (TÚ)
Filtra ambigüedades, indaga el camino de error y redacta en EARS/BDD.
Desarrollo & QA
Recibe requerimientos matemáticos, APIs, schemas y pruebas listas.
- • "El sistema debe calcular descuentos de forma inteligente."
- • "Queremos que la app sea intuitiva y muy rápida."
- • "Que se envíe una alerta automática a los usuarios normales."
- • ¿Cuál es la fórmula matemática del descuento y bajo qué regla de antigüedad?
- • ¿Rápida significa responder en menos de 1.5 segundos con 50 usuarios?
- • ¿Qué roles exactos reciben la alerta y qué canal se usa (SMS/Email/Push)?
Frontera de Alcance Blindada
Define qué se desarrollará y qué queda explícitamente fuera de la versión actual para proteger el presupuesto.
"El software gestionará todas las ventas, clientes, pedidos y cobros de la empresa."
Dentro de Alcance: Registro web de órdenes, validación de stock y app móvil de entrega con firma.
Fuera de Alcance v1.0: Facturación electrónica fiscal directa y cobro con tarjeta en sitio.
Perfiles de Usuario y Contexto Físico
| Perfil / Rol | Nivel Técnico | Entorno de Uso | Requerimiento Crítico |
|---|---|---|---|
| Operador de Almacén | Básico | $-18^\circ\text{C}$, con guantes térmicos | Botones gigantes ($>48\text{px}$) y lector de código de barras |
| Chofer de Reparto | Básico | Tráfico en calle y sótanos sin señal | Arquitectura 100% Offline-First con sincronización |
| Gerente de Logística | Medio-Avanzado | Escritorio con monitor 1080p | Dashboard analítico en vivo y exportación a Excel |
Sintaxis EARS & Escenarios BDD / Gherkin
Requisitos No Funcionales (Métricas SMART)
| Categoría | ❌ Antipatrón Subjetivo | ✅ Métrica SMART Medible |
|---|---|---|
| Rendimiento | "Que cargue rápido" | Tiempo de respuesta $< 1.2\text{s}$ para el $P_{95}$ con 100 usuarios activos. |
| Disponibilidad | "Que nunca se caiga" | $99.7\%$ de Uptime garantizado en horario operativo (06:00 a 22:00 hrs). |
| Seguridad | "Que esté bien protegido" | TLS 1.3 en tránsito y base de datos móvil SQLite cifrada con AES-256. |
Interfaces & Matriz de Riesgos FMEA
Calcula el Risk Priority Number (RPN) para priorizar las características más complejas de desarrollo:
RPN = Severidad (1-10) × Ocurrencia (1-10) × Detección (1-10)Calculadora Dinámica de Riesgos FMEA
Ajusta los parámetros para evaluar si un modo de falla requiere mitigación obligatoria en el SRS.
RIESGO CRÍTICO (Mitigación Obligatoria en SRS)
El Caso de Alimentos San Rafael (De la Frustración al SRS)
Historia de negocio real y cómo cada dolor operativo se tradujo en una especificación de software formal.
Dos vendedores venden el mismo stock limitado
Jorge le vende 40 cajas de carne a un restaurante; Patricia vende 35 cajas a un hotel al mismo minuto. Solo había 45 cajas reales en almacén. Solución en SRS: [RF-01] Bloqueo transaccional de 15 minutos.
Pérdida de $4,800 por disputa sin pruebas
Doña Carmen devuelve 3 cajas descongeladas y firma en papel carbón húmedo. El papel se rompe y el cliente se niega a pagar. Solución en SRS: [RF-05] Fotografía obligatoria de rechazo y firma digital POD.
Nadie sabe cuánto efectivo se cobró en el día
Laura pasa de 6:30 PM a 9:00 PM cuadrando billetes y notas arrugadas a ciegas. Solución en SRS: [RF-08] Conciliación en vivo de efectivo y retornos por ruta.
Comienza tu Levantamiento con Nuestras Apps Web
Accede a la aplicación interactiva para construir tu documento paso a paso o consulta el caso de estudio de Alimentos San Rafael en su página dedicada.