El documento describe el proceso de ingeniería de requisitos, incluyendo las etapas de obtención, elaboración, negociación, especificación, validación y gestión de requisitos. Explica que la ingeniería de requisitos ayuda a comprender mejor el problema mediante tareas específicas y es esencial analizar el problema antes de resolverlo. También describe técnicas como casos de uso, diagramas de entidad-relación y análisis orientado a objetos para modelar requisitos.

1. Ingeniería de
requisitos

2.  Ayuda a comprender mejor el
problema, mediante la elaboración de
tareas especificas las cuales ayudan a
comprender mejor el impacto del
software sobre el negocio y/o usuarios.

3. Ingeniería de Requerimientos:
 Debe adaptarse a las necesidades del
proceso
 Es una acción que comienza durante la
actividad de comunicación y las
actividades de modelado.
 Tareas definidas para comprender mejor
los requisitos de software.
 Es esencial analizar el problema antes de
resolverlo.

4. Tareas de la IR
 Proporciona el mecanismo adecuado para
entender al cliente.
 Se lleva acabo de siete funciones:
 Inicio
 Obtención
 Elaboración
 Negociación
 Especificación
 Validación
 Gestión

5. Inicio
 Tener una comunicación continua con el
cliente.
 Obtener la suficiente información para
identificar correctamente el problema.

6. Obtención
 Es difícil definir cuales son los objetivos para
el sistema o producto, a continuación de
identifican una serie de problemas que
ayudan a entender la difícil obtención de
requisitos.
 Para superar estos problemas, los ingenieros
de requisitos deben realizar en forma
organizada la actividad de recopilación de
requisitos.

7.  Problemas de ámbito: Detalles innecesarios que no
ayudan a clarificar los objetivos generales del
sistema.
 Problemas de comprensión: Los clientes no
comprenden y no están seguros del dominio del
problema, tienen problemas al comunicar sus
necesidades al isc, omiten información que para
ellos es obvia, especifican requisitos ambiguos o
inestables.
 Problemas de volatilidad: Los problemas cambian
conforme transcurre el tiempo.
Problemas comunes en la
obtención de requisitos

8. Elaboración
 Se enfoca en el desarrollo de un modelo
técnico refinado de las funciones,
características t restricciones del software.
 Se conduce mediante la creación y el
refinamiento de escenarios del usuario
que describen la forma en que el usuario
final interactuara en con el sistema.

9.  Se obtienen clases de análisis.
 Se definen atributos de cada clase de análisis.
 Se identifican los servicios que requiere cada clase.
 Se identifican las relaciones y colaboración entre
las clases.
El resultado es un modelo de análisis que define el
dominio de la información, funciones y el
comportamiento del problema.

10. Negociación
 Los clientes, usuarios y otros interesados deben
ordenar sus requisitos y posteriormente discutir los
conflictos relacionados con la prioridad.
 Se identifican y analizan riesgos asociados con
cada requisito.
 Se hacen estimaciones preliminares del impacto,
desarrollo, costo y tiempo.
 Mediante un enfoque iterativo, los requisitos se
eliminan, combinan o modifican de forma que
cada parte alcance cierto grado de satisfaccion.

11. Especificación
 Es el trabajo final que genera la IR.
 Sirve como base para las actividades de
Ingeniería de Software subsecuentes.
 Describe la función y el desempeño de
un sistema basado en computadora y las
restricciones que regirán el desarrollo.

12. Validación
 Examina la especificación para asegurar
que los requisitos del software se han
establecido de manera precisa, que se
han detectado las inconsistencias,
omisiones y errores y que han sido
corregidos.
 Los productos de trabajo cumplen con
los estándares establecidos por el
proceso, proyecto y producto.

13. Gestión de Requisitos
 Conjunto de actividades que ayudan al
equipo de protector a identificar,
controlar y rastrear los requisitos y los
cambios a estos en cualquier momento
mientras se desarrolla el proyecto.
 Comienza con la identificación.

