INGENIERIA DE REQUISITOS

Qu es ?
La

IR trata de los principios, mtodos, tcnicas y herramientas que permiten descubrir, documentar y mantener los requisitos, de forma sistemtica y repetible. Ayuda a los ingenieros de software a entender mejor el problema en cuya solucin trabajarn. Por qu es importante? Se debe entender lo que el cliente quiere antes de comenzar a disear y construir un sistema. Toma en cuenta errores, coste y tiempo. Servicios que el sistema debe proporcionar junto a las restricciones en la operacin del sistema

Propsito

El objetivo del proceso de la ingeniera de requisitos es

darle a todas las partes una explicacin escrita del problema.

Es esencial que se haga un esfuerzo real por entender los

requisitos de un problema antes de intentar resolverlo.

Requisitos Funcionales y No Funcionales

Funcionales Describen los servicios que se esperan del sistema. No funcionales Restricciones sobre los requisitos funcionales Existen dos tipos:
ORIENTADOS AL USUARIO Fiabilidad Seguridad Usabilidad Robustez Rendimiento, etc ORIENTADOS AL DESARROLLADOR Disponibilidad Portabilidad Adaptabilidad Testabilidad Comprensibilidad

Tareas de la IR
Proporciona el mecanismo adecuado para entender lo que

el cliente quiere.
Fases de la IR:

Actividades de la IR

Inicio
Se inicia muchas veces por:
Identifica nueva necesidad de negocios.

Se descubre un nuevo mercado.

Se descubre un nuevo servicio.

Inicio del Proceso de la IR

Identificacin de los interesados.
Todos aquellos que se benefician en una forma directa o

indirecta del sistema.

Reconocimiento de mltiples puntos de vista.
Categorizar la informacin de los interesados de manera que

permita elegir un conjunto de requisitos para el sistema que sean consistentes de manera interna.
Trabajo con respecto a la colaboracin.
Identificar reas en comn y reas inconsistentes.

Formulacin de las primeras preguntas

Las preguntas deben ser libres de contexto. Quin usar la solucin?

Cul ser el beneficio econmico de una solucin exitosa?

Obtencin
La obtencin de informacin no es tan fcil como parece. Los ingenieros deben realizar en forma organizada la actividad de recopilacin de requisitos.
DE MBITO DE COMPRENSIN DE VOLATILIDAD

Limite del sistema mal definido

El cliente no est seguro 100% de que es lo que necesita

Los problemas cambian con el tiempo.

Detalles tcnicos innecesarios, etc.

Tienen dificultades para comunicar sus necesidades, etc.

Obtencin de los Requisitos

Recopilacin conjunta de requisitos La meta es identificar el problema, proponer elementos

de solucin, negociar diferentes enfoques y especificar un conjunto de requisitos preliminares.

Elaboracin
Objetivo: Desarrollar modelo tcnico refinado de las

funciones, caractersticas y restricciones del software.

Se conduce mediante la creacin y refinamiento de

escenarios.
El resultado final es un modelo de anlisis que define:

El dominio de la informacin.
Funciones. Comportamiento del problema.

Negociacin
Clientes, usuarios y otros interesados deben ordenar sus

requisitos y luego discutir los conflictos relacionados con la prioridad.

Hacer estimaciones preliminares del esfuerzo requerido

para su desarrollo.
Mediante un enfoque iterativo los requisitos se elimina,

combinan o modifican.

Negociacin de Requisitos
El objetivo es desarrollar un plan proyecto que satisfaga

las necesidades del cliente.

DIRECTRICES A CONSIDERAR Reconocer que no es una competencia Decidir que es lo que se deseara lograr No se debe pensar en formular una respuesta mientras la otra parte est hablando Enfocarse en los intereses de la otra parte No dejar que se vuelva personal Negociacin de las condiciones Ganadoras para unirlas en un conjunto de condiciones del tipo ganar - ganar para todos los involucrados.

ACTIVIDADES A CONSIDERAR
Identificacin de los interesados clave en el sistema o subsistema.

Determinacin de las condiciones 'ganadoras ' de los interesados.

Ser creativo
Estar listo para pactar.

Especificacin
Puede ser:
Documento escrito Conjunto de modelos grficos Modelo matemtico formal Escenarios de uso Prototipo Una combinacin de estos.

Se recomienda que:
SISTEMAS GRANDES Documentos escritos SISTEMAS PEQUEOS Escenarios de uso

