Procesos de Ingeniería de

Requerimientos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 1

 Objetivos
 Describir las principales relaciones de la
ingeniería de requerimientos
 Introducir a las técnicas de obtención y
análisis de requerimientos
 Describir la validación de requerimientos y la
función de la revisión de requerimientos
 Discutir la función de la gestión de
requerimientos en apoyo de otros procesos
de la ingeniería de requerimientos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 2

 Tópicos Expuestos
 Estudios de viabilidad
 Obtención y análisis de requerimientos
 Validación de requerimientos
 Gestión de requerimientos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 3

 Procesos de la ingeniería de
requerimientos

 Los procesos utilizados para la ingeniería de

requerimientos varían ampliamente
dependiendo en el dominio de la aplicación,
las personas implicadas y la organización
que desarrolla los requerimientos.
 Sin embargo, hay una serie de actividades
genéricas comunes a todos los procesos
• Obtención de requerimientos;
• Análisis de requerimientos;
• Validación de requerimientos;
• Gestión de requerimientos.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 4

 El proceso de ingeniería de
requerimientos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 5

 Ingeniería de requerimientos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 6

 Estudios de viabilidad
 Un estudio de viabilidad decide si el sistema
propuesto es meritorio o no.
 Es un estudio breve orientado a resolver
varias cuestiones
• Si el sistema contribuye a los objetivos
organizacionales;
• Si el sistema puede ser diseñado utilizando la
tecnología actual y dentro del presupuesto;
• Si el sistema puede integrarse con otros
sistemas existentes.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 7

 Implementación del estudio de
viabilidad
 Sobre la base de evaluación de la información (lo
que se requiere), la recopilación de información y
redacción de informes.
 Preguntas para las personas en la organización
• Qué pasaría si el sistema no se implementaria?
• Cuáles son los problemas con los procesos actuales?
• Cómo ayudará el sistema propuesto?
• Cuáles serán los problemas de integración?
• Nueva tecnología es requerida por el sistema?
• A qué debe ayudar el sistema?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 8

 Obtención y análisis
 A veces llamado obtención o descubrimiento de
requerimientos.
 Implica personal técnico que trabaja con los clientes
para conocer el dominio de aplicación, los servicios
que debe proporcionar el sistema y las restricciones
operacionales del sistema.
 Puede implicar a los usuarios finales,
administradores, ingenieros involucrados en el
mantenimiento, expertos de dominio, los sindicatos,
etc. Estos se llaman stakeholders (afectados por el
sistema).

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 9

 Problemas de análisis de
requerimientos
 Los afectados (stakeholders) no saben lo que
realmente quieren.
 Los afectados por el sistema expresan los
requerimientos en sus propios términos.
 Las diferentes partes interesadas (stakeholders)
pueden tener requerimientos conflictivos.
 Factores organizacionales y políticos pueden influir
en los requerimientos del sistema.
 Las requerimientos cambian durante el proceso de
análisis. Pueden surgir nuevos stakeholders y el
entorno empresarial cambia.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 10

Proceso de obtención y análisis de
requerimientos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 11

 Actividades del proceso
 Descubrimiento de requerimientos
• Interactuar con las partes interesadas para conocer sus
necesidades. Los requerimientos del dominio son
también descubiertos en esta etapa.
 Clasificación y organización de requerimientos
• Agrupa los requerimientos relacionados y los organiza de
un modo coherente.
 Ordenación por prioridades y negociación
• Priorizar requerimientos y resolver los conflictos entre los
mismos.
 Documentación de requerimientos
• Los requerimientos son documentados e ingresados en la
siguiente iteración.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 12

 Descubrimiento de
requerimientos
 Proceso de recopilación de información
sobre los sistemas propuestos y existentes y
la destilación de los requerimientos de
usuario y del sistema a partir de esta
información.
 Fuentes de información que incluyen la
documentación, afectados por el sistema
(stakeholders) y las especificaciones de
sistemas similares.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 13

 Stakeholders de un sistema de
cajero automático
 Los clientes del banco
 Representantes de otros bancos
 Directores de banco
 Contadores
 Administradores de base de datos
 Los administradores de seguridad
 Departamento de marketing
 Ingenieros de mantenimiento de hardware y
software
 Reguladores bancarios

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 14

 Puntos de vista
 Son una forma de estructuración de los
requerimientos para representar las
perspectivas de diferentes stakeholders. Los
stakeholders pueden ser clasificados por
diferentes puntos de vista.
 Este análisis de perspectiva múltiple es
importante ya que no existe una única forma
correcta de analizar los requerimientos del
sistema.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 15

 Tipos genéricos de punto de vista
 Puntos de vista de los interactuadores
