Respuesta.

La SRS es un documento estructurado que describe todos los requisitos del sistema en desarrollo. Su tarea es traducir de la manera más clara y completa posible las expectativas comerciales al lenguaje del equipo de proyecto. Secciones principales:

1. Introducción (objetivos, alcance, terminología)
2. Descripción del producto y contexto empresarial
3. Descripciones de usuarios y sus roles
4. Requisitos funcionales (casos de uso, historias de usuarios)
5. Requisitos no funcionales (seguridad, rendimiento, usabilidad)
6. Restricciones
7. Interfaces
8. Dependencias externas
9. Criterios de aceptación de requisitos
10. Glosario de términos

Características clave:

La SRS contiene tanto requisitos funcionales como no funcionales.
Los requisitos se formulan de manera clara, con la menor ambigüedad posible.
En la SRS se reflejan obligatoriamente los escenarios de uso, restricciones y criterios de éxito.

Para controlar la completud y calidad, el analista utiliza listas de verificación de validación, plantillas, estándares IEEE 830 y revisiones regulares con los principales interesados.

Preguntas problemáticas.

¿Es suficiente describir solo las historias de usuarios para una SRS completa?

No. Las historias de usuarios demuestran el aspecto funcional, pero no cubren requisitos no funcionales, restricciones, interfaces, escenarios de excepción y criterios de aceptación.

¿Se pueden usar diferentes términos para la misma entidad en el documento?

No. Es obligatorio mantener la uniformidad de la terminología: para ello se crea un glosario de términos y se lleva a cabo una revisión cruzada del documento.

¿Debería la SRS incluir requisitos de seguridad y rendimiento?

Sí. Los requisitos no funcionales son críticamente importantes: su ausencia conduce a deudas técnicas o a la imposibilidad de operar el sistema.

Errores comunes y anti-patrones

Insuficiente detalle en los requisitos, falta de ejemplos y criterios de aceptación.
Uso de formulaciones ambiguas: "rápido", "conveniente", "fiable" sin características numéricas.
Ignorar requisitos no funcionales.

Ejemplo de la vida real

Caso negativo

La SRS se escribe únicamente sobre la base de historias de usuarios, se olvidan los requisitos de rendimiento y seguridad.

Pros:

Rápida preparación de la documentación.

Contras:

El proyecto no pasó la auditoría de seguridad, no soporta la cantidad necesaria de usuarios simultáneos.

Caso positivo

La SRS abarca todo el conjunto de atributos necesarios: funcionalidad, requisitos no funcionales, criterios de aceptación, glosario.