GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I

Ingeniería de Requisitos: conceptos,procesos y estado de lainvestigación

Seminario de DoctoradoGrupo Arcos, Depto. Informática, Univ. Carlos IIIMadrid, 1-3/02/2005

Pere Botella - Depto. LSI - UPCbotella@lsi.upc.edupere.botella@upc.edu

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Contenidos

z Definiciones y ámbitoz Los procesos: conceptos básicosz El proceso de la Ingeniería de Requisitos: modelos de

procesoz Las actividades: descripción de las diferentes tareasz Propiedades y validaciónz Gestión de requisitosz La investigación: visión generalz Grupos de investigación relevantes y sus líneasz La investigación en el grupo GESSI

Y en algunos momentos...

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I

Referenciasz [Dav92] Davis, A. (1992). Software Requirements: Objects, Functions

and States. Prentice-Hallz [Fil94] Finkelstein, A. (1994)Requirements Engineering: a review and research

agenda. Proc 1st Asian & Pacific Software Engineering Conference,IEEE CS Press

z [Jac95] Jackson, M. (1995). Software Requirements & Specifications.Addison-Wesley

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

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

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

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

Mas...

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Contenidos

z Definiciones y ámbitoz Los procesos: conceptos básicosz El proceso de la Ingeniería de Requisitos: modelos de

procesoz Las actividades: descripción de las diferentes tareasz Propiedades y validaciónz Gestión de requisitosz La investigación: visión generalz Grupos de investigación relevantes y sus líneasz La investigación en el grupo GESSI

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Definición 1

Requirements Engineering is the branch of SystemsEngineering concerned with the real-world goals for, servicesprovided by,and constraints on a large and complex software-intensive systems. It is also concerned with the relationship ofthese factors to precise specifications of system behaviour, andto their evolutionover time and across system families.

Zave, P. (1994); Call for Papers and Associated Classification Scheme;IEEE International Symposium on Requirements Engineering 1995.

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Definición 2

Requirements Engineering deals with activities which attempt tounderstand the exact needs of the users of a software intensivesystem and to translate such needs into precise and unambiguousstatements which will be subsequently be used in the developmentof the system

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

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Definición 3

A requirement is:1. A condition or capacity needed by a user to solve a problem orachieve an objective2. A condition or capability that must be met or possesed by asystem or system component to satisfy a contract, standard,specification, or other formally imposed documents3. A documented representation of a condition or capabilityas in 1 or 2

IEEE-Std.’610’ (1990) IEEE Standard Glossary of Software EngineeringTerminology. IEEE Computer Society Press

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Definición 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 EngineeringMcGraw-Hill, 1995

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I • Se trata de un término relativamente reciente que pretende cubrirtodas las actividades relacionadas con descubrir, documentar ymantener un conjunto de requisitos para un sistema informático(KS97)

• Tiene mucho en común con el tradicionalmente denominado“análisis de sistemas”

• Es una de las áreas mas activas de investigación actual, yaunque emerge de la Ingeniería del Software, se reclama partede la Ingeniería de Sistemas, entendida de forma más ampliaque la anterior

• Es la etapa inicial de un proyecto de sistema de información, yes imprescindible en el pre-proyecto (si se desea una estimaciónfiable)

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I - Porqué es importante la Ingeniería de Requisitos (el caso negativo)

- Contacto con el cliente- Gasto de tiempo y esfuerzo- Coste de depurar errores- Minimizar riesgos

- Porqué es importante la Ingeniería de Requisitos (el caso positivo)

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

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

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I

- European User Survey Analysis, M. Ibañez (European SoftwareInstitute) & H. Rempp (Forschungszentrum Karlsruhe), proyectoESPITI, ESI report TR95104

- 17 paises, 4000 cuestionarios, sector IT, empresas de productios y servicios

- “Requirements specification” y “Managing customer requirements”los dos problemas señalados cómo mas importantes, un 50 % como“problema mayor” , un 35 % como “problema menor”, menos de un12 % como “no es problema”.

- Por encima de documentación, “testing”, calidad, standards, diseño,gestión de la configuración y programación.

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

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I The 1994 Chaos report (www.standishgroup.com)

z Muestra de 365 encuestasz Final de los proyectos estudiados

� 16,2 % terminan bien (tiempo, dinero, requisitos)

� 52,7 % termina y funciona, pero +tiempo, +dinero, -requisitos

� 31,1 % proyecto canceladoz Project success factors: 1) user involvement (15,9%),

3) clear statement of requirementsz Project challenged factors: 1) lack of user input, 2)

incomplete requirements, 3) changing requirementsz Cambios en el report de 2001...z Y seguramente en el report “The 2004 Chaos

research”... pero cuesta 3500$ !!!

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Contenidos

z Definiciones y ámbitoz Los procesos: conceptos básicosz El proceso de la Ingeniería de Requisitos: modelos de

procesoz Las actividades: descripción de las diferentes tareasz Propiedades y validaciónz Gestión de requisitosz La investigación: visión generalz Grupos de investigación relevantes y sus líneasz La investigación en el grupo GESSI

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I

Conceptos de tecnología de procesos (no relacionados directamentecon la Ing. de Requisitos)

z Proceso Software: conjunto de tareas inter-relacionadasconducentes a la construcción de software

z Modelo de proceso software: descripción abstracta (osimplificada) de una clase de procesos

z SPA (Software Process Assessment): evaluación de un procesosoftware, determinación de capacidad y madurez

z SPI (Software Process Improvement): mejora de procesossoftware, basada en la evaluación

z SPM (Software Process Modelling): modelización de procesossoftware, mediante lenguajes o notaciones de diversagranularidad

z Modelos para SPA/SPI: CMM, ISO 15288 (SPICE)

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Contenidos

z Definiciones y ámbitoz Los procesos: conceptos básicosz El proceso de la Ingeniería de Requisitos: modelos de

procesoz Las actividades: descripción de las diferentes tareasz Propiedades y validaciónz Gestión de requisitosz La investigación: visión generalz Grupos de investigación relevantes y sus líneasz La investigación en el grupo GESSI

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I El proceso de la Ingeniería de Requisitos

