Ingeniera de Requisitos

Qu es?
Ayuda a los Ingenieros de Software a
entender mejor el problema en que
trabajarn
Es un conjunto de tareas que llevan a

comprender:
Cul ser el impacto del software sobre el
negocio
Qu es lo que el cliente quiere y

Cmo interactuarn los usuarios finales con el

software
Ingeniera de Requisitos
Por qu es importante?

Porque un programa elegante que

resuelve un problema incorrecto no
satisface las necesidades de nadie.

Por lo tanto hay que entender lo que

el cliente quiere antes de disear y
construir el sistema
 Quines lo hacen?
Ingenieros de sistemas
Analistas
Usuarios (gerentes, clientes, usuarios
finales)

Cmo?
Todos los pasos deben
Adaptarse a las necesidades del proyecto

Definir lo que el cliente quiere

Establecer una base slida para el diseo y

construccin
Algunos pasos ocurren en paralelo
 Pasos
Inicio Define el mbito y la naturaleza del
problema
Los clientes definen necesidades
Obtencin

Se refina y modifican los requisitos

bsicos
Elaboracin
Se definen prioridades, aspectos
esenciales y
Negociacin en qu momentos se requieren

Se detalla el problema
Especificacin

Se valida y verifica que lo que especifica
el
Validacin analista coincide con la percepcin del
cliente

Gestin Identifica, controla y rastrea los
requerimientos y los cambios
Cul es el producto obtenido?

El objetivo del proceso de la IR es darle

a todas las partes una explicacin
escrita del problema.
Por ejemplo:
Escenarios de uso
Lista de funciones y caractersticas
Modelo de anlisis
La parte ms difcil de construir un sistema de software es
decidir qu construir. Ninguna parte del trabajo estropea
tanto el sistema resultante si se hace mal. Ninguna parte es
ms difcil de rectificar despus
Fred Brooks
 Ingeniera de Requisitos

La IR establece una base slida

para el Diseo y la Construccin.
La IR proporciona un mecanismo
apropiado para:
Entender lo que el cliente quiere
Analizar las necesidades
Evaluar la factibilidad
Negociar una solucin razonable
Especificar la solucin sin
ambigedades
Validar la especificacin
Administrar los requisitos
 INICIO
Cmo se inicia un proyecto de
software?
Conversacin informal

Cuando se identifica una necesidad de

negocios o se descubre un nuevo

mercado o servicio potencial.
Las preguntas y respuesta
bsicas establecen el mbito del
problema y la percepcin global
de una solucin
 INICIO (Cont.)
Formulacin de las primeras preguntas
Libres de contexto
Ejemplos:
Quin usar la solucin?
Cul ser el beneficio econmico?

Estas preguntas se enfocan en el cliente y

otros interesados, metas generales y en los
beneficios

Ayudan a identificar a todos los

participantes
 INICIO (Cont.)
Segunda serie de preguntas
Permiten una mejor comprensin del problema
y se deja que el cliente exprese sus
percepciones acerca de una solucin
Ejemplo
Podra usted describir o mostrar el ambiente de
negocios en el que se utilizar la solucin?
Serie final de preguntas
Las metapreguntas
Se enfocan en la efectividad de la actividad de
comunicacin en si misma.
Ejemplo
Debera preguntarle otra cosa?
Alguien ms me puede dar informacin adicional?
 OBTENCIN DE REQUISITOS
Dificultades en la obtencin
de requisitos
Problemas de mbito
Lmite del sist. mal definido
Especificacin de detalles tcnicos
innecesarios que confunden los objetivos
generales del sistema
Problemas de comprensin
Omisin de informacin que parece obvia
Especificacin de requisitos ambiguos o
inestables
Problemas de volatibilidad
Los problemas cambian con el tiempo
 OBTENCIN DE REQUISITOS
(Cont.)
Recopilacin conjunta de
requisitos
Apunta a lograr un acuerdo entre los
participantes

Un equipo de participantes y desarrolladores

trabajan juntos para:
identificar el problema,
proponer elementos de solucin,
negociar diferentes enfoques y
especificar un conjunto preliminar de requisitos
 OBTENCIN DE REQUISITOS
(Cont.)
Despliegue de la Funcin de
Calidad
Traduce las necesidades del cliente en
requisitos tcnicos para el sistema
Requisitos Normales
Ejemplo: tipos de grficos en pantalla
Requisitos Esperados
Ejemplo: interaccin hombre/mquina amigable
Requisitos Estimulantes
 OBTENCIN DE REQUISITOS
(Cont.)
Escenarios del usuario
Son Casos de Uso que describen cmo se usar el
sistema.

Un Caso de Uso cuenta una historia de la manera

