viernes, 1 de agosto de 2008

Team Skill 5: Refinando la Definición del Sistema

Según Managing Software Requirements - A Unified Approach de Dean Leffingwell y Don Widrig (ISBN: 0-201-61593-2), los requerimientos son la clave de las técnicas de comunicación para capturar las necesidades del usuario, de manera que el desarrollador pueda crear un sistema para satisfacer esas necesidades. Además, los requerimientos necesitan ser especificados lo suficiente para que podamos decir cuándo se han cumplido. Tenemos que recordar que toda esta metodología de Team Skills apunta más a un entorno orientado al plan (como puede ser RUP) que a un entorno ágil, por ende, mucho de lo que escribí en mi post anterior sobre user stories no aplica en este contexto.

Paquete de SRS moderno

Los requerimientos pueden estar organizados y documentados en una variedad de formas. Managing Software Requirements introduce el concepto de Paquete de SRS (Software Requirement Specification) moderno, una construcción lógica que nos permite documentar requerimientos en Casos de Uso, documentos, base de datos de formularios u otras técnicas.


En otras palabras, un Paquete de SRS moderno es un paquete de información que describe el comportamiento externo del sistema en forma completa. Sirve para crear un modelo conceptual del sistema a construir. Todo desarrollo debe fluir de los requerimientos especificados en el Paquete de SRS moderno. Nada debe ser desarrollado fuera de este paquete. Todas las especificaciones en el paquete deben ser reflejadas en las actividades de desarrollo. Dado que estos son los elementos que rigen, se deduce que todas las actividades, tales como las limitaciones reglamentarias, deben reflejar el paquete y viceversa. El paquete de SRS Moderno debe ser revisado y actualizado a través de todo el ciclo de vida del proyecto. El equipo de desarrollo, a través de la WBS, será el encargado de la creación y el mantenimiento de los componentes que se incluirán. El paquete debe especificar qué funciones deben realizarse, requerimientos funcionales, requerimientos no funcionales y restricciones de diseño.
El paquete de SRS moderno sirve para:

  • Establecer una base para la comunicación entre las partes
  • Representar un acuerdo entre las partes
  • Establecer un estándar de referencia para la administración del proyecto
  • Input para diseño e implementación
  • Input para testing y aseguramiento de la calidad (QA)
  • Controlar la evolución del sistema durante la fase de desarrollo del proyecto

Medidas de Calidad en los Requerimientos de Software

En esta Habilidad Grupal, Dean Leffingwell y Don Widrig proporcionan una serie de medidas para evaluar la calidad de los paquetes y de los diversos elementos que figuran en él.

Un conjunto de requerimientos debe ser:
  • Correcto: si y sólo si cada requerimiento definido representa algo requerido por el sistema
  • Completo: si y sólo si describen todos los requerimientos de importancia para el usuario
  • Consistente: si y sólo si ningún subconjunto de requerimientos individuales entra en conflicto con otro
  • No ambiguo: si y sólo si puede ser sujeto a una única interpretación
  • Verificable: si y sólo si existe un procedimiento finito y estimable que pueda determinar que el software conforma con el requerimiento
  • Modificable: si y sólo si cualquier cambio puede ser realizado fácil, completa y consistentemente
  • Rastreable: si y sólo si cada uno de los componentes es claro y si existe un mecanismo que hace posible referirse a ese requerimiento en futuros esfuerzos de desarrollo
  • Entendible: si y sólo si la comunidad de usuarios y el equipo de desarrollo pueden comprender completamente los requerimientos individuales y la funcionalidad agregada por el conjunto

Medidas de Calidad del Paquete SRS

Los siguientes son algunos de los componentes que debería contener un buen SRS:
  • Una buena Tabla de Contenidos (TOC)
  • Un buen índice
  • Una historia de revisión incluyendo: número de revisión, la fecha de cada revisión, un pequeño sumario de las revisiones hechas sobre la información publicada y el nombre de la persona responsable de los cambios en el documento
De más está decir que si damos un vistazo al template SRS de RUP (cualquiera, el extendido o el reducido para proyectos más pequeños) vemos que cumple con todas estas medidas de calidad y más.

Técnicas para especificar Requerimientos

Managing Software Requirements especifica que, donde sea necesario, la documentación de requerimientos debe ser complementada con uno o más métodos o especificaciones formales (especificaciones más tradicionales o estructuradas).

No voy a entrar en detalle sobre este tema. Simplemente transcribo una enumeración de algunas de las técnicas de especificación de requerimientos más conocidas en el mundo de la Ingeniería de Software:
  • Pseudocódigo
  • Máquinas de estado finito (autómatas)
  • Árboles de decisión
  • Diagramas de actividad (o de flujo)
  • Modelos de entidad-relación (DER)
  • Análisis orientado a Objetos (diagrama de clases y compañía)
  • Análisis estructurado (DFD y compañía)

Entradas Relacionadas