z Proceso de construcción del documento o especificación delos requisitos del sistema a construir

z Veremos este proceso según LK95, KS97 y Poh96z Veremos las actividades o tareas que incluyez Veremos un modelo de niveles de madurez, según SS97

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I

Usuario

Adquisición(elicitation) Especificación Validación

Dominio delproblema

Requisitosdel usuario

Espec. derequisitos

Modelo avalidar

Respuesta

Conocimiento

Petición

Modelos

Resultado

Conocimiento Conocimiento

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

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

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

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

z Análisis; especificación o modelizaciónz Validación

El proceso se adapta a los diferentes modelos de proceso general de Ingeniería del Software (cascada, espiral, prototipado, transformacional, etc.)

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

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

AdquisiciónAnálisis ynegociación Documentación Validación

Necesidades delusuario, dominiode información, sistemas existentes,normas, estándares, ...

Documento derequisitos

Especificacióndelsistema

Requisitosacordados

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I El proceso de la Ingeniería de Requisitos:un modelo espiral (según KS97)

Análisis y negociación

Documentación

Inicio

Validación

Adquisición

Requisitos “en bruto”

Requisitosacordados

Borrador del documento

Documentovalidado

Punto de decisión:aceptar o re-entrar

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

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

Validación &Verificación

Validación &Verificación ElicitaciónElicitación

NegociaciónNegociaciónEspecificación &Documentación

Especificación &Documentación

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Un modelo de madurez para la RE (SS97)

Nivel 1 - InicialRE “ad-hoc”Problemas frecuentescon los requisitos

Nivel 2 - RepetibleRE estandarizadaPocos problemas con los requisitos

Nivel 3 - DefinidoProceso bien definido.Se proponen mejorasdel proceso de la RE

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

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Contenidos

z Definiciones y ámbitoz Los procesos: conceptos básicosz El proceso de la Ingeniería de Requisitos: modelos de

procesoz Las actividades: descripción de las diferentes tareasz Propiedades y validaciónz Gestión de requisitosz La investigación: visión generalz Grupos de investigación relevantes y sus líneasz La investigación en el grupo GESSI

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

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

z Se define como el proceso de adquirir (elicitar,determinar, “sonsacar”, obtener...) todo el conocimientorelevante necesario para producir el modelo de losrequisitos del problema dominio

z Puede calificarse cómo proceso socialz Se utilizan técnicas diversas:

� Entrevistas (metódicas)� Cuestionarios� Standards de IdS� Sistemas existentes� Análisis de textos (lenguaje natural)� etc.

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

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

z Se basa en comprender cuatro dimensiones:

� Dominio de aplicación

� Problema a resolver

� Necesidades y restricciones de los “stakeholders” (usuario ensentido amplio: todos los agentes implicados en el sistema aconstruir)

� Contexto organizativo

z Las técnicas de prototipado ayudan en el proceso de descubrimiento

z El resultado es un documento que contiene esencialmente una lista (yque se suele denominar SRS: Software Requirements Specification, esdecir, documento de especificación)

Mas sobre adquisición... Mas sobre prototipos...

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Análisis y negociación de requisitos (KS97)

z Análisis basado en “checklists”, lista de preguntas que se puedeusar para cada requisito

z Mediante matrices, se pueden representar las relaciones entrerequisitos: conflicto, solapamiento e independencia (mas)

z La negociación “guiada” entre agentes (”stakeholders”) es elproceso para resolver conflictos y contradicciones (mas)

z Hay que tener presentes los diferentes puntos de vista (mas)

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

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

z En los modelos de proceso descritos (y habitualmente), se consideraesta actividad cómo la responsable de obtener una lista depurada derequisitos, una vez obtenida la lista “en bruto” y una vez analizada yresueltos los conflictos

z Existen guias para este documento, cómo la de IEEE Std 1233 (1998Edition IEEE Guide For Developing System RequirementsSpecifications,http://standards.ieee.org/reading/ieee/std_public/description/se/1233-1998_desc.html ) o las plantillas de “Volere” (http://www.volere.co.uk/ )

z Un ejemploz Sin embargo, las buenas prácticas de la Ingeniería de Software

recomiendan completar este documento, ya en ésta fase, con unmodelo (usando UML, p.ej.), al que también se suele denominarespecificación

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

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Modelización (o especificación) de requisitos

z Consiste en construir un modelo (o varios) del sistema aconstruir, desde el punto de vista de su uso (interacciónusuario-sistema) que recoja todos y cada uno de los requisitosde la lista

z Además del documento, se parte del dominio que se modela, elUniverso del Discurso (UoD)

z Aspectos a tener en cuenta:

� Modelización conceptual

� Modelización de empresas

� Modelización de requisitos funcionales

� Modelización de requisitos no funcionalesz 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 realizaruna estimación de costes y tiempos (p.ej., por puntos defunción)

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Modelización conceptual de Sistemas de Información

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

z Se suele denominar “Modelo conceptual” a la especificación delos requisitos de la información que deberá contener y manejarel sistema, y que parte de extraer y comprender conocimientodel dominio de aplicación (el UoD)

z Una especificación desarrollada en términos de un ModeloConceptual representa abstracciones, asunciones yrestricciones del dominio de aplicación

z En UML, podemos representar un Modelo Conceptual medianteel diagrama de clases, con sus relaciones y restricciones(expresadas normalmente en OCL)

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Modelización de empresas

z “Enterprise modelling” o “Business modelling”z Un modelo de este tipo incluye: estructuras organizativas;

objetivos; actividades, procesos y productos; agentes yroles

z Sirve para delimitar el modelo de los requisitos delsistema a construir

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

z En UML se puede describir, en parte, con un diagrama deactividad, y en el RUP, mediante workflows

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

IModelización de requisitos funcionales

z Construcción de un modelo de aquellos requisitos quedescriben interacción (no información), es decir, la funcionalidaddel sistema a construir

z A lo largo de los años se han propuesto muchos formalismos omé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étodosalgebraicos)

� Basados en puntos de vista o “viewpoints” ( SADT, CORE,VOSE, VORD)

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