en que un usuario final (el que desempea uno de
varios papeles posibles) interacta con el sistema en
un conjunto especfico de circunstancias.
La historia puede ser un texto narrativo, una
representacin por medio de diagramas, etc.
Un caso de uso muestra el sistema desde el punto
de vista del usuario final.
OBTENCIN DE REQUISITOS
(Cont.)
Producto de trabajo de la
obtencin
Qu informacin genera la
recopilacin de requisitos?
Un enunciado de necesidad y factibilidad
Un enunciado limitado del mbito del sistema
Un listado de los participantes (clientes, usuarios y
otros participantes)
Una descripcin del ambiente tcnico del sistema
Una lista de requisitos (organizados por funcin) y
las restricciones del dominio aplicables a cada una.
Un conjunto de escenarios de uso
Prototipos desarrollados para definir de mejor forma
los requisitos.
 ELABORACIN

Etapa donde se refina la informacin obtenida en

las etapas anteriores (Inicio y Obtencin).
Se enfoca en el desarrollo de un modelo tcnico
refinado de las funciones, caractersticas y
restricciones de SW.
Crea y refina escenarios que describen la forma
en que el usuario final (y otros actores)
interactan con el sistema.
Se definen clases, atributos y servicios; y las
relaciones entre ellas.
 ELABORACIN

Resultado final de la
ELABORACIN

Modelo de anlisis que define

el dominio de la informacin,
las funciones y
El comportamiento del problema.
 DESARROLLO DE CASO DE USO

Definicin: muestra el sistema desde el punto de un

actor (papel que los usuarios o dispositivos representan
cuando interactan con el sistema)

Desarrollo:
Definir conjunto de actores (primarios-
secundarios)
Realizar preguntas para desarrollar casos
de uso
Presentar los aspectos formalmente
(descripcin de la interaccin entre el actor y el sistema)
 CONSTRUCCIN DEL MODELO DE
ANLISIS
Definicin: representacin de los requisitos en un momento
determinado.
Caractersticas
Para describir los dominios de informacin, funcionamiento y
comportamiento.
Es evolutivo elementos estables/inestables
Componentes generales
Elementos del Modelo de anlisis (basado en escenarios)
Elementos basados en clases (objetos clase)
Elementos de comportamiento (diagrama de estado)
Elementos orientados al flujo (diagrama de flujo de datos)
 PATRONES DE ANALISIS

Definicin
Representacin de algo (una clase, funcin o comportamiento)
dentro del dominio de aplicacin que puede reutilizarse al
modelar muchas aplicaciones.
Se integran al modelo mediante una referencia al nombre del
patrn.
Beneficios
Aceleran el desarrollo de modelos
Facilitan la transformacin del Modelo de Anlisis a un
modelo de diseo al sugerir patrones de diseo y
soluciones confiables para problemas comunes.
Plantilla (muestra la informacin de un P. A.)
 NEGOCIACIN
La negociacin se lleva a cabo entre el cliente y el
desarrollador.
El cliente debe realizar un balance de la funcionalidad, el
rendimiento y otras caractersticas del sistema frente al
costo y el tiempo de colocacin en el mercado.
Objetivos: desarrollar un plan de proyecto que satisfaga las necesidades del
cliente al mismo tiempo que refleja las restricciones del mundo real a las que esta
sometido el equipo de sistema.
Las mejores negociaciones son aquellas cuyos resultados son
del tipo ganar-ganar.
Actividades de negociacin
Identificacin de los interesados
Determinacin de las condiciones ganadoras de los interesados
Negociacin de las condiciones ganadoras para conciliarlas en un conjunto del
tipo ganar-ganar.
 NEGOCIACIN

Directrices valiosas
1. Reconocer que no es una competencia
2. Disear una estrategia

3. Escuchar de manera activa

4. Enfocarse en los intereses de la otra

persona
5. No dejar que se vuelva personal

6. Ser creativo

7. Estar listo para negociar

 VALIDACION
Definicin: revisin de cada elemento del modelo para
conocer su consistencia, omisiones y ambigedades.
Enfoque:
Cada requisito. es consistente con el objetivo del sistema?
Todos los requisitos fueron especificados con la abstraccin
suficiente?
Algunos requisitos dan un grado de detalle tcnico
inapropiado en esta etapa?
El requisito es relevante o es una caracterstica agradable?
Hay requisitos que estn en conflicto con otros?
Cada requisito est limitado y no es ambiguo?
Cada requisito es alcanzable dentro del mbito tcnico que
tendr el sistema?
Cada requisito se puede probar una vez que este haya sido
implementado?
El modelo refleja la informacin, funcin y comportamiento
que tendr el sistema?
Se han utilizado P. A. para simplificar el modelado de
requisito?
 En resumen, aspectos
importantes:
Es necesario entender los requisitos del cliente
antes de emprender cualquier diseo.
Se lleva a cabo una actividad dentro de la Ing. de
SW que es la Ingeniera de Requisitos
Consta de 7 tareas/funciones: Inicio, Obtencin,
Elaboracin, Negociacin, Especificacin,
Validacin y Gestin.
Durante este proceso se debe lograr:
Identificar requisitos
Obtener un modelo de anlisis
Plan de proyecto
Base slida y vlida para el diseo