INGENIERIA DE REQUISITOS

MsC. Diana Carolina Rivera Velasco

PORQUE ES IMPORTANTE LA INGENIERIA DE REQUISITOS ?

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

El caso positivo
Focaliza el inters en el usuario Da soporte a la adaptacin y la evolucin
Fuente: A. Finkelstein, conferencia The Voice of the Customer, UPC, Nov. 1997

The 1994 Chaos report (www.standishgroup.com)

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.

FUENTES
[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

El proceso de la Ingeniera de Requisitos

Proceso de construccin del documento o especificacin de los requisitos del sistema a construir. Veremos este proceso segn LK95, KS97 y Poh96 Veremos las actividades o tareas que incluye.

Un marco para la descripcin del proceso de la RE (LK95)

El proceso de la Ingeniera de Requisitos (segn LK95)

Adquisicin (captura, definicin, determinacin, identificacin, obtencin, ...). Anlisis; especificacin o modelizacin. Validacin. El proceso se adapta a los diferentes modelos de proceso general de Ingeniera del Software (cascada, espiral, prototipado, transformacional, etc).

El proceso de la Ingeniera de Requisitos (segn KS97)

El proceso de la Ingeniera de Requisitos (segn Poh96)

Adquisicin (LK95, KS97) o elicitacin (Poh96) de requisitos

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 cmo proceso social se utilizan tcnicas diversas:
Entrevistas (metdicas) Cuestionarios Sistemas existentes Anlisis de textos (lenguaje natural) Lluvia de ideas

Adquisicin (LK95, KS97) o elicitacin (Poh96) de requisitos

Se basa en comprender cuatro dimensiones:

Las tcnicas 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 especificacin).

Dominio de aplicacin Problema a resolver Necesidades y restricciones de los stakeholders (usuario en sentido amplio: todos los agentes implicados en el sistema a construir) Contexto organizativo

Especificacin (LK95) o Documentacin (KS97) de requisitos

En los modelos de proceso descritos (y habitualmente), se considera esta actividad cmo 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, cmo la de IEEE Std 1233 (1998 Edition IEEE Guide For Developing System Requirements Specifications, http://standards.ieee.org/reading/ieee/std_public/description/se/12331998_desc.html). Sin embargo, las buenas prcticas de la Ingeniera de Software recomiendan completar este documento, ya en sta fase, con un modelo (usando UML, p.ej.), al que tambin se suele denominar especificacin As, que segn el autor, la especificacin puede ser la lista o el modelo (por ello, prefiero hablar de documento de requisitos y de modelo(s) del sistema).

Modelizacin (o especificacin) de requisitos

Consiste en construir un modelo (o varios) del sistema a construir, desde el punto de vista de su uso (interaccin usuario-sistema) que recoja todos y cada uno de los requisitos de la lista. Adems del documento, se parte del dominio que se modela, el Universo del Discurso (UoD). Aspectos a tener en cuenta:
Modelizacin conceptual Modelizacin de empresas Modelizacin de requisitos funcionales Modelizacin de requisitos no funcionales

La modelizacin es esencial en los pre-proyectos (documento de requisitos + modelos + (opc.) prototipo + estimacin + presupuesto), ya que permite una validacin y tambin realizar una estimacin de costes y tiempos (p.ej., por puntos de funcin).

Modelizacin conceptual de Sistemas de Informacin

El trmino nace del rea de los sistemas de informacin y se asocia tradicionalmente al mbito de las Bases de Datos. Se suele denominar Modelo conceptual a la especificacin de los requisitos de la informacin que deber contener y manejar el sistema, y que parte de extraer y comprender conocimiento del dominio de aplicacin (el UoD). Una especificacin desarrollada en trminos de un Modelo Conceptual representa abstracciones, asunciones y restricciones del dominio de aplicacin en UML, podemos representar un Modelo Conceptual mediante el diagrama de clases, con sus relaciones y restricciones.

Modelizacin de empresas
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 identificacin 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.

Modelizacin de requisitos funcionales

Construccin de un modelo de aquellos requisitos que describen interaccin (no informacin), es decir, la funcionalidad del sistema a construir. A lo largo de los aos se han propuesto muchos formalismos o mtodos para la definicin de modelos
Estructurados (SASD, YSM, Information Engineering, etc.) Orientados a objetos (Booch, Fusion, OMT, UML) Tcnicas de descripcin formal (VDM, Z, mtodos 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 colaboracin.

Es el aspecto mas divulgado y conocido (a veces, con nombres errneos, cmo metodologas los primeros y segundos, omtodos formales los terceros).

Modelizacin de requisitos no funcionales

Muy importantes, y al tiempo, muy olvidados Se refieren a todos aquellos requisitos que ni describen informacin a guardar, ni funciones a realizar. Aspectos de proceso (mtodo de desarrollo, entorno de implementacin, standards, etc.) Aspectos de producto (Integracin, Rendimiento, Capacidad, Seguridad, Integridad, Fiabilidad, Usabilidad, etc.) Aspectos externos (Aspectos sociales, Aspectos econmicos, Factores contractuales, Factores polticos, etc.) Han de poseer dos atributos (Sommerville92): Han de ser objetivos Han de poder ser probados

Propiedades de las especificaciones (LK95)

Consistencia No ambigedad Minimalidad Completitud No redundancia

Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin 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 redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector Segn ANSI/IEEE (Std. 830-1984), una especificacin debe ser: No ambigua, Completa, Verificable, Consistente, Modificable, Trazable, Usable durante operacin y mantenimiento.

Validacin de requisitos
Consiste en verificar el grado de cumplimiento de las propiedades Tcnicas (LK95):
Uso de prototipos Animacin (aplic. de tiemporeal) Parafraseado (de espec. formales) Sistemas expertos (CASE) Revisiones Prototipado Validacin del modelo Prueba (testing)

Tcnicas (KS95):

GESTION DE REQUISITOS (KS97)

La Gestin de requisitos es el proceso de gestionar los cambios en los requisitos de un sistema, y se integra en la Gestin del proyecto Los requisitos de un sistema evolucionan => los sistemas no son estables Para su gestin, hay que tener en cuenta algunos aspectos:
Requisitos estables y voltiles (mutables, emergentes, por uso, de compatibilidad) Identificacin y almacenamiento Gestin del cambio Trazabilidad Gestin de riesgos

TRAZABILIDAD DE REQUISITOS
Define la capacidad de describir y seguir la vida de un requisito en las dos direcciones (atrs y adelante).