Patrones de especificación de requisitos by vsg12289

VIEWS: 27 PAGES: 5

									                                                                    QA:news – N2

                          Por Luis Reyes, IBM Rational Technical Solution Architect
                                                                            Julio 2009


                Patrones de especificación de requisitos
Otra entrevista más. Si tenemos suerte no se alargará más de la cuenta. Si tenemos
aun más suerte no divagaremos demasiado y hasta seremos capaces de entender los
requisitos o aquello que sea que nos pide el entrevistado. Y, si ya somos
enormemente afortunados, encontraremos la forma de transmitir todo aquello a lo que
llamamos requisitos de usuario en algo comprensible para el equipo de desarrollo.


Detrás de esa suerte, por supuesto, se encuentra el talento. Y, un poco más atrás
(habitualmente al fondo a la derecha), los recursos metodológicos habituales. Hoy
vamos a centrarnos precisamente en esta última parte. Por ejemplo, estamos
acostumbrados a la clasificación tradicional de los requisitos (usuario, funcionales, no
funcionales) que no aporta prácticamente ningún valor salvo para crear secciones en
los documentos Word. Sin embargo, podríamos y deberíamos ser mucho más
ambiciosos a la hora de etiquetar y clasificar requisitos.


Hay que tener en cuenta que recoger y especificar requisitos no es una actividad
sencilla. Requiere dotes técnicas para poder manejar conceptos del negocio o
tecnológicos, capacidades sociales y mucha psicología para llevar a cabo entrevistas
y, por supuesto, un buen manejo del lenguaje y de las reglas de modelado para evitar
ser ambiguo al escribir o representar los requisitos. Requiere, en definitiva, una gran
cantidad de aptitudes tanto humanas como técnicas.


Aunque parece que todo está dicho acerca de la gestión de requisitos, creo que
todavía hay mucha inmadurez en los procesos y las técnicas aplicadas, con
lamentables consecuencias de las que habremos leído y oído en infinidad de
ocasiones.


Nada más lejos de mi intención el hecho de inundaros con números, estadísticas o
análisis sobre las problemáticas habituales. Por el contrario, os voy a proponer
algunos patrones que pueden ayudar a mejorar los modelos clásicos de gestión de
requisitos. Como todo patrón que se precie, estos también incorporan prácticas y
experiencias que han funcionado bien en diferentes dominios.
                                                                   QA:news – N2
Patrón #1. Necesidades y especificaciones. DIVISIÓN

Hay muchas definiciones sobre lo que es un requisito. De hecho, hay demasiadas para
hacerse una idea clara de lo que realmente es.


Más que hablar de requisitos, que es un concepto tremendamente ambiguo, yo
prefiero referirme a necesidades para expresar todas aquellas peticiones (los
problemas que realmente se quieren solucionar) que nos llegan originalmente del
interlocutor y especificación para todas aquellas definiciones formales que establecen
lo que el producto final debe ser.

Patrón #2. Necesidades y especificaciones. CLASIFICACIÓN

Más allá de la clasificación ortodoxa de requisitos, la cual tiende a difuminar
demasiado la diferencia entre necesidades y especificaciones, debemos avanzar hacia
un modelo más ambicioso y asignar diferentes categorías o etiquetas adaptadas,
evidentemente, a las características de nuestros desarrollos.


Por ejemplo, podríamos clasificar las necesidades como:


   •   Limitaciones, políticas, restricciones u objetivos impuestos por el negocio
       cuando tratamos aspectos muy cercanos a los responsables.
   •   Escenarios, precondiciones, capacidades, atributos del sistema, aspectos
       técnicos, funcionales u otras necesidades cercanas a lo que se espera del
       producto cuando hablamos con usuarios.
   •   Descripciones muy concretas de datos, diseños de pantallas u otros aspectos
       de infraestructura más a bajo nivel cuando nuestros interlocutores tienen un
       nivel y conocimiento técnico y de la aplicación muy alto.


