INGENIERIA DE REQUISITOS

MsC. Diana Carolina Rivera Velasco

El caso negativo Contacto con el cliente Gasto de tiempo y esfuerzo Coste de depurar errores Minimizar riesgos

El caso positivo Focaliza el interés en el usuario Da soporte a la adaptación y la evolución

PORQUE ES IMPORTANTE LA INGENIERIA DE REQUISITOS ?

Fuente: A. Finkelstein, conferencia “The Voice of the Customer”, UPC, Nov. 1997

Muestra de 365 encuestas. Final de los proyectos estudiados.

16,2 % terminan bien (tiempo, dinero, requisitos) 52,7 % termina y funciona, pero +tiempo, +dinero, -

requisitos 31,1 % proyecto cancelado

Project success factors: 1) user involvement (15,9%),3) clear statement of requirements

Project challenged factors: 1) lack of user input, 2) incomplete requirements, 3) changing requirements.

The 1994 Chaos report (www.standishgroup.com)

[KS97] Kotonya, G., Sommerville, P. (1997). Requirements Engineering: Processes and Techniques. John Wiley & sons

[LK95] Locopoulos, P., Karakostas V. (1995). System Requirements Engineering . McGraw Hill Int.

[Poh96] Pohl, K. (1996). Requirements Engineering: An Overview. En “Encyclopedia of Computer Science and Technology”, Vol. 36, Marcel Dekker Inc.,New York

FUENTES

Proceso de construcción del documento o especificación de los requisitos del sistema a construir.

Veremos este proceso según LK95, KS97 y Poh96

Veremos las actividades o tareas que incluye.

El proceso de la Ingeniería de Requisitos

Un marco para la descripción del proceso de la RE (LK95)

Adquisición (captura, definición, determinación, identificación, obtención, ...).

Análisis; especificación o modelización. Validación. El proceso se adapta a los diferentes

modelos de proceso general de Ingeniería del Software (cascada, espiral, prototipado, transformacional, etc).

El proceso de la Ingeniería de Requisitos (según LK95)

El proceso de la Ingeniería de Requisitos(según KS97)

El proceso de la Ingeniería de Requisitos (según Poh96)

Se define como el proceso de adquirir (elicitar, determinar, “sonsacar”, obtener...) todo el conocimiento relevante necesario para producir el modelo de los requisitos del problema dominio

Puede calificarse cómo proceso social se utilizan técnicas diversas: Entrevistas (metódicas) Cuestionarios Sistemas existentes Análisis de textos (lenguaje natural) Lluvia de ideas

Adquisición (LK95, KS97) o “elicitación” (Poh96) de requisitos

Se basa en comprender cuatro dimensiones: Dominio de aplicación Problema a resolver Necesidades y restricciones de los “stakeholders” (usuario en

sentido amplio: todos los agentes implicados en el sistema a construir)

Contexto organizativo Las técnicas de prototipado ayudan en el proceso de

descubrimiento El resultado es un documento que contiene esencialmente una

lista (y que se suele denominar SRS: Software Requirements Specification, es decir, documento de especificación).

Adquisición (LK95, KS97) o “elicitación” (Poh96) de requisitos

En los modelos de proceso descritos (y habitualmente), se considera esta actividad cómo la responsable de obtener una lista depurada de requisitos, una vez obtenida la lista “en bruto” y una vez analizada y resueltos los conflictos

