Repasando el artículo anterior
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.
¿Cuándo usar esta plantilla?
- Esta plantilla es muy detallada y se recomienda para proyectos que cuenten con al menos una analista dedicada a realizar este trabajo.
- Además si el proyecto es altamente complejo en cuanto a negocio o implementación también se recomienda utilizar esta plantilla.
- Cuando deseas tener los requisitos bien documentados.
- 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
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
- Llegar hasta el más bajo nivel en la descripción de los flujos, precondiciones y pos-condiciones.
- Utilizar una correcta ortografía.
- Pensar cómo se haría lo que estás describiendo a nivel de programación y como puede ser probado.
- 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.
- 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.
- 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.
- Llevar un correcto control del documento describiendo cada cambio y en que versión del producto se incorpora.
- 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.
- 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.
Excelente articulo, muy buena la metodologia, agil, aplicable, entendible, gestionable, me gusta, voy a profundizar en ella para mis proyectos, y enviare resultados. gracias
ResponderEliminar