- apuntarlos y documentarlos
- abstraerlos en casos de uso tradicionales
- manejarlos y fusionarlos con otros análisis:
1.- requerimientos funcionales y no funcionales
2.- matriz de requerimientos
3.- priorización de los requerimientos.
Apuntar y documentar requerimientos
Hay muchas maneras, desde muy metodológicas a muy informales, de documentar los requerimientos.
Yo utilizo fundamentalmente las historias de usuario.
Una historia de usuario tiene los siguientes elementos:
1.-Identificador
2.-Título
3.-Historia
4.-Notas
El identificador lo suelo poner como F1,F2,F3... para las historias que conllevan requerimientos funcionales, y NF1, NF2... para las que conllevan no funcionales (veremos qué es un requerimiento funcional y otro no funcional en breve).
El título tiene una frase cortísima que me permite recordar el requerimiento de un vistazo (yo soy muy malo recordando siglas y números).
La historia explica el requerimiento. O bien de forma clara, breve y concisa ("el sistema debe permitir editar las fichas de los productos y que queden todas las operaciones registradas") o bien en forma tradicional de historia ("como gerente de productos debo poder editar las fichas de los productos para hacer las modificaciones que necesite y todas las operaciones han de quedar guardadas").
En notas voy apuntando todo lo que se me va ocurriendo del requerimiento, clarificaciones, cuestiones de desarrollo, etc. Con fecha, autor y texto.
Abstracción a casos de uso
En algunas ocasiones es necesario (bien por requerimientos de la compañía, bien para generar una documentación interesante y vendible, bien por gusto) hacer una agrupación de los requerimientos en casos de uso al estilo RUP o al estilo Cockburn.
Lo que yo hago en este caso es seleccionar los actores intervinientes en todos los requerimientos y agrupar los mismos en función de estos actores. Luego, usando el sentido común, agrupo los requerimientos en un mismo caso de uso.
La descripción del caso de uso viene de manera natural a la vista de los requerimientos que lo conforman (¡no más de diez!) y es cuando, según Cockburn, yo los documento.
Otros análisis sobre los requerimientos
Estamos viendo que todas las acciones sobre los requisitos nos van sirviendo para ir dándoles forma y que ésta es una labor continua, sin una fase claramente delimitada.
Entre las otras acciones que podemos hacer para "amasar" los requerimientos están:
Distinción en requerimientos funcionales y no funcionales
En breve, los requerimientos funcionales son los que aportan valor al producto. Los no funcionales son el lastre con el que tenemos que contar pero que no aportan nada visible; sin embargo, de no encontrarse, se echarían en falta.
Tadicionalmente, los requerimientos no funcionales ser refieren a:
Disponibilidad
Certificación
Dependencia de otras partes
Documentación
Eficiencia
Ser extensible
Aspectos legales y de licencias
Mantenimiento
Performance
Plataforma
Precio
Calidad
Necesidad de recursos
Seguridad
Compatibilidad
Estabilidad
Soporte.
Matriz de requerimientos
Siguiendo con nuestras técnicas de manipulación, podemos interrelacionar los requerimientos entre ellos, con los casos de uso y con los elementos del software que vamos creando (por ejemplo pantallas, APIs, módulos o cualquier agrupación que hagamos) por medio de matrices.
Una matriz de requerimientos tiene en un eje los requerimientos y en el otro los otros requerimientos, los casos de uso o los elementos funcionales. En sus entradas aparecerá o una X cuando haya cierta relación de relevancia o un valor (habitualmente 1,3,9) que indique esa relación y su grado.
Así sabremos cuáles son los requerimientos con mayor influencia sobre los casos de uso, los que tienen un mayor impacto a la hora de ser cambiados sobre los elementos funcionales o los que se relacionan con otros requerimientos formando una malla.
Lo ideal a nivel de gestión del cambio de requerimientos es que los requerimientos sean ortogonales (es decir, la matriz requerimientos-requerimientos sea diagonal), porque elimina la necesidad de estudiar el impacto de un cambio en los requisitos.
Priorización
Si pensamos que todos los requerimientos han quedado absolutamente claros y puestos de manifiesto y que vamos a ser capaces de desarrollarlos completamente en el tiempo esperado, la priorización sobra.
Quizás sea por eso por lo que cuesta tanto extraer de las personas sobre las que pesa la decisión de impulsar el proyecto y de obtener el mayor beneficio de él una priorización: estamos obligándo a asumir que no todo es evidente ni claro ni completo ni predecible. En definitiva, les estamos forzando a que asuman como cierto el riesgo inherente en el proceso de fabricación de software... algo que es verdadero, en definitiva.
Como la gestión de los requerimientos surge de la falta de precisión implicita en todo proyecto de software, es evidente que una parte de esa gestión será la priorización: ¿qué queremos que se clarifique con mayor prioridad?.
En definitiva, priorizar los requerimientos es también un paso conducente a clarificarlos, porque nos ayuda a determinar qué se espera realmente del software por hacer. También nos sirve de vehículo de comunicación con los promotores: es posible hacer una plan de ruta claro en los objetivos. Y sirve para dotar de mayor control a los promotores del proyecto, que pueden detenerlo cuando estén satisfechos con los objetivos.
En conclusión, debemos vender la necesaria priorización de requisitos con la idea de que aportan:
- un plan de releases claro en los objetivos y aproximado en el tiempo
- una vía para clarificar requerimientos: qué se espera del producto
- mayor control a los promotores del proyecto: viibilidad y capacidad para detener el proyecto