La especificacin es el trabajo final que genera la IR.

Validacin
Examina la especificacin para asegurar que los requisitos

de software se han establecido de manera precisa.

ALGUNAS PREGUNTAS RECOMENDADAS PARA VALIDAR La fuente del requisito est identificado? Cules otros requisitos estn relacionados con ste?

El requisito viola alguna restriccin del dominio del sistema?

El requisito se puede probar? Se pueden especificar las pruebas?, etc.

Validacin de Requisitos
Los modelos de anlisis se examinan para conocer que

consistencia, omisiones o ambigedades portan.

Cada requisito y modelo de anlisis se validan como un

todo contrastndolos con las necesidades del cliente para asegurar que se construir el sistema correcto.
ASPCTOS DE LA VALIDACIN
Validez Consistencia Completitud Realismo

Gestin
Es el conjunto de actividades que ayuda al equipo del

proyecto a identificar, controlar, rastrear los requisitos como tambin los cambios a stos en el desarrollo del proyecto. La gestin formal se inicia solo para proyectos grandes Para esto se desarrollan las siguientes tablas:
TABLAS De rastreabilidad de las caractersticas.

De rastreabilidad de la fuente. De rastreabilidad del subsistema. De rastreabilidad de la interfaz.

Despliegue de la funcin de Calidad

Es una tcnica que traduce las necesidades del cliente en

requisitos tcnicos para el software. QFD define los requisitos para maximizar la satisfaccin del cliente. QFD identifica 3 tipos de requisitos.

NORMALES Objetivos y metas Establecidos para un sistema durante Las reuniones con el cliente.

ESPERADOS Estn implcitos en el producto o sistema.

ESTIMULANTES Caractersticas que van ms all de las expectativas del cliente.

Despliegue de la funcin de Calidad

Se aplica para determinar el valor de cada funcin que se

requiere para el sistema.

El despliegue de la informacin identifica los datos de los

objetos y eventos que debe consumir y producir el sistema.

El despliegue de tareas examina el comportamiento del

sistema o producto dentro del contexto de su entorno.

Despliegue de la funcin de Calidad

Escenarios del usuario. Proporcionan una descripcin de cmo se usar el

sistema.
Productos de trabajo de obtencin. Los productos producidos como consecuencia de la

obtencin de requisitos variar de acuerdo con el tamao del sistema a construir.

Desarrollo de Casos de Uso

Un caso de uso muestra el software o sistema desde el

punto de vista del usuario final. Los actores son las diferentes personas que utilizan el sistema dentro del contexto de la funcin y el comportamiento que se describir. Un actor es algn elemento que se comunica con el sistema y que es externo al sistema.
PRIMARIOS
Interactan para lograr la funcin requerida del sistema

SECUNDARIOS

Dan soporte al sistema.

Caso de Uso

Modelo de Anlisis
El objetivo del modelo de anlisis radica en describir

requeridos de comportamiento computadoras.

informacin, funcionamiento para un sistema basado

y en

Es una representacin de los requisitos en un momento

determinado.
Los elementos del modelo los determina el mtodo de

modelado que se utilice.

Elementos del Modelo de Anlisis

Elementos basados en escenarios Sirven como una entrada para la creacin de otros

elementos de modelado. Elementos basados en clases. Conjuntos de objetos que se manipula mientras un actor interacta con el sistema.

Modelo de Anlisis
Elementos de comportamiento. El comportamiento de un sistema puede tener efecto

sobre el diseo que se elija. Un estado es cualquier forma de comportamiento observable. Las variables de estado indican la manera en que el estado se manifiesta.

Modelo de Anlisis

Elementos orientados al flujo.

La informacin se transforma mientras fluye a travs de

un sistema. Es posible crear un modelo de flujo para un sistema sin que importe su complejidad.

Patrones de Anlisis
Representan algo dentro del dominio de aplicacin que

puede reutilizarse al modelar muchas aplicaciones.

Se pueden encontrar en casi cualquier actividad de la vida

diaria.
PLANTILLA Nombre del patrn Intencin Motivacin Fuerzas y contexto Solucin Consecuencias Diseo Usos conocidos Patrones relacionados

Referencias
Ingeniera de software: un enfoque prctico Roger

Pressman, VI edicin, McGrawHill.

www.gris.det.uvigo.es/~jose/doctorado/re/ www.lsi.us.es/docs/informes/LSI-2002-4.pdf