GESSI Grup de recerca en Enginyeria del Software per als SI

Ingeniera de Requisitos: conceptos, procesos y estado de la investigacin

Seminario de Doctorado Grupo Arcos, Depto. Informtica, Univ. Carlos III Madrid, 1-3/02/2005
Pere Botella - Depto. LSI - UPC botella@lsi.upc.edu pere.botella@upc.edu

GESSI Grup de recerca en Enginyeria del Software per als SI

Contenidos
z z z z z z z z z

Definiciones y mbito Los procesos: conceptos bsicos El proceso de la Ingeniera de Requisitos: modelos de proceso Las actividades: descripcin de las diferentes tareas Propiedades y validacin Gestin de requisitos La investigacin: visin general Grupos de investigacin relevantes y sus lneas La investigacin en el grupo GESSI
Y en algunos momentos...

Referencias
GESSI Grup de recerca en Enginyeria del Software per als SI
z z

z z z z z

[Dav92] Davis, A. (1992). Software Requirements: Objects, Functions and States. Prentice-Hall [Fil94] Finkelstein, A. (1994)Requirements Engineering: a review and research agenda. Proc 1st Asian & Pacific Software Engineering Conference, IEEE CS Press [Jac95] Jackson, M. (1995). Software Requirements & Specifications. Addison-Wesley [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

[SS97] Sommerville, I., Sawyer, P. (1997). Requirements Engineering: A Good Practice Guide. John Wiley & sons

Mas...

GESSI Grup de recerca en Enginyeria del Software per als SI

Contenidos
z z z z z z z z z

Definiciones y mbito Los procesos: conceptos bsicos El proceso de la Ingeniera de Requisitos: modelos de proceso Las actividades: descripcin de las diferentes tareas Propiedades y validacin Gestin de requisitos La investigacin: visin general Grupos de investigacin relevantes y sus lneas La investigacin en el grupo GESSI

GESSI Grup de recerca en Enginyeria del Software per als SI

Definicin 1

Requirements Engineering is the branch of Systems Engineering concerned with the real-world goals for, services provided by,and constraints on a large and complex softwareintensive systems. It is also concerned with the relationship of these factors to precise specifications of system behaviour, and to their evolutionover time and across system families.
Zave, P. (1994); Call for Papers and Associated Classification Scheme; IEEE International Symposium on Requirements Engineering 1995.

GESSI Grup de recerca en Enginyeria del Software per als SI

Definicin 2

Requirements Engineering deals with activities which attempt to understand the exact needs of the users of a software intensive system and to translate such needs into precise and unambiguous statements which will be subsequently be used in the development of the system

Loucopoulos, P; Karakostas, V. (1995); System Requirements Engineering McGraw-Hill, 1995

GESSI Grup de recerca en Enginyeria del Software per als SI

Definicin 3

A requirement is: 1. A condition or capacity needed by a user to solve a problem or achieve an objective 2. A condition or capability that must be met or possesed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents 3. A documented representation of a condition or capability as in 1 or 2
IEEE-Std.610 (1990) IEEE Standard Glossary of Software Engineering Terminology. IEEE Computer Society Press

GESSI Grup de recerca en Enginyeria del Software per als SI

Definicin 4

Requirements Engineering can be defined as the systematic process of developing requirements through an iterative co-operative process of analysing the problem, documenting the resulting observation in a variety of representation formats, and checking the accuracy of the understanding gained

Loucopoulos, P; Karakostas, V. (1995); System Requirements Engineering McGraw-Hill, 1995

GESSI Grup de recerca en Enginyeria del Software per als SI

Se trata de un trmino relativamente reciente que pretende cubrir todas las actividades relacionadas con descubrir, documentar y mantener un conjunto de requisitos para un sistema informtico (KS97) Tiene mucho en comn con el tradicionalmente denominado anlisis de sistemas Es una de las reas mas activas de investigacin actual, y aunque emerge de la Ingeniera del Software, se reclama parte de la Ingeniera de Sistemas, entendida de forma ms amplia que la anterior Es la etapa inicial de un proyecto de sistema de informacin, y es imprescindible en el pre-proyecto (si se desea una estimacin fiable)

GESSI Grup de recerca en Enginyeria del Software per als SI

- Porqu es importante la Ingeniera de Requisitos (el caso negativo) - Contacto con el cliente - Gasto de tiempo y esfuerzo - Coste de depurar errores - Minimizar riesgos - Porqu es importante la Ingeniera de Requisitos (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

GESSI Grup de recerca en Enginyeria del Software per als SI

- European User Survey Analysis, M. Ibaez (European Software Institute) & H. Rempp (Forschungszentrum Karlsruhe), proyecto ESPITI, ESI report TR95104 - 17 paises, 4000 cuestionarios, sector IT, empresas de productios y servicios - Requirements specification y Managing customer requirements los dos problemas sealados cmo mas importantes, un 50 % como problema mayor , un 35 % como problema menor, menos de un 12 % como no es problema. - Por encima de documentacin, testing, calidad, standards, diseo, gestin de la configuracin y programacin.
Fuente: A. Finkelstein, conferencia The Voice of the Customer, UPC, Nov. 1997

GESSI Grup de recerca en Enginyeria del Software per als SI

The 1994 Chaos report (www.standishgroup.com)

z z

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

z z z z

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 Cambios en el report de 2001... Y seguramente en el report The 2004 Chaos research... pero cuesta 3500$ !!!

GESSI Grup de recerca en Enginyeria del Software per als SI

Contenidos
z z z z z z z z z

Definiciones y mbito Los procesos: conceptos bsicos El proceso de la Ingeniera de Requisitos: modelos de proceso Las actividades: descripcin de las diferentes tareas Propiedades y validacin Gestin de requisitos La investigacin: visin general Grupos de investigacin relevantes y sus lneas La investigacin en el grupo GESSI

GESSI Grup de recerca en Enginyeria del Software per als SI

Conceptos de tecnologa de procesos (no relacionados directamente

con la Ing. de Requisitos)
z z z z z

Proceso Software: conjunto de tareas inter-relacionadas conducentes a la construccin de software Modelo de proceso software: descripcin abstracta (o simplificada) de una clase de procesos SPA (Software Process Assessment): evaluacin de un proceso software, determinacin de capacidad y madurez SPI (Software Process Improvement): mejora de procesos software, basada en la evaluacin SPM (Software Process Modelling): modelizacin de procesos software, mediante lenguajes o notaciones de diversa granularidad Modelos para SPA/SPI: CMM, ISO 15288 (SPICE)

GESSI Grup de recerca en Enginyeria del Software per als SI

Contenidos
z z z z z z z z z

Definiciones y mbito Los procesos: conceptos bsicos El proceso de la Ingeniera de Requisitos: modelos de proceso Las actividades: descripcin de las diferentes tareas Propiedades y validacin Gestin de requisitos La investigacin: visin general Grupos de investigacin relevantes y sus lneas La investigacin en el grupo GESSI

GESSI Grup de recerca en Enginyeria del Software per als SI

El proceso de la Ingeniera de Requisitos

z z z z

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 Veremos un modelo de niveles de madurez, segn SS97

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

GESSI Grup de recerca en Enginyeria del Software per als SI Usuario Requisitos del usuario Espec. de requisitos Conocimiento Especificacin Peticin Resultado Respuesta Modelo a validar

Adquisicin (elicitation)

Modelos Validacin

Conocimiento

Dominio del problema

Conocimiento

GESSI Grup de recerca en Enginyeria del Software per als SI

El proceso de la Ingeniera de Requisitos (segn LK95)

z z z

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

GESSI Grup de recerca en Enginyeria del Software per als SI

El proceso de la Ingeniera de Requisitos (segn KS97)

Adquisicin

Anlisis y negociacin

Documentacin

Validacin

Necesidades del usuario, dominio de informacin, sistemas existentes, normas, estndares, ...

Documento de requisitos Especificacin del sistema Requisitos acordados

GESSI Grup de recerca en Enginyeria del Software per als SI

El proceso de la Ingeniera de Requisitos: un modelo espiral (segn KS97)

Punto de decisin: aceptar o re-entrar

Requisitos en bruto

Adquisicin Inicio

Anlisis y negociacin

Documento validado

Validacin

Requisitos acordados Documentacin

Borrador del documento

GESSI Grup de recerca en Enginyeria del Software per als SI

El proceso de la Ingeniera de Requisitos (segn Poh96)

Validacin Validacin & & Verificacin Verificacin

Elicitacin Elicitacin

Especificacin Especificacin & & Documentacin Documentacin

Negociacin Negociacin

GESSI Grup de recerca en Enginyeria del Software per als SI

Un modelo de madurez para la RE (SS97)

Nivel 3 - Definido Proceso bien definido. Se proponen mejoras del proceso de la RE Nivel 2 - Repetible RE estandarizada Pocos problemas con los requisitos Nivel 1 - Inicial RE ad-hoc Problemas frecuentes con los requisitos

Nota: Recordemos que los niveles del CMM son cinco: 1) Inicial, 2) Repetible, 3) Definido, 4) Gestionado y 5) Optimizado

