Ingeniera de requisitos

La evidencia emprica demuestra que

S Los requisitos contienen demasiados errores S Muchos de estos errores no se detectan al principio S Muchos de estos errores podran ser detectados al principio S No detectar estos errores incrementar los costes S (tiempo, dinero) de forma exponencial S Adems, los programadores obedecen los requisitos S (cuando existen).

PARTE I Introduccin

S Lo ms difcil en la construccin de un sistema software

es decidir precisamente qu construir...

S No existe tarea con mayor capacidad de lesionar al

sistema, cuando se hace mal... Ninguna otra tarea es tan difcil de rectificar a posterioriF. P. Brooks, 1987

Consecuencias

S El sistema resultante no satisfar a los usuarios

S Se producirn desacuerdos entre usuarios y

desarrolladores
S Puede ser imposible demostrar si el software cumple, o

no, los requisitos

S Se gastar tiempo y dinero en construir el

sistemaequivocado

La complejidad

S OJO: No estamos hablando de sistemas de 15 o 30 requisitos.

Tambin hay
S Sistemas de cientos de requisitos S Sistemas de miles de requisitos S Sistemas de 5.000 requisitos S Sistemas de ms de 10.000 S Sistemas de incluso 60.000 (!) requisitos

1995/2001: The Chaos Report

S Gasto anual en EEUU: $250 mil millones en unos

175.000 proyectos.
S 31,1% (23%) son cancelados S 52,7% (49%) cuestan un 190% ms de lo estimado

S Un 16,2% (28%) ser finalizado a tiempo y dentro del

presupuesto, pero el producto final poseer (aprox.) la mitad de los requisitos iniciales

La crisis del software y los requisitos

S

Boehm, 1975: 45% de los errores tienen su orgen en los requisitos y en el diseo preliminar.

S
S S S S S

DeMarco, 1984: 56% de los errores que tienen lugar en un proyecto Sw. Se deben a una mala Especificacin de Requisitos
Chaos Report: Los factores principales que conducen al fracaso en los proyectos Sw. Son Falta de comunicacin con los usuarios Requisitos incompletos Cambios a los requisitos Hoy. Parece que se mejora, pero muy poco a poco.

Coste de los errores

Etapa Requisitos Diseo Codificiacin Pruebas Unitrias Pruebas de sistema Explotacin /mantenimiento Costo A1-2 5 10 20 50 200

Acumulacin de los errores

Qu podemos hacer?

S Tomar conciencia del problema. Estar a la defensiva.

S No conocemos todas las respuestas, pero conocemos muchas

de las preguntas. Tenemos experiencia.

S Podemos minimizar el impacto de los errores en los requisitos

S Podemos tratar de organizar mejor las tareas relacionadas con

los requisitos
S MAS RECURSOS PARA LA FASE DE REQUISITOS !!!

Soluciones definitivas?

S S S S S S

No se ha encontrado solucin universalmente vlida Hay serias dudas acerca de si dicha solucin existe Nos movemos en la frontera socio-tcnica de los sistemas: borrosa, voluble e inconsistente Los requisitos es donde lo formal se encuentra con lo informal (M. Jackson) Los requisitos estan vivos: emergen, interactan, cambian, desaparecen... Desconfiar de quien ofrezca la solucin definitiva a estos problemas !!!

Ingeniera de Requisitos

S Para remediar en lo posible esta situacin, surge la

Ingeniera de Requisitos (IR)

S La IR trata de los principios, mtodos, tcnicas y

herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemtica y repetible.
S La comparacin del Chaos Report de 1995 con 2002

parece indicar que no vamos por el mal camino...

Qu son los requisitos (Jackson & Zave)

S Todo problema sw. consiste en configurar una mquina para

que ejerza unos efectos R en un dominio K. La conexin se realiza a travs de una interfaz S.
S Los efectos R son los requisitos: Necesidades, metas,

objetivos S El conocimiento del dominio K describe el contexto. S La mquina (hw+sw) es la que realizar los requisitos R, gracias a S, que describe la conexin con el dominio K. S En la fase de requisitos tan slo necesitamos K, S y R. No necesitamos describir el comportamiento interno de la mquina Idealmente: K y S => R