z Es el aspecto mas divulgado y conocido (a veces, con nombreserróneos, cómo “metodologías” los primeros y segundos, o“métodos formales” los terceros)

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Modelización de requisitos no funcionales

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

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

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

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

Factores contractuales, Factores políticos, etc.)z Han de poseer dos atributos (Sommerville’92):

� Han de ser objetivos

� Han de poder ser probadosz UML no los contempla (excepto con anotaciones), hay pocas

notaciones para modelizarlos, y poco divulgadas

Mas...

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Contenidos

z Definiciones y ámbitoz Los procesos: conceptos básicosz El proceso de la Ingeniería de Requisitos: modelos de

procesoz Las actividades: descripción de las diferentes tareasz Propiedades y validaciónz Gestión de requisitosz La investigación: visión generalz Grupos de investigación relevantes y sus líneasz La investigación en el grupo GESSI

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Propiedades de las especificaciones (LK95)

z Consistencia internaz No ambigüedadz Consistencia externaz Minimalidadz Completitudz No redundancia

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

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Validación de requisitos

z Técnicas (LK95):

� Uso de prototipos

� Animación (aplic. de tiempo-real)

� Parafraseado (de espec.formales)

� Sistemas expertos (CASE)

z Técnicas (KS95):

� Revisiones

� Prototipado� Validación del modelo

� Prueba (“testing”)

Consiste en verificar el grado de cumplimiento de las propiedades

Mas...

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Contenidos

z Definiciones y ámbitoz Los procesos: conceptos básicosz El proceso de la Ingeniería de Requisitos: modelos de

procesoz Las actividades: descripción de las diferentes tareasz Propiedades y validaciónz Gestión de requisitosz La investigación: visión generalz Grupos de investigación relevantes y sus líneasz La investigación en el grupo GESSI

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I

• 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 sonestables

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

Gestión de requisitos (KS97)

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Trazabilidad de requisitos

- Define la capacidad de describir y seguir la vida de un requisito en las dos direcciones (atrás y adelante)- Se diferencia la Pre-RT de la Post-RT

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

Pre-RT Post-RT

Fuentes Especificación Diseño Código

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Contenidos

z Definiciones y ámbitoz Los procesos: conceptos básicosz El proceso de la Ingeniería de Requisitos: modelos de

procesoz Las actividades: descripción de las diferentes tareasz Propiedades y validaciónz Gestión de requisitosz La investigación: visión generalz Grupos de investigación relevantes y sus líneasz La investigación en el grupo GESSI

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I

What is the purpose of RENOIR ?

The general purpose of RENOIR is to develop thecoordination mechanisms and infrastructure for research inrequirements engineering. Specific objectives are: to provide aframework for coordinated, joint research related to industrialneeds, to support the diffusion of RE research; to provide REresearch training and to support technology transfer in RE.

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)

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I

Who belongs to RENOIR ?

The sixty eight founding members of RENOIR include almostall the key research teams working in the area of requirementsengineering within Europe. The coordinator of RENOIR is theUniversity College London (UCL), UK. Membership is opento any research laboratory or industrial group of researchers inEurope (or in countries with cooperation agreements with theEuropean Union) which has interests in the area ofrequirements engineering, which subscribes to the aims ofRENOIR and is interested in participating in the activities ofthe network. New applicants for membership are welcome.

La coordinación en España fue a cargo de la UPC

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I

• 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

RENOIR brings together research teams from industry,academia, and research centres round a set of shared technicalgoals relating to the:

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Temas del CfP de RE’05 (www.re05.org)5HTXLUHPHQWV�HOLFLWDWLRQ�DQG�LGHQWLILFDWLRQ�,QIRUPDO�PRGHOOLQJ�RI�UHTXLUHPHQWV�'RPDLQ�PRGHOOLQJ�)RUPDO�PRGHOOLQJ�RI�JRDOV�DQG�UHTXLUHPHQWV�6SHFLILFDWLRQ�ODQJXDJHV�)RUPDO�DQDO\VLV�DQG�YHULILFDWLRQ�0XOWLSOH�YLHZSRLQWV��PDQDJLQJ�LQFRQVLVWHQF\�1RQIXQFWLRQDO�DQG�TXDOLW\�UHTXLUHPHQWV�3ULRULWL]DWLRQ��QHJRWLDWLRQ��DQG�UHVROXWLRQ�RI�FRQIOLFWLQJ�UHTXLUHPHQWV�3URWRW\SLQJ��DQLPDWLRQ��VLPXODWLRQ�5HTXLUHPHQWV�YDOLGDWLRQ�5HTXLUHPHQWV�HYROXWLRQ�RYHU�WLPH��DFURVV�SURGXFW�IDPLOLHV�������YDULDELOLW\�UHTXLUHPHQWV�5HTXLUHPHQWV�PDQDJHPHQW��WUDFHDELOLW\��PHWULFV�5HTXLUHPHQWV�PHWKRGRORJLHV��H�J���$JLOH�PHWKRGV��6RFLDO��FXOWXUDO��DQG�FRJQLWLYH�IDFWRUV�LQ�UHTXLUHPHQWV�DFWLYLWLHV�$OLJQLQJ�UHTXLUHPHQWV�WR�EXVLQHVV�JRDOV�DQG�SURFHVVHV�5HODWLQJ�UHTXLUHPHQWV�WR�V\VWHP�DUFKLWHFWXUH��WHVWLQJ�5HTXLUHPHQWV�IRU�&276�EDVHG�V\VWHPV�5HTXLUHPHQWV�IRU�LQWHURSHUDWLQJ��PXOWL�RUJDQL]DWLRQDO�V\VWHPV�'RPDLQ�VSHFLILF�SUREOHPV�DQG�VROXWLRQV��H�J���KLJK�DVVXUDQFH�V\VWHPV�������������VHFXUH�V\VWHPV��VRFLR�WHFKQLFDO�V\VWHPV��WHOHFRPPXQLFDWLRQV�DQG������������GLVWULEXWHG�V\VWHPV��EXVLQHVV�DQG�LQIRUPDWLRQ�V\VWHPV�

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Temas del CfP de RE’04 (www.re04.org)

