Técnicas para la captura de Requisitos

Todos sabemos lo complejo que es capturar los requisitos (de modo que lo que entendemos sea lo que el cliente quería decirnos) sobre todo si el entorno de trabajo es desconocido para el equipo de analistas.

Existen algunas técnicas clásicas que pueden ayudarnos a realizar esta ingeniería de requisitos.

ENTREVISTAS: resultan una técnica muy aceptada dentro de la ingeniería de requisitos y su uso está ampliamente extendido.

· Las entrevistas le permiten al analista tomar conocimiento del problema y comprender los objetivos de la solución buscada.

· A través de esta técnica el equipo de trabajo se acerca al problema de una forma natural. Existen muchos tipos de entrevistas y son muchos

· la estructura de la entrevista abarca estos pasos:

-identificación de los entrevistados,

-preparación de la entrevista,

-realización de la entrevista y

-documentación de los resultados (protocolo de la entrevista).

· No es una técnica sencilla de aplicar: requiere que el entrevistador sea experimentado y tenga capacidad para elegir bien a los entrevistados y obtener de ellos toda la información posible en un período de tiempo siempre limitado.

JAD (Joint Application Development/Desarrollo conjunto de aplicaciones): esta técnica resulta una alternativa a las entrevistas.

· Es una práctica de grupo que se desarrolla durante varios días y en la que participan analistas, usuarios, administradores del sistema y clientes (IBM, 1997).

· Está basada en cuatro principios fundamentales:

-dinámica de grupo,

-el uso de ayudas visuales para mejorar la comunicación,

-mantener un proceso organizado y racional y

-una filosofía de documentación WYSIWYG (What You See Is What You Get, lo que ve es lo que obtiene), es decir, durante la aplicación de la técnica se trabajará sobre lo que se generará.

· Tras una fase de preparación del JAD al caso concreto, el equipo de trabajo se reúne en varias sesiones. En cada una de ellas se establecen los requisitos de alto nivel a trabajar, el ámbito del problema y la documentación.

· Durante la sesión se discute en grupo sobre estos temas, llegándose a una serie de conclusiones que se documentan. En cada sesión se van concretando más las necesidades del sistema.

· Esta técnica presenta una serie de ventajas frente a las entrevistas tradicionales, ya que ahorra tiempo al evitar que las opiniones de los clientes se tengan que contrastar por separado, pero requiere un grupo de participantes bien integrados y organizados.

BRAINSTORMING (Tormenta de ideas):

· es también una técnica de reuniones en grupo cuyo objetivo es que los participantes muestren sus ideas de forma libre

· Consiste en la mera acumulación de ideas y/o información sin evaluar las mismas.

· El grupo de personas que participa en estas reuniones no debe ser muy numeroso (máximo 10 personas), una de ellas debe asumir el rol de moderador de la sesión, pero sin carácter de controlador.

· Como técnica de captura de requisitos es sencilla de usar y de aplicar, contrariamente al JAD, puesto que no requiere tanto trabajo en grupo como éste.

· Además suele ofrecer una visión general de las necesidades del sistema, pero normalmente no sirve para obtener detalles concretos del mismo, por lo que suele aplicarse en los primeros encuentros.

CONCEPT MAPPING:

· Los concept maps (Pan, Zhu & Johnson, 2001) son grafos en los que los vértices representan conceptos y las aristas representan posibles relaciones entre dichos conceptos.

· Estos grafos de relaciones se desarrollan con el usuario y sirven para aclarar los conceptos relacionados con el sistema a desarrollar.

· Son muy usados dentro de la ingeniería de requisitos, pues son fáciles de entender por el usuario, más aún si el equipo de desarrollo hace el esfuerzo de elaborarlo en el lenguaje de éste.

· Sin embargo, deben ser usados con cautela porque en algunos casos pueden ser muy sugestivos y pueden llegar a ser ambiguos en casos complejos, si no se acompaña de una descripción textual.

SKETCHES Y STORYBOARDS:

· Está técnica es frecuentemente usada por los diseñadores gráficos de aplicaciones en el entorno web.

· Consiste en representar sobre papel en forma muy esquemática las diferentes interfaces al usuario (sketches).

· Estos sketches pueden ser agrupados y unidos por enlaces dando idea de la estructura de navegación (storyboard).

CASOS DE USO

· Aunque inicialmente se desarrollaron como técnica para la definición de requisitos (Jacobson, 1995), algunos autores proponen casos de uso como técnica para la captura de requisitos

· Los casos de uso permiten mostrar el contorno (actores) y el alcance (requisitos funcionales expresados como casos de uso) de un sistema.

· Un caso de uso describe la secuencia de interacciones que se producen entre el sistema y los actores del mismo para realizar una determinada función.

· La ventaja esencial de los casos de uso es que resultan muy fáciles de entender para el usuario o cliente, sin embargo carecen de la precisión necesaria si no se acompañan con una información textual o detallada con otra técnica como pueden ser los diagramas de actividades.

CUESTIONARIOS Y CHECKLISTS:

· Esta técnica requiere que el analista conozca el ámbito del problema en el que está trabajando.

· Consiste en redactar un documento con preguntas cuyas respuestas sean cortas y concretas, o incluso cerradas por unas cuantas opciones en el propio cuestionario (Checklist).

· Este cuestionario será cumplimentado por el grupo de personas entrevistadas o simplemente para recoger información en forma independiente de una entrevista.

Comparación de terminología:

· Uno de los problemas que surge durante la toma de requisitos es que usuarios y expertos no llegan a entenderse debido a problemas de terminología.

· Esta técnica es utilizada en forma complementaria a otras técnicas para obtener consenso respecto de la terminología a ser usada en el proyecto de desarrollo.

· Para ello es necesario identificar el uso de términos diferentes para los mismos conceptos (correspondencia), misma terminología para diferentes conceptos (conflictos) o cuando no hay concordancia exacta ni en el vocabulario ni en los conceptos (contraste)

Existen más técnicas para la captura de requisitos incluso también es común encontrar alternativas que combinen varias de estas técnicas

Como resumen podríamos concluir:

· Que el uso de lenguajes naturales producen resultados más imprecisos que una descripción con casos de uso y ésta a su vez es más imprecisa que requisitos descriptos formalmente.

· Los casos de uso son apropiados tanto para pequeños como grandes sistemas,

· El uso de plantillas resultan menos aptas para grandes sistemas.

· Técncias como JAD son más difíciles de usar y consumen mucho más tiempo que entrevistas, permitiendo en cambio obtener resultados de mayor calidad.

Leer más: Ingeniería de Requisitos en Aplicaciones para la Web – Un estudio comparativo