Ejemplo K,S y R

S Sistema de control de una caldera de vapor. Ejemplos: S K: el agua entra en ebullicin a 100 Grados Centgrados y a 1 atm. de presin S R: El sistema evitar que el agua entre en ebullicin S S: El sistema leer la temperatura del agua por medio del sensor S342, El sistema podr subir la temperatura del agua por medio del regulador R452

S Propiamente hablando tan slo R son requisitos, pero a la

Ingeniera de Requisitos le interesan tambien K y S, pues todas son necesarias.

S Pero K, S y R no son suficientes...

Otros contenidos relevantes

Informacin acerca del problema a solucionar Propiedades y comportamiento del sistema Restricciones de diseo y fabricacin del producto Descripciones acerca de cmo el futuro sistema ayudar a sus usuarios a realizar mejor sus tareas

Restricciones acerca de la tecnologa que ser utilizada en la construccin del sistema (protocolos, SSOO, COTS, etc.)
Restricciones acerca de las propiedades emergentes del sistema (requisitos no funcionales)
S

Los requisitos NO son anlisis top-down, ni son la arquitectura del sistema, ni son el qu frente al cmo.

Visin comercial de los requisitos.

Cmo escribir requisitos?

S La mejor forma de escribir requisitos no existe

S Lo ms utilizado es el lenguaje natural. Cada requisito

expresado en una frases corta (el sistema har X ..., se facilitar Y..., etc) notaciones formales

S O lenguaje natural complementado con diagramas y/o S La notacin utilizada depende de quien lee o quien

escribe los requisitos.

Ejemplo de lo que podemos encontrar en un documento de requisitos

S 1. El sistema mantendr la temperatura de la caldera entre 70 y 80 S 2. El sistema mantendr un registro de todos los materiales de la S biblioteca, incluyendo libros, peridicos, revistas, videos y CDRoms S 3. El sistema permitir a los usuarios realizar una bsqueda por ttulo,

autor o ISBN
S 4. El interfaz de usuario se implementar sobre un navegador Web S 5. El sistema deber soportar al menos 20 transacciones por segundo S 6. El sistema permitir que los nuevos usuario se familiaricen con su

uso en menos de 15 minutos.

Requisitos en negativo

S Es importante decir lo que el sistema NO debe hacer

S Estos requisitos en negativo limitan el mbito del sistema.

S Dicen donde NO se deben emplear recursos S Fundamental para sistemas crticos

S Se debe mantener la distincin liveness/safety S Liveness: dicen lo que el sistema debe hacer S Safety: dicen lo que el sistema no debe hacer

Reqs. funcionales y no funcionales

S Los requisitos funcionales describen los servicios (funciones)

que se esperan del sistema

S

El sistema aceptar pagos con VISA

S Los requisitos no funcionales son restricciones sobre los

requisitos funcionales
S El sistema aceptar pagos con VISA de forma segura y con un

tiempo de respuesta menor de 5 segundos

S Pero esta distincin, muchas veces, resulta arbitraria. S El sistema aceptar pagos con VISA a travs del protocolo

SET

Tipos de Reqs. No Funcionales

S S S S S S S S S S S

Orientados al usuario: Fiabilidad Seguridad (security) Seguridad (safety) Usabilidad Robustez Disponibilidad Rendimiento Tiempo de respuesta Capacidad (carga) Throughput

S S S S S S S

Orientados al desarrollador: Disponibilidad Portabilidad Adaptabilidad Testabilidad Comprensibilidad Etc,

Relacin RequisitosArquitectura?
S La eleccin de una determinada arquitectura sw. Debe tener

en cuenta los requisitos funcionales pero, sobre todo, los requisitos no funcionales
S No hay una regla definitiva para establecer, dados los

requisitos, el tipo de arquitectura

S Tan slo hay una serie de heursticas para, dados unos

requisitos, elegir la arquitectura.

S En la prctica, es difcil desarrollar uno sin el otro

El proceso de requisitos

El proceso 2

S El proceso de Ingeniera de Requisitos es un conjunto

estructurado de actividades que sirven para derivar, validar y mantener los requisitos de un sistema (hardware, software o hardware+software).

