Toma de Requisitos - Paso 9: Requisitos no funcionales

Toma de Requisitos - Paso 9: Requisitos no funcionales

Hoy vamos a  finalizar esta serie de artículos sobre la toma de requisitos (algunos suspiraréis de alivio), explicando el último paso: la documentación de requisitos no funcionales.

Esta entrada forma parte de una serie cuyo índice es el siguiente:

1. Identificación de usuarios finales clave.
2. Entrevista a dichos usuarios finales.
3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
4. Presentación del prototipo a los usuarios finales, solicitando feedback.
5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
7. Utilizar el prototipo como la primera línea de base de los requisitos.
8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Una vez tenemos cerrado el prototipo, es importante cerrar la documentación de usuario (que representa sobre todo los requisitos de interfaz), pero también, es vital complementarlo con los requisitos no funcionales.

Las tareas realizadas en los Pasos 1 a 8 nos han permitido solventar proyectos basados principalmente en interfaz, proyectos más bien pequeños.

Sin embargo, siempre tendremos funcionalidades necesarias pero difíciles de plasmar en un prototipo o en un manual de usuario: los requisitos no funcionales. Aquí podemos encontrar entre otros:

• Velocidad de acceso a la aplicación, o tiempos de respuesta.
• Uso de memoria.
• Interfaz con el sistema operativo o con otros sistemas (tanto hardware como software).
• Algoritmos detallados con reglas internas de comportamiento (reglas de negocio).

¿Hay que hacer un documento con todo esto? Pues no del todo. Lo que hay que hacer es recopilar esta información para que no se pierda, y esto puede hacerse en varios sitios (seamos ágiles):

• Como un anexo del manual de usuario
• Como notas en una pizarra o post-its en la pared (que alguien se acuerde de hacerle una foto, antes de que se los lleve el viento!!)
• Etc.

Finalmente, viene la parte más dura: hay que revisar, establecer una línea base, y poner bajo control de cambios este documento/foto/pizarra.

• Revisar: siempre viene bien, 4 ojos ven más que 2. Si programar entre pares produce buen código...¿porqué no revisar más de una persona los documentos?
• Línea base: hay que dejar claro un punto de partida. Difícilmente sabremos llegar a ningún sitio si no tenemos claro cuál era nuestro punto de origen.
• Control de cambios. No pongáis la cara que suelen poner la gente en mis proyectos cuando les cuento esto. Control de cambios podría ser hacer una foto nueva a la pizarra cada vez que cambiamos los post-it, o guardar el documento en subversion y guardar una nueva versión cada vez que lo modificamos.

Y esto ha sido todo. Para finalizar, decir que estos 9 puntos no indican COMO ha de ser una toma de requisitos. Es tan sólo una aproximación para hacerlo, orientada a proyectos en los que sea primordial contar con un prototipo, exista un cliente involcurado, predominen los requisitos funcionales sobre otros, etc.

Como ya creo haber comentado en algún otro post anterior, estaría relacionado con la metodología UIDD (o User Interface Driven Development), donde lo primero que se hace es la interfaz, y se va propagando el desarrollo a otras capas o partes del sistema. Ojo, no significa esto que la interfaz esté cerrada. Recordad que la realidad siempre estará en contra nuestra, y lo más probable que cambie...sea lo más estable y asentado que tengamos. Gracias Sr. Murphy por tu ley.