Plantilla de especificación de requisitos de software (ERS) al estilo de DAC (I)

Plantilla ERS Especificación de Requisitos de Software

Uno de los principios de DAC es generar solo la documentación necesaria para garantizar la calidad del proceso y los productos. Es por esto que DAC propone en su expediente de proyecto de referencia 3 diferentes plantillas para especificar requisitos de software detallados y una plantilla para la Especificación de Requisitos del Software Entregable:

• Especificación General de Requisitos de Software ERS 
• Descripción técnica de requisitos detallada para nuevos desarrollos guiados por requisitos (Publicada en este blog) 
• Especificación funcional de requisitos mediante ingeniería inversa (Próximamente aquí) 
• Especificación de requisitos para desarrollo rápido (Próximamente aquí)

Es válido aclarar que las plantillas de especificación de requisitos que propone DAC se basan en el estándar IEEE 830.

En la etapa de Análisis y Diseño de Alto Nivel (Ver el Ciclo de vida de DAC) el analista a partir del levantamiento de requisitos confecciona un catálogo tratando de desglosar los requisitos hasta el más bajo nivel a partir de los requisitos de alto nivel obtenidos en la elicitación de los requisitos.

Luego hace un análisis de estos requisitos de manera general para tener una idea de cómo engranarlos e integrarlos en el software. Durante este análisis puede que se agreguen, eliminen o modifiquen requisitos. La salida fundamental de esta etapa es la Especificación de Requisitos de Software que va a servir de guía para la posterior especificación detallada ya enfocada a la implementación de los requisitos y además va a permitir mostrarle al cliente descripciones de los requisitos que ellos puedan entender.

Esta es la plantilla que explicaremos hoy: "Plantilla ERS Especificación de Requisitos de Software". Descargarla aquí.

Secciones del documento ERS para especificación de requisitos funcionales y no funcionales

El documento ERS puede tener tantas secciones como se consideren necesarias según lo que espera y pide el cliente y las necesidades de validación que tiene el equipo de proyecto. Al ser un documento entregable debe estar escrito correctamente y evitar el uso de términos técnicos. Estas son las secciones básicas que propone DAC en su plantilla aunque cada organización es libre de definir su plantilla de ERS a partir de sus necesidades y tipos de proyecto:

1. Vista del producto: en esta sección debería ir la descripción general del software, un resumen de requisitos clasificados pro complejidad y prioridad, también clasificados por sprint y entregas o versiones. Una parte muy importante de esta sección es el Modelo conceptual y el diccionario de datos del modelo conceptual. En futuros artículos hablaremos específicamente de los diccionarios de datos. 
2. Catálogo de requisitos funcionales: en un formato bien definido y agrupados por requisitos de alto nivel y agrupaciones lógicas de funcionalidades se especifican a grandes rasgos los requisitos funcionales. 
3. Componentes del sistema: en esta sección se explican los módulos o componentes del sistema haciendo una breve descripción de cada uno. 
4. Catálogo de requisitos no funcionales: en un formato bien definido se especifican los requisitos no funcionales.

Ejemplo de escenario de especificación de requisitos al estilo DAC

Aquí puedes encontrar un ejemplo de tabla para especificar requisitos funcionales en la ERS general. Esta tabla está basada en la idea de la Historia de Usuario, en este caso. Entre los stakeholders designados por el cliente para la definición y validación de los requisitos y el analista o miembro designado del equipo de proyecto deben enriquecer cada requisito:

Luego de que esta ERS sea validada con el cliente y una vez se tenga clara y establecida la arquitectura que soportará los requisitos planificados para la siguiente versión/entrega, se puede pasar a la siguiente etapa, donde el analista desarrollará los requisitos junto a los especialistas de calidad en plantillas más detalladas para que los requisitos puedan ser correctamente implementados y probados.

Una de estas especificaciones o descripciones detalladas las explico en mi siguiente artículo: Plantilla de especificación de requisitos de software. Descripción detallada

Pautas para la especificación de requisitos de software dirigidas al cliente

El analista o miembro designado del equipo debe tener en cuenta un conjunto de buenas prácticas para especificar requisitos enfocados al cliente:

1. Utilizar lenguaje natural, evitar detalles técnicos y de implementación. 
2. Utilizar una correcta ortografía. 
3. Pensar que lo que estás describiendo debe ser posible de programar y probar. 
4. Analizar la prioridad y complejidad para poder determinar el alcance de cada Entrega o Versión. 
5. Tratar de que en u solo documento quede recogida toda la información que el cliente debe validar, especialmente campos, validaciones fundamentales, requisitos funcionales y requisitos no funcionales. 
6. Llevar un correcto control del documento describiendo cada cambio y en que versión del producto se incorpora. 
7. Pensar durante la especificación a quien está dirigido el documento para que les sea útil. En este caso es para clientes y stakeholders externos al proyecto peor vinculados directamente ocn el objeto de informatización.