GESSI Grup de recerca en Enginyeria del Software per als SI

Contenidos
z z z z z z z z z

Definiciones y mbito Los procesos: conceptos bsicos El proceso de la Ingeniera de Requisitos: modelos de proceso Las actividades: descripcin de las diferentes tareas Propiedades y validacin Gestin de requisitos La investigacin: visin general Grupos de investigacin relevantes y sus lneas La investigacin en el grupo GESSI

GESSI Grup de recerca en Enginyeria del Software per als SI

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

z

z z

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 Standards de IdS Sistemas existentes Anlisis de textos (lenguaje natural) etc.

GESSI Grup de recerca en Enginyeria del Software per als SI

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

z

Se basa en comprender cuatro dimensiones: 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 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)

z z

Mas sobre adquisicin...

Mas sobre prototipos...

GESSI Grup de recerca en Enginyeria del Software per als SI

Anlisis y negociacin de requisitos (KS97)

Anlisis basado en checklists, lista de preguntas que se puede usar para cada requisito Mediante matrices, se pueden representar las relaciones entre requisitos: conflicto, solapamiento e independencia (mas) La negociacin guiada entre agentes (stakeholders) es el proceso para resolver conflictos y contradicciones (mas) Hay que tener presentes los diferentes puntos de vista (mas)

GESSI Grup de recerca en Enginyeria del Software per als SI

Especificacin (LK95) o Documentacin (KS97) de requisitos

z

z z

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 ) o las plantillas de Volere (http://www.volere.co.uk/ ) Un ejemplo 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)

GESSI Grup de recerca en Enginyeria del Software per als SI

Modelizacin (o especificacin) de requisitos

z

z z

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)

GESSI Grup de recerca en Enginyeria del Software per als SI

Modelizacin conceptual de Sistemas de Informacin

z z

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 (expresadas normalmente en OCL)

GESSI Grup de recerca en Enginyeria del Software per als SI

Modelizacin de empresas
z z

z z z

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

GESSI Grup de recerca en Enginyeria del Software per als SI
z

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, o mtodos formales los terceros)

GESSI Grup de recerca en Enginyeria del Software per als SI

Modelizacin de requisitos no funcionales

z z z z z z z

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 UML no los contempla (excepto con anotaciones), hay pocas notaciones para modelizarlos, y poco divulgadas
Mas...

GESSI Grup de recerca en Enginyeria del Software per als SI

Contenidos
z z z z z z z z z

Definiciones y mbito Los procesos: conceptos bsicos El proceso de la Ingeniera de Requisitos: modelos de proceso Las actividades: descripcin de las diferentes tareas Propiedades y validacin Gestin de requisitos La investigacin: visin general Grupos de investigacin relevantes y sus lneas La investigacin en el grupo GESSI

GESSI Grup de recerca en Enginyeria del Software per als SI

Propiedades de las especificaciones (LK95)

z z z z z z

Consistencia interna No ambigedad Consistencia externa Minimalidad Completitud No redundancia

Segn ANSI/IEEE (Std. 830-1984), una especificacin debe ser: No ambigua, Completa, Verificable, Consistente, Modificable, Trazable, Usable durante operacin y mentenimiento.

GESSI Grup de recerca en Enginyeria del Software per als SI

Validacin de requisitos

Consiste en verificar el grado de cumplimiento de las propiedades

z

Tcnicas (LK95):

Uso de prototipos Animacin (aplic. de tiemporeal) Parafraseado (de espec. formales) Sistemas expertos (CASE)

Tcnicas (KS95):

Revisiones Prototipado Validacin del modelo Prueba (testing)

Mas...

GESSI Grup de recerca en Enginyeria del Software per als SI

Contenidos
z z z z z z z z z

Definiciones y mbito Los procesos: conceptos bsicos El proceso de la Ingeniera de Requisitos: modelos de proceso Las actividades: descripcin de las diferentes tareas Propiedades y validacin Gestin de requisitos La investigacin: visin general Grupos de investigacin relevantes y sus lneas La investigacin en el grupo GESSI

GESSI Grup de recerca en Enginyeria del Software per als SI

Gestin 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 (mas)

GESSI Grup de recerca en Enginyeria del Software per als SI

Trazabilidad de requisitos

- Define la capacidad de describir y seguir la vida de un requisito en las dos direcciones (atrs y adelante) - Se diferencia la Pre-RT de la Post-RT
Fuente: A. Finkelstein, conferencia The Voice of the Customer, UPC, Nov. 1997

Fuentes

Especificacin

Diseo

Cdigo

Pre-RT

Post-RT

GESSI Grup de recerca en Enginyeria del Software per als SI

Contenidos
z z z z z z z z z

Definiciones y mbito Los procesos: conceptos bsicos El proceso de la Ingeniera de Requisitos: modelos de proceso Las actividades: descripcin de las diferentes tareas Propiedades y validacin Gestin de requisitos La investigacin: visin general Grupos de investigacin relevantes y sus lneas La investigacin en el grupo GESSI

