ingreqciii

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

Ingeniera de Requisitos: conceptos,procesos y estado de lainvestigacinSeminario de DoctoradoGrupo Arcos, Depto. Informtica, Univ. Carlos IIIMadrid, 1-3/02/2005

Pere Botella - Depto. LSI - [email protected]@upc.edu

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Contenidos

z Definiciones y mbitoz Los procesos: conceptos bsicosz El proceso de la Ingeniera de Requisitos: modelos de

procesoz Las actividades: descripcin de las diferentes tareasz Propiedades y validacinz Gestin de requisitosz La investigacin: visin generalz Grupos de investigacin relevantes y sus lneasz La investigacin en el grupo GESSI

Y en algunos momentos...

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

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

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Contenidos



GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Definicin 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

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Definicin 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

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Definicin 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

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Se trata de un trmino relativamente reciente que pretende cubrirtodas las actividades relacionadas con descubrir, documentar ymantener un conjunto de requisitos para un sistema informtico(KS97)

Tiene mucho en comn con el tradicionalmente denominadoanlisis de sistemas

Es una de las reas mas activas de investigacin actual, yaunque emerge de la Ingeniera del Software, se reclama partede la Ingeniera de Sistemas, entendida de forma ms ampliaque la anterior

Es la etapa inicial de un proyecto de sistema de informacin, yes imprescindible en el pre-proyecto (si se desea una estimacinfiable)

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

- 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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

