Ingeniería De Requerimientos:

Un Acercamiento

Introducción

M.C.C. Luis Islas Hernández

Luisih@uaeh.edu.mx
 ¿Qué es la Ingenieria de requisitos?

Es aquel conjunto de técnicas que ayuda a los ingenieros de software a entender mejor
el problema en el que trabajarán.

¿Cuál es el corazón de la Ingeniería de Requisitos?

Un conjunto de tareas guía.
Roger S. Pressman
¿A que conduce ese conjunto de tareas?

•Cuál será el impacto del software sobre el negocio.

•Qué es lo que el cliente quiere.

•Cómo interactuarán los usuarios finales con el

software.
 ¿Qué es un requisito?

Un requisito puede definirse como un atributo necesario dentro

de un sistema, que puede representar una capacidad, una
característica o un factor de calidad del sistema de tal
manera que le sea útil a los clientes o a los usuarios finales.
 Otras definiciones de Ingenieria de requisitos

La IR trata de los principios, métodos, técnicas y

herramientas que permiten descubrir, documentar y
mantener los requisitos para sistemas basados en
computadora, de forma sistemática y repetible.

Todas las actividades de la ingeniería de

sistemas/software relacionadas con:

• Identificación y documentación de necesidades de clientes y usuarios.

• Creación de un documento que describe la conducta externa y las
restricciones asociadas [de un sistema] que satisfará dichas necesidades.
• Análisis y validación del documento de requisitos para asegurar
consistencia, compleción y viabilidad.
• Evolución de las necesidades.
 ¿Porque es importante?

Programas elegantes resolviendo

Los problemas incorrectos.

Primero hay que entender

Exactamente lo que el cliente
quiere antes de comenzar a diseñar.
 ¿Y cómo se aplica?

Siguiendo una serie de pasos,

tareas o fases.

Comenzando por una fase de inicio

y terminando con la coincidencia
entre la concepción del problema que
tiene el ingeniero de software y la
percepción del cliente.
 Tu peor pesadilla

Ralph Young

Un cliente entra en tu oficina, se sienta,

te mira directo a los ojos y dice:

“Yo sé que usted piensa que entiende lo que

digo pero lo que usted no entiende es que lo que
digo no es realmente lo que quiero decir”
Y el problema es que…

El dinero es quizás lo más importante en el

desarrollo de proyectos informáticos.

El dinero esta en peligro, además no olvidemos que la reputación

esta en juego.
 Otro detalle importante…

¿Se pierde el tiempo con la Ingeniería de requisitos?

¡NO se pierde! Es realmente un punto importante que no debe omitirse.
Tareas de la
ingenieria de
requisitos.

Luis Islas Hernández

Luisih@uaeh.edu.mx
Inicio
Obtención

Elaboració
n
Negociación

Especificación
Validación

Gestion de requisitos
Inicio

Una conversación informal

Necesidad de negocios

Se descubre un nuevo mercado

Inicio

Preguntas libres de contexto

Objetivo principal

Comprensión básica del problema en cuestión

 Obtencion

Preguntar

•Clientes
•Usuarios
•Otros Interesados

•Qué es lo que se debe lograr.

•Forma en que el producto satisface las necesidades

del negocio.

•Como se utilizara dia con dia.

NO es facil hacerlo.

Problemas de ámbito.
•Limite mal definido.
•Detalles tecnicos innecesarios.
Problemas de volatilidad.
•Problemas cambian
•Conforme pasa el tiempo.
Obtencion
Problemas de comprensión.
•Ellos no estan seguros.
•No comprenden al 100% el dominio
del problema.
•Dificultad para comunicar
necesidades.
 Elaboracio
n

• La información se expande y se refina.

• Se enfoca en el desarrollo de un modelo técnico de:

1. Funciones.
2. Caracteristicas.
3. Restricciones.

• Es una acción del modelado de software.

• Creación de escenarios de uso del sistema.