• Personas u otros sistemas que interactúan directamente
con el sistema. En un cajero automático, el cliente y la
base de datos de la cuenta son puntos de vista de los
interactuadores.
 Puntos de vista indirectos
• Stakeholders que no utilizan el sistema en sí, pero
influyen en los requerimientos. En un cajero automático,
la gerencia del banco y el personal de seguridad son
puntos de vista indirectos.
 Puntos de vista del dominio
• Representan las características y restricciones del
dominio que influyen en los requerimientos del sistema.
En un cajero automático, un ejemplo serían los
estándares para las comunicaciones inter-bancarias.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 16
 Identificación de los puntos de
vista
 Identificar los puntos de vista utilizando
• Proveedores y receptores de los servicios del
sistema;
• Sistemas que interactúan directamente con el
sistema a especificar;
• Regulaciones y estándares que se aplican al
sistema;
• Fuentes de los negocios y los requerimientos
no funcionales.
• Ingenieros que han de desarrollar y mantener el
sistema;
• Marketing y otros puntos de vista.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 17

 Jerarquía de los puntos de vista
en el LIBSYS

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 18

 Entrevistas
 En el sector formal o informal de entrevistas,
el equipo de ingeniería de requerimientos
formula preguntas a los interesados sobre el
sistema que utilizan y el sistema a
desarrollar.
 Hay dos tipos de entrevista
• Entrevistas cerradas donde los stakeholders
responden a un conjunto de preguntas.
• Entrevistas abiertas, donde no hay una agenda
pre-definida y una gama de cuestiones se
estudian con los stakeholders del sistema.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 19

 Entrevistas en la práctica
 Normalmente una mezcla de entrevistas abiertas y
cerradas.
 Las entrevistas son buenas para obtener una
comprensión global de lo que hacen los
stakeholders y cómo pueden interactuar con el
sistema.
 Las entrevistas no son buenas para la comprensión
de los requerimientos de dominio
• Los ingenieros de requerimientos no pueden entender el
la terminología específica del dominio;
• Algún conocimiento del dominio es tan familiar que las
personas tienen dificultades para articular o pensar que
no vale la pena articular.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 20

 Entrevistadores eficaces
 Los entrevistadores deben ser de
mentalidad abierta, dispuestos a escuchar a
los stakeholders y no deben tener ideas pre-
concebidas acerca de los requerimientos.
 Deben impulsar al entrevistado con una
pregunta o una propuesta y no simplemente
esperar que responda a una pregunta como
qué quieres o esperas?.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 21

 Escenarios
 Los escenarios son ejemplos de la vida real
de cómo un sistema puede ser utilizado.
 Deben incluir
• Una descripción de la situación inicial;
• Una descripción del flujo normal de los
acontecimientos;
• Una descripción de lo que puede salir mal y
cómo manejarlo;
• Información acerca de otras actividades;
• Una descripción del estado del sistema cuando
finalice el escenario.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 22
 LIBSYS escenario (1)

Asunción inicial: El usuario ha abierto una sesión al sistema de LIBSYS y ha localizado el diario que
contenía la copia del artículo.
Normal: El usuario selecciona el artículo para ser copiado. El sistema entonces proporciona la información
del suscriptor para el diario e indica cómo se pagará el artículo. Los métodos alternativos del pago están por
la tarjeta de crédito o cotizando un número de cuenta bancaria. Entonces piden al usuario rellenar un
impreso de los derechos reservados que mantenga los detalles de la transacción y someten esto al sistema de
LIBSYS. Se comprueba la forma de los derechos reservados y, si es ACEPTABLE, la versión del pdf del
artículo se transfiere a la zona de trabajo de LIBSYS en la computadora del usuario y el usuario es
informado de que está disponible. Pide al usuario seleccionar una impresora y una copia del artículo se
imprime. Si el artículo se ha señalado por medio de una bandera como `solo imprimir' se suprime del sistema
una vez que el usuario ha confirmado la impresión completa.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 23

 LIBSYS escenario (2)

Qué puede salir mal: El usuario puede no poder rellenar el impreso de los derechos reservados
correctamente. En este caso, la forma se debe presentar al usuario para la corrección.
Si la forma sometida es todavía incorrecta, entonces el pedido de usuario del artículo se rechaza. El pago se
puede rechazar por el sistema.
El pedido de usuario el artículo se rechaza.
La transferencia directa del artículo puede fallar. Revise hasta acertado o el usuario termina la sesión. Puede
no ser posible imprimir el artículo.
Si el artículo no se señala por medio de una bandera como `imprímalo-only' entonces se sostiene en el
espacio de trabajo de LIBSYS. Si no, se suprime el artículo y la cuenta de usuario se acredita con el coste
del artículo.
Otras actividades: Transferencias directas simultáneas de otros artículos.
Estado de sistema en la terminación: Abren una sesión al usuario. El artículo transferido se ha suprimido
de espacio de trabajo de LIBSYS si se ha señalado por medio de una bandera como imprime-solamente.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 24

 Casos de uso
 Son un escenario basado en la técnica de