GESSI Grup de recerca en Enginyeria del Software per als SI

RENOIR: Requirements Engineering Network Of

International cooperating Research groups: a network of excellence http://www.cs.ucl.ac.uk/research/renoir/ (red de excelencia del V Programa Marco de la CCE, 1996-1999)

What is the purpose of RENOIR ? The general purpose of RENOIR is to develop the coordination mechanisms and infrastructure for research in requirements engineering. Specific objectives are: to provide a framework for coordinated, joint research related to industrial needs, to support the diffusion of RE research; to provide RE research training and to support technology transfer in RE.

GESSI Grup de recerca en Enginyeria del Software per als SI

Who belongs to RENOIR ? The sixty eight founding members of RENOIR include almost all the key research teams working in the area of requirements engineering within Europe. The coordinator of RENOIR is the University College London (UCL), UK. Membership is open to any research laboratory or industrial group of researchers in Europe (or in countries with cooperation agreements with the European Union) which has interests in the area of requirements engineering, which subscribes to the aims of RENOIR and is interested in participating in the activities of the network. New applicants for membership are welcome.
La coordinacin en Espaa fue a cargo de la UPC

GESSI Grup de recerca en Enginyeria del Software per als SI

RENOIR brings together research teams from industry, academia, and research centres round a set of shared technical goals relating to the: Context in which the requirements engineering process takes place, Groundwork necessary for requirements engineering, Acquisition of the "raw" requirements, Rendering these requirements useable through modelling and specification, Analysis of the requirements, Measurement to control the requirements and systems engineering process, and Communication and documentation of the results of requirements engineering

GESSI Grup de recerca en Enginyeria del Software per als SI

Temas del CfP de RE05 (www.re05.org)

5HTXLUHPHQWV HOLFLWDWLRQ DQG LGHQWLILFDWLRQ  ,QIRUPDOPRGHOOLQJ RI UHTXLUHPHQWV  'RPDLQ PRGHOOLQJ  )RUPDOPRGHOOLQJ RI JRDOV DQG UHTXLUHPHQWV  6SHFLILFDWLRQ ODQJXDJHV  )RUPDODQDO\VLV DQG YHULILFDWLRQ  0XOWLSOH YLHZSRLQWVPDQDJLQJ LQFRQVLVWHQF\  1RQIXQFWLRQDODQG T XDOLW\ UHTXLUHPHQWV  3ULRULWL]DWLRQQHJRWLDWLRQDQG UHVROXWLRQ RI FRQIOLFWLQJ UHTXLUHPHQWV  3URWRW\SLQJDQLPDWLRQVLPXODWLRQ  5HTXLUHPHQWV YDOLGDWLRQ  5HTXLUHPHQWV HYROXWLRQ RYHU WLPHDFURVV SURGXFW IDPLOLHV  YDULDELOLW\ UHTXLUHPHQWV  5HTXLUHPHQWV PDQDJHPHQWWUDFHDELOLW\PHWULFV  5HTXLUHPHQWV PHWKRGRORJLHV HJ$JLOH PHWKRGV  6RFLDOFXOWXUDODQG FRJQLWLYH IDFWRUV LQ UHTXLUHPHQWV DFWLYLWLHV  $OLJQLQJ UHTXLUHPHQWV WR EXVLQHV V JRDOV DQG SURFHVVHV  5HODWLQJ UHTXLUHPHQWV WR V\VWHP DUFKLWHFWXUHWHVWLQJ  5HTXLUHPHQWV IRU &276EDVHG V\VWHPV  5HTXLUHPHQWV IRU LQWHURSHUDWLQJPXOWLRUJDQL]DWLRQDOV\VWHPV  'RPDLQVSHFLILF SUREOHPV DQG VROXWLRQV HJKLJKDVVXUDQFH V\VWHPV  VHFXUH V\VWHPV VRFLRWHFKQLFDOV\VWHPV WHOHFRPPXQLFDWLRQV DQG  GLVWULEXWHG V\VWHPV EXVLQHVV DQG LQIRUPDWLRQ V\VWHPV

GESSI Grup de recerca en Enginyeria del Software per als SI

Temas del CfP de RE04 (www.re04.org)