Principalmente se busca establecer una base firme

para el diseño.
 Negociacion

Piden más de lo que se puede lograr.

Proponen requisitos que generan conflictos

•Se habla de la prioridad.

•Riesgos asociados con cada requisito.

•Impacto de cada requisito en el costo.

•Impacto en el tiempo de entrega.

 Negociacion

Y al final...

•Algunos requisitos se eliminan.

•Algunos requisitos se modifican.

•Algunos requisitos de combinan.

Ambas partes contentas

Especificacion

Una especificación podria ser…

•Un documento escrito.

•Un conjunto de modelos gráficos.
•Un modelo matemático formal.
•Una colección de escenarios de uso.
•Un prototipo.
•Una combinacion de todos los anteriores.
 Especificacion

Proyectos grandes

Un documento escrito combinando:

•Lenguaje natural
•Modelos gráficos.

Proyectos pequeños
•Escenarios de uso… siempre y
cuando residan en ambientes
tecnicos que se comprendan bien.
•Es el producto final de la
ingenieria de requisitos.
•Sirve como base para las
siguientes actividades.
 Validacion

•Se evalua la calidad.

•Sirve para asegurar que todos los requisitos

se establezcan de manera precisa.

Mecanismo primario
Revisión tecnica formal.
Examinan la especificación
•Se buscan errores.
•Areas que requieran clarificación.
•Información faltante.
•Inconsistencias.
•Conflictos entre requisitos.
 Validacion
Listas de verificación

Examinamos cada requisito frente a una serie de

preguntas.

¿Los requisitos estan establecidos de manera clara?

¿Pueden malinterpretarse?
¿Cuales otros requisitos estan relacionados con este?

Buen metodo que se puede aplicar a muchas areas no

Solo a ingenieria de requisitos.
 Gestion de requisitos

“El deseo de cambios persiste durante la vida del sistema”.

Conjunto de actividades que ayudan al equipo de proyecto a
identificar, controlar y rastrear los requisitos y los cambios a estos en
cualquier momento mientras se desarrolla el proyecto.

Identificación Tablas de rastreabilidad

Se comienza Se comienza
identificando cada identificando cada
requerimiento. requerimiento.
 Gestion de requisitos

Tablas de rastreabilidad
 Gestion de requisitos

Tablas de rastreabilidad

•De las caracteristicas.

Relacion requisitos/caracteristicas observables.
•De la fuente.
Indica la fuente de cada requisito.
•De dependencia.
Relacion entre si de los requisitos.
•Del subsistema.
Categorias de requisitos.
•De la interfaz.
Relaciones con las interfases internas y externas.
 Elementos del modelo de Analisis.

Basados en escenarios

Basados en Clases

Elementos

De comportamiento

Orientados al flujo
 Elementos orientados al flujo.

Entradas

Procesos

Salida

En efecto es posible crear un modelo de fluyo para cualquier sistema

basado en computadoras, sin importar su tamaño o complejidad.
Negociación de
requisitos.
¿Qué es la negociación de requisitos?

Definiéndola, la negociación de requisitos es una función de

la ingeniería de requisitos en la cual se llega a “negociar” con
el cliente los requisitos que van a
satisfacerse con el sistema, de modo

que ambas partes salgan ganando, es

decir, que obtengan lo que merecen.
Objetivos de la negociación de requisitos

Hay determinadas cosas que se persiguen al negociar los requisitos, y

son las siguientes:
•Satisfacer a ambas partes (cliente y equipo de desarrollo).
•Determinar requerimientos que puedan cumplirse (realistas).
•Satisfacer los intereses de la otra parte (cliente en nuestro caso).
•Realizar propuestas de posibles requerimientos necesarios pero que no
habían sido detectados.
•Establecer requerimientos que se encuentren dentro
del rango limitado por las restricciones del
proyecto tales como recursos, personal, tiempo.
 Negociar es llegar a un acuerdo

