Plantilla de especificación de requisitos de software al estilo de DAC (II). Descripción detallada.

Repasando el artículo anterior

En la primera parte de este artículo hablamos sobre la plantilla general de especificación de requisitos (descárgala aquí) que se hace en lenguaje natural y está enfocada a tener una comprensión general de cómo debe funcionar el sistema pero sin entrar en detalles de implementación.

En el artículo de hoy explicaremos una de las más utilizadas: 

La plantilla de especificación de requisitos detallada para implementación de un requisito de nuevo desarrollo.

En este link pueden descargar la plantilla completa.

¿Cuándo usar esta plantilla?  

1. Esta plantilla es muy detallada y se recomienda para proyectos que cuenten con al menos una analista dedicada a realizar este trabajo. 
2. Además si el proyecto es altamente complejo en cuanto a negocio o implementación también se recomienda utilizar esta plantilla. 
3. Cuando deseas tener los requisitos bien documentados. 
4. Cuando los casos de prueba o las pruebas se hacen a partir de los requisitos especificados.

La plantilla para especificación detallada de requisitos y sus partes

La mejor forma de describir estos requisitos es mediante la técnica de escenarios mezclada con la técnica del prototipado. En una tabla de varias secciones se van especificando cada uno de los pasos lógicos que debe seguir el programador para implementar el requisito. Como una imagen vale más que mil palabras explicaremos cada sección o grupo de secciones mediante imágenes.

Parte 1: Datos generales y de trazabilidad

Parte 2: Lo que se debe analizar antes de entrar en el flujo

Parte 3: Describir los flujos del requisito y las condiciones finales

• Flujo básico: Es el curso normal y satisfactorio del requisito 
• Flujos alternos: Cualquier desviación o alternativa en un paso del flujo básico o de otro flujo alterno

Parte 4: Mensajes y observaciones

Pautas para la especificación detallada de requisitos de software

El analista debe tener en cuenta un conjunto de buenas prácticas para especificar requisitos que están dirigidos al equipo de desarrollo, dígase programadores y probadores:

1. Llegar hasta el más bajo nivel en la descripción de los flujos, precondiciones y pos-condiciones. 
2. Utilizar una correcta ortografía. 
3. Pensar cómo se haría lo que estás describiendo a nivel de programación y como puede ser probado. 
4. Utilizar referencias a otros documentos donde se encuentren las reglas de negocio, diccionarios de datos, modelos de datos, mapa de navegación y otros requisitos, por lo general estamos hablando del modelo de diseño y de la ERS. 
5. Codificar todo lo que sea posible y me refiero por ejemplo a mensajes del sistema, nomencladores, objetos y enumeradores predefinidos del negocio. Tratar de que todo esto se encuentre centralizado para evitar errores y repeticiones innecesarias. 
6. No repetir el texto de reglas de negocio, requisitos y clases o entidades referenciados sino poner solo su código. Estos deben estar en un lugar centralizado para evitar problemas de trazabilidad ante una modificación. 
7. Llevar un correcto control del documento describiendo cada cambio y en que versión del producto se incorpora. 
8. Hacer un documento de descripción detallada de requisitos (DR) por cada requisito hace más fácil su localización, control de cambios y trazabilidad. 
9. Pensar durante la especificación a quien está dirigido el documento para que les sea útil. En este caso es para desarrolladores y probadores por lo que debe ser una guía lo suficientemente detallada para poder programar y probar el requisito.