14. Una vez identificados los requisitos de desarrollan las
tablas de rastreabilidad:
 Tabla de rastreabilidad de las características:
muestra la relación entre las características del
sistema/ producto observable para el cliente.
 Tabla de rastreabilidad de la fuente: identifica la
fuente de cada requisito.
 Tabla de rastreabilidad de dependencia: indica
la forma en que los requisitos están relacionados
entre si.
 Tabla de rastreabilidad del subsistema: establece
categorías entre los requisitos de acuerdo a los
subsistemas que gobiernan.
 Tabla de rastreabilidad de la interfaz: muestra la
forma en que los requisitos se relacionan con las
interfaces internas y externas del sistema.

15. INICIO DEL PROCESO DE LA
INGENIERIA DE REQUISITOS
Para comenzar un proyecto de forma que
se mantenga en movimiento hacia una
solución exitosa se deben seguir los
siguientes pasos:

16. Identificación de los interesados
 Crear una lista de personas que
contribuirán durante la obtención de
requisitos.

17. Reconocimiento de múltiples
puntos de vista
 Categorizar toda la información de los
interesados en forma que permita a quienes
tomen la decisión de elegir un conjunto de
requisitos para el sistema y que sea
consistente de manera interna.

18. Trabajo con respecto a la
colaboración
 Identificar áreas en común ( es decir, los
requisitos en los que los interesados están
de acuerdo) y áreas de conflicto o
inconsistencia.

19. Formulación de Preguntas
 Son libres de contexto.
 Son preguntas como ¿Quién?
¿Cómo?¿Qué?... Etc.
 Este tipo de preguntas ayudan a
identificar a todos los participantes que
están interesados en el proyecto.

20.  Existen otro tipo de preguntas que son las que
dejan que el equipo de DS comprenda mejor el
problema a solucionar.
 ¿Cómo?
 ¿Cuáles?
 ¿Podría describir en donde utilizaran la solución?

21. La serie de preguntas finales:
 Son las llamadas metapreguntas, que son
encadas a la efectividad de la actividad
de la comunicación en si misma.

22. Recopilación conjunta de
Requisitos
 En esta etapa los desarrolladores trabajan
conjuntamente con un equipo de trabajo
para identificar el problema y proponer
elementos de solución.

23. Directrices Básicas
 Las reuniones las dirige alguno de los
asistentes, ya sea ingeniero de software o
un cliente.
 Se establecen reglas para la preparación
y la participación.
 Se sugiere una agenda que sea tan
formal como para cubrir todos los puntos.
 Un moderador, que es el que controla la
reunión.

24.  Después de la etapa de preguntas y
respuestas, se elabora la “Solicitud del
Producto”, se revisa previo a la reunión y
después de esto se le pide a cada
asistente elabore una lista de los servicios
que manipulan o interactúan con los
objetos.

25.  El objetivo es desarrollar una lista consensada
en el área de cada tópico. Después de que
esta lista es completada, el equipo se divide
en subequípos menores, para desarrollar
miniespecificaciones.

26.  Después de realizar las miniespecificaciones, se
comentan en el equipo de trabajo para
analizar si se descubrieron nuevos requisitos,
servicios, restricciones y rendimiento.

27. Despliegue de la función de
calidad (QFD)
 QFD se concentra en aumentar la
satisfacción del cliente desde el proceso de
la ingeniería del software.
 El QFD identifica tres tipos de requisitos:
1. Requisitos normales (objetivos y metas)
2. Requisitos esperados (facilidad de
interacción)
3. Requisitos estimulantes (mas allá de las
expectativas del cliente)

28. Escenarios del usuario
Los escenarios, llamados con frecuencia casos
de uso proporcionan una descripción de
como se usara el sistema.

29. Productos de trabajo de la obtención
Productos de trabajo:
 Un enunciado de necesidad y facilidad
 Un enunciado limitado del ámbito del sistema o
producto
 Una lista de cliente, usuarios y otros interesados
que participaron en la obtención de requisitos
 Una descripción del ambiente técnico del sistema
 Una lista de requisitos y las restricciones de