UML que permite identificar a los actores
interactuantes y que describen la interacción
propiamente dicha.
 Un conjunto de casos de uso deben
describir todas las posibles interacciones
con el sistema.
 Diagramas de secuencia se puede utilizar
para añadir detalles a casos de uso,
mostrando la secuencia de transformación
de eventos en el sistema.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 25
 Caso de Uso - Imprimiendo

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 26

 LIBSYS - Casos de Uso

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 27

 Imprimir artículo

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 28

 Diagrama de Secuencia

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 29

 Factores sociales y
organizacionales
 Sistemas de software se utilizan en un
contexto social y organizativo. Esto puede
influir o incluso dominar los requisitos del
sistema.
 Factores organizativos y sociales no son un
único punto de vista, pero son factores que
influyen en todos los puntos de vista.
 Buenos analistas deben ser sensibles a
estos factores, pero actualmente no de
forma sistemática para hacer frente a su
análisis.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 30
 Etnografía
 Los analistas pasan un considerable tiempo
observando y analizando cómo la gente trabaja
realmente.
 La gente no tiene que explicar o articular su trabajo.
 Se pueden observar factores sociales y
organizacionales de importancia.
 Estudios etnográficos han mostrado que el trabajo
es generalmente más rico y más complejo que la
que sugieren los modelos de sistemas simples.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 31

 Etnografía enfocada
 Desarrollado en un proyecto de estudio de
un proceso de control de tráfico aéreo
 Combina la etnografía con prototipado
 Desarrollo de prototipos resulta en preguntas
sin respuesta que enfocan el análisis
etnográfico.
 El problema de la etnografía es que estudia
prácticas existentes que pueden tener cierta
base histórica, que ya no es relevante.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 32

 Etnografía y prototipado

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 33

 Alcance de la etnografía
 Los requerimientos se derivan de la forma
en que las personas trabajan realmente, no
de la manera en que las definiciones del
proceso sugieren que deberían trabajar.
 Los requerimientos se derivan de la
cooperación y el conocimiento de las
actividades de otras personas.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 34

 Validación de requerimientos
 Preocupado por demostrar que los
requerimientos definen el sistema que el
cliente realmente quiere.
 Los costes de error en los requerimientos
son muy altos, por lo que la validación es
muy importante
• Reparar un error en los requerimientos después
de la entrega puede costar hasta 100 veces
más que la reparación de un error de
implementación.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 35

 Verificación de los
requerimientos
 Verificaciones de validez. El sistema proporciona los
servicios que mejor responden a las necesidades
del cliente?
 Verificaciones de consistencia. Hay conflictos entre
los requerimientos?
 Verificaciones de completitud. Son todas las
funciones requeridas por el cliente?
 Verificaciones de realismo. pueden implementarse
los requerimientos dada la disponibilidad de
presupuesto y tecnología?
 Verificabilidad. Pueden ser verificados los
requisitos?
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 36
 Técnicas de validación de
requerimientos
 Revisiones de requerimientos
• Análisis sistemático manual de los
requerimientos.
 Construcción de prototipos
• Usando un modelo ejecutable del sistema para
verificar los requerimientos. Contempladas en
el Capítulo 17.
 Generación de casos de prueba
• Desarrollar pruebas para los requerimientos del
usuario y comprobar que éstos deben poder
probarse.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 37

 Evaluación de requerimientos
 Evaluaciones periódicas deberían realizarse
mientres la definición de los requerimientos
se está formulando.
 Tanto el cliente como el personal contratista
deben participar en las evaluaciones.
 Las evaluaciones pueden ser formales (con
documentos completos) o informales. Una
buena comunicación entre desarrolladores,
clientes y usuarios pueden resolver los
problemas en una etapa inicial o temprana.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 38
 Revisiones de los requerimientos
 Verificabilidad. Puede probarse el
requerimiento de modo realista?
 Comprensibilidad. Es el requisito
comprensible?
 Rastreabilidad. Está claramente definido el
origen del requerimiento?
 Adaptabilidad. Puede modificarse el
requerimiento sin causar un gran impacto en
otros requerimientos?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 39

 Gestión de requerimientos
 Es el proceso de gestionar la evolución de los
requerimientos durante el proceso de ingeniería de
requerimientos y el desarrollo del sistema.
 Los requerimientos son inevitablemente incompletos
e inconsistentes
• Nuevos requerimientos emergen durante el proceso de
cambio de requerimientos de la empresa y una mejor
comprensión del sistema es desarrollada;
• Puntos de vista diferentes, tienen diferentes
requerimientos y éstos son a menudo contradictorios.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 40

 Cambio en los requerimientos
 La prioridad de los requerimientos de los