Variaciones en el proceso

S Segn la naturaleza del proyecto S dirigido al mercado S a medida S Segn la naturaleza de la aplicacin S Riesgo S Recursos S Incertidumbre S Sistemas empotrados

Tenemos problemas en el proceso si:

S El proceso de requisitos es excesivamente largo y costoso S Los implicados en el proceso se quejan de falta de tiempo u otros

recursos
S Se reciben quejas acerca de la inteligibilidad del documento de

requisitos
S Los implementadores se quejan del trabajo perdido por culpa de

errores en los requisitos

S Los usuarios no utilizan muchas de las capacidades del sistema
S En cuanto el producto se entrega, se recibe una inmensa cantidad de

solicitudes de cambios
S Lleva demasiado tiempo alcanzar un acuerdo cuando se proponen

Educcin
S La educcin de requisitos se refiere a la captura y

descubrimiento de los requisitos.

S Es una actividad ms humana que tcnica S Se identifica a los interesados (stakeholders) y se

establecen las primeras relaciones entre ellos y el equipo de desarrollo

Fuentes de requisitos

S Los requisitos pueden proceder de:

S Metas: Factores crticos de xito (de la empresa)

S Conocimiento del dominio de la aplicacin S Los interesados. Los afectados por el sistema. S El entorno fsico que rodea al sistema S El entorno organizacional. Los procesos de negocio.

Problemas de la educcin

S Los usuarios no pueden/saben describir muchas de sus

tareas
S Mucha informacin importante no llega a verbalizarse S A veces hay que inventar los requisitos

S sistemas orientados a miles de usuarios: web, mercado

S La educcin no debera ser un proceso pasivo, sino

cooperativo

Hacer preguntas no es suficiente.

S S S S S

S S
S S S S S S

Diseador: para cuando? Cliente: 18 meses Diseador: qu hay que transportar? Cliente: personas Diseador: Cuntas personas a la vez? Cliente: Una Diseador: Qu clase de energa lo mueve? Cliente: El pasajero Diseador: sobre que clase de superficie? Cliente: Una superficie plana y dura Diseador: Cul es la distancia mxima a recorrer? Cliente: Unos 2 km. Diseador: Cul es el coste?

S S S S S S S S

Cliente: Unos 300 pesos cada vez que se use. Etc. Finalmente: se fabrica un triciclo. El cliente (alcalde de Grindelwald) destaca su gran portabilidad (?). Dice: Es muy portable pero cmo se utiliza cuando llegue el momento de rescatar a un alpinista en la cara norte del monte Eiger? LO QUE SE QUERA ERA UN DISPOSITIVO QUE AYUDE A RESCATAR ALPINISTAS !

S S S

Tcnicas de educcin
S

Preliminares: Utilizar preguntas libres de contexto

S
S S

Brainstorming
Creatividad? (herramientas como ideafisher, curio, mindjet, etc.) Entrevistas: Es el mtodo tradicional

S
S S S S

Observacin y anlisis de tareas

Casos de uso / Escenarios: requisitos en contexto de uso Prototipado: tiles cuando la incertidumbre es total acerca del futuro sistema. Hay dos tipos principales: Evolutivo De usar y tirar (prototipos en papel, mago de Oz, etc.)

Tarjetas de recogida de requisitos

Anlisis de Requisitos

S Consiste en detectar y resolver conflictos entre requisitos

S Se precisan los lmites del sistema y la interaccin con su entorno

S Se trasladan los requisitos de usuario a requisitos del software

(implementables).
S Se realizan tres tareas fundamentales: S Clasificacin S Modelizacin

S Negociacin

Clasificacin de los requisitos

S En el anlisis de requisitos, stos se clasifican S En funcionales vs. no funcionales (Capacidades vs. S Restricciones) S Por prioridades S Por coste de implementacin S Por niveles (alto nivel, bajo nivel) S Segn su volatilidad/estabilidad S Si son requisitos sobre el proceso o sobre el producto S En Ingeniera de Sistemas, adems, se realiza la ubicacin de

requisitos (Requirements Allocation)

Modelizacin conceptual

S S S S

