INGENIERIA DE

REQUISITOS
 Qué es ?
 La IR trata de los principios, métodos, técnicas y
herramientas que permiten descubrir, documentar y
mantener los requisitos, de forma sistemática y repetible.
 Ayuda a los ingenieros de software a entender mejor el
problema en cuya solución trabajarán.
 ¿Por qué es importante? Se debe entender lo que el
cliente quiere antes de comenzar a diseñar y construir un
sistema.
 Toma en cuenta errores, coste y tiempo.
 Servicios que el sistema debe proporcionar junto a las
restricciones en la operación del sistema
 Propósito

 El objetivo del proceso de la ingeniería de requisitos es

darle a todas las partes una explicación 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 ORIENTADOS AL DESARROLLADOR

Fiabilidad Disponibilidad

Seguridad Portabilidad

Usabilidad Adaptabilidad

Robustez Testabilidad

Rendimiento, etc 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
 Identificación de los interesados.
 Todos aquellos que se benefician en una forma directa o
indirecta del sistema.
 Reconocimiento de múltiples puntos de vista.
 Categorizar la información 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 colaboración.
 Identificar áreas en común y áreas inconsistentes.
 Formulación de las primeras preguntas
Las preguntas deben ser „libres de contexto‟.
 ¿Quién usará la solución?
 ¿Cuál será el beneficio económico de una solución exitosa?
 Obtención

La obtención de información no es tan fácil como parece.

Los ingenieros deben realizar en forma organizada la
actividad de recopilación de requisitos.

DE ÁMBITO DE COMPRENSIÓN DE VOLATILIDAD

Limite del sistema El cliente no está seguro 100% Los problemas cambian
mal definido de que es lo que necesita con el tiempo.

Detalles técnicos Tienen dificultades para comunicar

innecesarios, etc. sus necesidades, etc.
 Obtención de los Requisitos

 Recopilación conjunta de requisitos

 La meta es identificar el problema, proponer elementos

de solución, negociar diferentes enfoques y especificar
un conjunto de requisitos preliminares.
 Elaboración
 Objetivo: Desarrollar modelo técnico refinado de las
funciones, características y restricciones del software.

 Se conduce mediante la creación y refinamiento de

escenarios.

 El resultado final es un modelo de análisis que define:

 El dominio de la información.
 Funciones.
 Comportamiento del problema.
 Negociación

 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.
 Negociación de Requisitos
 El objetivo es desarrollar un plan proyecto que satisfaga
las necesidades del cliente.
DIRECTRICES A CONSIDERAR
Reconocer que no es una competencia
ACTIVIDADES A CONSIDERAR
Decidir que es lo que se desearía lograr
Identificación de los interesados clave
en el sistema o subsistema. No se debe pensar en formular una
respuesta mientras la otra parte

Determinación de las condiciones Enfocarse en los intereses de la otra parte

'ganadoras ' de los interesados.
No dejar que se vuelva personal
Negociación de las condiciones
Ganadoras para unirlas en un Ser creativo
conjunto de condiciones
del tipo ganar - ganar para todos
Estar listo para pactar.
los involucrados.
 Especificación
 Puede ser:

Documento escrito
Conjunto de modelos gráficos
Modelo matemático formal
Escenarios de uso
Prototipo
Una combinación de estos.

 Se recomienda que:
SISTEMAS GRANDES SISTEMAS PEQUEÑOS
Documentos escritos Escenarios de uso

 La especificación es el trabajo final que genera la IR.

 Validación
 Examina la especificación para asegurar que los requisitos
de software se han establecido de manera precisa.

ALGUNAS PREGUNTAS RECOMENDADAS PARA VALIDAR

¿La fuente del requisito está identificado?

¿Cuáles otros requisitos están relacionados con éste?
¿El requisito viola alguna restricción del dominio del sistema?

requisito se puede probar? ¿Se pueden especificar las pruebas?, et

 Validación de Requisitos
 Los modelos de análisis se examinan para conocer que
consistencia, omisiones o ambigüedades portan.

 Cada requisito y modelo de análisis se validan como un

todo contrastándolos con las necesidades del cliente para
asegurar que se construirá el sistema correcto.

ASPÉCTOS DE LA VALIDACIÓN
Validez
Consistencia
Completitud
Realismo
 Gestión
 Es el conjunto de actividades que ayuda al equipo del
proyecto a identificar, controlar, rastrear los requisitos
como también los cambios a éstos en el desarrollo del
proyecto.
 La gestión formal se inicia solo para proyectos grandes
 Para esto se desarrollan las siguientes tablas:
TABLAS

De rastreabilidad de las características.

De rastreabilidad de la fuente.
De rastreabilidad del subsistema.
De rastreabilidad de la interfaz.
 Despliegue de la función de Calidad
 Es una técnica que traduce las necesidades del cliente en
requisitos técnicos para el software.
 QFD define los requisitos para maximizar la satisfacción
del cliente.
 QFD identifica 3 tipos de requisitos.

NORMALES ESPERADOS ESTIMULANTES

Objetivos y metas
Características que van
Establecidos para un Están implícitos
más allá de las
sistema durante Las en el producto
expectativas
reuniones con el o sistema.
del cliente.
cliente.
 Despliegue de la función de Calidad

 Se aplica para determinar el valor de cada función que se

requiere para el sistema.

 El despliegue de la información 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 función de Calidad

 Escenarios del usuario.

 Proporcionan una descripción de cómo se usará el
sistema.

 Productos de trabajo de obtención.

 Los productos producidos como consecuencia de la
obtención de requisitos variará de acuerdo con el
tamaño 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 función y el
comportamiento que se describirá.
 Un actor es algún elemento que se comunica con el
sistema y que es externo al sistema.

PRIMARIOS SECUNDARIOS
Interactúan para lograr
la función requerida Dan soporte al sistema.
del sistema
Caso de Uso
 Modelo de Análisis

 El objetivo del modelo de análisis radica en describir

requeridos de información, funcionamiento y
comportamiento para un sistema basado en
computadoras.

 Es una representación de los requisitos en un momento

determinado.

 Los elementos del modelo los determina el método de

modelado que se utilice.
 Elementos del Modelo de Análisis
 Elementos basados en escenarios
 Sirven como una entrada para la creación de otros
elementos de modelado.
 Elementos basados en clases.
 Conjuntos de objetos que se manipula mientras un actor
interactúa con el sistema.
 Modelo de Análisis
 Elementos de comportamiento.
 El comportamiento de un sistema puede tener efecto
sobre el diseño 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 Análisis

 Elementos orientados al flujo.

 La información se transforma mientras fluye a través de

un sistema.
 Es posible crear un modelo de flujo para un sistema sin
que importe su complejidad.
 Patrones de Análisis
 Representan algo dentro del dominio de aplicación que
puede reutilizarse al modelar muchas aplicaciones.

 Se pueden encontrar en casi cualquier actividad de la vida

diaria.
PLANTILLA
Nombre del patrón
Intención
Motivación
Fuerzas y contexto
Solución
Consecuencias
Diseño
Usos conocidos
Patrones relacionados
 Referencias
 “Ingeniería
de software: un enfoque práctico” Roger
Pressman, VI edición, McGrawHill.

 www.gris.det.uvigo.es/~jose/doctorado/re/

 www.lsi.us.es/docs/informes/LSI-2002-4.pdf