$FTXLULQJ GLVFRYHULQJ DQG FUHDWLQJ UHTXLUHPHQWV  9DOLGDWLQJ UHTXLUHPHQWV  3ULRULWLVLQJ DQG QHJRWLDWLQJ DERXW UHTXLUHPHQWV  5HTXLUHPHQWV PDQDJHPHQW DQG WUDFHDELOLW\  *RDORULHQWHG UHTXLUHPHQWV HQJLQHHULQJ  8VH FDVHV DQG VFHQDULRV LQ WKH UHTXLUHPHQWV SURFHV V  3URWRW\SLQJDQLPDWLQJ DQG H[HFXWLQJ UHTXLUHPHQWV  5HTXLUHPHQWV HQJLQHHULQJ IRU DJLOH SURFHVVHV  &RPELQLQJ IRUPDODQG LQIRUPDOUHTXLUHPHQWV VSHFLILFDWLRQ WHFKQLTXHV PDNLQJ IRUPDOWHFKQLTXHV XVDEOH  6RFLDOFXOWXUDODQG FRJQLWLYH IDFWRUV LQ UHTXLUHPHQWV HQJLQHHULQJ  5HTXLUHPHQWV PHWULFV  5HTXLUHPHQWV HQJLQHHULQJ HGXFDWLRQ  +RZ UHTXLUHPHQWV UHODWH WR EXVLQHV V SURFHVVHVZRUN UHGHVLJQ  DQG VRIWZDUH DUFKLWHFWXUHV  +RZ UHTXLUHPHQWV UHODWH WR VRIWZDUH DUFKLWHFWXUHV  ,QWHUWZLQLQJ UHTXLUHPHQWV DQG G HVLJQDQG UHTXLUHPHQWV DQG WHVWLQJ  7RROVXSSRUW IRU U HTXLUHPHQWV HQJLQHHULQJ 

GESSI Grup de recerca en Enginyeria del Software per als SI

Recursos en Internet
5HTXLUHPHQWV (QJLQHHULQJ 2Q OLQH 5(RQOLQH 'LVFXVVLRQ )RUXP KWWSUHVHDUFKLWXWVHGXDXUHVHUYLFHVBUHRQOLQHKWPO 3RLQWHUV WR 5HTXLUHPHQWV (QJLQHHULQJ 5HVRXUFHV KWWSUHVHDUFKLWXWVHGXDXUHFJLELQUHVRXUFHVBELEOLRJUDSK\FJL 5HTXLUHPHQWV (QJLQHHULQJ 3RUWDO KWWSZZZZHEZRUGFRPVHUYLFHVUSKWPO 6(, 5( 5HVRXUFHV KWWSLQWHUDFWLYHVHLFPXHGX)HDWXUHV0DUFK/LQNV/LQNVPDUKWP ,( ( ( 7DVN )RUFH RQ 5HTXLUHPHQWV (QJLQHHULQJ 7)5( KWWSZZZVKXDFXNWIUH 5HTXLUHPHQWV ELEOLRJUDSK\ KWWSZHEXFFVHGXDGDYLV8&&6UHTELEKWPGH $ODQ 'DYLV KWWSZZZLQISXFULREUaEGELEGH -XOLR  /HLWH )XHQWH $ODQ  'DYLV 'LGDU =RZJKL ,((( 6(  2QOLQH

&RQIHUHQFLDV GESSI Grup de recerca en Enginyeria del Software per als SI

,QWHUQDWLRQDO5HTXLUHPHQWV (QJLQHHULQJ &RQIHUHQFH5([ [ IXVLyQ GHVGH   GH ,&5( \ GHOZRUNVKRS 5( :RUNVKRSV HVSHFtILFRV HQ ,&6(2236/$(6(&-,6%'HWFHYHQWRV GH ,QJHQLHUtD GHO6RIWZDUH

5HYLVWDV
5HTXLUHPHQWV (QJLQHHULQJSXEOLFDGD SRU 6SULQJHU 9HUODJ $UWtFXORV HQ UHYLVWDV GH ,QJGHO6RIWZDUH ,(( ( 7UDQVDFWLRQV RQ 6( ,( ( ( 6RIWZDUH&RPPRI WKH $&0$&0 7UDQVRQ 6(HWF

+HUUDPLHQWDV
KWWSZZZYROHUHFRXNWRROVKWP

(VWiQGDUHV
,( ( ( 5HFRPHQGHG 3UDFWLFH IRU 6RIWZDUH 5HTXLUHPHQWV 6SHFLILFDWLRQ  ,((( KWWSZZZVWDQIRUGHGXFODVVFVKDQGRXWVLHHHSGI  ,( ( ( 6WG  (GLWLRQ ,((( *XLGH )RU 'HYHORSLQJ 6\VWHP 5HTXLUHPHQWV  6SHFLILFDWLRQV

KWWSVWDQGDUGV LHHHRUJUHDGLQJLHHHVWGBSXEOLFGHVFULSWLRQVHB GHVFKWPO

GESSI Grup de recerca en Enginyeria del Software per als SI

Contenidos
z z z z z z z z z

Definiciones y mbito Los procesos: conceptos bsicos El proceso de la Ingeniera de Requisitos: modelos de proceso Las actividades: descripcin de las diferentes tareas Propiedades y validacin Gestin de requisitos La investigacin: visin general Grupos de investigacin relevantes y sus lneas La investigacin en el grupo GESSI

0LHPEURV,),3 :*  www. wg 2 9 . o r g

GESSI Grup de recerca en Enginyeria del Software per als SI

$QWRQ$QQLH $WOHH-R %HUU\'DQ %XEHQNR-DQLV 'XERLV(ULF (DVWHUEURRN6WHYH )HDWKHU 0DUWLQ )HEORZLW] 0DUN )LFNDV6WHYH )LQNHOVWHLQ$QWKRQ\ *KH]]L&DUOR *UHHQVSDQ 6RO +HLWPH\HU &RQQLH -DFNVRQ0LFKDHO -DFNVRQ'DQLHO -DUNH0DWWKLDV .UDPHU-HII /HLWH-XOLR 0\ORSRXORV-RKQ 1XVHLEHK%DVKDU 3RKO .ODXV 3RWWV&ROLQ 5RELQVRQ%LOO 5\DQ .HYLQ 6XWFOLIIH$OLVWDLU YDQ /DPVZHHUGH$[HO =DYH3DPHOD

Editora de RE-Online: Didar Zowghi Editores portal de Req. Eng. En SE Online: Al Davis Didar Zowghi

Grupos en Espaa con trabajos explcitos en Ing. de Req. Universidad Politecnica de Valencia (Oscar Pastor, Isidro Ramos) Universidad de Murcia (Ambrosio Toval) Universidad de Sevilla (Miguel Toro, Amador Durn) Universidad Politecnica de Madrid (Natalia Juristo) Universidad Politecnica de Catalua (Xavier Franch, Pere Botella)

GESSI Grup de recerca en Enginyeria del Software per als SI

Grupos europeos promotores de RE-Net*

* Propuesta de Red de Excelencia en el programa VI, continuadora de RENOIR, no aprobada Austria: At the University of Klagenfurt, Heinrich Mayr and his group focuses on user centred requirements modeling (http://www.ifi.uni-klu.ac.at/IWAS/HM/Projects/NIBA) Belgium: Axel van Lamsweerde heads the software engineering group at the Department of Computing Science of the Universit catholique de Louvain. Since 1991 his group is instrumental in goal-oriented requirements http://www.info.ucl.ac.be/research/projects/AVL/ReqEng.html France : The CRI (Centre de Recherche en Informatique, http://panoramix.univ-paris1.fr/CRINFO is a research centre of the University Paris1 Panthon Sorbonne. Colette Rolland and her team have a long expertise in requirements engineering acquired through developing both theoretical research and more applied research. Germany : Klaus Pohl is full professor for software systems engineering at the Univ. of Essen and director of the Institute of Computer Science. He is/was involved in various European and German technology transfer and research projects in the area of RE see www.sse.uni-essen.de for details Greece: City Athens Software Engineering Institute (CASEI) - CASEI is new research institute that is being established in Athens by the City Athens Business School and with the collaboration of the City University in London. The RE team will involve George Spanoudakis (www.soi.city.ac.uk/~gespan/)

GESSI Grup de recerca en Enginyeria del Software per als SI

Italy: The group at Politecnico di Milano is interested in several aspects of requirements engineering: requirements modeling and analysis for high-assurance real-time systems, systematic derivation of the software architecture from the requirements, etc. The group is coordinated by Carlo Ghezzi. (www.elet.polimi.it/Users/DEI/Sections/CompEng/Carlo.Ghezzi/index.html) Ireland: Kevin Ryan (http://www.ul.ie/vpacad/CV.htm) of University of Limerick is one of the founders of the first major conference series on Requirements Engineering, and is co-author of a number of papers. Luxembourg: Eric Dubois works at the technology-transfer center CRP Henri Tudor (www.citi.tudor.lu). He is active in the area of formal languages http://www.info.fundp.ac.be/~edu/) for capturing requirements about multi-agents systems. Norway: The Information Systems Group (http://www.idi.ntnu.no/grupper/IS-grp/) at the Norwegian University of Science and Technology has a long-held interest in problem analysis and requirements engineering. The group is led by Prof. Arne Solvberg. Netherlands: The University of Twente has a program in evolutionary requirements engineering and on problem structuring analysis techniques for software and system requirements. http://is.cs.utwente.nl/. Dr. Roel Wieringa. http://wwwhome.cs.utwente.nl/~roelw/index.html is leading the group. UK: Researches of Anthony Finkelstein (Software Systems Engineering Group, University College London) has included significant contributions to work on specification from multiple viewpoints and to requirements traceability (http://www.cs.ucl.ac.uk/staff/A.Finkelstein/index.html). Spain: The software engineering research group at the Universitat Politcnica de Catalunya focuses on non-functional requirements. Pere Botella coordinates the group and has been active in the promotion of the RE field in his country. http://www.lsi.upc.es/~gessi .

GESSI Grup de recerca en Enginyeria del Software per als SI

Switzerland: Martin Glinz (http://www.ifi.unizh.ch/req) is leading the requirements engineering research group at the University of Zurich, which focuses on requirements models, and languages that can be applied and understood by practitioners in industry. Sweden: Bjrn Regnell and Requirements Engineering researchers within the Software Engineering Research Group (http://serg.telecom.lth.se/) at Lund University, has special expertise in the area of market-driven requirements engineering and the group has a long tradition of conducting empirical research in close co-operation with industry. Additional centres of RE expertise: The following private and public centres of expertise already expressed their interest to join the final RE-Net proposal as members of the outer circle (see organization details below): Sjaak Brinkkemper (Baan, Netherland), Matthias Jarke (Fraunhofer, Germany), Manfred Kaindl (Siemens AG sterreich), Bashar Nuseibeh (The Open University, UK), I. Sommerville (Lancaster University, UK).

GESSI Grup de recerca en Enginyeria del Software per als SI

Contenidos
z z z z z z z z z

Definiciones y mbito Los procesos: conceptos bsicos El proceso de la Ingeniera de Requisitos: modelos de proceso Las actividades: descripcin de las diferentes tareas Propiedades y validacin Gestin de requisitos La investigacin: visin general Grupos de investigacin relevantes y sus lneas La investigacin en el grupo GESSI

GESSI Grup de recerca en Enginyeria del Software per als SI

GESSI Grup de recerca en Enginyeria del Software per als SI

GESSI Grup de recerca en Enginyeria del Software per als SI

Trabajos recientes del grupo Gessi

z z z z z

Junio 2001, JIRA 01, notacin NoFun Septiembre 2002, RE02, modelos de calidad, requisitos para seleccin de COTS Noviembre 2002, WER02, visin global Julio 2004, SCI2004, construccin de taxonomas basada en metas Uso del modelo i*

El modelo i* (Yu)

GESSI Grup de recerca en Enginyeria del Software per als SI

Interfaces & Connectors

RTA

Easy Administration

Package Routed

Efficient Routing

Up-to-Date Management of Routing Tables

Routing Status

Destination IP Address

D
DNS

Performance Tuning

RT
Forvide Unwanted Routing

Interconection Facilities

D
D
D

D
RTU

D
D

GESSI Grup de recerca en Enginyeria del Software per als SI

Universitat Politcnica de Catalunya

Las transparencias que siguen a sta, y hasta la ltima corresponden al curso Definicin de Requerimientos del Mster de Ingeniera de Software de la UPC, y su uso en ste curso ha sido autorizado por su autor, Josep Maria Llovet. Se utilizan intercaladas con las propias del curso para reforzar algunos temas. Mi agradecimiento a JM Llovet. P. Botella (volver...)

Definicin de Requerimientos

Master de Ingeniera del Software

Josep M Llovet Prez

jmllovet@telefonica.net

GESSI Grup de recerca en Enginyeria del Software per als SI

Bibliografa
Definicin de Requerimientos: Managing Software Requirements: A Use Case Approach, Second Edition. Dean Leffingwell & Don Widrig.$GGLVRQ :HVOH\ 2003 Requirements Engineering: process and techniques. Gerald Kotonya & Ian Sommerville. John Wiley & sons. 2000 Requirements Engineering: a good practice guide. Ian Sommerville & Pete Sawyer. John Wiley & sons. 1997 Software Requirements & Specifications. Michael Jackson. Addison-Wesley. 1995 Software Requirements. Objects, Functions and States. Alan Davis. Prentice Hall International.1993

GESSI Grup de recerca en Enginyeria del Software per als SI

Bibliografa (2)

Modelizacin de empresas y negocios: Business Rules and Information Systems: Aligning IT with Business Goals. Tony Morgan. Addison-Wesley. 2002 Business Modelling with UML. Business Patterns at Work. Hans-Erik Eriksson, Magnus Penker. OMG Press. John Wiley & sons. 2000 Enterprise Modelling with UML. Chris Marshall. AddisonWesley. 1999 Ingeniera del Software (captulos dedicados a la DR): Ingeniera del Software, Un enfoque prctico. Roger Pressman. Captulo 10. 5a edicin Ed Mc Graw Hill. 2001 Ingeniera del Software. Ian Sommerville. Captulos 5 al 9. 6a edicin. Addison-Wesley. 2001

GESSI Grup de recerca en Enginyeria del Software per als SI

Referencias y enlaces

Tcnicas, guas y documentacin sobre DR:

z

Guas y documentacin sobre Definicin de Requerimientos Proyecto Reaims

http://www.comp.lancs.ac.uk/computing/resources/re-gpg/ http://www.comp.lancs.ac.uk/computing/research/cseg/projects/ reaims/

Herramientas:
z

Herramientas CASE (ver 2 ltimas transparencias) o buscar por tipo de herramientas en:
http://www.qucis.queensu.ca/Software-Engineering/toolcat.html http://www.incose.org/tools/eia632tax/reqdefine.html http://stfc.comp.polyu.edu.hk/STFC/SoftFactory/database/tools. html

GESSI Grup de recerca en Enginyeria del Software per als SI

Referencias y enlaces (2)

Volver

Estandards:
z

http://www.ips.id.ethz.ch/~parish/standard.html http://www.ansi.org/ http://standards.ieee.org/ http://www.iso.ch/

American National Standards Institute IEEE Standards International Organization for Standardization National Institute for Standards and Technology
http://www.nist.gov/

z z

GESSI Grup de recerca en Enginyeria del Software per als SI

Anlisis de riesgos
z z

Volver

Los riesgos deben documentarse en el plan de gestin del proyecto Riesgos habituales son:
Los incumplimientos de los requerimientos no funcionales del sistema tales como el rendimiento, la facilidad de uso y otros La no disponibilidad de componentes empaquetadas (off-the-shelf) o reutilizables Las desviaciones en plazos y costes La elevada rotacin de personal en empresas subcontratadas La reducida experiencia de las personas que construyen el software La no conformidad del producto obtenido a los requerimientos planteados (en un % significativo o en aspectos clave) La volatilidad de los requerimientos Uso de nuevas tecnologas no suficientemente probadas y estables Insuficiente seguridad de los datos y/o del acceso a los mismos

En ciertos entornos puede ser necesario disear simuladores que generen datos para asegurar los riesgos del proyecto, p.e. en el sector del transporte un aspecto fundamental es el de la seguridad y puede precisarse un simulador de azar para verificar que los requerimientos vinculados a la seguridad se definen y se cumplen

GESSI Grup de recerca en Enginyeria del Software per als SI

Diagrama de Flujo de Datos (DFD)

Visualizar detalles Detalles vuelo Planificacin Plan vuelo Vuelos Detalles cambio Detalles vuelo Asesorar situacin Datos radar Instrucciones cambio Peticin cambio Aeronave Conformidad peticin cambio Archivo

Detalles vuelo

Radar

Seal radar

Procesar seales Datos radar Visualizar radar

GESSI Grup de recerca en Enginyeria del Software per als SI

DFD con Flujo de Control

Visualizar detalles Detalles vuelo Planificacin Plan vuelo Vuelos Salida aeronave Visualizar aeronave Salida aeronave Status sector

Detalles cambio

Aproximacin aeronave Detalles vuelo Asesorar situacin

Archivo

Detalles vuelo

Radar

Seal radar

Procesar seales Datos radar Visualizar radar

Datos radar

Instrucciones cambio Peticin cambio

Conformidad peticin cambio

Aeronave

GESSI Grup de recerca en Enginyeria del Software per als SI

Diagrama de Estados Finitos

Aproximacin Aeronave Esperando aeronave Asesorar situacin Controlando aeronave Visualizar Aeronave Mostrar detalles Archivo detalles Salida aeronave Mostrando detalles

GESSI Grup de recerca en Enginyeria del Software per als SI

Diagrama Entidad-Relacin

Datos entrada Direccin Hora Altitud Localizacin 1 Datos transitorios 1 1 1 Datos salida Plan de Vuelo

Cdigo vuelo Tipo aeronave Origen Destino

Volver

GESSI Grup de recerca en Enginyeria del Software per als SI

Diagrama de Clase
Motor 1..4 Piloto 1..2 Vendedor de billetes 1

1 Avin 1 { disjunta, completa } *

* Vuelo 1 *

* Reserva

*
1

Avin militar

Avin comercial

Lnea area

{ disjunta, completa }

Avin de carga

Avin de pasajeros

GESSI Grup de recerca en Enginyeria del Software per als SI

Diagrama de Estados

alta

baja nmero_prstamos = 0

sin prstamos

Socio Biblioteca Nmero : int Nombre : char[50] Nmero prstamos : int = 0 Alta() Baja() Prestar(CdigoLibro : int, Fecha : date) Devolver(CdigoLibro : int, Fecha : date)

prestar

devolver[ nmero_prstamos = 1 ]

nmero_prstamos > 0 con prstamos

prestar

devolver[ nmero_prstamos > 1 ]

Al modelo...

GESSI Grup de recerca en Enginyeria del Software per als SI

Diagrama de Actividad
Buscar Bebida [no hay caf] [no hay zumo] [hay zumo]

[hay caf]

Poner caf en filtro Aadir agua al depsito Coger taza Poner filtro en mquina Coger zumo

Encender mquina ^cafetera.On Caf en preparacin indicador de fin Servir caf Beber

GESSI Grup de recerca en Enginyeria del Software per als SI

Diagrama de Actividad con bandas

Pasajero
Solicitar pasaje

Vendedor

Airline

Verificar existencia vuelo Dar detalles vuelo Informar alternativas y precios

Seleccionar vuelo

Solicitar pago Reservar plazas Pagar pasaje Confirmar plaza reservada

Emitir billete Volver...

GESSI Grup de recerca en Enginyeria del Software per als SI

Diagrama de Casos de Uso

Verificar Situacin

Vendedor

Cliente Establecer Crdito Supervisor

Preparar Catlogo

Secretaria

Tipos de Venta

GESSI Grup de recerca en Enginyeria del Software per als SI

Diagrama de Colaboracin
1: Coger libro : Libro

: Socio

2: Solicitar prstamo 3: Verificar situacin socio

: Ficha socio

8: Autorizar prstamo

4: Situacin socio ok

6: Situacin libro ok

: Encargado 7: Introducir prstamo : Prstamo

5: Verificar situacin libro : Ficha libro

GESSI Grup de recerca en Enginyeria del Software per als SI

Diagrama de Secuencia

Volver

: Socio

: Encargado Coger libro

: Libro

: Ficha socio

: Ficha libro

: Prstamo

Solicitar prstamo Verificar situacin socio Situacin socio ok Verificar situacin libro Situacin libro ok Introducir prstamo Autorizar prstamo

GESSI Grup de recerca en Enginyeria del Software per als SI

Obtencin de los requerimientos

Fuentes de los requerimientos

Identificar los objetivos del proyecto y eventualmente realizar un estudio de viabilidad de los mismos mbito de aplicacin o dominio de conocimiento del proyecto (permitir resolver conflictos entre actores) Identificar a todos los actores del proyecto para poder disear un sistema que recoja el punto de vista y sea fcil de usar por todos ellos Identificar el entorno operacional para poder establecer las restricciones del proyecto y los costes que comportarn las mismas Entorno organizativo: identificacin de los condicionantes que la estructura, la cultura y la poltica interna de la organizacin puedan imponer o sobre-entender

GESSI Grup de recerca en Enginyeria del Software per als SI

Obtencin de los requerimientos (2)

z

Tcnicas de obtencin de los requerimientos

  

Entrevistas con los actores: cerradas / abiertas Cuestionarios con preguntas concretas y respuestas cerradas / abiertas Escenarios (instancias de casos de uso): permiten contextualizar y preguntarse sobre Qu pasara si ... ? Cmo se hace esto ? Prototipos: permiten clarificar y precisar requerimientos Reuniones de grupo (normales o brainstorming): permiten aportar mayores puntos de vista que a travs de entrevistas individuales y aflorar puntos de vista contrapuestos. Es necesario gestionarlas correctamente para evitar conflictos o puntos de vista dominantes Observacin de los sistemas actuales y medida de distintos parmetros de los mismos a travs de la inmersin operacional. Ilustra acerca de las tareas y ciertos procesos complejos o sobreentendidos que raramente se explicitan Estudio de los documentos y formularios existentes actualmente Visitas a otras instalaciones, investigacin externa, jornadas profesionales, ferias Presentaciones comerciales, estudio de productos SW ya existentes

GESSI Grup de recerca en Enginyeria del Software per als SI

Entrevistas (1)
z

Planificacin
  

Qu datos desean obtenerse ? Quin debe ser entrevistado ? Cundo debe efectuarse la entrevista ? Dnde debe efectuarse la entrevista ? Recabar informacin externa sobre el problema a resolver Preparar preguntas como gua de la entrevista Informarse de las funciones, personalidad y cargo del entrevistado Concretar da, hora y lugar de la entrevista Anticipar objeto de la entrevista y agenda

Preparacin
    

GESSI Grup de recerca en Enginyeria del Software per als SI

Entrevistas (2)
z

Inicio
 

Exposicin general de la entrevista, objetivos, y duracin estimada Explicacin de la utilidad de la entrevista solicitud de apoyo al entrevistado Se invita y estimula al entrevistado a hablar informalmente Solicitud informal de autorizacin para tomar notas Las preguntas deben apuntar a la obtencin de la informacin deseada Permitir que el entrevistado siga su lnea de pensamiento y exposicin sin interrupciones Guiar la conversacin invitando al detalle si es preciso pero con momentos de sntesis con recapitulaciones Evitar controversias o crticas y sugerencias precipitadas Asegurarse de obtener toda la informacin necesaria y complementaria

Desarrollo
    

GESSI Grup de recerca en Enginyeria del Software per als SI

Entrevistas (3)

Volver

Cierre
 

Resumen de los puntos anotados Comprobacin de que se ha suministrado toda la informacin solicitada Dejar abierta la posibilidad de entrevistas posteriores Agradecimiento por la colaboracin En funcin del caso, brindar la entrega de una copia del documento resumen de la entrevista

Conclusiones

Elaboracin de un resumen formal de la entrevista Opcionalmente, se entrega copia al entrevistado y/o al interlocutor Confirmar conclusiones en las entrevistas posteriores Aclarar puntos de duda sin menospreciarlos, verificando los datos obtenidos

GESSI Grup de recerca en Enginyeria del Software per als SI

Anlisis de los requerimientos

Debe detectar conflictos entre requerimientos. Para ello usar matrices o tablas de doble entrada:
 

Poner los identificadores de los requerimientos en las primeras fila y columna Comparar cada requerimiento con cada uno de los restantes y en la celda correspondiente:
Si hay conflicto poner un 1 Si hay solapamiento poner un 1000 Si hay independencia poner un 0

Sumar filas y columnas El resto de dividir una suma entre 1000 nos da el nmero de conflictos para el requerimiento en cuestin El cociente de dividir una suma entre 1000 nos da el nmero de solapamientos para el requerimiento en cuestin Esta tcnica es operativa cuando el nmero de requerimientos <= 200 Si el nmero es superior a 200 conviene dividir el total de requerimientos en grupos funcionalmente homogneos: entradas de datos, procesamiento, salidas de datos, subsistemas, etc, para aplicarla a cada grupo

GESSI Grup de recerca en Enginyeria del Software per als SI

Cuestionario para analizar requerimientos

Diseo prematuro Requerimientos atmicos / combinados Requerimientos innecesarios Uso de hardware no standard Conformidad con los objetivos propuestos Requerimientos ambiguos Requerimientos realistas Requerimientos testeables Requiere el requerimiento un diseo prematuro o informacin sobre su implementacin? La descripcin del requerimiento lo es de un nico requerimiento o puede descomponerse en varios requerimientos? Es el requerimiento un aditamento cosmtico al sistema que no es necesario? Es necesario HW o SW no standard para implementar el requerimiento? Es el requerimiento consistente con los objetivos de negocio planteados al inicio de la DR? Pueden interpretar personas diferentes de modo diverso el mismo requerimiento? Qu interpretaciones son posibles? Es realista el requerimiento dada la tecnologa en la que deber implementarse el sistema? Podr generarse un juego de pruebas para testear si el sistema incluye el presente requerimiento y es conforme a la especificacin?

GESSI Grup de recerca en Enginyeria del Software per als SI

Anlisis de requerimientos (3)

Atmico / Combinado Innecesario Tecnologa no standard Realista Testeable Requerimiento Diseo prematuro

Ejemplos de tablas para detectar conflictos y solapamientos y para el anlisis de requerimientos

Req R1 R2 R3 R4 R5 R6 R1 0 0 1000 0 1 1 R2 0 0 0 0 0 0 R3 1000 0 0 1000 0 1000 R4 0 0 1000 0 1 1 R5 1 0 0 1 0 0 R6 1 0 1000 1 0 0

R1 R2 R3 R4 R5 R6

N N N N N S

A A C A A A

N N N N N N

N S N N N N

S S S S S S

S S N S S N

R1 y R3, R3 y R4, R3 y R6 se solapan R1 y R5, R1 y R6, R4 y R5, R4 y R6 presentan conflictos R2 es independiente de los dems

R6 requiere diseo prematuro R3 es combinacin de otros 2 req. R2 requiere tecnologa no standard R3 y R6 no pueden ser testeados

GESSI Grup de recerca en Enginyeria del Software per als SI

Anlisis de los requerimientos (4)

z

z z

Debe delimitar los lmites del sistema y cmo interacciona con el entorno, manualmente o con otros sistemas informticos Hay que especificar las interfases o intercambios de informacin entre sistemas y su modalidad (on-line, batch) Debe elaborar la lista de los requerimientos funcionales y no funcionales del sistema para facilitar los requerimientos de software Clasificacin de los requerimientos:
Funcionales / no funcionales Del producto / del proceso De alto nivel / propiedad emergente / derivado Prioridad mbito y componentes Volatilidad / Estabilidad Otras
Volver
      

GESSI Grup de recerca en Enginyeria del Software per als SI

Puntos de vista
Puntos de vista enfocando los requerimientos inherentes al problema Problema

PV1

PV2

Puntos de vista proyectando los requerimientos en el sistema

Sistema

GESSI Grup de recerca en Enginyeria del Software per als SI

El proceso de definicin de requerimientos con puntos de vista

Obtencin de requerimientos Identificar el asunto clave Elaborar el asunto clave
Versiones de requerimientos, Cambios de puntos de vista

Identificar Puntos de vista

Descubrir requerimientos
Asunto clave, Puntos de vista, Requerimientos externos, Requerimientos

Ciclo de Obtencin, Anlisis, Negociacin

Inconsistencias, Incompletitudes

Resolver inconsistencias Negociacin de requerimientos

Analizar interacciones entre puntos de vista Anlisis de requerimientos

Asunto clave de los puntos de vista

Integrar y dar formato Definicin de requerimientos

GESSI Grup de recerca en Enginyeria del Software per als SI

Puntos de vista (3)

z z z z z z z z

Volver

z z

Aportan la visin parcial de los distintos actores del sistema Debe incluirse el PV de las interfases con otros sistemas Deben incluirse como PV los requerimientos de seguridad Centran la atencin del analista en las partes que afectan a cada actor Aseguran mayor completitud en la DR Pueden evidenciar conflictos o incompatibilidades entre los requerimientos de los distintos actores Duplican requerimientos compatibles (potencialmente podrn ser integrados en uno solo) Permiten identificar inconsistencias entre requerimientos. Para ello conviene aplicar la tcnica descrita para analizar conflictos entre requerimientos Permiten una trazabilidad ms clara Es una tcnica complementaria a las otras tcnicas descritas

GESSI Grup de recerca en Enginyeria del Software per als SI

Requerimientos no funcionales
PRESSMAN 1988 BOEHM 1976
z z z z z z z

Correccin Fiabilidad Eficacia Integridad Facilidad mantenimiento Flexibilidad Facilidad de prueba Portabilidad Reusabilidad (Reutilizacin del SW) Interoperabilidad Facilidad de uso (Usabilidad)

Portabilidad Fiabilidad Eficiencia Amigabilidad Verificabilidad Comprensible Modificable

GESSI Grup de recerca en Enginyeria del Software per als SI

Posibles mtricas para la especificacin de requerimientos no funcionales

Fiabilidad Fiabilidad Disponibilidad Rendimiento Rendimiento Tiempo medio entre fallos Tasa de ocurrencias de fallos Probabilidad de fallo ante una peticin Nmero de transacciones a ser procesadas por segundo Tiempo de respuesta ante un input del usuario

Utilizacin de Tamao mximo del sistema en Kb (kilobytes) almacenamiento Usabilidad Usabilidad Robustez Integridad Tiempo requerido para aprender el 75% de las funcionalidades del sistema por parte de un usuario Promedio del nmero de errores cometidos por los usuarios en un perodo determinado Tiempo para reiniciar el sistema ante una cada del sistema Prdida mxima de datos ante una cada del sistema

Volver

GESSI Grup de recerca en Enginyeria del Software per als SI

Negociacin de los requerimientos

z z

Volver

Tambin denominada resolucin de conflictos Se refiere a la resolucin de conflictos entre:

  

Requerimientos incompatibles Actores que demandan requerimientos incompatibles Recursos disponibles y requerimientos solicitados Requerimientos funcionales y restricciones

z z

Frecuentemente el analista no tiene capacidad para decidir, por lo que debe favorecer el consenso, y si hay un contrato de prestacin de servicios, debe dejarse traza del por qu de la decisin tomada Podra incorporarse como parte de la Validacin de requerimientos La mejor tcnica es la de las reuniones con los involucrados, previamente preparadas y documentadas para conocer el impacto de los conflictos y sus posibles soluciones Otras tcnicas son: correo electrnico, boletines electrnicos, bases de datos compartidas tipo Lotus Notes con la documentacin de los requerimientos y sus conflictos. No estn excesivamente probadas y su utilidad puede ser dudosa si se genera una actitud de desinters

GESSI Grup de recerca en Enginyeria del Software per als SI

Ejemplo de especificacin de requerimientos

Volver

REQUERIMIENTO DESCRIPCIN

Comprobar la validez de la tarjeta en un cajero automtico Esta operacin debe asegurar que la tarjeta introducida por el usuario ha sido emitida por uno de los bancos asociados, es vigente y contiene la identificacin de la cuenta bancaria. Los datos son ledos de la banda magntica IdentificadorBanco, NmeroCuenta, FechaExpiracin Mdulo xyz - Gestin cajero Estatus(0,1) ListaBancos, FormatoCuentas, FechaDaActual La tarjeta ha sido introducida y la banda magntica leda Estatus = 1 si IdentificadorBanco EST EN ListaBancos Y NmeroCuenta COINCIDE CON FormatoCuentas Y FechaExpiracin >= FechaDaActual Estatus = 0 EN CASO CONTRARIO

ORIGEN INPUTS DESTINO OUTPUTS PRE-REQUISITOS PRE-CONDICIN POSTCONDICIN

GESSI Grup de recerca en Enginyeria del Software per als SI

Validacin de los requerimientos

La conduccin de la revisin de los requerimientos

 

Los mecanismos habituales son las inspecciones y las revisiones formales Se constituir un grupo de revisores con representacin de todos los actores o al menos los ms significativos para buscar:
Errores y contradicciones Supuestos y/o hechos errneos Falta de claridad Desviaciones de las prcticas standard

La composicin del grupo incluir representantes de los distintos actores que trabajarn sobre la base de la check-list o lista de requerimientos. Es deseable la participacin de algn experto ajeno a la DR, que acte como abogado del diablo Servirn para completar los documentos DR y SRS o generarn una nueva versin

GESSI Grup de recerca en Enginyeria del Software per als SI

Cuestionario de validacin de la DR
Completitud Consistencia Comprensible Ambigedad Estructuracin Trazabilidad Conformidad a standards Es completo el conjunto de requerimientos? Falta algn requerimiento? Es completo cada uno de los requerimientos? Falta alguna informacin? Son consistentes los requerimientos? Hay alguna contradiccin entre distintos requerimientos? Son comprensibles los requerimientos? Puede un lector entender lo que significan cada uno de ellos? Son ambiguos algunos requerimientos? Pueden darse distintas interpretaciones de los mismos? Est estructurado el documento DR? Estn agrupados los requerimientos relacionados entre s? Sera ms fcil de entender otra estructura? Pueden identificarse unvocamente los requerimientos? Incluyen enlaces a los requerimientos relacionados y a las razones para incluirlos? Es conforme a los estndares definidos el documento DR en su conjunto? Es conforme a los estndares definidos cada uno de los requerimientos individualmente?

GESSI Grup de recerca en Enginyeria del Software per als SI

Validacin de los requerimientos (2)

G

La comisin de validacin debe contar con la presencia de uno o varios usuarios, un responsable del cliente, desarrolladores, el o los analistas de requerimientos y varios expertos funcionales en el problema Todos ellos cumplimentarn la tabla adjunta que se adjuntar a la documentacin de la DR En reuniones plenarias revisarn los requerimientos y resolvern los problemas que hayan surgido Acordarn los cambios y cerrarn la versin o decidirn reiniciar el proceso de anlisis
Volver

Completo

Consistente

Comprensible

Ambiguo

Estructurado

Trazable

Conforme a standards

DR Req-1 Req-2 Req-3 -----Req-N

GESSI Grup de recerca en Enginyeria del Software per als SI

Prototipos
z z z z z z

z z z

Se usan habitualmente para validar requerimientos Tambin pueden usarse para la obtencin de nuevos requerimientos si stos no estn claros o hay malentendidos Facilitan la identificacin de los errores del analista y del por qu de dichos errores Son una herramienta dinmica para la discusin de la interfase de usuario en lugar de flip-charts, storyboards o similares Corren el riesgo de distraer la atencin en aspectos secundarios como la esttica o detalles no relevantes No sirven para mostrar los requerimientos de tiempo real como sensores, automatismos,... ni para los requerimientos no funcionales de usabilidad, fiabilidad, etc Pueden ser de usar y tirar a los solos efectos de la validacin, o evolutivos que constituyen la base del futuro producto software Su coste depende del de la herramienta que se use y del tipo y detalle de prototipo (obliga a profundizar en la arquitectura del software) Herramientas: generadores de prototipos, Visualbasic, pginas Web

GESSI Grup de recerca en Enginyeria del Software per als SI

Prototipos de usar y tirar

ESTUDIO PREVIO DEFINICIN DE REQUERIMIENTOS

ESPECIFICACIN PROTOTIPO

CONSTRUIR PROTOTIPO

VALIDAR PROTOTIPO

ESPECIFICACIN REQUERIMIENTOS

ANLISIS Y DISEO

CONSTRUCCIN

IMPLEMENTACIN

GESSI Grup de recerca en Enginyeria del Software per als SI

Prototipos evolutivos

Volver

ESTUDIO PREVIO

ESPECIFICACIN INCREMENTO

CONSTRUIR INCREMENTO

VALIDAR INCREMENTO

IMPLEMENTAR ELEMENTO

NO

SISTEMA COMPLETO ?

SI
IMPLEMENTAR SISTEMA COMPLETO