dominio aplicables a cada uno
 Un conjunto de escenarios de uso que
proporcionen un discernimiento de la utilización
del sistema o producto en diferentes condiciones
de operación.
 Cualesquiera prototipo desarrollados para definir
de mejor forma los requisitos.

30. Desarrollo de casos de uso
 Un caso de uso captura un contrato
 Comportamiento del sistema
 Definir los actores (diferentes personas que van a utilizar el
sistema)
 Preguntas para crear los casos de uso
1. ¿Quién es el actor primario?
2. ¿Cuales son las metas del actor?
3. ¿Cuáles son las condiciones previas que deben existir
antes de comenzar la historia?
4. ¿Cuáles son las tareas o funciones principales que
realiza el actor?
5. ¿Cuáles excepciones podrían consideraras mientras se
describe la historia ?
6. ¿Cuáles son las variaciones posibles en la interacción
del actor?

31. Diagrama entidad-relación
 La pareja objeto-relación es la piedra angular del
modelo de datos. Con este diagrama se identifican
los componentes primarios :
 Objetos de datos, atributos, relaciones e indicadores
de varios tipos. El propósito primordial de este
modelo es representar objetos de datos y sus
relaciones.
 Las conexiones entre objetos de datos y relaciones
se establecen mediante una variedad de símbolos
especiales que indican su cardinalidad y modalidad.


32. Diagrama Entidad-Relación

33. Análisis Orientado a Objetos.
1. Deben comunicarse los requisitos básicos del usuario entre
el cliente y el ingeniero de software.
2. Deben identificarse las clases.
3. Se define una jerarquía de clases.
4. Deben representarse las relaciones de objeto a objeto.
5. Debe modelarse el comportamiento del objeto.
6. Las tareas 1 a 5 se vuelven a aplicar de manera iterativa
hasta que el modelo esté completo.

34. Conceptos Orientados a
Objetos
 Atributos: Una colección de valores de los
datos que describen una clase.
 Clase: Encapsula datos y las abstracciones
de procedimiento requeridos para describir el
contenido y el comportamiento de alguna
entidad del mundo real.
 Objeto: Instancia de una clase en especifica,
heredan los atributos y operaciones de una
clase.

35. Conceptos Orientados a
Objetos
 Operaciones: también llamadas métodos y
servicios, proporcionan la representación de uno
de los comportamientos de una clase.
 Subclase: una especialización de la superclase.
Una subclase puede heredar tanto los atributos
como las operaciones de una superclase.
 Superclase: también llamada clase básica, es una
generalización de un conjunto de clases que
están relacionadas con ella.

36. Actividades de negociación
 En lugar de actividades sencillas de
comunicación con el cliente, se define las
siguientes actividades:
1. Identificación de los interesados clave en el
sistema o subsistema.
2. Determinación de las «condiciones ganadoras»
de los interesados
3. Negociación de las condiciones ganadoras de
los interesados para reconciliarlas en conjunto
de condiciones del tipo ganar- ganar para
todos los involucrados (incluso el equipo de
software).

37. El arte dela negociación
1. Reconocer que no es una competencia
2. Diseñar una estrategia
3. Escuchar de manera activa
4. Enfocarse en los intereses de la otra
parte
5. No dejar que se vuelva personal
6. Ser creativo
7. Estar listo para pactar.

38. Validación de requisitos
Una revisión del modelo de análisis se enfoca en las
siguientes preguntas:
 ¿cada requisito es consistente con el objetivo general del
sistema/producto?
 ¿todos los requisitos han sido especificados con el grado
apropiado de abstracción?
 ¿el requisito es necesario en realidad o representa una
característica agregada irrelevante para el objetivo del
sistema?
 ¿cada requisito esta limitado y no es ambiguo?
Estas y otras preguntas deben realizarse y contestarse para
asegurar que el modelo de requisitos es un reflejo exacto de
las necesidades del cliente y que proporciona una base
sólida para el diseño.