Ciertos aspectos de los requisitos se expresan mediante modelos de datos, de control, de estados, de interaccin, de objetos, etc. La meta es entender mejor el problema, ms que iniciar el diseo de la solucin (idealmente) El tipo de modelo elegido depende de
S S S S

La naturaleza del problema La experiencia del modelizador La disponibilidad de herramientas Por decreto. El cliente impone una notacin

Negociacin de requisitos

S En todo proceso de IR intervienen distintos

S individuos con distintos y, a veces, enfrentados intereses

S Estos conflictos entre requisitos se descubren durante el

anlisis. Todo conflicto descubierto debera disparar un proceso de (re)negociacin.

S Los conflictos NUNCA se deben resolver por decreto

El Documento de Requisitos

S S

Es el modo habitual de guardar y comunicar requisitos. Es buena prctica utilizar, al menos, dos documentos, a distinto nivel de detalle
S S

DRU = Documento de Requisitos de Usuario (en ingls, URD) ERS = Especificacin de Requisitos Software (en ingls, SRS)

OJO: Con Documento nos referimos a cualquier medio electrnico de almacenamiento y distribucin:
S S S

Procesador de textos Base de Datos Herramienta de Gestin de Requisitos

Estndares

S IEEE Std. 1362 (ConOps)

S IEEE Std. 830 (SRS)

S PSS-05 de la Agencia Espacial Europea (ESA) S Las herramientas de gestin de requisitos permiten

generar documentacin en los anteriores formatos, a partir de una base de datos de requisitos.

Caractersticas deseables de una ERS

S Una ERS de calidad
S S S S S S
S S S S S

S
S

debera poseer 24! caractersticas: No ambigua Completa Correcta Comprensible Verificable Internamente consistente Externamente consistente Realizable

Concisa Independiente del diseo Trazable Modificable Electrnicamente almacenada S Ejecutable/Interpretable S Anotada por rel. importancia S Anotada por rel. estabilidad

MAS

S
S S S S

Anotada por versin

No redundante A un nivel de detalle adecuado Precisa Reutilizable

S
S S

Trazada
Organizada Con referencias cruzadas

Gestin de Requisitos

S Consiste, bsicamente, en gestionar los cambios a los

requisitos.
S Asegura la consistencia ente los requisitos y el sistema

construido (o en construccin)
S Consume grandes cantidades de tiempo y esfuerzo S Abarca todo el ciclo de vida del producto

Por qu es necesaria?

S Los requisitos son voltiles S El entorno fsico cambia S Trasladar un sistema de un entorno a otro requiere modificaciones S El entorno organizacional cambia S Las polticas cambian S Cambios en las reglas y en los procesos del negocio provocan cambios en el sistema S La propia existencia del sistema va a generar nuevos requisitos

por parte de los usuarios

La Gestin de Requisitos implica

S Definir procedimientos de cambios: definen los pasos y

los anlisis que se realizarn antes de aceptar los cambios propuestos (una Software Change Request (SCR) de la NASA ocupa ms de 500 pginas !!!).
S Cambiar los atributos de los requisitos afectados

S Mantener la trazabilidad: hacia atrs, hacia delante y

entre requisitos (P.ej. Proyectos para la FDA) Control de versiones del documento de requisitos

Herramientas de Gestin de Requisitos

S

Facilitan las tareas relacionadas con la escritura, trazabilidad y gestin de cambios.

S
S S

Organizan los requisitos en bases de datos.

Gestin (incremental) de lineas-base Todas permiten aadir atributos a los requisitos

Ejemplos:
S S S

DOORS (de QSS/Telelogic), RequisitePro (de Rational), IRqA, icConcept, etc.

Eplogo

S Slo habr una verdadera Ingeniera de Requisitos cuando S Todos los posibles sistemas software hayan sido construidos al

menos una vez (fin de las novedades) ... S Los sistemas se instalen en entornos fijos e inamovibles, como sucede con los puentes o los edificios ... S La tecnologa deje de evolucionar ... S Se pueda predecir el futuro con exactitud
S Mientras tanto, tenemos la obligacin de minimizar los daos

causados por una pobre gestin de los requisitos.