- European User Survey Analysis, M. Ibaez (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 requirementslos dos problemas sealados cmo mas importantes, un 50 % comoproblema mayor , un 35 % como problema menor, menos de un12 % como no es problema.

- Por encima de documentacin, testing, calidad, standards, diseo,gestin de la configuracin y programacin.


GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

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

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Contenidos



GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

Conceptos de tecnologa de procesos (no relacionados directamentecon la Ing. de Requisitos)

z Proceso Software: conjunto de tareas inter-relacionadasconducentes a la construccin de software

z Modelo de proceso software: descripcin abstracta (osimplificada) de una clase de procesos

z SPA (Software Process Assessment): evaluacin de un procesosoftware, determinacin de capacidad y madurez

z SPI (Software Process Improvement): mejora de procesossoftware, basada en la evaluacin

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

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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Contenidos



GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I El proceso de la Ingeniera de Requisitos

z Proceso de construccin del documento o especificacin delos requisitos del sistema a construir

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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

Usuario

Adquisicin(elicitation) Especificacin Validacin

Dominio delproblema

Requisitosdel usuario

Espec. derequisitos

Modelo avalidar

Respuesta

Conocimiento

Peticin

Modelos

Resultado

Conocimiento Conocimiento

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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

El proceso de la Ingeniera de Requisitos(segn LK95)

z Adquisicin (captura, definicin, determinacin,identificacin, obtencin, ...)

z Anlisis; especificacin o modelizacinz Validacin

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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

El proceso de la Ingeniera de Requisitos(segn KS97)

Adquisicin Anlisis ynegociacin Documentacin

Validacin

Necesidades delusuario, dominiode informacin, sistemas existentes,normas,

estndares, ...

Documento derequisitos

Especificacindelsistema

Requisitosacordados

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

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

Anlisis y negociacin

Documentacin

Inicio

Validacin

Adquisicin

Requisitos en bruto

Requisitosacordados

Borrador del documento

Documentovalidado

Punto de decisin:aceptar o re-entrar

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I El proceso de la Ingeniera de Requisitos (segn Poh96)

Validacin &Verificacin

Validacin &Verificacin ElicitacinElicitacin

NegociacinNegociacinEspecificacin &DocumentacinEspecificacin &Documentacin

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

Un modelo de madurez para la RE (SS97)

Nivel 1 - InicialRE ad-hocProblemas 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

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Contenidos



GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Adquisicin (LK95, KS97) o elicitacin (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 cmo proceso socialz Se utilizan tcnicas diversas:

Entrevistas (metdicas) Cuestionarios Standards de IdS Sistemas existentes Anlisis de textos (lenguaje natural) etc.

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I 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 ensentido amplio: todos los agentes implicados en el sistema aconstruir)

Contexto organizativo

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

Mas sobre adquisicin... Mas sobre prototipos...

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Anlisis y negociacin de requisitos (KS97)

z Anlisis 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 negociacin guiada entre agentes (stakeholders) es elproceso para resolver conflictos y contradicciones (mas)

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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Especificacin (LK95) o Documentacin (KS97) de requisitos

z En los modelos de proceso descritos (y habitualmente), se consideraesta actividad cmo 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, cmo 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 prcticas de la Ingeniera de Software

recomiendan completar este documento, ya en sta fase, con unmodelo (usando UML, p.ej.), al que tambin se suele denominarespecificacin

z As, que segn el autor, la especificacin puede ser la lista o elmodelo (por ello, prefiero hablar de documento de requisitos y demodelo(s) del sistema)

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Modelizacin (o especificacin) de requisitosz Consiste en construir un modelo (o varios) del sistema a

construir, desde el punto de vista de su uso (interaccinusuario-sistema) que recoja todos y cada uno de los requisitosde la lista

z Adems del documento, se parte del dominio que se modela, elUniverso del Discurso (UoD)

z Aspectos a tener en cuenta:

Modelizacin conceptual

Modelizacin de empresas

Modelizacin de requisitos funcionales

Modelizacin de requisitos no funcionalesz La modelizacin es esencial en los pre-proyectos (documento

de requisitos + modelos + (opc.) prototipo + estimacin +presupuesto), ya que permite una validacin y tambin realizaruna estimacin de costes y tiempos (p.ej., por puntos defuncin)

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Modelizacin conceptual de Sistemas de Informacin

z El trmino nace del rea de los sistemas de informacin y seasocia tradicionalmente al mbito de las Bases de Datos

z Se suele denominar Modelo conceptual a la especificacin delos requisitos de la informacin que deber contener y manejarel sistema, y que parte de extraer y comprender conocimientodel dominio de aplicacin (el UoD)

z Una especificacin desarrollada en trminos de un ModeloConceptual representa abstracciones, asunciones yrestricciones del dominio de aplicacin

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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Modelizacin de empresas

z Enterprise modelling o Business modellingz 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 identificacin 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

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

Modelizacin de requisitos funcionales

z Construccin de un modelo de aquellos requisitos quedescriben interaccin (no informacin), es decir, la funcionalidaddel sistema a construir

z A lo largo de los aos se han propuesto muchos formalismos omtodos para la definicin de modelos

Estructurados (SASD, YSM, Information Engineering, etc.)

Orientados a objetos (Booch, Fusion, OMT, UML)

Tcnicas de descripcin formal (VDM, Z, mtodosalgebraicos)

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 colaboracin

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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Modelizacin de requisitos no funcionales

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

informacin a guardar, ni funciones a realizarz Aspectos de proceso (mtodo de desarrollo, entorno de

implementacin, standards, etc.)z Aspectos de producto (Integracin, Rendimiento, Capacidad,

Seguridad, Integridad, Fiabilidad, Usabilidad, etc.)z Aspectos externos (Aspectos sociales, Aspectos econmicos,

Factores contractuales, Factores polticos, etc.)z Han de poseer dos atributos (Sommerville92):

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

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Contenidos



GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Propiedades de las especificaciones (LK95)

z Consistencia internaz No ambigedadz Consistencia externaz Minimalidadz Completitudz No redundancia

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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Validacin de requisitos

z Tcnicas (LK95):

Uso de prototipos

Animacin (aplic. de tiempo-real)

Parafraseado (de espec.formales)

Sistemas expertos (CASE)

z Tcnicas (KS95):

Revisiones

Prototipado Validacin del modelo

Prueba (testing)

Consiste en verificar el grado de cumplimiento de las propiedades

Mas...

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Contenidos



GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

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 sonestables

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)