Algo similar podemos hacer con las especificaciones. Las habrá puramente textuales
y las clasificaremos como reglas de negocio, restricciones tecnológicas o de diseño,
lista de funcionalidades, etc. Pero también las habrá gráficas, normalmente basadas
en modelos UML que recogen casos de uso, entidades del dominio o aspectos de
navegación e interfaz gráfica de usuario.


Quiero insistir nuevamente en la diferencia tan sutil, pero tan importante entre
necesidades (más o menos técnicas, más o menos de alto nivel pero necesidades al
                                                                    QA:news – N2

fin y al cabo) y especificaciones (más o menos gráficas más o menos formales, pero
que describe claramente las características del producto).

Patrón #3. Necesidades y especificaciones. DERIVACIÓN
Si hemos conseguido clasificar las distintas instancias de uno u otro tipo, ahora es
sencillo establecer una correspondencia entre ellas.




Ilustración 1. Posible mapeo de necesidades


Por ejemplo, una regla impuesta por el usuario puede derivarse en una precondición
de un caso de uso; o un cambio en la navegación puede derivarse directamente en
una nueva versión de nuestro modelo de interfaz de usuario.


Es decir, partiendo de una determinada necesidad, podremos obtener una
especificación para nuestro producto de manera muy directa, escribiendo o modelando
de manera formal lo que dicha necesidad sugiere, ya sea un aspecto de negocio, de
comportamiento de la aplicación o de infraestructura y no sólo identificaremos más
rápido y mejor lo que nos dice el cliente, sino que lo transmitiremos mejor al equipo de
desarrollo.
                                                                      QA:news – N2


Patrón #4. Necesidades y especificaciones. GESTIÓN
Las necesidades, como todos sabemos, nunca cesan de surgir. Cuando las
recogemos al principio del proyecto, las solemos llamar requisitos. Cuando no
tenemos más remedio que asumirlas durante la implementación del producto las
llamamos cambios. En cualquier caso, siempre son las necesidades los elementos que
disparan cualquier ciclo de desarrollo, bien sea un proyecto, una iteración, una release
o un parche, y tienen vigencia exclusivamente dentro del ciclo en el que se tratan.


En cuanto a las especificaciones, al representar formalmente las características del
producto, las tendremos que mantener a lo largo de toda la vida útil del mismo al igual
que el código, la base de datos o las pruebas. Por tanto, permanecen vigentes para
todos y cada uno de los ciclos de desarrollo que afrontemos.


Este paradigma abre nuevas y emocionantes perspectivas en la gestión de requisitos,
por ejemplo:


       o   Los criterios de calidad exigidos a la hora de describir necesidades o
           especificaciones   del   producto    (nivel   de   ambigüedad,      completitud,
           consistencia, etc.) se orientarían a cada tipología en particular
       o   El análisis de impacto y de trazabilidad estaría basado en considerar a las
           necesidades como punto inicial o final de dicho análisis
       o   Podríamos estimar el tipo de necesidades que irían surgiendo a lo largo de
           la vida del producto y por tanto, preparar mejor a nuestros equipos y
           stakeholders para optimizar su tratamiento. En fases iniciales, el tipo de
           necesidades que recibimos tienen más que ver con el negocio o con
           funcionalidades de alto nivel, mientras que en fases de construcción o
           mantenimiento del producto, recibiremos necesidades de tipo más técnico,
           mucho más concretas y atómicas.
                                                                  QA:news – N2




Ilustración 2. Evolución de necesidades en el ciclo de vida


Resumiendo, un modelo coherente de división, clasificación, derivación y gestión de
necesidades del usuario y especificaciones del producto es la mejor ayuda para tratar
con esos compañeros de viaje llamados vulgarmente requisitos y que esconden aún
muchos secretos. Antes o después descubriremos todos ellos y, sin duda, el reto se
presenta apasionante.


                                Luis Reyes, IBM Rational Technical Solution Architect

								
To top