$FTXLULQJ���GLVFRYHULQJ�DQG�FUHDWLQJ�UHTXLUHPHQWV�9DOLGDWLQJ�UHTXLUHPHQWV�3ULRULWLVLQJ�DQG�QHJRWLDWLQJ�DERXW�UHTXLUHPHQWV�5HTXLUHPHQWV�PDQDJHPHQW�DQG�WUDFHDELOLW\�*RDO�RULHQWHG�UHTXLUHPHQWV�HQJLQHHULQJ�8VH�FDVHV�DQG�VFHQDULRV�LQ�WKH�UHTXLUHPHQWV�SURFHVV�3URWRW\SLQJ��DQLPDWLQJ�DQG�H[HFXWLQJ�UHTXLUHPHQWV�5HTXLUHPHQWV�HQJLQHHULQJ�IRU�DJLOH�SURFHVVHV�&RPELQLQJ�IRUPDO�DQG�LQIRUPDO�UHTXLUHPHQWV�VSHFLILFDWLRQ�WHFKQLTXHV��������PDNLQJ�IRUPDO�WHFKQLTXHV�XVDEOH�6RFLDO��FXOWXUDO�DQG�FRJQLWLYH�IDFWRUV�LQ�UHTXLUHPHQWV�HQJLQHHULQJ�5HTXLUHPHQWV�PHWULFV�5HTXLUHPHQWV�HQJLQHHULQJ�HGXFDWLRQ�+RZ�UHTXLUHPHQWV�UHODWH�WR�EXVLQHVV�SURFHVVHV��ZRUN�UH�GHVLJQ��������DQG�VRIWZDUH�DUFKLWHFWXUHV�+RZ�UHTXLUHPHQWV�UHODWH�WR�VRIWZDUH�DUFKLWHFWXUHV�,QWHUWZLQLQJ�UHTXLUHPHQWV�DQG�GHVLJQ��DQG�UHTXLUHPHQWV�DQG�WHVWLQJ�7RRO�VXSSRUW�IRU�UHTXLUHPHQWV�HQJLQHHULQJ�

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Recursos en Internet

5HTXLUHPHQWV�(QJLQHHULQJ�2Q�OLQH��5(�RQOLQH��'LVFXVVLRQ�)RUXPKWWS���UHVHDUFK�LW�XWV�HGX�DX�UH�VHUYLFHVBUHRQOLQH�KWPO�3RLQWHUV�WR�5HTXLUHPHQWV�(QJLQHHULQJ�5HVRXUFHV�KWWS���UHVHDUFK�LW�XWV�HGX�DX�UH�FJL�ELQ�UHVRXUFHVBELEOLRJUDSK\�FJL�5HTXLUHPHQWV�(QJLQHHULQJ�3RUWDOKWWS���ZZZ�ZHEZRUG�FRP�VHUYLFHV�US�KWPO�6(,�5(�5HVRXUFHVKWWS���LQWHUDFWLYH�VHL�FPX�HGX�)HDWXUHV������0DUFK�/LQNV�/LQNV�PDU���KWP�,(((�7DVN�)RUFH�RQ�5HTXLUHPHQWV�(QJLQHHULQJ��7)5(�KWWS���ZZZ�VKX�DF�XN�WIUH��5HTXLUHPHQWV�ELEOLRJUDSK\KWWS���ZHE�XFFV�HGX�DGDYLV�8&&6�UHTELE�KWP��GH�$ODQ�'DYLV�KWWS���ZZZ�LQI�SXF�ULR�EU�aEGELE��GH�-XOLR� /HLWH�

)XHQWH��$ODQ� 'DYLV��'LGDU�=RZJKL ��,(((�6(� 2QOLQH

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I&RQIHUHQFLDV,QWHUQDWLRQDO�5HTXLUHPHQWV�(QJLQHHULQJ�&RQIHUHQFH��5(¶[[��IXVLyQ�GHVGH�����GH�,&5(�\�GHO�ZRUNVKRS�5(�:RUNVKRSV�HVSHFtILFRV�HQ�,&6(��2236/$��(6(&��-,6%'��HWF���HYHQWRV�GH,QJHQLHUtD�GHO�6RIWZDUH

5HYLVWDV³5HTXLUHPHQWV�(QJLQHHULQJ´��SXEOLFDGD�SRU�6SULQJHU �9HUODJ$UWtFXORV�HQ�UHYLVWDV�GH�,QJ��GHO�6RIWZDUH��,(((�7UDQVDFWLRQV�RQ�6�(��,(((�6RIWZDUH��&RPP��RI�WKH�$&0��$&0�7UDQV��RQ�6�(���HWF��+HUUDPLHQWDVKWWS���ZZZ�YROHUH�FR�XN�WRROV�KWP(VWiQGDUHV,(((�5HFRPHQGHG�3UDFWLFH�IRU�6RIWZDUH�5HTXLUHPHQWV�6SHFLILFDWLRQ��,(((�������������KWWS���ZZZ�VWDQIRUG�HGX�FODVV�FV����KDQGRXWV�LHHH���������SGI�,(((�6WG������������(GLWLRQ�,(((�*XLGH�)RU�'HYHORSLQJ�6\VWHP�5HTXLUHPHQWV�6SHFLILFDWLRQV��KWWS���VWDQGDUGV�LHHH�RUJ�UHDGLQJ�LHHH�VWGBSXEOLF�GHVFULSWLRQ�VH����������B GHVF�KWPO

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Contenidos

z Definiciones y ámbitoz Los procesos: conceptos básicosz El proceso de la Ingeniería de Requisitos: modelos de

procesoz Las actividades: descripción de las diferentes tareasz Propiedades y validaciónz Gestión de requisitosz La investigación: visión generalz Grupos de investigación relevantes y sus líneasz La investigación en el grupo GESSI

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I0LHPEURV,),3�:*����w w w . w g 2 9 . o r g

$QWRQ��$QQLH$WOHH��-R%HUU\��'DQ%XEHQNR��-DQLV'XERLV��(ULF(DVWHUEURRN��6WHYH)HDWKHU��0DUWLQ)HEORZLW]��0DUN)LFNDV��6WHYH)LQNHOVWHLQ��$QWKRQ\*KH]]L��&DUOR*UHHQVSDQ�� 6RO+HLWPH\HU�� &RQQLH-DFNVRQ��0LFKDHO-DFNVRQ��'DQLHO-DUNH��0DWWKLDV.UDPHU��-HII/HLWH��-XOLR0\ORSRXORV��-RKQ1XVHLEHK��%DVKDU3RKO�� .ODXV3RWWV��&ROLQ5RELQVRQ��%LOO5\DQ��.HYLQ6XWFOLIIH��$OLVWDLUYDQ�/DPVZHHUGH��$[HO=DYH��3DPHOD

Editora de RE-Online: Didar Zowghi

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

Grupos en España con trabajos explícitos en Ing. de Req.

Universidad Politecnica de Valencia (Oscar Pastor, Isidro Ramos)Universidad de Murcia (Ambrosio Toval)Universidad de Sevilla (Miguel Toro, Amador Durán)Universidad Politecnica de Madrid (Natalia Juristo)Universidad Politecnica de Cataluña (Xavier Franch, Pere Botella)

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I 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 Panthéon 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/)

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

IItaly: 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 Politècnica 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 .

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

ISwitzerland: 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: Björn 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).

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Contenidos

z Definiciones y ámbitoz Los procesos: conceptos básicosz El proceso de la Ingeniería de Requisitos: modelos de

procesoz Las actividades: descripción de las diferentes tareasz Propiedades y validaciónz Gestión de requisitosz La investigación: visión generalz Grupos de investigación relevantes y sus líneasz La investigación 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

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Trabajos recientes del grupo Gessi

z Junio 2001, JIRA 01, notación NoFunz Septiembre 2002, RE02, modelos de calidad,

requisitos para selección de COTSz Noviembre 2002, WER02, visión globalz Julio 2004, SCI’2004, construcción de taxonomías

basada en metasz Uso del modelo i*

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I

D

RT

EasyAdministration RTUPackage Routed

RTA

DNS

Efficient Routing

D

D

D

DD

D D

D

DDD

D

D

D

DD

D

Routing Status

Forvide UnwantedRouting

InterconectionFacilities

PerformanceTuning

Up-to-DateManagement ofRouting Tables

Destination IPAddress

DD

Interfaces &Connectors

El modelo i* (Yu)

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

Definición de RequerimientosDefinición de Requerimientos

Josep M Llovet PérezJosep M Llovet Pérezjmllovetjmllovet@@telefonica.nettelefonica.net

Universitat Politècnica de Catalunya

Master de Ingeniería del SoftwareMaster de Ingeniería del Software

Las transparencias que siguen a ésta, y hasta la última corresponden al curso “Definición de Requerimientos” del Máster de Ingeniería 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...)

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Bibliografía

Definición de Requerimientos:• Managing Software Requirements: A Use Case Approach,

Second Edition. Dean Leffingwell & Don Widrig.�$GGLVRQ�:HVOH\� 2003

• Requirements Engineering: process and techniques. GeraldKotonya & Ian Sommerville. John Wiley & sons. 2000

• Requirements Engineering: a good practice guide. IanSommerville & 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

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Bibliografía (2)

Modelización 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. JohnWiley & sons. 2000

• Enterprise Modelling with UML. Chris Marshall. Addison-Wesley. 1999

Ingeniería del Software (capítulos dedicados a la DR):• Ingeniería del Software, Un enfoque práctico. Roger

Pressman. Capítulo 10. 5a edición Ed Mc Graw Hill. 2001• Ingeniería del Software. Ian Sommerville. Capítulos 5 al 9.

6a edición. Addison-Wesley. 2001

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Referencias y enlaces

Técnicas, guías y documentación sobre DR:z Guías y documentación sobre Definición de

Requerimientos

� http://www.comp.lancs.ac.uk/computing/resources/re-gpg/

z Proyecto Reaims

� 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

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Referencias y enlaces (2)

Estandards:

� http://www.ips.id.ethz.ch/~parish/standard.html

z American National Standards Institute

� http://www.ansi.org/

z IEEE Standards

� http://standards.ieee.org/

z International Organization for Standardization

� http://www.iso.ch/

z National Institute for Standards and Technology

� http://www.nist.gov/

Volver

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Análisis de riesgos

z Los riesgos deben documentarse en el plan de gestión del proyectoz Riesgos habituales son:

� Los incumplimientos de los requerimientos no funcionales del sistema tales comoel 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 rotación 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 tecnologías no suficientemente probadas y estables

� Insuficiente seguridad de los datos y/o del acceso a los mismos

z En ciertos entornos puede ser necesario diseñar simuladores quegeneren datos para asegurar los riesgos del proyecto, p.e. en elsector del transporte un aspecto fundamental es el de la seguridady puede precisarse un simulador de azar para verificar que losrequerimientos vinculados a la seguridad se definen y se cumplen

Volver

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Diagrama de Flujo de Datos (DFD)

Planificación

Radar

Aeronave

Visualizar detalles

Procesar señales

Visualizarradar

Asesorarsituación

Señal radar

Datosradar

Datosradar

Detallesvuelo

Detallesvuelo

Plan vuelo

Detallesvuelo

Detallescambio

Peticióncambio

Conformidad petición cambioInstrucciones

cambio

Vuelos Archivo

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I DFD con Flujo de Control

Planificación

Radar

Aeronave

Visualizar detalles

Procesar señales

Visualizarradar

Asesorarsituación

Statussector

Señal radar

Datosradar

Datosradar

Detallesvuelo

Detallesvuelo

Plan vuelo

Detallesvuelo

Detallescambio

Peticióncambio

Conformidad petición cambioInstrucciones

cambio

Vuelos Archivo

Salida aeronave

Salida aeronave

Visualizar aeronave

Aproximación aeronave

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Diagrama de Estados Finitos

AproximaciónAeronave

Asesorarsituación

VisualizarAeronave

Mostrardetalles

Salida aeronave

Esperandoaeronave

Controlandoaeronave

Mostrando detalles

Archivo detalles

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Diagrama Entidad-Relación

Datostransitorios

Plan deVuelo

Código vuelo

Tipo aeronave

Origen

Destino

Dirección

Hora

Altitud

Localización Datos salida

Datos entrada

1

1

1

1

Volver

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Diagrama de Clase

Avión militar Avión comercial

Avión de carga Avión de pasajeros

Motor

Avión

1..4

1

Piloto Vendedor de billetes

Reserva

*

1

Vuelo*1

1..2

**1

Línea aérea

1

1

1..4 1..2 1

1 * 1 *

*{ disjunta, completa }

{ disjunta, completa }

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Diagrama de Estados

con préstamos

sin préstamos

alta baja

prestar devolver[ número_préstamos = 1 ]

prestar

devolver[ número_préstamos > 1 ]

número_préstamos = 0

número_préstamos > 0

Socio BibliotecaNúmero : intNombre : char[50]Número préstamos : int = 0

Alta()Baja()Prestar(CódigoLibro : int, Fecha : date)Devolver(CódigoLibro : int, Fecha : date)

Al modelo...

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Diagrama de Actividad

Buscar Bebida

Poner café en filtro Añadir agua al depósito Coger taza

Poner filtro en máquina

Encender máquina

Café en preparación

Servir café

Coger zumo

Beber

[no hay café]

[hay café]

[no hay zumo]

[hay zumo]

^cafetera.On

indicador de fin

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Diagrama de Actividad con bandas

Emitir billete

Pasajero Vendedor Airline

Solicitar pago Reservar plazas

Confirmar plaza reservadaPagar pasaje

Informar alternativas y precios

Verificar existencia vuelo

Dar detalles vuelo

Solicitar pasaje

Seleccionar vuelo

Volver...

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Diagrama de Casos de Uso

Cliente

VendedorVerificar Situación

SupervisorEstablecer Crédito

SecretariaPreparar Catálogo

Tipos de Venta

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Diagrama de Colaboración

: Socio

: Encargado

: Libro

: Ficha libro

: Ficha socio

: Préstamo

1: Coger libro

2: Solicitar préstamo

8: Autorizar préstamo

3: Verificar situación socio

4: Situación socio ok

5: Verificar situación libro

6: Situación libro ok

7: Introducir préstamo

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Diagrama de Secuencia

: Socio : Encargado : Libro : Ficha libro : Ficha socio : Préstamo

Coger libro

Solicitar préstamo

Verificar situación socio

Situación socio ok

Verificar situación libro

Situación libro ok

Introducir préstamo

Autorizar préstamo

Volver

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Obtención de los requerimientos

z Fuentes de los requerimientos

Identificar los objetivos del proyecto y eventualmenterealizar un estudio de viabilidad de los mismos

Ámbito de aplicación o dominio de conocimiento delproyecto (permitirá resolver conflictos entre actores)

Identificar a todos los actores del proyecto para poderdiseñar un sistema que recoja el punto de vista y seafácil de usar por todos ellos

Identificar el entorno operacional para poder establecerlas restricciones del proyecto y los costes quecomportarán las mismas

Entorno organizativo: identificación de los condicionantesque la estructura, la cultura y la política interna de laorganización puedan imponer o sobre-entender

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Obtención de los requerimientos (2)

z Técnicas de obtención 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 ypreguntarse sobre ‘¿Qué pasaría si ... ?’ ‘¿Cómo se hace ‘esto’ ?’

Prototipos: permiten clarificar y precisar requerimientos

Reuniones de grupo (normales o ‘brainstorming’): permiten aportar mayorespuntos de vista que a través de entrevistas individuales y aflorar puntos devista contrapuestos. Es necesario gestionarlas correctamente para evitarconflictos o puntos de vista dominantes

Observación de los sistemas actuales y medida de distintos parámetros de losmismos a través de la inmersión operacional. Ilustra acerca de las tareas yciertos procesos complejos o sobreentendidos que raramente se explicitan

Estudio de los documentos y formularios existentes actualmente

Visitas a otras instalaciones, investigación externa, jornadas profesionales,ferias

Presentaciones comerciales, estudio de productos SW ya existentes

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Entrevistas (1)

z Planificación

� Qué datos desean obtenerse ?

� Quién debe ser entrevistado ?

� Cuándo debe efectuarse la entrevista ?

� Dónde debe efectuarse la entrevista ?

z Preparación

� Recabar información externa sobre el problema a resolver

� Preparar preguntas como guía de la entrevista

� Informarse de las funciones, personalidad y cargo del entrevistado

� Concretar día, hora y lugar de la entrevista

� Anticipar objeto de la entrevista y agenda

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Entrevistas (2)

z Inicio

� Exposición general de la entrevista, objetivos, y duraciónestimada

� Explicación de la utilidad de la entrevista solicitud de apoyo alentrevistado

� Se invita y estimula al entrevistado a hablar informalmente

� Solicitud informal de autorización para tomar notas

z Desarrollo

� Las preguntas deben apuntar a la obtención de la informacióndeseada

� Permitir que el entrevistado siga su línea de pensamiento yexposición sin interrupciones

� Guiar la conversación invitando al detalle si es preciso pero conmomentos de síntesis con recapitulaciones

� Evitar controversias o críticas y sugerencias precipitadas

� Asegurarse de obtener toda la información necesaria ycomplementaria

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Entrevistas (3)

z Cierre

Resumen de los puntos anotados

Comprobación de que se ha suministrado toda la informaciónsolicitada

Dejar abierta la posibilidad de entrevistas posteriores

Agradecimiento por la colaboración

En función del caso, brindar la entrega de una copia deldocumento resumen de la entrevista

z Conclusiones� Elaboración 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

Volver

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Análisis de los requerimientos

z Debe detectar conflictos entre requerimientos. Paraello usar matrices o tablas de doble entrada:

� Poner los identificadores de los requerimientos en las primeras fila ycolumna

� Comparar cada requerimiento con cada uno de los restantes y en la celdacorrespondiente:

• 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 número de conflictos parael requerimiento en cuestión

� El cociente de dividir una suma entre 1000 nos da el número desolapamientos para el requerimiento en cuestión

� Esta técnica es operativa cuando el número de requerimientos <= 200

� Si el número es superior a 200 conviene dividir el total de requerimientos engrupos funcionalmente homogéneos: entradas de datos, procesamiento,salidas de datos, subsistemas, etc, para aplicarla a cada grupo

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Cuestionario para analizar requerimientos

¿La descripción del requerimiento lo es de un único requerimiento opuede descomponerse en varios requerimientos?

Requerimientosatómicos / combinados

¿Podrá generarse un juego de pruebas para testear si el sistemaincluye el presente requerimiento y es conforme a la especificación?

Requerimientostesteables

¿Es realista el requerimiento dada la tecnología en la que deberáimplementarse el sistema?

Requerimientosrealistas

¿Pueden interpretar personas diferentes de modo diverso el mismorequerimiento? ¿Qué interpretaciones son posibles?

Requerimientosambiguos

¿Es el requerimiento consistente con los objetivos de negocioplanteados al inicio de la DR?

Conformidad con losobjetivos propuestos

¿Es necesario HW o SW no standard para implementar elrequerimiento?

Uso de hardware nostandard

¿Es el requerimiento un aditamento cosmético al sistema que no esnecesario?

Requerimientosinnecesarios

¿Requiere el requerimiento un diseño prematuro o información sobresu implementación?

Diseño prematuro

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Análisis de requerimientos (3)

001100001R6

001001R5

110100000R4

100001000001000R3

000000R2

110100000R1

R6R5R4R3R2R1Req

R1 y R3, R3 y R4, R3 y R6 se solapanR1 y R5, R1 y R6, R4 y R5, R4 y R6presentan conflictosR2 es independiente de los demás

R6 requiere diseño prematuroR3 es combinación de otros 2 req.R2 requiere tecnología no standardR3 y R6 no pueden ser testeados

Ejemplos de tablas para detectarconflictos ysolapamientos y para el análisis derequerimientos

NSNNASR6

SSNNANR5

SSNNANR4

NSNNCNR3

SSSNANR2

SSNNANR1

Testeable

Realista

Tecnología nostandard

Innecesario

Atóm

ico /C

ombinado

Diseño

prematuro

Requerim

iento

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Análisis de los requerimientos (4)

z Debe delimitar los límites del sistema y cómo interaccionacon el entorno, manualmente o con otros sistemasinformáticos

z Hay que especificar las interfases o intercambios deinformación entre sistemas y su modalidad (on-line, batch)

z Debe elaborar la lista de los requerimientos funcionales y nofuncionales del sistema para facilitar los requerimientos desoftware

z Clasificación de los requerimientos:

� Funcionales / no funcionales

� Del producto / del proceso

� De alto nivel / propiedad emergente / derivado

� Prioridad

� Ámbito y componentes

� Volatilidad / Estabilidad

� Otras

Volver

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I

Problema

Sistema

Puntos de vista

PV1 PV2

Puntos de vista enfocandolos requerimientosinherentes al problema

Puntos de vista proyectandolos requerimientos enel sistema

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

IEl proceso de definición de requerimientos con puntos devista

Descubrirrequerimientos

IdentificarPuntos de vista

Elaborar el asunto clave

Identificar el asunto clave

Obtención de requerimientos

Analizar interaccionesentre puntos de vista

Análisis derequerimientos

Resolverinconsistencias

Negociación derequerimientos

Asunto clave,Puntos de vista,Requerimientosexternos,Requerimientos

Versiones de requerimientos,

Cambios de puntos de vista

Integrar y dar formato

Definición derequerimientos

Inconsistencias,Incompletitudes

Asunto clave de los puntos de vista

Ciclo deObtención,Análisis,Negociación

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Puntos de vista (3)

z Aportan la visión parcial de los distintos actores del sistemaz Debe incluirse el PV de las interfases con otros sistemasz Deben incluirse como PV los requerimientos de seguridadz Centran la atención del analista en las partes que afectan a cada actorz Aseguran mayor completitud en la DRz Pueden evidenciar conflictos o incompatibilidades entre los

requerimientos de los distintos actoresz Duplican requerimientos compatibles (potencialmente podrán ser

integrados en uno solo)z Permiten identificar inconsistencias entre requerimientos. Para ello

conviene aplicar la técnica descrita para analizar conflictos entrerequerimientos

z Permiten una trazabilidad más claraz Es una técnica complementaria a las otras técnicas descritas

Volver

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Requerimientos no funcionales

BOEHM 1976

z Portabilidadz Fiabilidadz Eficienciaz Amigabilidadz Verificabilidadz Comprensiblez Modificable

PRESSMAN 1988

• Corrección

• Fiabilidad

• Eficacia

• Integridad

• Facilidad mantenimiento

• Flexibilidad

• Facilidad de prueba

• Portabilidad

• Reusabilidad (Reutilización del SW)

• Interoperabilidad

• Facilidad de uso (Usabilidad)

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Posibles métricas para la especificación de requerimientosno funcionales

Pérdida máxima de datos ante una caída del sistemaIntegridad

Tiempo para reiniciar el sistema ante una caída del sistemaRobustez

Promedio del número de errores cometidos por los usuariosen un período determinado

Usabilidad

Tiempo requerido para aprender el 75% de lasfuncionalidades del sistema por parte de un usuario

Usabilidad

Tamaño máximo del sistema en Kb (kilobytes)Utilización dealmacenamiento

Tiempo de respuesta ante un input del usuarioRendimiento

Número de transacciones a ser procesadas por segundoRendimiento

Probabilidad de fallo ante una peticiónDisponibilidad

Tasa de ocurrencias de fallosFiabilidad

Tiempo medio entre fallosFiabilidad

Volver

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Negociación de los requerimientos

z También denominada resolución de conflictosz Se refiere a la resolución de conflictos entre:

� Requerimientos incompatibles

� Actores que demandan requerimientos incompatibles

� Recursos disponibles y requerimientos solicitados

� Requerimientos funcionales y restricciones

z Frecuentemente el analista no tiene capacidad para decidir, por loque debe favorecer el consenso, y si hay un contrato de prestaciónde servicios, debe dejarse traza del por qué de la decisión tomada

z Podría incorporarse como parte de la Validación de requerimientosz La mejor técnica es la de las reuniones con los involucrados,

previamente preparadas y documentadas para conocer el impactode los conflictos y sus posibles soluciones

z Otras técnicas son: correo electrónico, boletines electrónicos,bases de datos compartidas tipo Lotus Notes con la documentaciónde los requerimientos y sus conflictos. No están excesivamenteprobadas y su utilidad puede ser dudosa si se genera una actitudde desinterés

Volver

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Ejemplo de especificación de requerimientos

Estatus = 1 si IdentificadorBanco ESTÁ EN ListaBancos Y NúmeroCuenta COINCIDE CON FormatoCuentas Y FechaExpiración >= FechaDíaActualEstatus = 0 EN CASO CONTRARIO

POST-CONDICIÓN

La tarjeta ha sido introducida y la banda magnética leídaPRE-CONDICIÓN

ListaBancos, FormatoCuentas, FechaDíaActualPRE-REQUISITOS

Estatus(0,1)OUTPUTS

Módulo xyz - Gestión cajeroDESTINO

IdentificadorBanco, NúmeroCuenta, FechaExpiraciónINPUTS

Los datos son leídos de la banda magnéticaORIGEN

Esta operación debe asegurar que la tarjeta introducida por elusuario ha sido emitida por uno de los bancos asociados, es vigentey contiene la identificación de la cuenta bancaria.

DESCRIPCIÓN

Comprobar la validez de la tarjeta en un cajero automáticoREQUERIMIENTO

Volver

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Validación de los requerimientos

z La conducción de la revisión de los requerimientos

� Los mecanismos habituales son las inspecciones y lasrevisiones formales

� Se constituirá un grupo de revisores con representación detodos los actores o al menos los más significativos para buscar:

• Errores y contradicciones• Supuestos y/o hechos erróneos• Falta de claridad• Desviaciones de las prácticas standard

� La composición del grupo incluirá representantes de losdistintos actores que trabajarán sobre la base de la ‘check-list’o lista de requerimientos. Es deseable la participación de algúnexperto ajeno a la DR, que actúe como ‘abogado del diablo’

� Servirán para completar los documentos DR y SRS ogenerarán una nueva versión

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Cuestionario de validación de la DR

¿Es conforme a los estándares definidos el documento DR en su conjunto?¿Es conforme a los estándares definidos cada uno de los requerimientosindividualmente?

Conformidad astandards

¿Pueden identificarse unívocamente los requerimientos? ¿Incluyen enlaces alos requerimientos relacionados y a las razones para incluirlos?

Trazabilidad

¿Está estructurado el documento DR? ¿Están agrupados los requerimientosrelacionados entre sí? ¿Sería más fácil de entender otra estructura?

Estructuración

¿Son ambiguos algunos requerimientos? ¿Pueden darse distintasinterpretaciones de los mismos?

Ambigüedad

¿Son comprensibles los requerimientos? ¿Puede un lector entender lo quesignifican cada uno de ellos?

Comprensible

¿Son consistentes los requerimientos? ¿Hay alguna contradicción entredistintos requerimientos?

Consistencia

¿Es completo el conjunto de requerimientos? ¿Falta algún requerimiento?¿Es completo cada uno de los requerimientos? ¿Falta alguna información?

Completitud

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Validación de los requerimientos (2)

l La comisión de validación debecontar con la presencia de uno ovarios usuarios, un responsabledel cliente, desarrolladores, el olos analistas de requerimientos yvarios expertos funcionales en elproblema

l Todos ellos cumplimentarán latabla adjunta que se adjuntará ala documentación de la DR

l En reuniones plenarias revisaránlos requerimientos y resolveránlos problemas que hayan surgido

l Acordarán los cambios ycerrarán la versión o decidiránreiniciar el proceso de análisis

Req-N

------

Req-3

Req-2

Req-1

DR

Conform

e a standards

Trazable

Estructurado

Am

biguo

Com

prensible

Consistente

Com

pleto

Volver

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Prototipos

z Se usan habitualmente para validar requerimientosz También pueden usarse para la obtención de nuevos requerimientos si éstos

no están claros o hay malentendidosz Facilitan la identificación de los errores del analista y del por qué de dichos

erroresz Son una herramienta dinámica para la discusión de la interfase de usuario en

lugar de ‘flip-charts’, ‘storyboards’ o similaresz Corren el riesgo de distraer la atención en aspectos secundarios como la

estética o detalles no relevantesz No sirven para mostrar los requerimientos de ‘tiempo real’ como sensores,

automatismos,... ni para los requerimientos no funcionales de usabilidad,fiabilidad, etc

z Pueden ser ‘de usar y tirar’ a los solos efectos de la validación, o ‘evolutivos’que constituyen la base del futuro producto software

z Su coste depende del de la herramienta que se use y del tipo y detalle deprototipo (obliga a profundizar en la arquitectura del software)

z Herramientas: generadores de prototipos, Visualbasic, páginas Web

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Prototipos de ‘usar y tirar’

CONSTRUCCIÓN

ANÁLISIS Y DISEÑO

DEFINICIÓN DE REQUERIMIENTOS

IMPLEMENTACIÓN

VALIDAR PROTOTIPO

CONSTRUIR PROTOTIPO

ESPECIFICACIÓN PROTOTIPO

ESTUDIOPREVIO

ESPECIFICACIÓN REQUERIMIENTOS

GE

SS

I – G

rup

de r

ecer

ca e

n E

ngin

yeri

a de

l Sof

twar

e pe

r al

s S

I Prototipos ‘evolutivos’

VALIDARINCREMENTO

CONSTRUIRINCREMENTO

ESPECIFICACIÓNINCREMENTO

ESTUDIOPREVIO

IMPLEMENTAR SISTEMA COMPLETO

IMPLEMENTARELEMENTO

SISTEMA COMPLETO ?

SI

NO

Volver