La especificación de requerimientos de software consiste en documentar de manera clara, organizada y verificable lo que el sistema debe cumplir. Es el resultado de transformar necesidades, reglas, restricciones y acuerdos en una referencia útil para el proyecto.
Una buena especificación ayuda a que usuarios, clientes, analistas, desarrolladores, testers y responsables del proyecto compartan una misma comprensión sobre lo que se construirá.
No existe un único formato válido. La especificación puede tomar la forma de un documento formal, una lista estructurada, historias de usuario, casos de uso, criterios de aceptación, modelos, prototipos o una combinación de artefactos.
Especificar significa describir un requerimiento con suficiente claridad para que pueda ser entendido, analizado, construido, probado y validado.
Una especificación útil debe responder qué se necesita, por qué, para quién, bajo qué condiciones, con qué restricciones y cómo se verificará.
La especificación cumple varios propósitos:
Si la especificación no ayuda a tomar decisiones o verificar resultados, probablemente necesita mejorar.
Una especificación puede ser leída por personas con necesidades distintas.
| Audiencia | Qué necesita encontrar |
|---|---|
| Cliente o patrocinador | Alcance, objetivos, prioridades, restricciones y criterios de aceptación. |
| Usuarios | Funciones, flujos, reglas y resultados esperados. |
| Desarrolladores | Datos, reglas, comportamiento, integraciones y condiciones técnicas. |
| Testers | Criterios de aceptación, escenarios, excepciones y resultados esperados. |
| Responsables de proyecto | Alcance, dependencias, riesgos, prioridades y cambios. |
| Auditoría o legal | Restricciones, trazabilidad, registros, controles y cumplimiento normativo. |
El nivel de detalle debe ser suficiente para el contexto. Un sistema crítico, regulado o con muchos equipos puede requerir especificación más formal. Un proyecto pequeño puede usar documentos más livianos.
Factores que influyen en el detalle:
El exceso de documentación puede ser costoso; la falta de documentación puede ser riesgosa. Hay que buscar equilibrio.
Una especificación de requerimientos puede incluir:
Cada requerimiento importante debería tener un identificador único. Esto facilita referencia, trazabilidad, revisión y cambios.
Ejemplos:
La nomenclatura puede variar, pero debe ser consistente.
Un requerimiento puede documentarse con varios campos.
| Campo | Propósito |
|---|---|
| Identificador | Permite referenciar el requerimiento. |
| Nombre | Resume el requerimiento. |
| Descripción | Explica qué debe cumplir el sistema. |
| Tipo | Funcional, no funcional, regla, restricción, dato, interfaz. |
| Prioridad | Indica importancia relativa. |
| Fuente | Persona, documento o sistema que originó el requerimiento. |
| Criterios de aceptación | Condiciones para verificar cumplimiento. |
| Dependencias | Otros requerimientos o sistemas relacionados. |
| Estado | Candidato, validado, aprobado, cambiado, descartado. |
| Identificador | RF-014 |
|---|---|
| Nombre | Registrar reclamo |
| Tipo | Funcional |
| Descripción | El sistema debe permitir que un operador registre un reclamo indicando cliente, motivo, descripción y canal de ingreso. |
| Prioridad | Alta |
| Criterios de aceptación | No debe guardarse sin cliente ni motivo. Debe asignarse número único. El estado inicial debe ser abierto. |
| Reglas relacionadas | RN-003: prioridad inicial según motivo. |
| Fuente | Taller con atención al cliente. |
La especificación puede ser más formal o más liviana según el contexto.
| Enfoque | Características | Uso habitual |
|---|---|---|
| Formal | Documento estructurado, revisiones, aprobaciones, trazabilidad detallada. | Sistemas críticos, contratos, regulación, equipos grandes. |
| Liviano | Historias, criterios, tableros, notas, prototipos y documentación mínima suficiente. | Equipos ágiles, productos evolutivos, proyectos con alta colaboración. |
| Mixto | Combina documentos base con historias, modelos y criterios de aceptación. | Muy frecuente en proyectos reales. |
El formato debe servir al proyecto, no convertirse en un fin en sí mismo.
Los requerimientos funcionales deben especificar acciones, datos, reglas, actores y resultados esperados.
Ejemplo de redacción:
Cuando el comportamiento es complejo, puede complementarse con escenarios o casos de uso.
Los requerimientos no funcionales deben especificarse de forma medible cuando sea posible.
Ejemplo:
Evitar frases como "rápido", "seguro" o "amigable" sin criterios de verificación.
La especificación debe incluir elementos que complementan los requerimientos:
Estos elementos pueden documentarse en secciones separadas y referenciarse desde los requerimientos funcionales.
La trazabilidad permite relacionar requerimientos con su origen, decisiones, diseño, pruebas y cambios.
En una especificación conviene registrar:
La trazabilidad será estudiada con más profundidad en temas posteriores.
La especificación puede cambiar. Por eso, debe existir alguna forma de controlar versiones.
Conviene registrar:
Sin versionado, distintas personas pueden trabajar con versiones diferentes de la verdad.
Una especificación debe validarse con interesados adecuados. Documentar no garantiza que el contenido sea correcto.
Validar implica revisar si:
La especificación es una herramienta de comunicación. Debe ser comprensible para quienes deben usarla.
Para mejorar comunicación conviene:
Una especificación que nadie entiende o consulta pierde valor.
Al especificar requerimientos, suelen aparecer estos errores:
Algunas buenas prácticas son:
La especificación de requerimientos de software convierte acuerdos y análisis en una referencia útil para el proyecto. Su valor está en comunicar con claridad qué debe cumplir el sistema y cómo se verificará.
Una buena especificación no depende de ser extensa, sino de ser clara, completa para su propósito, verificable y mantenible.
En el próximo tema estudiaremos las características de un buen requerimiento, profundizando en criterios como claridad, completitud, consistencia, factibilidad, verificabilidad y trazabilidad.