diferentes puntos de vista cambia durante el
proceso de desarrollo.
 Los clientes del sistema pueden especificar
los requerimientos desde una perspectiva
empresarial que entra en conflicto con los
requerimientos de los usuarios finales.
 El entorno empresarial y técnico del sistema
cambia durante su desarrollo.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 41

 Evolución de requerimientos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 42

 Requerimientos duraderos y
volátiles
 Requerimientos duraderos. Derivados de la
actividad principal de la organización. Por
ejemplo, un hospital tendrá siempre
médicos, enfermeras, etc. Pueden derivarse
de modelos del dominio
 Requerimientos volátiles. Requerimientos
que cambian durante el desarrollo o cuando
el sistema está en uso. En un hospital,
requerimientos derivados de la política de
atención a la salud

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 43

 Clasificación de los
requerimientos

Tipo de Descripcion
requerimiento
Requerimientos Requerimientos que cambian debido a los cambios en el entorno en el que opera la
cambiantes organización. Por ejemplo, en los sistemas hospitalarios, el pago del cuidado del
paciente puede cambiar y así requerir un tratamiento diferente la información a tratar
Requerimientos Requerimientos que emergen a medida que la comprensión del sistema por parte del
emergentes cliente aumenta durante el desarrollo del sistema. El proceso de diseño puede revelr
nuevos requerimientos emergentes.
Requerimientos Requerimientos que resultan de la introducción de un sistema informático o
consecuentes computacional. Al introducir dicho sistema pueden cambiar los procesos
empresariales y abrir nuevas formas de trabajo que generan nuevos requerimientos
del sistema
Requerimientos Requerimientos que dependen en sistemas particulares o procesos empresariales
de dentro de las organizaciones. A medida que esos cambian, los requerimientos de
compatibilidad compatibilidad en el sistema entregado puede que también tengan que evolucionar.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 44

 Planificación de la gestión de
requerimientos
 Durante el proceso de ingeniería de requerimientos,
usted tiene que planificar:
• La identificación de requerimientos
• Cómo los requerimientos son identificados individualmente;
• Un proceso de gestión del cambio
• El proceso seguido en el análisis de requerimientos de un
cambio;
• Las políticas de rastreo
• La cantidad de información acerca de las relaciones de los
requerimientos que se mantienen;
• Herramientas CASE de apoyo
• La herramienta de apoyo requerida para ayudar a gestionar
los cambios en los requerimientos;

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 45

 Rastreabilidad
 La rastreabilidad se refiere a las relaciones entre los
requerimientos, sus fuentes y el diseño del sistema
 Información de rastreo de la fuente
• Enlaces de los requerimientos a los stakeholders que
propusieron estos requerimientos;
 Información de rastreo de los requerimientos
• Vínculos entre los requerimientos dependientes;
 Información de rastreo del diseño
• Enlaces de los requerimientos hacia el diseño;

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 46

 Herramienta CASE de apoyo
 Almacenamiento de requerimientos
• Los requerimientos deben ser administrados de forma
segura, desde un almacén de datos.
 Gestión del cambio
• El proceso de gestión del cambio es un proceso de flujo
de trabajo cuyas etapas pueden ser definidas y el flujo de
información entre estas etapas parcialmente
automatizado.
 Gestión de rastreo
• Recuperación automatizada de los vínculos entre los
requisitos.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 47

 Gestión del cambio de
requerimientos

 Debería aplicarse a todos los cambios

propuestos a los requerimientos.
 Principales etapas
• Análisis de problemas. Discutir las necesidades
y proponer cambios;
• Análisis del cambio y cálculo de costos. Evaluar
los efectos del cambio en los demás
requerimientos;
• Implementación del cambio. Modificar el
documento de requerimientos y otros
documentos a fin de reflejar el cambio.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 48

 Gestión del cambio

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 49

 Puntos clave
 El proceso de ingeniería de requerimientos
incluye un estudio de viabilidad, obtención y
análisis de requerimientos, especificación de
los requerimientos y gestión de
requerimientos.
 Obtención y análisis de requerimientos es
iterativa, puesto que implica la comprensión
de dominio, clasificación, estructuración,
priorización y validación.
 Los sistemas tienen múltiples stakeholders
con diferentes requerimientos.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 50
 Puntos clave
 Factores sociales y organizacionales
influyen en los requerimientos del sistema.
 La validación de requerimientos se refiere a
verificaciones de validez, consistencia,
integridad, realismo y la verificabilidad.
 Cambios en las empresas inevitablemente
llevan a cambios en los requerimientos.
 La gestión de requerimientos incluye la
planificación y gestión del cambio.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 51