INGENIERIA DE REQUISITOS

CAPTURA DE REQUISITOS

El proceso comienza con la realización de la captura de requisitos, el grupo de técnicos toma la información suministrada por los usuarios y clientes. Esta información puede provenir de fuentes muy diversas: documentos, aplicaciones existentes, a través de entrevistas, etc.

Finalmente con la validación de requisitos se realiza la valoración de los mismos, comprobando si existen inconsistencias, errores o si faltan requisitos por definir.

El proceso de captura de requisitos puede resultar complejo, principalmente si el entorno de trabajo es desconocido para el equipo de analistas, y depende mucho de las personas queparticipen en él.

A continuación se presentan un grupo de técnicas que de forma clásica han sido utilizadas para esta actividad en el proceso de desarrollo de todo tipo de software.

-        Entrevistas:Las entrevistas le permiten al analista tomar conocimiento del problema y comprender los objetivos de la solución buscada. Básicamente, la estructura de la entrevista abarca tres 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).

-        JAD (Joint Application Development/Desarrollo conjunto de  aplicaciones): 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á.

-        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.

-        Concept Mapping: Los concept maps 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.

-        Sketches y Storyboards: 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: 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. Los actores son elementos externos (personas, otros sistemas, etc.) que interactúan con el sistema como si de una caja negra se tratase. Un actor puede participar en varios casos de uso y un caso de uso puede interactuar con varios actores.

VALIDACION DE REQUISITOS

Los requisitos una vez definidos necesitan ser validados. La validación de requisitos tiene como misión demostrar que la definición de los requisitos define realmente el sistema que el usuario necesita o el cliente desea. Es necesario asegurar que el análisis realizado y los resultados obtenidos de la etapa de definición de requisitos son correctos. Pocas son las propuestas existentes que ofrecen técnicas para la realización de la validación y muchas de ellas consisten en revisar los modelos obtenidos en la definición de requisitos con el usuario para detectar errores o inconsistencias.

-        Reviews o Walk-throughs: Está técnica consiste en la lectura y corrección de la completa documentación o modelado de la definición de requisitos. Con ello solamente se puede validar la correcta interpretación de la información transmitida.

-        Auditorías: La revisión de la documentación con esta técnica consiste en un chequeo de los resultados contra una checklist predefinida o definida a comienzos del proceso, es decir sólo una muestra es revisada.

-        Matrices de trazabilidad: Esta técnica consiste en marcar los objetivos del sistema y chequearlos contra los requisitos del mismo.

-        Prototipos: Algunas propuestas se basan en obtener de la definición de requisitos prototipos que, sin tener la totalidad de la funcionalidad del sistema, permitan al usuario hacerse una idea de la estructura de la interfaz del sistema con el usuario.

TRATAMIENTO DE REQUISITOS

Son muchos los autores que han propuesto técnicas y modelos para el desarrollo de este tipo de sistemas, pero como se ha comentado, estas propuestas se centran principalmente en las últimas fases del proceso de desarrollo.

-        WSDM: Web Site Design Method

Es una propuesta para el desarrollo de sitios web, en la que el sistema se define en base a los grupos de usuarios. Su proceso de desarrollo se divide en cuatro fases: modelo de usuario, diseño conceptual, diseño de la implementación e implementación.

-        SOHDM: Scenario-based Object-Oriented Hypermedia Design Methodology Esta propuesta presenta la necesidad de disponer de un proceso que permita capturar las necesidades del sistema.

-        RNA: Relationship-Navegational Analysis Plantea una secuencia de pasos para el desarrollo de aplicaciones web, centrándose  fundamentalmente en el flujo de trabajo de análisis. El proceso de trabajo que presenta RNA se basa en la realización de las siguientes fases:

Análisis del entorno, Elementos de interés, Análisis del conocimiento, Análisis de la navegación e Implementación del análisis.

-        UWE: UML-Based Web Engineering Propuesta metodológica basada en el Proceso Unificado y UML para el desarrollo de aplicationes web. UWE cubre todo el ciclo de vida de este tipo de aplicaciones, centrando además su atención en aplicaciones personalizadas (adaptivas). Esta metodología distingue entre la tarea de elicitar requisitos, definir y validar los requisitos. El resultado final de la captura de requisitos en UWE es un modelo de casos de uso acompañado de documentación que describe los usuarios del sistema, las reglas de adaptación, los casos de uso y la interfaz. UWE clasifica los requisitos en dos grandes grupos: funcionales y no funcionales.