“Un acuerdo es el arte de dividir un pastel de tal forma que cada

Uno piense que se quedó con la rebanada más grande.”
Ludwig Erhard

Porqué? Porque cuando se llega a un acuerdo, quiere decir que todos los
que participamos del acuerdo estamos satisfechos con lo que hemos
obtenido de él.
 ¿Porqué hay que negociar los requisitos?

Es de vital importancia negociar los requisitos con el cliente en vez de

tener una simple charla de lo que ellos quieren porque de esa forma se
evitan cosas como:
•No hacer todo lo que el cliente requiere por incapacidad de hacerlo.
•Quedar mal con el cliente.
•Hacer las cosas pero utilizar más recursos de los disponibles y emplear
mas tiempo del estipulado.
Actividades de la negociación de requisitos

Bohem ha establecido que hay 3 actividades que componen la

negociación de requisitos, y el cumplimiento de estas actividades
asegurará un acuerdo exitoso en el que todas las partes salgan ganando.
Dichas actividades son:
•Identificación de l@s interesad@s clave en el sistema o subsistema.
•Determinación de las condiciones ganadoras (requisitos) de los
interesados.
•Negociación de dichas conexiones para reconciliarlas
(establecerlas) en un conjunto de requerimientos
del tipo ganar-ganar.
Validacion de
requisitos.
 ¿Porqué validar los requisitos?

Cuando estamos haciendo funciones como determinar, formular, negociar

requisitos es necesario examinarlos detalladamente para conocer su
consistencia, omisiones y ambigüedades (es decir,
interpretado de varias formas, lo que da
lugar a dudas).
Estos requisitos son jerarquizados debido
a que son puestos en paquetes de
requisitos que son implementados
como incrementos de software
(prototipos) que son entregados al
cliente (Esto en caso de trabajar con
un modelo de desarrollo de software
que en donde se entregan prototipos
regularmente durante el ciclo de vida
del software).
 Preguntas clave en la revisión de los
requisitos.

¿El requisito es necesario en realidad o es una característica agregada

irrelevantemente para el objetivo del sistema?
¿Cada requisito es alcanzable en el ambiente técnico
que recibirá al sistema o producto?
¿El modelo de requisitos refleja de manera adecuada
la información, la función y el comportamiento?
¿Cada requisito está limitado y no es ambiguo?
¿Algunos requisitos entran en conflicto con otros?
Extras.
Muy importante: ¿Es lo mismo?

Ingeniería de Requisitos

¿Son iguales?

Análisis de Requisitos
 Ingeniería de Requisitos

Es aquel conjunto de técnicas que ayuda a

los ingenieros de software a entender mejor
el problema en el que trabajarán.

Análisis de Requisitos

Es aquel que genera la especificación de características operacionales de software

; Indica la interfaz del software con otros elementos del sistema, y establece las
restricciones que debe tener el software.

El Ing. de Software se extiende sobre requisitos básicos establecidos en la Inge-

nieria de requisitos.
 Caso de la vida real 1.

Consecuencias de no aplicar la Ingeniería de requisitos adecuadamente.

•Cliente con poco tiempo.

•Cliente mentiroso.
•Desarrolladores cómodos.
•Mala relación con el cliente.

El cliente ha amenazado con acciones legales.

El proyecto ha cambiado mucho.
El cliente se tomo las cosas personales.
El proyecto se ha vuelto un desafió.
 Caso de la vida real 2.

Consecuencias de no aplicar la Ingeniería de requisitos adecuadamente.

•Cliente abusador.
•Cliente paranoico.
•Desarrolladores temperamentales.
•Mala relación con el cliente.

El cliente no nos dejo respirar.

Recibía de 7 a 15 emails diarios y de 5 a 6 llamadas
diarias.
El cliente cambio de parecer muchas veces.
El cliente llamaba a las 10/11 de la noche al celular.
Preguntas y
respuestas