Existen guias para este documento, cómo la de IEEE Std 1233 (1998 Edition IEEE Guide For Developing System Requirements Specifications, http://standards.ieee.org/reading/ieee/std_public/description/se/1233-1998_desc.html).

Sin embargo, las buenas prácticas de la Ingeniería de Software recomiendan completar este documento, ya en ésta fase, con un modelo (usando UML, p.ej.), al que también se suele denominar especificación

Así, que según el autor, la “especificación” puede ser la lista o el modelo (por ello, prefiero hablar de “documento de requisitos” y de “modelo(s) del sistema”).

Especificación (LK95) o Documentación (KS97) de requisitos

Consiste en construir un modelo (o varios) del sistema a construir, desde el punto de vista de su uso (interacción usuario-sistema) que recoja todos y cada uno de los requisitos de la lista.

Además del documento, se parte del dominio que se modela, el Universo del Discurso (UoD).

Aspectos a tener en cuenta: Modelización conceptual Modelización de empresas Modelización de requisitos funcionales Modelización de requisitos no funcionales

La modelización es esencial en los pre-proyectos (documento de requisitos + modelos + (opc.) prototipo + estimación + presupuesto), ya que permite una validación y también realizar una estimación de costes y tiempos (p.ej., por puntos de función).

Modelización (o especificación) de requisitos

El término nace del área de los sistemas de información y se asocia tradicionalmente al ámbito de las Bases de Datos.

Se suele denominar “Modelo conceptual” a la especificación de los requisitos de la información que deberá contener y manejar el sistema, y que parte de extraer y comprender conocimiento del dominio de aplicación (el UoD).

Una especificación desarrollada en términos de un Modelo Conceptual representa abstracciones, asunciones y restricciones del dominio de aplicación en UML, podemos representar un Modelo Conceptual mediante el diagrama de clases, con sus relaciones y restricciones.

Modelización conceptual de Sistemas de Información

“Enterprise modelling” o “Business modelling”. Un modelo de este tipo incluye: estructuras

organizativas; objetivos; actividades, procesos y productos; agentes y roles.

Sirve para delimitar el modelo de los requisitos del sistema a construir.

Ayuda a la identificación de los “stakeholders” (todos los agentes implicados en el sistema a construir).

En UML se puede describir, en parte, con un diagrama de actividad, y en el RUP, mediante workflows.

Modelización de empresas

Construcción de un modelo de aquellos requisitos que describen interacción (no información), es decir, la funcionalidad del sistema a construir.

A lo largo de los años se han propuesto muchos formalismos o métodos para la definición de modelos Estructurados (SASD, YSM, Information Engineering, etc.) Orientados a objetos (Booch, Fusion, OMT, UML) Tècnicas de descripción formal (VDM, Z, métodos algebraicos) Basados en puntos de vista o “viewpoints” ( SADT, CORE, VOSE, VORD)

En UML este aspecto lo cubren esencialmente los casos de uso, junto a diagramas de secuencia y colaboración.

Es el aspecto mas divulgado y conocido (a veces, con nombres erróneos,

cómo “metodologías” los primeros y segundos, o“métodos formales” los terceros).

Modelización de requisitos funcionales

Muy importantes, y al tiempo, muy olvidados Se refieren a todos aquellos requisitos que ni describen

información a guardar, ni funciones a realizar. Aspectos de proceso (método de desarrollo, entorno de

implementación, standards, etc.) Aspectos de producto (Integración, Rendimiento, Capacidad,

Seguridad, Integridad, Fiabilidad, Usabilidad, etc.) Aspectos externos (Aspectos sociales, Aspectos económicos,

Factores contractuales, Factores políticos, etc.) Han de poseer dos atributos (Sommerville’92): Han de ser objetivos Han de poder ser probados

Modelización de requisitos no funcionales

Consistencia No ambigüedad Minimalidad Completitud No redundancia

Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.

  Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.

  Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.

  No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector

Según ANSI/IEEE (Std. 830-1984), una especificación debe ser: No ambigua, Completa, Verificable, Consistente, Modificable, Trazable, Usable durante operación y mantenimiento.

Propiedades de las especificaciones (LK95)

Consiste en verificar el grado de cumplimiento de las propiedades

Técnicas (LK95): Uso de prototipos Animación (aplic. de tiemporeal) Parafraseado (de espec. formales) Sistemas expertos (CASE)

Técnicas (KS95): Revisiones Prototipado Validación del modelo Prueba (“testing”)

Validación de requisitos

La Gestión de requisitos es el proceso de gestionar los cambios en los requisitos de un sistema, y se integra en la Gestión del proyecto

Los requisitos de un sistema evolucionan => los sistemas no son estables

Para su gestión, hay que tener en cuenta algunos aspectos: Requisitos estables y volátiles (mutables, emergentes, por uso,

de compatibilidad) Identificación y almacenamiento Gestión del cambio Trazabilidad Gestión de riesgos

GESTION DE REQUISITOS (KS97)

Define la capacidad de describir y seguir la vida de un requisito en las dos direcciones (atrás y adelante).

TRAZABILIDAD DE REQUISITOS