Gestin de requisitos (KS97)

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

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


Pre-RT Post-RT

Fuentes Especificacin Diseo Cdigo

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Contenidos



GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

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

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

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 coordinacin en Espaa fue a cargo de la UPC

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

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

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Temas del CfP de RE05 (www.re05.org)5HTXLUHPHQWVHOLFLWDWLRQDQGLGHQWLILFDWLRQ,QIRUPDOPRGHOOLQJRIUHTXLUHPHQWV'RPDLQPRGHOOLQJ)RUPDOPRGHOOLQJRIJRDOVDQGUHTXLUHPHQWV6SHFLILFDWLRQODQJXDJHV)RUPDODQDO\VLVDQGYHULILFDWLRQ0XOWLSOHYLHZSRLQWVPDQDJLQJLQFRQVLVWHQF\1RQIXQFWLRQDODQGTXDOLW\UHTXLUHPHQWV3ULRULWL]DWLRQQHJRWLDWLRQDQGUHVROXWLRQRIFRQIOLFWLQJUHTXLUHPHQWV3URWRW\SLQJDQLPDWLRQVLPXODWLRQ5HTXLUHPHQWVYDOLGDWLRQ5HTXLUHPHQWVHYROXWLRQRYHUWLPHDFURVVSURGXFWIDPLOLHVYDULDELOLW\UHTXLUHPHQWV5HTXLUHPHQWVPDQDJHPHQWWUDFHDELOLW\PHWULFV5HTXLUHPHQWVPHWKRGRORJLHVHJ$JLOHPHWKRGV6RFLDOFXOWXUDODQGFRJQLWLYHIDFWRUVLQUHTXLUHPHQWVDFWLYLWLHV$OLJQLQJUHTXLUHPHQWVWREXVLQHVVJRDOVDQGSURFHVVHV5HODWLQJUHTXLUHPHQWVWRV\VWHPDUFKLWHFWXUHWHVWLQJ5HTXLUHPHQWVIRU&276EDVHGV\VWHPV5HTXLUHPHQWVIRULQWHURSHUDWLQJPXOWLRUJDQL]DWLRQDOV\VWHPV'RPDLQVSHFLILFSUREOHPVDQGVROXWLRQVHJKLJKDVVXUDQFHV\VWHPVVHFXUHV\VWHPVVRFLRWHFKQLFDOV\VWHPVWHOHFRPPXQLFDWLRQVDQGGLVWULEXWHGV\VWHPVEXVLQHVVDQGLQIRUPDWLRQV\VWHPV

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Temas del CfP de RE04 (www.re04.org)$FTXLULQJGLVFRYHULQJDQGFUHDWLQJUHTXLUHPHQWV9DOLGDWLQJUHTXLUHPHQWV3ULRULWLVLQJDQGQHJRWLDWLQJDERXWUHTXLUHPHQWV5HTXLUHPHQWVPDQDJHPHQWDQGWUDFHDELOLW\*RDORULHQWHGUHTXLUHPHQWVHQJLQHHULQJ8VHFDVHVDQGVFHQDULRVLQWKHUHTXLUHPHQWVSURFHVV3URWRW\SLQJDQLPDWLQJDQGH[HFXWLQJUHTXLUHPHQWV5HTXLUHPHQWVHQJLQHHULQJIRUDJLOHSURFHVVHV&RPELQLQJIRUPDODQGLQIRUPDOUHTXLUHPHQWVVSHFLILFDWLRQWHFKQLTXHVPDNLQJIRUPDOWHFKQLTXHVXVDEOH6RFLDOFXOWXUDODQGFRJQLWLYHIDFWRUVLQUHTXLUHPHQWVHQJLQHHULQJ5HTXLUHPHQWVPHWULFV5HTXLUHPHQWVHQJLQHHULQJHGXFDWLRQ+RZUHTXLUHPHQWVUHODWHWREXVLQHVVSURFHVVHVZRUNUHGHVLJQDQGVRIWZDUHDUFKLWHFWXUHV+RZUHTXLUHPHQWVUHODWHWRVRIWZDUHDUFKLWHFWXUHV,QWHUWZLQLQJUHTXLUHPHQWVDQGGHVLJQDQGUHTXLUHPHQWVDQGWHVWLQJ7RROVXSSRUWIRUUHTXLUHPHQWVHQJLQHHULQJ

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Recursos en Internet

5HTXLUHPHQWV(QJLQHHULQJ2QOLQH5(RQOLQH'LVFXVVLRQ)RUXPKWWSUHVHDUFKLWXWVHGXDXUHVHUYLFHVBUHRQOLQHKWPO3RLQWHUVWR5HTXLUHPHQWV(QJLQHHULQJ5HVRXUFHVKWWSUHVHDUFKLWXWVHGXDXUHFJLELQUHVRXUFHVBELEOLRJUDSK\FJL5HTXLUHPHQWV(QJLQHHULQJ3RUWDOKWWSZZZZHEZRUGFRPVHUYLFHVUSKWPO6(,5(5HVRXUFHVKWWSLQWHUDFWLYHVHLFPXHGX)HDWXUHV0DUFK/LQNV/LQNVPDUKWP,(((7DVN)RUFHRQ5HTXLUHPHQWV(QJLQHHULQJ7)5(KWWSZZZVKXDFXNWIUH5HTXLUHPHQWVELEOLRJUDSK\KWWSZHEXFFVHGXDGDYLV8&&6UHTELEKWPGH$ODQ'DYLVKWWSZZZLQISXFULREUaEGELEGH-XOLR /HLWH

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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

&RQIHUHQFLDV,QWHUQDWLRQDO5HTXLUHPHQWV(QJLQHHULQJ&RQIHUHQFH5([[IXVLyQGHVGHGH,&5(\GHOZRUNVKRS5(:RUNVKRSVHVSHFtILFRVHQ,&6(2236/$(6(&-,6%'HWFHYHQWRVGH,QJHQLHUtDGHO6RIWZDUH

5HYLVWDV5HTXLUHPHQWV(QJLQHHULQJSXEOLFDGDSRU6SULQJHU 9HUODJ$UWtFXORVHQUHYLVWDVGH,QJGHO6RIWZDUH,(((7UDQVDFWLRQVRQ6(,(((6RIWZDUH&RPPRIWKH$&0$&07UDQVRQ6(HWF+HUUDPLHQWDVKWWSZZZYROHUHFRXNWRROVKWP(VWiQGDUHV,(((5HFRPHQGHG3UDFWLFHIRU6RIWZDUH5HTXLUHPHQWV6SHFLILFDWLRQ,(((KWWSZZZVWDQIRUGHGXFODVVFVKDQGRXWVLHHHSGI,(((6WG(GLWLRQ,(((*XLGH)RU'HYHORSLQJ6\VWHP5HTXLUHPHQWV6SHFLILFDWLRQVKWWSVWDQGDUGVLHHHRUJUHDGLQJLHHHVWGBSXEOLFGHVFULSWLRQVHB GHVFKWPO

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Contenidos



GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

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

$QWRQ$QQLH$WOHH-R%HUU\'DQ%XEHQNR-DQLV'XERLV(ULF(DVWHUEURRN6WHYH)HDWKHU0DUWLQ)HEORZLW]0DUN)LFNDV6WHYH)LQNHOVWHLQ$QWKRQ\*KH]]L&DUOR*UHHQVSDQ 6RO+HLWPH\HU &RQQLH-DFNVRQ0LFKDHO-DFNVRQ'DQLHO-DUNH0DWWKLDV.UDPHU-HII/HLWH-XOLR0\ORSRXORV-RKQ1XVHLEHK%DVKDU3RKO .ODXV3RWWV&ROLQ5RELQVRQ%LOO5\DQ.HYLQ6XWFOLIIH$OLVWDLUYDQ/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)

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

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 .

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Contenidos



G E S S I G r u p d e r e c e r c a e n E n g i n y e r i a d e l S o f t w a r e p e r a l s S I

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Trabajos recientes del grupo Gessi

z Junio 2001, JIRA 01, notacin NoFunz Septiembre 2002, RE02, modelos de calidad,

requisitos para seleccin de COTSz Noviembre 2002, WER02, visin globalz Julio 2004, SCI2004, construccin de taxonomas

basada en metasz Uso del modelo i*

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

D

RT

EasyAdministration RTUPackage RoutedRTA

DNS

Efficient Routing

D

DD

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)

G E S S I G r u p d e r e c e r c a e n E n g i n y e r i a d e l S o f t w a r e p e r a l s S I

Definicin de RequerimientosDefinicin de Requerimientos

Josep M Llovet PrezJosep M Llovet Prezjmllovetjmllovet@@telefonica.nettelefonica.net

Universitat Politcnica de Catalunya

Master de Ingeniera del SoftwareMaster de Ingeniera del Software

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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I BibliografaDefinicin 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

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I 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. JohnWiley & sons. 2000

Enterprise Modelling with UML. Chris Marshall. Addison-Wesley. 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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Referencias y enlaces

Tcnicas, guas y documentacin sobre DR:z Guas y documentacin sobre Definicin 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

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Referencias y enlaces (2)

Estandards:

http://www.ips.id.ethz.ch/~parish/standard.htmlz 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

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Anlisis de riesgos

z Los riesgos deben documentarse en el plan de gestin 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 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 mismosz En ciertos entornos puede ser necesario disear simuladores que

generen 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

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Diagrama de Flujo de Datos (DFD)

Planificacin

Radar

Aeronave

Visualizar detalles

Procesar seales

Visualizarradar

Asesorarsituacin

Seal radar

Datosradar

Datosradar

Detallesvuelo

Detallesvuelo

Plan vuelo

Detallesvuelo

Detallescambio

Peticincambio

Conformidad peticin cambioInstrucciones

cambio

Vuelos Archivo

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I DFD con Flujo de Control

Planificacin

Radar

Aeronave

Visualizar detalles

Procesar seales

Visualizarradar

Asesorarsituacin

Statussector

Seal radar

Datosradar

Datosradar

Detallesvuelo

Detallesvuelo

Plan vuelo

Detallesvuelo

Detallescambio

Peticincambio

Conformidad peticin cambioInstrucciones

cambio

Vuelos Archivo

Salida aeronave

Salida aeronave

Visualizar aeronave

Aproximacin aeronave

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Diagrama de Estados Finitos

AproximacinAeronave

Asesorarsituacin

VisualizarAeronave

Mostrardetalles

Salida aeronave

Esperandoaeronave

Controlandoaeronave

Mostrando detalles

Archivo detalles

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Diagrama Entidad-Relacin

Datostransitorios

Plan deVuelo

Cdigo vuelo

Tipo aeronave

Origen

Destino

Direccin

Hora

Altitud

Localizacin Datos salida

Datos entrada

1

1

1

1

Volver

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Diagrama de Clase

Avin militar Avin comercial

Avin de carga Avin de pasajeros

Motor

Avin

1..4

1

Piloto Vendedor de billetes

Reserva*

1

Vuelo*1

1..2

*

*1

Lnea area1

1

1..4 1..2 1

1 * 1 *

*{ disjunta, completa }

{ disjunta, completa }

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Diagrama de Estados

con prstamos

sin prstamos

alta baja

prestar devolver[ nmero_prstamos = 1 ]

prestar

devolver[ nmero_prstamos > 1 ]

nmero_prstamos = 0

nmero_prstamos > 0

Socio BibliotecaNmero : intNombre : char[50]Nmero prstamos : int = 0

Alta()Baja()Prestar(CdigoLibro : int, Fecha : date)Devolver(CdigoLibro : int, Fecha : date)

Al modelo...

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Diagrama de Actividad

Buscar Bebida

Poner caf en filtro Aadir agua al depsito Coger taza

Poner filtro en mquina

Encender mquina

Caf en preparacin

Servir caf

Coger zumo

Beber

[no hay caf]

[hay caf]

[no hay zumo]

[hay zumo]

^cafetera.On

indicador de fin

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Diagrama de Actividad con bandas

Emitir billete

Pasajero Vendedor Airline

Solicitar pago Reservar plazasConfirmar

plaza reservadaPagar pasaje

Informar alternativas y precios

Verificar existencia vuelo

Dar detalles vuelo

Solicitar pasaje

Seleccionar vuelo

Volver...

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Diagrama de Casos de Uso

Cliente

VendedorVerificar Situacin

SupervisorEstablecer Crdito

SecretariaPreparar Catlogo

Tipos de Venta

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Diagrama de Colaboracin

: Socio

: Encargado

: Libro

: Ficha libro

: Ficha socio

: Prstamo

1: Coger libro

2: Solicitar prstamo

8: Autorizar prstamo

3: Verificar situacin socio

4: Situacin socio ok

5: Verificar situacin libro

6: Situacin libro ok

7: Introducir prstamo

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Diagrama de Secuencia

: Socio : Encargado : Libro : Ficha libro : Ficha socio : Prstamo

Coger libro

Solicitar prstamo

Verificar situacin socio

Situacin socio ok

Verificar situacin libro

Situacin libro ok

Introducir prstamo

Autorizar prstamo

Volver

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Obtencin de los requerimientos

z Fuentes de los requerimientos

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

mbito de aplicacin o dominio de conocimiento delproyecto (permitir resolver conflictos entre actores)

Identificar a todos los actores del proyecto para poderdisear un sistema que recoja el punto de vista y seafcil de usar por todos ellos

Identificar el entorno operacional para poder establecerlas restricciones del proyecto y los costes quecomportarn las mismas

Entorno organizativo: identificacin de los condicionantesque la estructura, la cultura y la poltica interna de laorganizacin puedan imponer o sobre-entender

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I 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 ypreguntarse sobre Qu pasara si ... ? Cmo se hace esto ?

Prototipos: permiten clarificar y precisar requerimientos

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

Observacin de los sistemas actuales y medida de distintos parmetros de losmismos a travs de la inmersin 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, investigacin externa, jornadas profesionales,ferias

Presentaciones comerciales, estudio de productos SW ya existentes

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Entrevistas (1)

z Planificacin

Qu datos desean obtenerse ?

Quin debe ser entrevistado ?

Cundo debe efectuarse la entrevista ?

Dnde debe efectuarse la entrevista ?z Preparacin

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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Entrevistas (2)

z Inicio

Exposicin general de la entrevista, objetivos, y duracinestimada

Explicacin de la utilidad de la entrevista solicitud de apoyo alentrevistado

Se invita y estimula al entrevistado a hablar informalmente

Solicitud informal de autorizacin para tomar notasz Desarrollo

Las preguntas deben apuntar a la obtencin de la informacindeseada

Permitir que el entrevistado siga su lnea de pensamiento yexposicin sin interrupciones

Guiar la conversacin invitando al detalle si es preciso pero conmomentos de sntesis con recapitulaciones

Evitar controversias o crticas y sugerencias precipitadas

Asegurarse de obtener toda la informacin necesaria ycomplementaria

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Entrevistas (3)

z Cierre

Resumen de los puntos anotados

Comprobacin de que se ha suministrado toda la informacinsolicitada

Dejar abierta la posibilidad de entrevistas posteriores

Agradecimiento por la colaboracin

En funcin del caso, brindar la entrega de una copia deldocumento resumen de la entrevista

z 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

Volver

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Anlisis 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 nmero de conflictos parael requerimiento en cuestin

El cociente de dividir una suma entre 1000 nos da el nmero desolapamientos para el requerimiento en cuestin

Esta tcnica es operativa cuando el nmero de requerimientos

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Cuestionario para analizar requerimientos

La descripcin del requerimiento lo es de un nico requerimiento opuede descomponerse en varios requerimientos?

Requerimientosatmicos / combinados

Podr generarse un juego de pruebas para testear si el sistemaincluye el presente requerimiento y es conforme a la especificacin?

Requerimientostesteables

Es realista el requerimiento dada la tecnologa en la que deberimplementarse 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 cosmtico al sistema que no esnecesario?

Requerimientosinnecesarios

Requiere el requerimiento un diseo prematuro o informacin sobresu implementacin?

Diseo prematuro

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Anlisis de requerimientos (3)

001100001R6001001R5110100000R4

100001000001000R3000000R2110100000R1

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 dems

R6 requiere diseo prematuroR3 es combinacin de otros 2 req.R2 requiere tecnologa no standardR3 y R6 no pueden ser testeados

Ejemplos de tablas para detectarconflictos ysolapamientos y para el anlisis derequerimientos

NSNNASR6SSNNANR5SSNNANR4NSNNCNR3SSSNANR2SSNNANR1

Te

steable

Re

alistaT

ecn

ologa n

osta

ndard

Inn

ece

sario

Atm

ico /

Co

mbin

adoD

iseop

rem

aturo

Reque

rimie

nto

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Anlisis de los requerimientos (4)

z Debe delimitar los lmites del sistema y cmo interaccionacon el entorno, manualmente o con otros sistemasinformticos

z Hay que especificar las interfases o intercambios deinformacin 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 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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

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

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

El proceso de definicin de requerimientos con puntos devista

Descubrirrequerimientos

IdentificarPuntos de vista

Elaborar el asunto clave

Identificar el asunto clave

Obtencin de requerimientos

Analizar interaccionesentre puntos de vista

Anlisis derequerimientos

Resolverinconsistencias

Negociacin derequerimientos

Asunto clave,Puntos de vista,Requerimientosexternos,Requerimientos

Versiones de requerimientos,

Cambios de puntos de vista

Integrar y dar formatoDefinicin de

requerimientos

Inconsistencias,Incompletitudes

Asunto clave de los puntos de vista

Ciclo deObtencin,Anlisis,Negociacin

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Puntos de vista (3)z Aportan la visin 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 atencin 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 podrn ser

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

conviene aplicar la tcnica descrita para analizar conflictos entrerequerimientos

z Permiten una trazabilidad ms claraz Es una tcnica complementaria a las otras tcnicas descritas

Volver

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Requerimientos no funcionales

BOEHM 1976

z Portabilidadz Fiabilidadz Eficienciaz Amigabilidadz Verificabilidadz Comprensiblez Modificable

PRESSMAN 1988

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

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I

Posibles mtricas para la especificacin de requerimientosno funcionales

Prdida mxima de datos ante una cada del sistemaIntegridadTiempo para reiniciar el sistema ante una cada del sistemaRobustez

Promedio del nmero de errores cometidos por los usuariosen un perodo determinado

Usabilidad

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

Usabilidad

Tamao mximo del sistema en Kb (kilobytes)Utilizacin dealmacenamiento

Tiempo de respuesta ante un input del usuarioRendimientoNmero de transacciones a ser procesadas por segundoRendimientoProbabilidad de fallo ante una peticinDisponibilidadTasa de ocurrencias de fallosFiabilidadTiempo medio entre fallosFiabilidad

Volver

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Negociacin de los requerimientos

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

Requerimientos incompatibles

Actores que demandan requerimientos incompatibles

Recursos disponibles y requerimientos solicitados

Requerimientos funcionales y restriccionesz Frecuentemente el analista no tiene capacidad para decidir, por lo

que debe favorecer el consenso, y si hay un contrato de prestacinde servicios, debe dejarse traza del por qu de la decisin tomada

z Podra incorporarse como parte de la Validacin de requerimientosz La mejor tcnica es la de las reuniones con los involucrados,

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

z Otras tcnicas son: correo electrnico, boletines electrnicos,bases de datos compartidas tipo Lotus Notes con la documentacinde los requerimientos y sus conflictos. No estn excesivamenteprobadas y su utilidad puede ser dudosa si se genera una actitudde desinters

Volver

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Ejemplo de especificacin de requerimientos

Estatus = 1 si IdentificadorBanco EST EN ListaBancos Y NmeroCuenta COINCIDE CON FormatoCuentas Y FechaExpiracin >= FechaDaActualEstatus = 0 EN CASO CONTRARIO

POST-CONDICIN

La tarjeta ha sido introducida y la banda magntica ledaPRE-CONDICINListaBancos, FormatoCuentas, FechaDaActualPRE-REQUISITOSEstatus(0,1)OUTPUTSMdulo xyz - Gestin cajeroDESTINOIdentificadorBanco, NmeroCuenta, FechaExpiracinINPUTSLos datos son ledos de la banda magnticaORIGEN

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

DESCRIPCINComprobar la validez de la tarjeta en un cajero automticoREQUERIMIENTO

Volver

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Validacin de los requerimientos

z La conduccin de la revisin de los requerimientos

Los mecanismos habituales son las inspecciones y lasrevisiones formales

Se constituir un grupo de revisores con representacin detodos 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 losdistintos actores que trabajarn sobre la base de la check-listo lista de requerimientos. Es deseable la participacin de algnexperto ajeno a la DR, que acte como abogado del diablo

Servirn para completar los documentos DR y SRS ogenerarn una nueva versin

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Cuestionario de validacin de la DR

Es conforme a los estndares definidos el documento DR en su conjunto?Es conforme a los estndares definidos cada uno de los requerimientosindividualmente?

Conformidad astandards

Pueden identificarse unvocamente los requerimientos? Incluyen enlaces alos requerimientos relacionados y a las razones para incluirlos?

Trazabilidad

Est estructurado el documento DR? Estn agrupados los requerimientosrelacionados entre s? Sera ms fcil de entender otra estructura?

Estructuracin

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

Ambigedad

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

Comprensible

Son consistentes los requerimientos? Hay alguna contradiccin entredistintos requerimientos?

Consistencia

Es completo el conjunto de requerimientos? Falta algn requerimiento?Es completo cada uno de los requerimientos? Falta alguna informacin?

Completitud

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Validacin de los requerimientos (2)

l La comisin de validacin 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 cumplimentarn latabla adjunta que se adjuntar ala documentacin de la DR

l En reuniones plenarias revisarnlos requerimientos y resolvernlos problemas que hayan surgido

l Acordarn los cambios ycerrarn la versin o decidirnreiniciar el proceso de anlisis

Req-N

------

Req-3

Req-2

Req-1DR

Co

nform

e a

standa

rds

Tra

zable

Estructu

rado

Am

biguo

Co

mp

ren

sible

Co

nsiste

nte

Co

mpleto

Volver

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Prototipos

z Se usan habitualmente para validar requerimientosz Tambin pueden usarse para la obtencin de nuevos requerimientos si stos

no estn claros o hay malentendidosz Facilitan la identificacin de los errores del analista y del por qu de dichos

erroresz Son una herramienta dinmica para la discusin de la interfase de usuario en

lugar de flip-charts, storyboards o similaresz Corren el riesgo de distraer la atencin en aspectos secundarios como la

esttica 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 validacin, o evolutivosque 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, pginas Web

GE

S

S

I

G

r

u

p

d

e

r

e

c

e

r

c

a

e

n

E

n

g

i

n

y

e

r

i

a

d

e

l

S

o

f

t

w

a

r

e

p

e

r

a

l

s

S

I Prototipos de usar y tirar

CONSTRUCCIN

ANLISIS Y DISEO

DEFINICIN DE REQUERIMIENTOS

IMPLEMENTACIN

VALIDAR PROTOTIPO

CONSTRUIR P

ingreqciii

Documents