IREB OFICIAL Cap 1-9 FULL

1
Certificación de Profesional en Ingeniería de

Requisitos
Nivel Básico
Basado en la Versión 2.1 de junio del 2012
2
Acuerdos fundamentales para el buen funcionamiento del Curso
• Quién es el presentador?
• Qué es este curso?
• Cuánto dura? Hay descansos?
• Debo hacer ejercicios?
• Me van a dejar tareas?
• Puedo obtener mi certificado?
• Puedo usar mi teléfono celular o revisar mi correo electrónico durante la clase?
• Alguna otra inquietud?
3
Materiales
• Este curso está basado en

– Version 2.1 del Nivel Básico del programa de Certificación
Profesional IREB en Ingeniería de Requisitos (Ver Syllabus en www.isqi.org)
• Los términos provienen del glosario
• Materiales de referencia, glosario y ayudas de estudio para aquellos en búsqueda de certificación
• Para uso en los ejercicios

– Documento de Requisitos de Marketing de Omninet
– Documento de Requisitos del Sistema de Omninet
• Un cuaderno para hacer los ejercicios
4
Ejercicios
• En algunos ejercicios, usted se desempeña como Ingeniero de Requisitos del Proyecto

Omninet
• Omninet es un proyecto para desplegar una red de quioscos con acceso público a Internet en
sitios como centros comerciales, teatros y otros sitios públicos
• En este proyecto real, usted tendrá la oportunidad de aplicar algunas de las técnicas que
discutiremos
• Otros ejercicios se han adicionado para ilustrar puntos específicos
5
Sus objetivos del Curso
• Este material está diseñado para ayudarlo a convertirse en un

ingeniero de requisitos más efectivo y eficiente, y para ayudarlo a
obtener el certificado IREB Nivel Básico
• Por favor pase los siguientes minutos escribiendo qué

le gustaría obtener del curso
• Use la página siguiente para sus objetivos
 No deje terminar el curso sin alcanzar uno solo de los objetivos!
6
Mis Objetivos del Curso
7
Este es SU Curso
Por favor únase a él

 Pregunte
 Comente
 Comparta experiencias
 Segundas opiniones y desacuerdos son

bien recibidos Las mejores sesiones tienen mucho de esto...
Por qué está aquí?
Qué quiere aprender, discutir y enseñar?
…así como de esto.
8
CONTENIDO DEL CURSO
El curso está dividido en nueve capítulos de acuerdo con el programa de estudio del IREB®
- Capítulo 1 Introducción y Fundamentos (1 ¼ horas)
- Capítulo 2 Definición de sistema y contexto (1 ¼ horas)
- Capítulo 3 Obtención de requisitos (1 ½ horas)
- Capítulo 4 Documentación de requisitos (2 horas)
- Capítulo 5 Documentación en lenguaje natural (1hora)
- Capítulo 6 Documentación basada en modelos (5 horas)
- Capítulo 7 Validación y negociación de requisitos (2 ½ horas)
- Capítulo 8 Gestión de requisitos (2 ½ horas)
- Capítulo 9 Apoyo de herramientas (1 hora) (1 hora)
9
CONTENIDO DEL CURSO
- Capítulo 9 Apoyo de herramientas (1 hora) (1 hora)
10
Capítulo 1 Introducción y Fundamentos (1 ¼ horas)
• 1.1 Conocer los síntomas y los motivos de una IR inadecuada

1.2 Conocer las cuatro actividades principales de una IR
1.3 Conocer el papel de la comunicación en la IR
1.4 Conocer las habilidades de un ingeniero de requisitos
1.5 Conocer los tres tipos de requisitos.
1.6 Comprender el papel de los requisitos de calidad
11
Qué hace a un requisito ser de poca calidad?
• Un requisito de poca calidad es aquel que no comunica efectivamente el comportamiento

deseado
– Vago
– Ambiguo
– Contradictorio
– Sin posibilidad de implementarse o probarse
– Implícito más no declarado
• Un requisito que no se pueda leer con facilidad o que sea incorrecto gramaticalmente
también puede ser un problema
12
Y cuando simplemente están mal?
• Algunos requisitos están mal

– Invalido
– Incorrecto
– Falso
• Faltan requisitos
13
Qué pasa si un Requisito es malo?
• El desarrollador no sabe qué implementar, entonces no se implementa nada

– Resultado: El usuario no recibe lo que pensó haber pedido y queda descontento.
• El desarrollador adivina qué debe implementar

– Resultado: El usuario puede recibir o no el
producto correcto. Aquel que efectúa las
pruebas no sabe qué debe probar.
• El desarrollador se hace su propia idea

de qué implementar y así procede
– Resultado: El usuario recibe algo, que probablemente no cubre sus necesidades, resultando
en un desperdicio de desarrollo y tiempo de prueba, así como en repetición de trabajo
14
Requirements Issues?
Como lo pidió el Como lo entendió el Como lo que diseñó el Como el programador lo Como lo describió el
cliente lider de proyecto Ingeniero de Requsitos escribió consultor de negocios
Como se documentó el El producto instalado Como le cobraron al Como se le brindó La verdadera

proyecto cliente soporte necesidad del cliente
15
Los Costos de Malos Requisitos
• Dependiendo de a quién le crea, requisitos incorrectos o no válidos representan entre 15 y

60% de los errores identificados en un producto
• Este número varía por el tipo de producto y la pericia del equipo de trabajo para identificar
adecuadamente la causa primaria de los errores encontrados
• Un mal requisito encarece mientras permanezca en el proyecto debido al esfuerzo perdido y la

repetición del trabajo
• De cualquier manera, esto es un costo elevado!
16
Ejemplos de Costos
• Si un mal requisito es identificado en la revisión de requisitos, son de esperar los siguientes costos
adicionales:
– Costo del Ingeniero de Requsitos para reparar/remplazar el requisito

– Tiempo del Cliente empleado en la interacción con el Ingeniero de Requsitos para la
clarificación
– El tiempo gastado por el revisor durante la sesión de revisión y cualquier discusión/revisión
posterior
• Algún otro?
17
Ejemplos de Costos
• Si un mal requisito es identificado durante el diseño de arquitectura/código, son de esperar

los siguientes costos adicionales:
– El tiempo empleado por el desarrollador resolviendo el misterio del requisito problema

– El tiempo empleado por Desarrollador/Ingeniero de Requsitos discutiendo el mal
requisito
– El tiempo empleado por el Revisor durante las sesiones de revisión y cualquier
discusión/revisión posterior
– Otros?
• Y no olvidar todos los costos previos incurridos!
18
Ejemplos de Costos
• Si un mal requisito es identificado durante la revisión de código, son de esperar los siguientes
costos adicionales:
– Tiempo de cada desarrollador generando código

– Tiempo desarrollando los casos de prueba
– Tiempo empleado en el diseño de Interfaz y probablemente de implementación también
– Tiempo de la unidad de desarrollo de pruebas (note que la unidad de pruebas no va a
descubrir ningún mal requisito)
– Tiempo del revisor empleado en la revisión del código
– Tiempo del desarrollador en el rediseño y codificación
– Otros?
• Y no olvidar todos los costos previos incurridos!
19
Ejemplos de Costos
• Si un mal requisito es identificado durante las pruebas (ahora si que se hace costoso!), espere los
siguientes costos adicionales:
– Desarrollo de código del interfaz y sus dependencias
– Tiempo de ejecución del caso de prueba
– Tiempo de automatización del desarrollo de pruebas
– Tiempo de rastreo de errores (y parte del costo del sistema de rastreo de errores)
– Tiempo empleado por probador y desarrollador determinando que el requisito tiene errores
– Rediseño y ejecución de prueba cuando el nuevo código se recibe
– Otros?
• Y no olvidar todos los costos previos!
20
Ejemplos de Costos
• Si un mal requisito se identifica durante las pruebas de aceptación hechas por el cliente (el
asunto se hace vergonzoso!), espere los siguientes costos adicionales:
– El costo de fallar frente al usuario
– En el mejor de los casos el cliente vuelve a hacer las pruebas de aceptación cuando el
código se haya corregido
– El peor de los casos, el cliente rechaza el sistema
– Otros?
21
Ejemplos de Costos
• Si un mal requisito se identifica en la etapa de producción (oh oh!), espere los siguientes costos
adicionales:
– Costos de soporte técnico y mesa de ayuda

– Investigación y resolución de errores, pruebas y entrega
– Cambios en la documentacion
– Demoras en la implementación con otros clientes
– Cuál es el costo de un cliente insatisfecho?
• Posibilidad de perder ventas

• Pérdida en futuras actualizaciones
• Pérdida de cuentas que sirven de
referentes
• Mala publicidad
– Otros?
22
Costos de Oportunidad
• Una consideración más de costos….
• Cuando el equipo está trabajando en solucionar un problema causado por un mal requisito, ellos
no estan trabajando en nuevos proyectos
• Un mal requisito no impacta solamente el cronograma del proyecto actual
• Los equipos de trabajo se frustran!
23
Por qué se Presentan Malos Requisitos?
• No se toma el suficiente tiempo en el análisis
• El representante del cliente no conoce a cabalidad las necesidades del cliente
• Se asumen requisitos como “obvios” y que no necesitan declararse
• Problemas de comunicación en cualquier etapa de desarrollo del proyecto
• Programación de tiempo inadecuada – apresurarse en generar código, o la etapa de pruebas,

y pensar que todo se puede arreglar luego
24
Más causales de malos requisitos?
• Se “explica por sí mismo”, generalmente no es así
• Errores de comunicación debido a diferentes niveles de conocimiento y experiencia
• Presión impuesta por el cliente para que se entregue el sistema final antes de lo previsto o aún de
manera parcial
25
Buenos Requisitos Brindan
• Una clara comunicación entre las partes interesadas
• Un cronograma y presupuesto válidos
• Uso eficiente de los recursos sin repetir tareas
• Mantener el trascurso del proyecto bajo control
• Clientes felices
26
Buenos Requisitos
• Buenos requisitos son como buena tubería

– Todo fluye suavemente a través del proceso
– Normalmente se da por sentado y “esperado”
– Crítico para la eficiencia
• Cómo se comparan malos requisitos con mala tubería?
27
Ejercicio
• Identifique problemas que usted haya encontrado y que podrían evitarse con una buena ingeniería
de requisitos
• Compare los costos de los siguientes casos:
– Un requisito no identificado de desempeño o eficiencia

– Un requisito impreciso de interfaz de usuario
– Un requisito equivocado de funcionalidad
28

29
Grupos de Actividades del Proceso
Descubrimiento de Requsitos
Revisiones y
Documentación
Contexto
Levantamiento Aprobaciones
de Información Lenguaje
natural Modelos
Planeación, Administración y Control General de la Calidad
Herramientas
30

31
Teoría de la Comunicación
• Sobre todas las cosas, un Ingeniero de Requisitos debe ser un comunicador efectivo
• El Ingeniero de Requisitos exitoso debe ser capaz de:
– Identificarse con las partes interesadas a lo largo del proyecto

– Comunicarse efectivamente de manera escrita y hablada (esto incluye correo electrónico,
mensajes instantáneos, conferencias telefónicas…)
– Entender la dinámica del grupo
– Estar capacitado en los métodos usados para observación y entrevistas
– Entender la conformación de grupos de trabajo
32
Qué es la teoría de la comunicación?
• Es un campo de estudio relativamente nuevo que abarca todos los aspectos de la comunicación
• El modelo de Lasswell se usa comúnmente para describir el acto de la comunicación: “Quién dice
Qué, en Qué canal, a Quién y con Qué efecto”
• La teoría de la comunicación trata de entender la comunicación en términos de normas sociales,

contextos, suposiciones (de parte del receptor
y del emisor) y muchos otros factores
33
Comunicación
• El ingeniero de Requisitos debe ser capaz de comunicarse empleando un lenguaje

natural
– Terminología común
– Medio efectivo (escrito/hablado)
• Todos los entes interesados tienen la responsabilidad de concentrarse y simplificar
34

35
Ingeniero de Requisitos?
• Conceptos clave
– Qué es un ingeniero de requisitos?
– Cuáles son las habilidades requeridas para este trabajo?
36
Principales Actividades del Ingeniero de Requisitos
• Hay cuatro actividades principales dentro de la Ingeniería de Requisitos:
– Obtener los requisitos

– Documentar los requisitos
– Comprobar y reconciliar los requisitos
– Administrar los requisitos
• Poco énfasis en los procesos de negocios y las políticas
37
Habilidades Requeridas
• Conceptos clave
– Aplicación de la teoría de la comunicación
– Trabajar bien con los demás
– Habilidades requeridas para ser efectivo
38
Habilidades Requeridas para la Ingeniería de Requisitos
• Emplear técnicas de análisis estructurado
• Manejar efectivamente los impedimentos y generar conclusiones
• Comunicarse con todos los entes involucrados a lo largo del proyecto
• Aprender y avanzar continuamente en las habilidades
• Entender y exponer las consideraciones de usabilidad
• Mediar y resolver los problemas que surjan
39
Indispensable
Conocer el Dominio del Negocio
• Producción de la organización así como productos competentes y pendientes
• Procesos en uso hacia adentro y afuera de la organización
• Mejores prácticas en la industria
• Mercados, actual y futuro
• Fuentes de información
40
Conocimiento TI Requerido
• Metodologías para el ciclo de vida del desarrollo de software

• Opciones de ambiente/configuración
• Herramientas y formatos
• Almacenamiento, acceso y protección de la Información
• Requisitos de seguridad
• Reglamentación para el tipo de negocio específico
41
Habilidades Avanzadas del Ingeniero de Requsitos
• Reunir gestión y moderación • Preguntar

• Presentaciones • Escalar
• Pensamiento y razonamiento • Lógica
analítico • Conciencia cultural y ambiental
• Tomar decisiones • Manejo de relaciones
• Facilitar • Habilidades de lider, incluyendo
• Empatía motivación, las entrevistas y la
• Resolución de conflictos delegación
• Negociación y persuasión • Confianza en sí mismo
42
Varios Ingeniero de Requsitos?
• La división de tareas puede ser necesaria
• Estrategias incluyen una división basada en

– Experiencia específica en la materia
– Complejidad
– Experiencia previa con las partes interesadas
– Geografía/cultura
– Áreas de interés
– Disponibilidad
43
La Información debe ser Coordinada
• La coordinación debe estar presente dentro del equipo para que haya consistencia
– Terminología
– Metodología
– Otros?
• Debe haber coordinación entre los miembros del equipo

– Para evitar superposiciones y repetición del trabajo
– Asegurar un adecuado punto de control
• Deben hacerse provisiones para la transferencia de conocimiento

– Capturar, recopilar y compartir conocimiento tácito para que se vuelva conocimiento
explícito
– Entrenamiento cruzado permite una holgura para ausencias, vacaciones
44
Misión del Ingeniero de Requisitos
“COMUNICAR EFECTIVAMENTE”
1) todos los Requisitos de producto final.

2) Honrando las necesidades de todos los interesados
y obteniendo su aprobación.
3) Habiendo seguido un
proceso repetible
y acordado.
45

46
Lo Podemos Probar?
• Todos los requisitos deben ser comprobables

• Deben establecer claramente cómo se puede verificar si la implementación fue
hecha correctamente
• Se requiere un claro entendimiento y un claro enunciado de los detalles del
requisito
• Requisitos pueden tener aspectos funcionales y no funcionales a la vez
Ejemplo: La ayuda debe estar disponible en todas las

ventanas y debe aparecer dentro de cuatro segundos
después de seleccionada.
47
Terminología
• Un requisito es
– Una condición o capacidad requerida por un interesado en resolver un
problema o alcanzar un objetivo
– Una condición o capacidad que debe ser suministrada por un sistema o
componente de sistema para satisfacer un documento formalmente
impuesto (como un contrato o especificación)
– Una representación documentada de alguno de los anteriores
• Una característica es
– Un servicio suministrado por el sistema para satisfacer una necesidad del
interesado
– Una muestra identificable de la funcionalidad del sistema que caracteriza
el sistema ante el usuario
– Categorizada entre funcional o de calidad del servicio
48
Tipos de Requisitos
• Requisito del Negocio – nivel más alto de razones relacionadas con las metas del proyecto
• Requisito del Usuario – necesidades de un interesado específico (o de un grupo de ellos)
• Requisito Funcional – describe el comportamiento u operación de la solución (el “Qué”)
• Requisitos de calidad de servicio (Quality of Service QOS) – condiciones bajo las cuales la
solución debe permanecer efectiva
• Requisitos no funcionales – describen la manera en que la solución va a trabajar (el “Cómo”).

Requisitos QOS son un subconjunto de los requisitos no funcionales
• Suposiciones y limitaciones – aspectos que pueden limitar o impactar el diseño de la solución
• Requisitos de implementación – Capacidades que se necesitarán temporalmente durante la

transición de la empresa, del estado actual al estado futuro
49
Categorización de los Requisitos
1. Requisitos funcionales
2. Requisitos no funcionales
50
Requisitos Funcionales
• Los requisitos funcionales ordenan qué va a hacer el sistema (“el Qué”)

• “Dato Y va a aparecer en el Reporte X como se muestra en la maqueta.”
• Esto puede ser claramente verificado al comparar el reporte obtenido con la maqueta
del reporte.
• Todos los requisitos funcionales deben establecer claramente cómo se determina la aceptación de
la implementación
• “Dato Y va a aparecer en el Reporte X.”
• Puede que aparezca, pero aparece de manera correcta? Estaba supuesto a ir subrayado
o en itálica? No se sabe.
51
Requisitos Funcionales Completos
• Un solo requisito funcional completo debe considerar las importantes características de calidad
• Cada característica debe estar claramente descrita
• El criterio de aceptación de cada requisito debe indicarse claramente
52
Atributos de los Requisitos Funcionales
• Precisión y claridad del requisito en la especificación del comportamiento del sistema
• Capacidad del software de satisfacer las necesidades del usuario
• Requisitos de interoperabilidad del software para trabajar dentro del ambiente objetivo
(incluyendo software, hardware, configuración, aplicaciones relacionadas y arquitectura)
• Seguridad que se debe brindar a los datos y la aplicación
53
Requisitos No-Funcionales
• Requisitos no-funcionales explican “cómo” se debe suministrar la funcionalidad al cliente
• “La primera página del reporte Y, utilizando el criterio predeterminado de selección,

aparecerá para el usuario dentro de cinco segundos luego de enviada la solicitud
cuando no haya otros usuarios en el sistema.”
• Esta es una prueba directa y también muestra el nivel de carga esperado en el sistema
cuando se cumpla este criterio de desempeño. También esperaríamos ver un requisito
determinando como se va a comportar el sistema con 100 usuarios o 10.000 usuarios.
• Como con los requisitos funcionales, el criterio de éxito también debe ser claramente
establecido.
• “La primera página del reporte Y debe aparecer realmente rápido.”
• Oh-oh, esto no puede ser verificado, “realmente rápido” es una medida subjetiva.
54
Requisitos No Funcionales
• Conceptos clave
– Qué son requisitos no funcionales?
– Cómo se agrupan y clasifican los requisitos no funcionales?
– Qué criterio de aceptación se requiere?
• Términos parar recordar
55
Requisitos No Funcionales
• Los requisitos no funcionales se refieren a “cómo” el producto va a satisfacer las

necesidades del usuario
• A menudo se clasifican en la categoría de “esperados” y no “definidos”
• Estos incluyen aspectos como usabilidad, apariencia y sentido, velocidad, confiabilidad,

seguridad
• Cumplir con los estandar normativos de seguridad y legales es primordial
56
Uso Repetido de Requisitos No Funcionales
• Una vez definidos, los requisitos no funcionales se utilizan repetidamente en los proyectos al
interior de una organización
• Crear una librería de estos requisitos resulta ser rentable
• Los Requisitos Legales, de Seguridad y Normativos pueden requerir un aporte externo
• Algunos afectan procesos al interior de la organización (SLAs, backup/restore)
57
Requisitos No Funcionales - Aceptación
• Descripciones imprecisas de requisitos no funcionales son fácilmente ignoradas durante la

implementación
• Deben ser descritos claramente para ser comprobables
• Proyectos pueden fallar debido a una pobre implementación de los aspectos no funcionales
• Costos pueden ser de largo plazo (ejemplo, costos de portabilidad y mantenibilidad)
58
Categorías Diferentes?
• IREB categoriza los requisitos como:

– Funcional
– No Funcional
• Requisitos no funcionales incluyen:

– Requisitos de calidad (como se muestra en ISO 9126)
– Las restricciones que además definen los requisitos funcionales (como son
seguridad o la precisión en los cálculos)
59
Ejercicio No Funcional
• A usted le dieron el trabajo de escribir los requisitos para un sistema de comercio electrónico que
va a brindar la posibilidad de comprar boletas de concierto a los usuarios
• Solamente con esta información, que requisitos no funcionales espera usted que tenga el
sistema?
60
Más Términos
• Necesidad – carencia de algo requerido, deseable, o útil

• Deseo – una voluntad expresa
• Parte interesada (Stakeholder) – aquel involucrado o afectado por el curso de una acción
• Ingeniería de Requisitos – análisis sistemático de requisitos
• Gestión de requisitos – el acto de mantener, controlar y monitorear los documentos de requisitos
y procesos
• Análisis de Requisitos – tareas que llevan a determinar las necesidades o condiciones a cumplir
en un producto nuevo o alterado
• Especificación de Requisitos – descripción completa del comportamiento del software o sistema
a desarrollar
• Documentación de Requisitos – todos los documentos que contribuyen a la descripción del
sistema a desarrollar
61
Procesos de Negocio
• Proceso de negocio es un término general, pero a la vez específico en que

– Tiene una meta
– Tiene entradas específicas
– Tiene salidas específicas
– Usa recursos
– Tiene un número de actividades que son cumplidas en algún orden
– Afecta al menos una unidad organizacional
– Crea valor para el cliente (de ambos modos, interno y externo)
62
Identificar los Procesos de Negocio
• Sean definidos o no, el Ingeniero de Requisitos debe identificar y entender los procesos de
negocio
• Los procesos de negocio permiten a una organización alcanzar sus metas
• La buena definición de los procesos de negocio indica la madurez del nivel de organización
63
Necesidades del Negocio y Metas
• Una meta del negocio es un objetivo a corto o largo plazo

– Una meta debe ser específica, optimista, realista y con un alcance de corto o largo plazo
– Suministra una visión, medida y compromiso hacia los objetivos
– S.M.A.R.T. se utiliza a menudo para definir las metas
• Una necesidad describe un problema u oportunidad
64
Objetivos*
Financiera
Problema 2
Clientes / Mercado
Procesos
Conocimiento / Necesidades
Aprendizaje Espacio del problema
Características Espacio de la solución
y Requsitos
de Software Producto
Texto y/o Casos de Uso
NO
FUNCIONALES
FUNCIONALES
Lenguaje
Modelado Calidad Restricciones
natural
Lenguaje
natural
Casos de prueba Desarrollo y

Arquitectur
a Modelo
de Negocio
*Basado en las 4 dimensiones de Balance Scorecard
Ejercicio
• Dé un ejemplo de requisito de calidad del servicio

• Dé un ejemplo de una suposición
• Dé un ejemplo de un stakeholder
66

67
ISO/IEC 9126
• ISO 9126 es empleado a menudo para definir caracteríticas no funcionales
– Confiabilidad
– Eficiencia
Características no
– Usabilidad
funcionales de
– Mantenibilidad
– Portabilidad
calidad
• Características funcionales también son consideradas por ISO 9126 y ya fueron

discutidas.
68
Sub-Características de ISO 9126
• Confiabilidad – incluye requisitos, falla y backup y recuperacion MTTR (Mean Time to Repair –
Tiempo Medio Para Reparar) y MTBF (Mean Time Between Failures – Tiempo Medio Entre
Fallas)
• Eficiencia – incluye desempeño, carga, esfuerzo, escalabilidad y utilización de recursos
• Usabilidad – incluye accesibilidad
• Mantenibilidad – incluye analizabilidad, cambiabilidad, estabilidad y comprobabilidad
• Portabilidad – incluye adaptabilidad, instalabilidad, intercambiabilidad, y coexistencia
69
CONTENIDO DEL CURSO
El curso está dividido en nueve capítulos de acuerdo con el programa de
estudio del IREB®
- Capítulo 9 Apoyo de herramientas (1 hora)
70
Capítulo 2 Definición de sistema y contexto (1 ¼ horas)
• 2.1 Conocer el contexto del sistema, la frontera del sistema y la frontera del
contexto
2.2 Dominar y utilizar la frontera del sistema y la frontera del contexto
71
Contexto del Proyecto
• Contexto del Proyecto es el entorno en que el proyecto existirá

• El entorno incluye
– Equipo
– Programas
– Redes
– Personas
– Organización
– Otros proyectos
72
Contexto del Sistema
Encierra todo lo que es relevante LIMITE DEL CONTEXTO
CONTEXTO
LIMITE DEL SISTEMA

1) Documentos
SISTEMA
ALCANCE
Sistema
Externo
2) Interesados
- requisitos
3) Sistemas - Funcionalidades planteadas
Funcionalidad 1 Funcionalidad 2
•Entradas Funcionalidad 3
•Actividades 4) Eventos Trazabilidad
•Roles
•Salidas
Actividad 2
5) Procesos Actividad 1
Actividad 3
73
Capítulo 2 Definición de sistema y contexto (1 ¼ horas)
• 2.1 Conocer el contexto del sistema, la frontera del sistema y la frontera del
contexto
2.2 Dominar y utilizar la frontera del sistema y la frontera del contexto
74
Sistema vs. Límites de Contexto
• Los límites del sistema definen los aspectos de qué está dentro del sistema vs.
qué es parte del entorno del sistema
• Límites de contexto identifican parte del entorno que se conecta con el sistema
• El contexto del proyecto define el contexto del proyecto específico (puede ser
un subconjunto del sistema total)
75
Alcance/Contexto son Importantes?
• Presupuestos no son válidos sin un alcance y contexto definidos
• Todo el trabajo subsecuente del proyecto dependerá de la definición de

alcance/contexto
• El alcance puede variar de un proyecto a otro

– Proyecto específico
– A través de departamentos
– A través de la organización
76
Riesgos de una Definición Inadecuada
• El crecimiento descontrolado del alcance no es posible detectarlo si el alcance no

se ha definido
• Cambios de contexto pueden impactar considerablemente el proyecto si no son

detectados y se les hace seguimiento
• Interfaces deben ser definidas y previstas
77
Zonas Grises
• Los límites del sistema y el contexto algunas veces cambian durante el proyecto por la
llamada “zona gris”
– La funcionalidad y calidad deseadas pueden cambiar

– Aspectos ambientales pueden hacerse más o menos importantes a medida que el
proyecto avanza
– Los límites de contexto pueden cambiar debido a cambios externos como pueden ser los
requisitos legales
• Los diagramas de caso de uso y diagramas de flujo de datos, ayudan a mostrar el contexto y a
identificar áreas que pueden o van a cambiar
78
Ejercicio
• Si el equipo en un proyecto está disperso geográficamente, Qué inconvenientes

esperaría encontrar?
• Si el equipo en un proyecto tiene una débil gestión del proyecto, Qué haría usted para
compensar esta debilidad?
• Si usted está ante un contrato de precio fijo para la labor de desarrollo y pruebas,
Cómo afecta esto su análisis?
79
Ejercicios Adicionales
• Por qué es importante definir el alcance de un proyecto?
• Si se establece el alcance del proyecto, pero el contexto está cambiando, Qué puede
pasarle al proyecto entre la definición y la entrega?
80
CONTENIDO DEL CURSO
81
Capítulo 3 Obtención de requisitos (1 ½ horas)
• 3.1.1 Conocer distintos tipos de fuentes de requisitos

3.1.2 Conocer el significado de las fuentes de requisitos y las consecuencias de ignorar fuentes
de requisitos
3.1.3 Conocer la información más importante de documentación de los implicados
3.1.4 Conocer los principios importantes en el trato con los implicados (derechos y obligaciones
de los implicados)
3.2.1 Dominar y utilizar el contenido e importancia del modelo de Kano
3.3.1 Conocer los factores que influyen en la selección de las técnicas de educción
3.3.2 Conocer las ventajas y desventajas de las técnicas de educción
3.3.3 Dominar y utilizar los siguientes tipos de técnicas de educción y aportar ejemplos para
cada una de ellas: técnicas de prospección, técnicas creativas, técnicas basadas en la
documentación, técnicas de observación y técnicas de soporte
82
Fuentes de Requisitos LIMITE DEL CONTEXTO
CONTEXTO
LIMITE DEL SISTEMA

1) Documentos
SISTEMA
ALCANCE
Sistema
Externo
2) Interesados
- requisitos
3) Sistemas - Funcionalidades planteadas
Funcionalidad 1 Funcionalidad 2
•Entradas Funcionalidad 3
•Actividades 4) Eventos Trazabilidad
•Roles
•Salidas
Actividad 2
5) Procesos Actividad 1
Actividad 3
83
Fuentes de Requisitos según IREB
• Personas (partes interesadas)

• Sistemas en operación (técnico, software, hardware)
• Procesos (técnicos, físicos y de negocios)
• Eventos (técnicos, físicos)
• Documentos (leyes, normas, documentos de sistema)
84
Identificar las Fuentes
• Conceptos claves
– Las partes interesadas son solo una fuente de requisitos
– Requisitos completos requiren Obtención a partir de todas las fuentes pertinentes
85
Antes de Elicitar…
• Dónde puede conseguir la información?
• Dónde quiere conseguir la información?
• De quién puede obtener información?
• Cree un plan antes de salir a elicitar!
86
Considere la Fuente
• Requisitos provienen de múltiples fuentes
• Algunas fuentes son más accesibles que otras
• Algunas fuentes son más entendibles que otras
• Omitiendo algunas de las posibles fuentes puede llevar a requisitos incompletos o

inaceptables
87
Posibles Fuentes
• Información a partir de otras formas de análisis, particularmente análisis

empresarial
• Información heredada de un sistema que va a ser remplazado

– Código
– Especificaciones
– Problemas conocidos/Actualizaciones solicitadas
• Intentos fallidos anteriormente
88
Sistemas Externos
• Impacto en otros sistemas debe ser incluido en la linea base

– Si los otros sistemas cambian, muy seguramente habrá un impacto en el nuevo sistema
definido
– Puede que no haya control sobre los otros sistemas
• Métodos para monitorear los cambios propuestos también

deben exponerse
89
Información de Entorno
• Una visión o documento de estrategia
• Estandares de la compañía o la industria, especificaciones, políticas y prácticas
• Guías de estilo y planes arquitectónicos
• Regulaciones legales
• Soluciones de la competencia
90
Y No Olvidarse del Negocio
• Fuentes para información de dominio

– Literatura
– Investigación
– Tendencias del Mercado
– Información de los competidores
• No olvide preguntarle a la gente que trabaja en el negocio todos los días
91
Ejercicio
• Usted ha estado elicitando requisitos y ha descubierto que la interpretación

del cliente/usuario de la actual operación del sistema no concuerda con la
operación actual del sistema de acuerdo en la documentación. Que debería
hacer?
• Cuáles son los métodos legal/éticos para obtener información de los

productos de la competencia?
92

de requisitos
de los implicados)
93
Encontrando las Partes Interesadas
• Conceptos clave
– Encontrar las partes interesadas
– Gestionar la relación con las partes interesadas
– Riesgos de las partes interesadas
94
Rol de las Partes Interesadas
• Las partes interesadas son una fuente de requisitos
• Las partes interesadas debe tener

– Disponibilidad de trabajar en el trabajo tanto como se necesiten
– Conocimiento del producto que va a desarrollarse
– La capacidad de tomar decisiones
• Sin estos requisitos, las partes interesadas pueden impedir o complicar el proceso
de requisitos
95
Compromiso y Gestión de Riesgo
• Las partes interesadas deben entender la importancia de su rol
• Deben estar involucrado a lo largo del proyecto
• La relación debe ser gestionada
• Los caminos de comunicación deben establecerse
• Los compromisos de tiempo deben ser entendidos
96
Probables Interesados
• Externos al equipo del proyecto • En el equipo del proyecto

– Clientes – Gestores del proyecto
– Usuarios – Arquitectos
– Leyes – Desarrolladores
– Seguridad – Probadores
– Infraestructura – Gestores de configuración
– Análisis de otros proyectos – Mercadeo/ventas
– Gestores de calidad – Ingeniero de Requsitoss de éste proyecto
97
Rastree estas Partes Interesadas
• Por cada interesado que sea una fuente de requisitos, grabe:

– Nombre
– Función (rol)
– Datos personales y de contacto
– Disponibilidad (sitio y tiempo)
– Relevancia dentro del proyecto
– Area y nivel de experiencia
– Metas e intereses dentro del proyecto
98
Responsabilidades del Ingeniero de Requisitos
- Expresarse en el mismo lenguaje que el implicado

- Familiarizarse con la materia/tema (“subject matter”)
- Crear un documento de requisitos
- Ser capaz de hacer que los resultados sean comprensibles para todos
- Comunicarse con los implicados con el debido respecto
- Suscitar ideas, presenta un conjunto de alternativas y formas de resolver problemas
- Apoyar a los implicados a suscitar temas/asuntos que hacen al sistema más simple y amigable al
usuario
- Abogar por la implementación del sistema según se ha especificado en los requisitos que reflejan
las expectativas del implicado
99
Responsabilidades del implicado
- Guiar al ingeniero de requisitos en la materia/asunto/tema (“subject matter”)

- Suministrar/aportar al ingeniero de requisitos la información respecto de los requisitos
- Enunciar los requisitos con objetivos específicos y concisos
- Decidir en plazo
- Respetar la evaluación de costes y viabilidad realizada por el ingeniero de requisitos
- Ser capaz de asignar prioridades a los requisitos
- Mantener revisiones del documento de requisitos
- Comunicar cambios relevantes de forma inmediata
- Seguir el proceso de cambio que fuera acordado con el ingeniero de requisitos
100
Lista de implicados – Estructura (ejemplo)
Información
Implicado Descripción Representante Disponibilidad Competencia
de contacto
101

de requisitos
de los implicados)
102
El modelo de Kano
• Kano agrupa los requisitos en tres categorías
– Factores básicos y estandar – requisitos que son asumidos a estar ahí

– Factores de desempeño – exigidos explicitamente
– Factores de emoción – requisitos que hacen que el sistema guste a los usuarios y
genere deseos de usarse
– El valor de cada factor varía por producto y por usuario
103

de requisitos
de los implicados)
104
Aplicar Técnicas de Obtención
• Conceptos Clave
– Cómo funciona la Obtención?
– Establecer las metas de la Obtención
– Técnicas para la Obtención de requisitos
– Ajustar la Obtención a las partes interesadas
105
Propósito de la Obtención
• Obtener las verdaderas necesidades del cliente
• Determinar los requisitos concientes, inconcientes y subconcientes.
• Lograr los mejores aportes posibles a los requisitos
• Producir requisitos completos, claros, correctos y consistentes
106
Qué es la Obtención de requisitos?
• No es un un esfuerzo aislado o compartimentado
• Métodos por los cuales se derivan y refinan los requisitos
107
Cuándo se términa?
• Cuándo tiene suficiente para iniciar la documentación?
• Cuándo se tiene una visión clara del alcance?
• Cuándo se puede decir que se ha hablado con los interesados representativos?
108
Habilidades Necesarias
• Para ser bueno elicitando requisitos, el Ingeniero de Requsitos debe tener habilidades en
– Elicitar y evaluar información

– Asimilar rápidamente nueva información
– Entrevistar
– Facilitar sesiones colaborativas
– Observar
– Resolver conflictos
– Pensamiento abstracto
– Comunicación verbal y escrita
• Es probale que durante la Obtención se aplique una combinación de todas estas

habilidades
109
Mientras se elicita…
• Trazabilidad – cada requisito debe ser trazable para los objetivos y mentas del negocio
definido
• Atributos – a medida que se identifica un requisito, sus atributos, como la prioridad

debe ser definida
• Glosario – términos deben ser identificados y definidos a lo largo del proceso
110
Tipos de Técnicas
Técnicas de prospección
- Se pregunta al implicado respecto de sus requisitos con distintos niveles de detalle
- Ejemplos:
- Entrevista o cuestionario
- Lista de comprobación de Osborn (cuestionario específico que se centra en la experiencia
adquirida con un producto)
Técnicas creativas
La creatividad rompe el molde del pensamiento convencional
- Creatividad orientada a objetivos en lugar de caos creativo
Ejemplos
- Tormenta de ideas
- Técnica de analogía: Se buscan posibles soluciones basadas en analogías a problemas encontrados
en la naturaleza con una estructura similar
- Cambio de perspectiva (1)
- Consideración de un problema desde diferentes puntos de vista
111
………Tipos de Técnicas
Técnicas basadas en la documentación
- Lectura basada en la perspectiva

- Reutilización de requisitos
Técnicas de observación
– Observación de campo
Técnicas de observación
– Aprendizaje (“apprenticing”)
Técnicas de apoyo
- Talleres de diseño de interfaz de usuario
- Tarjetas CRC
- Grabaciones: audio/video
- Modelado de casos de
- Prototipos
112
Lluvia de Ideas
• Qué es? • Por qué usarla?

– Es una estrategia para la obtención de – Para indagar en la experiencia y
ideas en la que los participantes creatividad de un grupo de interesados
producen tantas opciones o soluciones – Para obtener ideas
a un problema como sea posible en un – Para responder o dar soluciones a
determinado lapso de tiempo problemas específicos
– Produce una amplia y diversa cantidad – Ej. Cómo se puede presentar esta
de ideas rapidamente información al usuario?
113
Lluvia de Ideas
• Cómo se hace? • Quién participa?
– Defina el área de interés – Equipo del proyecto

– Defina el plazo de tiempo – Partes interesadas
– Escoja los participantes • Bueno/malo
– Comparta ideas sin evaluar – Bueno para obtener ideas
– Registre visiblemente todas las ideas rápidamente
– Cualquier idea es una buena idea – Depende de la creatividad de los
– Después de registrarlas todas, evalue participantes
con un criterio predefinido – Debe hacerse en un ambiente sin
– Condense la lista de ideas enjuiciamientos
– Califique las ideas
– Distribuya las que quedan
114
Grupos Focales
• Qué es? • Por qué usarlo?
– Provee un entorno interactivo al – Se obtiene información con calidad

grupo para pedirles ideas a cerca de – Se obtienen puntos concretos para
una oportunidad de soportar acciones específicas
producto/sistema – Se puede hacer en cualquier
– Los miembros del grupo comparten momento del ciclo de vida
sus preferencias, necesidades e – Se usa para discernir nuervos
impresiones requisitos, posicionar productos y
– El proceso es guiado por un evaluar ideas de un producto
moderador
115
Grupos Focales

– Reclute los participantes (brinde – Partes interesadas
comida!) – Ingeniero de Requsitos
– Cree grupos de 6-12 – Mercadeo
– Considere grupos homogeneos o • Bueno/malo
heterogeneos – Mucha información al instante
– Consiga un buen moderador – Se obtiene un buen entendimiento
– Cree las preguntas que van a ser de las actitudes, experiencias y
discutidas (abiertas-cerradas) deseos del grupo
– Conduzca una sesión de 1-2 horas – La gente complementa mutuamente
permaneciendo en agenda pero sus aportes
permitiendo un flujo libre – La gente se muestra reacia a
– Documente los participar o contradecir
resultados – La gente puede no ser honesta
116
Entrevistas

– Un acercamiento sistemático a la – Ayuda a construir una buena
Obtención de información de una relación con los interesados
persona o un grupo – Crea comunicación uno a uno
– Un método para hacer preguntas – Permite un fácil seguimiento y
relevantes y documentar las respuestas clarificación
– Puede usar preguntas pre-definidas
117
Entrevistas

– Defina el enfoque o meta de la – Partes interesadas
entrevista – Ingeniero de Requsitos
– Identifique los entrevistados • Bueno/Malo
– Determine que va a preguntar – Método simple y directo
(abierto o cerrado) – Permite observación de
– Organice las preguntas en orden comportamiento no verbal
lógico (general a específico) – El valor depende del
– Escuche! conocimiento del entrevistado y
– Documente y organice la la habilidad del entrevistador
información obtenida – No ayuda a crear concenso
– Verifique que los resultados – Puede resultar costoso
documentados sean correctos – Los resultados son interpretados
118
Observación
– Estudiar a la gente haciendo su – La gente algunas veces olvida algunas

trabajo en el sistema que va a ser de las labores que realiza
remplazado o mejorado – Se muestra el flujo de trabajo en los
– Se puede hacer sin hablar o usuarios
interrumpir al usuario
(pasivo/invisible) o hablandole a
usuario (activo/visible)
– Puede involuclar al anlista aún
participando en el trabajo
119
Observación

– Seleccione los usuario – Ingeniero de Requsitos
representativos – Diseñadores
– Prepare las preguntas a hacer – Espertos en factores humanos
– Gentilmente presente el proceso al • Bueno/Malo
usuario – Conocimiento práctico y realista
– Tome notas detalladas – Descubrir soluciones no
– Obtenga respuesta a sus preguntas documentadas
– Documente lo encontrado – Sólo funciona si hay un proceso o
– Proporcione una retroalimentación al sistema en curso
usuario – Puedes consumir mucho tiempo
– Combine las observaciones como – Puede ser molesto!
necesite – El trabajo tiene que ser observable y
entendible
120
Talleres de Requisitos

– Un evento enfocado atendido por – Se usa para descubrir, definir,
partes interesadas calificadas y SMEs priorizar y resolver problemas con
con el objetivo de idetificar o evaluar requisitos
requisitos – Una de las maneras más efectivas de
– Algunas veces llamado diseño de obtener requisitos de calidad
aplicación conjunta (JAD) rápidamente
– Usualmente toma de uno a varios – Promueve la confianza y
días comunicación entre las partes
– Facilitado por un moderador interesadas
121
Talleres de Requisitos
– Determine qué necesita definirse – Equipo del proyecto
– Identifique los interesades que • Bueno/Malo
deben participar – Muchos requisitos detallados en un
– Determine la agenda corto período de tiempo
– Elicite, analice y documente los – Permite la colaboración entre los
requisitos durante el taller interesados
– Resuelva los conflictos que se – Más barato que hacer muchas
presenten entrevistas
– Mantenga el encuentro profesional – Puede resultar difícil de programar
en curso – El facilitador tiene que ser bueno
– Haga preguntas y obtenga – Seleccionar el correcto número de
respuestas participantes puede ser complicado
– Concluya y documente los
resultados
122
Encuestas y Cuestionarios
• Qué es? • Por qué se usa?

– Le da a un grupo de interesados un – La información se puede obtener de una
grupo de preguntas para contestar gran cantidad de personas de manera
rápida
– Las respuestas son evaluadas y la
información utilizada para – Las respuestas pueden ser anónimas y
determinar los cambios, ser más honestas
mejoramientos y capacidades – Una ecuesta desarrollada
necesarios profesionalmente puede ayudar a
– Las encuestas utilizan preguntas remover el sesgo
abiertas y cerradas – Respuestas a preguntas abiertas pueden
proporcionar una gran cantidad de
información
123
Encuestas y Cuestionarios
– Prepare la encuesta – Mercadeo
– Seleccione el grupo objetivo a – Equipo del proyecto
encuestar – SMEs
– Escoja las víctimas – Partes interesadas
– Determine cómo distribuir y – Clientes/usuarios
recoger la encuesta • Bueno/Malo
– Decida si también va a necesitar – Preguntas cerradas son fáciles de
entrevistas cuantificar
– Determine la información – Preguntas abiertas proporcionan más
demografica necesaria información
– Fácil, rápido, corto – Tiempo efectivo
– Pruebe la encuesta – Funciona para un grupo disperso
– Conduzca la encuesta – Dificultad de escribir
– Recopile y analice los resultados – Buenas opiniones, pero pueden no
reflejar el comportamiento actual
124
Prototipos

– Un ejemplo o muestra del sistema – Ayuda a descubrir requisitos no
futuro para evaluarse por los definidos de interfarz y usabilidad
usuarios – Cambios menos costosos antes de
– Prototipo horizontal proporciona una que el desarrollo real esté en curso
visión general del interfaz con poca o – Puede desecharse, sólo para
sin funcionalidad demostración. Puede utilizarse como
– Prototipo vertical muestra una visión un modelo que evolucione y
profunda de una pieza particular de convertirse en la base para el
funcionalidad software real.
125
Prototipos

– Identifique el tipo de prototipo (para – Diseñadores
desechar o para evolucionar, vertical – Expertos en Factores Humanos
u horizontal) • Bueno/Malo
– Identifique la funcionalidad a – A los usuarios les gusta!
representar
– Un elemento simple a desechar puede
– Construya el prototipo brindar una retroalimentación valiosa
– Conduzca una revisión del prototipo – Prototipos de mayor alcance pueden
con el usuario resultar costosos y demorados de crear
– Documente lo encontrado – Los usuarios pueden crearse falsas
– Actualice los requisitos como sea expectativas del sistema final
necesario
126
Análisis de Interfaz
• Qué es? • Por qué utilizarlo?

– Define los límites del sistema y su – Define la interfaz de usuario
interacción con otros – Define las interfaces desde y hacia
– Permite la separación de requisitos sistemas externos y dispositivos
por sistema mientras se definen las – Clarifica los límites y
conexiones e intercambios de datos responsabilidades
– Provee los parámetros para la
interoperabilidad exitosa
– Ayuda a definir el glosario que abarca
múltiples sistemas
127
Análisis de Interfaz

– Identifique los interfaces necesarios – Ingeniero de Requsitoss de negocios
(un diagrama de contexto es de gran – Diseñadores de interfaz de usuario
ayuda) – Arquitectos de datos
– Para cada interfaz determine su tipo – Diseñadores de sistemas
– Para interfaces de usuario, la • Bueno/Malo
Obtención de requisitos incluirá los
modelos de uso – Alerta temprana del impacto en la
fecha de entrega
– Para las interfaces de datos, la
Obtención de requisitos requirirá – Pronta colaboración con otros sistemas
identificación de entidad y atributos o proyectos
– No proporciona mucha visión del
proceso de negocio soportado
128
Ingeniería Inversa

– El proceso de tomar un sistema – Provee mejor información que la
existente y determinar los procesos simple observación
existentes, datos y reglas utilizados – Puede examinar las limitacioines
– Generalmene resulta en un alto nivel actuales
de abstracción del sistema – Puede usarse para examinar
– Puede ser una caja negra o caja productos de terceros
blanca dependiendo del nivel de
estudio
129
Ingeniería Inversa
– Determine a qué le va a hacer – Equipo de proyecto

ingeniería inversa (puede ser un • Bueno/Malo
proceso simple o todo un sistema) – Brinda información acertada respecto a
– Evalúe costo/beneficio cómo trabaja el sistema realmente
– Determine el nivel de esfuerzo – Util cuando la documentación del
garantizado sistema está desactualizada o no está
– Desarme o “decompile” el sistema disponible
existente – Puede ser costoso y ocupar mucho
– Documente los resultados en un alto tiempo
nivel de abstracción – Puede ser restringido por leyes de
derecho de autor
– Requiere habilidades especializadas
130
Análisis de Documentos
• Quién participa?
• Cómo se hace? – Equipo de proyecto
– Evaluar la documentación existente – Expertos en la materia
(sistema y negocio) por relevancia
• Bueno/Malo
– Estudiar los materiales y encontrar la
información útil – Brinda un punto de partida
– Hacer seguimiento con preguntas a – Permite aprovecharse de los
usuarios/SMEs para confirmar el materiales existentes
entendimiento y resolver inquietudes – Brinda un manera de verificar la
completabilidad
– Se limita a una perspectiva de como
están las cosas
– La documentación puede estar
desactualizada, equivocada o
simplemente imposible de encontrar
131
Un poco más de algunos
• Cuando se usan técnicas de creatividad como la tormenta de ideas
– Considere la lluvia de ideas paradójica (pensar en todas las cosas que el producto
no debería hacer)
– Considere el cambio de perspectiva (qué pasa si usted fuera el usuario?)
– Considere la técnica de la analogía (adicionar un usuario es como aceptar una
tarjeta de crédito)
132
Un poco más de algunos
• Cuando se usan técnicas de observación

– Considere el aprendizaje (realmente aprender a hacer el trabajo)
• Cuando se usen técnicas de soporte como los talleres

– Considere usar el mapeo de ideas (diagramar palabras, ideas, tareas que estén vinculados a
la idea central)
– Considere usar fichas CRC para determinar relaciones (clase/responsabilidad/colaboración)
133
Muchas Técnicas
• Las mejores técnicas varian en

– Situación
– Tipo de requisito (funcional, no-functional)
– Nivel de detalle o refinamiento del requisito
– Voluntad de los participantes
– Conocimiento y participación de los participantes
– Restricciones del proyecto (organizacional, humano, de contenido)
• No olvide sus propias habilidades y preferencias
134
Todo el mundo dice algo
• Todas las técnicas necesitan recibir la información de los requisitos en un lenguaje

natural
• El lenguaje natural muchas veces es ambiguo y siempre interpretado por quien

escucha
• El lenguaje natural es sujeto a un “proceso transformacional”
135
CONTENIDO DEL CURSO
136
Capítulo 4 Documentación de requisitos (2 horas)
• 4.1.1 Conocer las razones principales para documentar los requisitos

4.2.1 Conocer las tres perspectivas de los requisitos funcionales
4.2.2 Conocer las ventajas y desventajas de la documentación de requisitos en lenguaje natural
4.2.3 Conocer la forma más importante de documentación de requisitos basada en modelos
4.2.4 Conocer las ventajas de la combinación de formas de documentación de requisitos
4.3.1 Conocer las ventajas de las estructuras estandarizadas de documentos
4.3.2 Conocer una estructura de documento de amplia difusión
4.3.3 Conocer los puntos importantes para una estructura estándar adaptada
4.4.1 conocer actividades que se basan en, o dependen de, los documentos de requisitos
4.5.1 Dominar y utilizar criterios de calidad para los documentos de requisitos
4.6.1 Dominar y utilizar criterios de calidad para los requisitos
4.6.2 Conocer las dos reglas de estilo más importantes para los requisitos
4.7.1 Dominar y utilizar los contenidos e importancia de un glosario
4.7.2 Dominar y utilizar las normas para gestionar el glosario
137
Alistandose para Documentar
• Conceptos clave
– Establecer el modelo de requisitos
– Asegurarse de tener los elementos adecuados
– Podemos cumplir los requisitos de la audiencia?
138
Alistandose para Documentar
• Documentar suele empezar mientras el análisis aún está en curso
• Requisitos documentados se convierten en la base del contrato entre los interesados
• El grupo de entregables debe ser acordado en

– Profundidad de la información
– Audiencia objetivo
139
Estructurar el Modelo de Requisitos
• Trabajando con los interesados, el Ingeniero de Requsitos mantiene y actualiza el

modelo de requisitos
• El modelo de requisitos se usa para

– Definir los límites de la solución
– Estructurar la definición de la solución – qué puede hacerse ahora vs luego
– Descomponer las metas en objetivos medibles
– Descomponer la lista de características para priorizar
– Descomponer las funciones en sub-procesos y actividades
140
Requisitos
• Documentar es una función de soporte en la comunicación del proyecto
• Requisitos son documentos duraderos, legalmente relevantes y complejos
• El acceso apropiado a los requisitos debe estar disponible a los interesados
141
Recuerde la Meta
• Requisitos completamente especificados!
• Requisitos completamente especificados son

– Factibles
– Implementables
– Suficientemente estables como para ser implementados
142
Recuerde las Reglas
• Cada requisito debe ser validado para asegurar

– Claridad (no ambigüedad)
– Consistencia
– El poder completar
– Exactitud
– Verificailidad (criterio de aceptación)
– Pesable (prioritización)
– Cambiabilidad
– Trazabilidad
• La validación no puede hacerse solo por quien escribe
143
Quién necesita Qué?
Clientes Probadores Gestores de Mantenedores
Proyecto
Sin ambigüedad X X X X
Consistente X X X X
Entendible X X X X
Completo X X X X
Correcto X
Verificable X
Pesable X
Modificable X
Trazable X
144
Guias de Ejecución
• Frases cortas y concisas
• Un requisito por frase, no anidar
• No mezcle requisitos con antecedentes
• Voz activa
• Terminología consistenten
• Evite generalizar (todo…) y de referencias clara
• Use “deber”, “poder” correctamente
145
Por Ser Determinado
• Algunos requisitos no pueden definirse aún
• TBD (Por Ser Determinado/To Be Defined) se usa como una referencia para el requisito
futuro
• TBDs deben completarse en algún momento!
146

147
Perspectivas
• Requisitos funcionales suelen tomar la forma de tres perspectivas

– Datos
– Comportamiento
– Función
• Se pueden usar varias formas de documentación, incluyendo

– Lenguaje Natural
– Modelos
148
Peligros Potenciales
• Lenguaje Natural
– Bueno – fácil de usar, generalmente entendible, fácil de comprender para usuarios
no-técnicos
– Débil – puede ser no-específico, las palabras pueden tener múltiples
interpretaciones, puede ser voluminoso
• Modelos
– Bueno – pueden representar información compleja en forma compacta, puede ser
fácil de revisar para llegar a la completud
– Débil – puede requerir de experticia para entender el modelo mismo, puede no ser
adecuado para lectores no-técnicos, puede requerir entrenamiento para quien
escribe, el modelo selecto puede no ser el adecuado para el proyecto/problema
149

150
Estructura de Referencia para los Requisitos
• Ventajas de usar estructuras de referencia para requisitos (como son IEEE 830-1998)
incluye
– Uso simplificado de la documentación de requisitos a lo largo del ciclo de vida (ej.,
para crear casos de prueba)
– Uso estándar a través de la organización
– Ajustes están permitidos específicamente para compañía/proyecto/aplicación
151
Usar Formatos
• Formatos ayudan al autor a crear requisitos de alta calidad
• Uso consistente de “deber”, “debería”, “será” ayuda a establecer los compromisos del
proyecto (como también lo es usar los atributos)
• Formatos de frases deberían usarse para entrenar y como un suplemento a la escritura

de buenos requisitos
152
Cinco Pasos Para el Uso de Formatos
• Determinar las obligaciones legales (si las hay)
• Determine el núcleo del requisito
• Caracterice la actividad del sistema
• Inserte los objetos específicos del requisito
• Determine las condiciones lógicas y temporales (de tiempo)
153
Lineamientos IEEE
• Conceptos clave
– Uso efectivo de los lineamientos IEEE
– Adaptarlos a sus necesidades
154
Documentos IEEE
• IEEE Std 1362-1998 – Guía para Tecnología de Información – Definición de Sistema –

Documento para Concepto de Operaciones (ConOps)
• IEEE Std 1233-1998 – IEEE Guía para Desarrollar Especificaciones de Requisitos de

Sistema
• IEEE Std 830-1998 – IEEE Práctica Recomendada para Especificaciones de Requisitos de

Software
155
IEEE 1362-1998
• El documento de concepto de operaciones (ConOps) describe las características del

sistema desde el punto de vista del usuario
• Comunica características cualitativas y cuantitativas del sistema a los interesados
156
Perfil del IEEE 1362-1998
• Página título Notas: Del prefacio debería

• Gráfico de Revisión incluir el propósito del
• Prefacio documento, alcance de las
• Lista de figuras actividades cubiertas, autor,
• Lista de tablas intención del documento y
audiencia a quien se dirige.
157
1. Alcance
Nota: El resumen del
1.1 Identificación
documento discute el
1.2 Resumen de documento
propósito y motivación
1.3 Resumen de sistema del mismo así como la
identificación de la
audiencia a quien se
dirige.
Nota: El resumen del sistema expone el propósito

del sistema identifica los promotores del proyecto y
otros interesados. Un resumen gráfico (diagrama de
contexto) se incluye normalmente aquí.
158
2. Documentos referenciados
Nota: Cualquier documento pertinente, incluyendo

versión y fecha.
159
3. Situación actual del sistema

3.1 Antecedentes, objetivos, alcance Nota: Describe el
3.2 Limitaciones y politicas operacionales sistema existente que
está siendo
3.3 Descripción del sistema o situación
actual remplazado o
mejorado o la
3.4 Modos de operación para el sistema o situación actual
situación que está
3.5 Tipos de usuarios y otro personal involucrado motivando este
3.6 Entorno de soporte proyecto.
Nota: 3.3 describe todos los aspectos del sistema en términos del usuario e incluye
elementos como entorno, capacidades, características, riesgos, desempeño, atributos de
calidad. Herramientas gráficas son usadas frecuentemente en ésta sección.
160
4. Justificación y naturaleza de los cambios Nota: Describe las

4.1 Justificación de los cambios deficiencias del
4.2 Descripción de los cambios deseados actual sistema o
situación.
4.3 Prioridades entre los cambios
4.4 Cambios considerados pero no incluidos
4.5 Suposiciones y limitaciones
Nota: 4.2 es un resumen de las capacidades nuevas o cambiadas que establecen los
elementos en 4.1.
Nota: 4.3 clasifica cada cambio como esencial, deseable u opcional (deber, debería,
podría).
161
5. Conceptos para el sistema propuesto Nota: Esta sección

5.1 Antecedentes, objectivos, alcance refleja la Sección 3.
5.2 Políticas y restricciones operacionales
5.3 Descripción del actual sistema o situación
5.4 Modos de operación del actual sistema o situación
5.5 Clases de usuario y otro personal involucrado
5.6 Entorno de soporte
Nota: Describe el sistema propuesto en una manera de alto nivel sin especificar
detalles de diseño. El nivel de detalle debería dar una explicación clara al usuario
respecto a como se van a suplir sus necesidades.
162
6. Escenarios Operacionales
Nota: Descripciones paso a paso de como el sistema

propuesto va a operar e interactuar con sus usuarios e
interfaces en un set de circunstancias definido.
163
7. Resumen de Impactos
7.1 Impactos operacionales
7.2 Impactos organizacionales
7.3 Impactos durante el desarrollo
Nota: Describe el impacto temporal y a largo plazo en usuarios, desarrolladores,

grupo de soporte y organizaciones de mantenimiento. Incluye cambios a los
procedimientos, acceso/uso de los datos, cambios a las resposabilidades, alerta de
reuniones sin fin…
164
Perfil de IEEE 1362-1998
8. Análisis del sistema propuesto

8.1 Resumen de mejoras
8.2 Desventajas y limitaciones
8.3 Alternativas y cambios considerados
Nota: Resume las mejoras (desempeño nuevo, suprimido, mejorado), cualquier

desventaja a la vista (como requisitos de entrenamiento) y todas las alternativas
mayores que fueron consideradas.
165
9. Notas
10. Apéndices
11. Glosario
Nota: Notas y apéndices se usan para detalles adicionales que ayudan a entender
pero pueden empantanar el documento.
166
IEEE Std 830-1998
• La especificación de los requisitos de software

– Ayuda a los clientes a describir qué quieren
– Ayuda al equipo del proyecto de software a entender lo que quiere el cliente
• Las mayores ventajas de un buen SRS

– Formas de acuerdo entre cliente y proveedores
– Reduce el esfuerzo de desarrollo
– Brinda la base para estimados de costo y tiempo
– Brinda la linea base para verificación y validación
167
IEEE Std 1233-1998
• Esta especificación describe como desarrollar las especificaciones de los requisitos

del sistema
• IEEE Std 830-1998 da los formatos/plantillas actuales para el documento SRS
• IEEE Std 1233-1998 distingue entre la especificación de los requisitos de sistema que
describen lo que el sistema debe hacer, y los requisitos de proceso que explican
como construir el sistema
• La meta del 1233 es la de brindar una descrpción de caja negra de que debería
hacer el sistema
168
Identifique los Crear el SRS
Requisitos
Aplicar técnicas de Organice los
Obtención, educación Requisitos
mutua y definición
conjunta Agrupamientos
lógicos, asignación
de atributos, mapeo
de relaciones
Construya
requisitos bien
formados Presente SRS
Necesario, conciso, Considere la
definitivo, audiencia, use texto
verificable y/o modelos
169
Formatos SRS
• IEEE 1233 contiene múltiples formatos SRS del mismo modo que IEEE 830
• Vamos a ver el formato IEEE 830
170
IEEE Std 830-1998
• SRS debe abordar

– Funcionalidad
– Interfaces externas
– Desempeño
– Atributos (características de cualidad)
– Cualquier restriccion de diseño basada en la implementación seleccionada
• El SRS no debería especificar un diseño en particular
171
Un Buen SRS Debería Ser…
• Correcto – todo lo dicho se debe cumplir
• Sin ambigüedad– sólo una interpretación

– Dificultades del lenguaje natural se evitan algunas veces usando lenguajes de especificación
de requisitos o herramientas de representación
– Estos no son necesariamente más entendibles!
• Completo – todos los requisitos cubiertos y documentados

– Todas las interfaces abordadas
– Todas las figuras, tablas y diagramas marcados
– Sin asuntos por determinar
• Consistente – con sigo mismo y con otros documentos

• Priorizado – ordenado por estabilidad del requisito o necesidad del cliente
• Verificable – un porceso esta definido para comprobar que el requisito implementado
• Modificable y extendible – organizado, sin redundancia y que sirva de base de otros
• Trazable – origen claro, derivaciones claras
172
1. Introducción
1.1 Propósito
Nota: 1.1 explica el
1.2 Alcance propósito y audiencia
1.3 Definiciones, acrónimos y abreviaciones objetivo.
1.4 Referencias – fecha, versión, localización
1.5 Vista general
Nota: 1.2 identifica los productos a producir, que van y que no van a hacer. Esta sección
también describe los beneficios, objetivos, metas y aplicación del software que está
produciendo.
Nota: 1.5 explica la organización del resto del SRS.
173
2. Descripción general
2.1 Perspectiva del producto

Nota: 2.1 Esta sección discute como el produco se relaciona con otros productos o componentes.
Incluye las sub-secciones de los interfaces de sistema, de usuario (presentaciones e interacciones de
usuario), de equipos, de software, de comunicaciones, restricciones de memoria, requisitos
operacionales y cualquier información específica del sitio.
2.2 Funciones del Producto
Nota: 2.2 es un resumen de alto nivel de las principales funciones que el software va a brindar. Esto se
muestra algunas veces en forma gráfica. Establece el contexto para los requisitos explicados en la
Sección 3.
174
Perfil de IEEE 830-1998
2. Descripción general
2.3 Características del usuario
2.4 Restricciones
Nota: 2.4 discuten cualquier limitación de las opciones del desarrollador como son
políticas regulatorias, limitaciones de equipamento, protocolos, requisitos de
confiabilidad, consideraciones de seguridad y aseguramiento, y otros.
2.5 Suposiciones y dependencias

2.6 Cálculo proporcional de los requisitos
Nota: 2.6 es usa para indicar cualquier requisito que pueda ser diferido a entregas
posteriores
175
3. Requisitos específicos
Nota: Sección 3 es el nucleo del documento SRS. El objeto es declarar cada requisito al
nivel de detalle necesario para el diseño, implementación, prueba y trazabilidad de cada
uno. Cada requisito debería incluir la entrada, salida y proceso que ocurrirá en respuesta a
las entradas para lograr las salidas.
176
3.1 Interfaces Externas
Nota: 3.1 incluye todas las entradas y salidas del sistema de software. Debería trabajar con
y sin contradecir la información de la sección 2 de éste documento. La información podría
incluir la fuente de la entrada, destino de la salida, medidas, rangos, tiempo, formatos y
mensajes.
3.2 Funciones
Nota: 3.2 describe la secuencia exacta de las operaciones a realizar en las entradas y la
creación de salidas, incluyendo las revisiones de validación, secuencia de operaciones,
manejo de error, secuenciamiento, conversiones, y cualquier parametrización. Elementos en
esta sección se describen como un “deber”.
177
3.3 Requisitos de desempeño
Nota: 3.3 incluye medidas para requisitos estáticos (capacidad) y dinámicos (desempeño).
Cada requisito debe ser medible.
3.4 Requisitos de base de datos lógicos
Nota: 3.4 describe el tipo de información, los entes de datos y sus relaciones, quién puede
acceder a qué, frecuencia de uso, requisitos de retención y cualquier restriccion de
integridad.
3.5 Restricciones de Diseño
Nota: 3.5 resalta cualquier restriccion que podría ser impuesta por normas, regulaciones,
prácticas organizacionales, auditorías y limitaciones similares.
178
3.6 Atributos del sistema de software
3.6.1 Confiabilidad
3.6.2 Disponibilidad
3.6.3 Seguridad
3.6.4 Mantenibilidad
3.6.5 Portabilidad
179
3.7 Organizar los requisitos específicos
Nota: 3.7 explica las maneras posibles de organizar los requisitos, incluyendo organización por
modo de operación del sistema, clase de usuario, objetos, caracteristicas, estímulos y
respuesta, y jerarquía funcional. Cualquiera de estas alternativas de organización pueden
requerir el uso de un requisito básico de disposición.
3.8 Comentarios adicionales
Nota: Dependiendo de la organización recogida por la sección 3.7, puede ser necesario
explicar cuáles técnicas organizacionales, o combinaciones, son utilizadas y por qué. La
técnica utilizada puede dictar las herramientas y notacones usadas también, por ejemplo,
organizar por modo puede indicar el uso de diagramas de estado.
Usar Formatos IEEE
• La mayoría de las organizaciones usan formatos como guías y no para adherirse de

manera estricta
• Cualquier formato seleccionado, lo que se quiere es que exista la consistencia a través

de los proyectos
• Recuerde, el contenido importa más que el formato!
181
Ejercicio
• Por cada uno de los formatos IEEE discutidos, compare las fortalezas y debilidades con
la documentación que su compañía actualmente usa.
182

183
Uso Común
• Documentos de requisitos cumplen varios usos

– Planeación
– Diseño arquitectónico
– Implementación (generación de código)
– Pruebas
– Cambio de gestion
– Uso y mantenimiento del sistema
– Gestión del contrato
• Cuando considere los formatos estandar, considere todos los usos
184
Necesidades
Características
y Requsitos
de Software
Texto y/o Casos de Uso
NO
FUNCIONALES
FUNCIONALES
Lenguaje
Modelado Calidad Restricciones
natural
Lenguaje
natural
Casos de prueba Desarrollo y

Arquitectur
a Modelo
de Negocio
*Basado en las 4 dimensiones de Balance Scorecard 185


186
Criterios de Calidad para los Documentos
• Ausencia de Ambiguedad y Consistencia

• Escritura Clara
• Capacidad de ser modificado y capacidad de ser ampliado
• Completud del documento
• Trazabilidad
187

188
Criterios de Calidad de los Requisitos
• - Consensuado
• - Evaluado
• - No ambiguo
• - Válido y actualizado
• - Correcto
• - Consistente
• - Verificable
• - Realizable
• - Trazable
• - Completo
• - Comprensible.
Además de estos criterios de calidad, existen dos reglas básicas de estilo para los requisitos
expresados en lenguaje natural que ayudan a su legibilidad:
• - Frases y párrafos cortos
• - Sólo un requisito por frase
189
Los Requisitos por Sí Mismos
• Requisitos deben ser declarados en términos de

– Capacidades – qué debería hacer
– Condiciones – atributos cualitativos o cuantitativos
– Restricciones – limitaciones conocidas
• Ejemplo de un sistema de tren de alta velocidad:

– Capacidad – mover gente entre San Diego y San Francisco
– Condición – Velocidad crucero de 90 mph
– Restricción – Máxima velocidad 110 mph
190

191
Preparar el Glosario
• Conceptos clave
– Qué va en el glosario?
– Mantenerse actualizado a lo largo del proyecto
192
Qué es un Glosario?
• El glosario del proyecto

– Hace la documentación de los requisitos más entendible
– Define términos sin ambigüedad
– Reduce la redundancia
– Se hace la definición definitiva de los términos
• Los glosarios de proyecto algunas veces se comparte con familias de proyectos
193
Un Buen Glosario…
• Explica el origen de los términos que • Contiene los términos definidos que
contiene deben usarse durante el proyecto
• Es generalmente accesible a los • Tiene reglas para mantener la
interesados información
• Se orienta hacia las partes interesadas • Es convenido por los interesados
que van a usarlo • Contiene términos definidos de
• Se maneja centralizadamente manera consistente
• Se inicia desde el comienzo del proyecto
y se mantiene a lo largo de su duración
194
Qué va en el Glosario?
• Cualquier término que potencialmente pudiera ser ambiguo para los

interesados
• Términos que son pertinentes al proyecto y el dominio de la aplicación
• Acrónimos y abreviaciones
El glosario no intenta documentar todos los posibles términos usados en el

proyecto – eso puede no ser un buen uso del tiempo!
195
Terminologia adicional del Glosario
• Homónimos (suena y se escribe del mismo modo, pero con diferente

significado, ej., nada –de nadar- y nada –de ninguno-)
• Sinónimos (dos palabras diferentes con el mismo significado)
• Póngalos en el glosario si pueden llegar a causar confusión en el proyecto
196
CONTENIDO DEL CURSO
El curso está dividido en nueve capítulos de acuerdo con el programa de estudio
del IREB®
197
Capítulo 5 Documentación de Requisitos en lenguaje natural
(1hora)
• 5.1 Dominar y utilizar los cinco procesos de transformación en la percepción y

redacción de requisitos en lenguaje natural, así como sus consecuencias en la
formulación de requisitos
5.2 Dominar y utilizar los cinco pasos para la formulación de requisitos utilizando
una plantilla de requisitos
198
Los 5 procesos de transformación en la percepción y redacción de
requisitos en lenguaje natural
– 1 Nominalización: Por medio de la nominalización, un proceso (algunas veces duradero) se

convierte en un evento (singular). Toda la información necesaria para describir de manera
adecuada el proceso se pierde. La palabra de proceso transmitir se convierte en transmisión.
La tendencia es a complicar la estructura de la frase
• Cambiar un verbo a nombre (como fallar a falla): “En caso de falla de un sistema, la re
inicialización del sistema debería ser realizada”. Los términos falla del sistema y
reinicializar, cada uno describen qué debería ser analizado de manera más precisa.
199
– 2 Nombres sin índice de referencia

• Una frase puede no ser clara como a quién o qué se refiere (el sistema necesita hablarle
a la base de datos antes de apagarse)
• Usar indexación remueve cualquier ambigüedad (el sistema necesita 1 hablarle a la base
de datos antes de que este se apague)
• Ejemplos de términos que contienen nombres especificados incompletamente son el usuario, el

controlador, el sistema, el mensaje, los datos, o la función.
200
– 3 Cuantificadores Universales
• Los Cuantificadores universales especifican cantidades o frecuencias. Agrupan un set de
objetos y hacen una afirmación a cerca del comportamiento de este set. Cuando se usan
cuantificadores universales, existe el riesgo de que el comportamiento o propiedad
especificada no aplique a todos los objetos dentro del set especificado. Los involucrados
tienden a agrupar objetos, aun algunos de estos objetos podrían ser casos especiales o
excepciones, donde el comportamiento especificado no aplica a todos los objetos de un grupo.
• Debe verificarse si un comportamiento específico realmente aplica a todos los objetos
resumidos a través de los cuantificadores. Cuantificadores universales pueden ser fácilmente
identificados a través de palabras como nunca, siempre, no, ninguno, cada uno, todos,
algunos, o nada.
• Algunas veces “todo” no significa realmente “todo”
201
– 4 Condiciones especificadas de manera incompleta
• Ejemplo:
El sistema de restaurante debería ofrecer todas las bebidas a un invitado registrado mayor de 20
años.
• Al menos un aspecto permanece sin especificar en el ejemplo anterior. Qué bebidas deberían
ofrecerse a un invitado que tiene 20 años o menos?
• Aclarando esta pregunta puede llevar a extender los requisitos como sigue:
El sistema de restaurante debería ofrecer:
-Todas las bebidas libres de alcohol a cualquier usuario registrado menor de 21 años
-Todas las bebidas, incluyendo las que contienen alcohol, a cualquier usuario mayor de 20 años.
202
– 5 Palabras de proceso (verbos) especificadas de manera incompleta
• Algunos verbos de proceso requieren más de un nombre para estar completamente
especificados.
El verbo transmitir, por ejemplo, requiere al menos tres suplementos para ser considerado
completo:
– Qué se transmite,
– De dónde se transmite
– A dónde se transmite.
– El uso de procesos especificados de manera incompleta puede ser evitado al máximo y
llevado al mínimo, si los requisitos son formulados usando voz activa en lugar de voz
pasiva.
• Ejemplo : requisitos usando voz pasiva: Para un usuario acceder al sistema , se ingresa la
información.
no es claro quién ingresa la información de acceso. Tampoco es claro dónde y cómo se hace. El
mismo requerimiento usando voz activa podría ser como sigue:
• Ejemplo: Requerimiento usando voz activa: El sistema debe permitir al usuario ingresar su
nombre y clave de acceso usando el teclado del terminal
203
Capítulo 5 Documentación en lenguaje natural (1hora)
• 5.1 Dominar y utilizar los cinco procesos de transformación en la percepción y

redacción de requisitos en lenguaje natural, así como sus consecuencias en la
formulación de requisitos
5.2 Dominar y utilizar los cinco pasos para la formulación de requisitos utilizando
una plantilla de requisitos
204
Los Cinco Pasos Para el Uso de Formatos:
1. Determinar las obligaciones legales (si las hay)
2. Determine el núcleo del requisito
3. Caracterizar la actividad del sistema
4. Insertar los objetos específicos del requisito
5. Determinar las condiciones lógicas y temporales (de tiempo)
205
Paso 1 Determinar la Obligatoriedad
• El establecimiento de la obligatoriedad a través del uso de los verbos. Por ejemplo:

• deberá ,
• debería,
• Será
• Nota: Si la obligatoriedad cambia, el requisito también cambia.
• El uso de atributos es otra posibilidad para documentar la obligatoriedad del requisito.

Se obtendrán mejores resultados sin hacer obligatorio el uso de la plantilla, sino formando a los
ingenieros de requisitos en el método y tratamiento de las plantillas de requisitos como
herramienta complementaria.
206
Paso 2 Establecer el núcleo del requisito
• El núcleo para cada requisito es la funcionalidad que este especifica. (e.g., imprimir, salvar, pegar
o calcular). Esta funcionalidad se refiere al proceso.
• Procesos son actividades y pueden ser descritas únicamente usando verbos. El proceso que
describe el comportamiento del sistema por medio de un requisito va a ser descrito en el paso 2.
• Como las palabras de proceso determinan semántica, estas deben ser definidas tan claramente
como sea posible y ser usadas de manera tan consistente como sea posible
207
Paso 3 Caracterizar la actividad del sistema
• Para requisitos funcionales, la actividad del sistema puede ser clarificada como uno de los tres
tipos relevantes:
– Sistema de actividad autónomo: el sistema desempeña el proceso autónomamente.
– Interacción con usuario: El sistema brinda el proceso como un servicio al usuario.
– requisitos de interfaz: el sistema realiza un proceso dependiendo de una tercera parte (e.g.,
otro sistema). El sistema es pasivo y espera por un evento externo.
• En el paso 3, cualquier tipo de actividad del sistema que sea especificada por un requisito del
sistema es documentado usando exactamente una de las tres plantillas de requisitos. Estas
plantillas de requisitos son descritas en mayor detalle en las siguientes secciones.
208
…….Paso 3 Caracterizar la actividad del sistema
• Después de realizar los pasos del 1 al 3, la estructura del requisito se ha desarrollado (vea fig. 5-2).
Las palabras escritas en los paréntesis deben remplazarse de manera acorde.
• En este ejemplo existen varias alternativas dependiendo de si el sistema hace, hace para un
tercero o es capaz de hacer.
209
Paso 4 Insertar los objetos específicos del requisito
• Algunos verbos de proceso requieren uno o más objetos adicionales que deben ser considerados
completos
• En el paso 4, objetos potencialmente perdidos y suplementos de objetos (adverbios) son
identificados y añadidos al requisito. Por ejemplo, la plantilla de requisitos para el verbo de
proceso imprimir es complementado por la información de qué se imprime y dónde se imprime
210
Paso 5 Determinar las condiciones lógicas y temporales (de tiempo)
• Para diferenciar fácilmente entre condiciones lógicas y temporales, escogemos la conjunción

temporal “tan pronto como” para condiciones temporales y la conjunción condicional “si” para
condiciones lógicas.
• La conjunción “cuando” no deja claro si es una condición lógica o temporal que se describe, y
debería entonces ser evitada.
• En el paso 5, requisitos de calidad que describen las condiciones bajo las cuales un requisito se
cumple, se adicionan al principio del requisito como una cláusula subordinada.
211
CONTENIDO DEL CURSO
212
Capítulo 6 Documentación basada en modelos (5 horas)
• 6.1.1 Conocer el término modelo y las propiedades de los mismos

6.1.2 Conocer los elementos de definición de un lenguaje de modelado conceptual
6.1.3 Conocer las ventajas de los modelos de requisitos
6.2.1 Conocer la importancia de los objetivos en ingeniería de requisitos
6.2.2 Conocer los dos tipos de descomposición de objetivos
6.2.3 Dominar y utilizar el modelado de objetivos en forma de árboles Y/O
6.3.1 Dominar y utilizar los diagramas de casos de uso
6.3.2 Dominar y utilizar las especificaciones de casos de uso
6.4.1 Conocer las tres perspectivas de los requisitos
6.5.1 Conocer el foco de la perspectiva de datos sobre requisitos
6.5.2 Dominar y utilizar diagramas de entidad-relación y diagramas UML de clases
6.6.1 Conocer el foco de la perspectiva funcional de requisitos
6.6.2 Dominar y utilizar diagramas de flujo de datos y diagramas UML de actividad
6.7.1 Conocer el punto de vista del comportamiento de requisitos
6.7.2 Dominar y utilizar diagramas UML de estado
213
El término modelo y las propiedades de los mismos
• El uso de modelos facilita la comprensión selectiva de la información de los hechos y sus

relaciones, así como su registro de forma más rápida y documentación de forma no ambigua.
• Un modelo es una abstracción de una realidad existente o de una realidad nueva que se pretende
crear.
• Los modelos de requisitos son modelos conceptuales que definen los requisitos del sistema que
se va a desarrollar.
• Modelos permiten explicar de manera concisa soluciones complejas
• Proveer un método de simplificación para permitir una comprensión más fácil
• Algunas herramientas de modelado ayudan con el eventual diseño de la solución
• Muchos tipos de modelo están disponible, algunos son más fácil de aprender que otros
214
Los elementos de definición de un lenguaje de modelado conceptual
• Los modelos tienen los siguientes elementos:
• Un lenguaje de modelaje se define por su sintaxis y semántica:

– Sintaxis: la sintaxis de un lenguaje de modelaje define los elementos de modelaje que se van
a usar y especifica las combinaciones válidas entre ellos.
– Semántica: la semántica define el significado de los elementos individuales de modelaje y
sirve entonces como una base para la interpretación de los modelos del respectivo lenguaje
de modelación.
• Lenguajes conceptuales de modelamiento se pueden clasificar como:

– formal,
– informal, y
– semi-formal,
El grado de formalización de un lenguaje de modelación depende de la magnitud de definiciones
formales (e.g., cálculo matemático) que definen la sintaxis y la semántica.
215
Características de los lenguajes de modelado conceptual
• Los modelos tienen tres características importantes:
– - Característica de representación: los modelos representan la realidad

– - Característica de reducción: los modelos reducen la realidad representada
– - Característica pragmática: los modelos se desarrollan con un propósito específico.
216
Las ventajas de los modelos de requisitos
• La documentación de los requisitos en términos de modelos conceptuales aporta, en

contraste a la documentación en lenguaje natural, las siguientes ventajas (entre otras):
– - La información presentada en forma de imágenes de entiende y memoriza con mayor

rapidez
– - Los modelos de requisitos permiten un modelado orientado de una perspectiva de los
requisitos
– - Al definir un lenguaje de modelado para un propósitos concreto, se puede especificar una
abstracción apropiada de la realidad.
La combinación de lenguaje natural y modelos de requisitos aporta las ventajas de ambos

tipos de documentación
217
3 Tipos de de requisitos a modelar
• 3 tipos de requisitos son documentados independientemente y usados en conjunción:
– Objetivos describen intenciones de involucrados o grupos de involucrados. Objetivos pueden

entrar en conflicto el uno con el otro.
– Casos de uso y escenarios documentan secuencias ejemplares de uso del sistema.

Escenarios están agrupados juntos en casos de uso.
– requisitos de sistema (generalmente referidos como requisitos) describen funciones

detalladas y calidades que el sistema a desarrollar debe tener o implementar. Además,
requisitos del sistema brindan una información precisa y completa que sirve de entrada para
pasos de desarrollo subsecuente.
218

219
La importancia de los objetivos en ingeniería de requisitos
• Un objetivo es la descripción intencional de una propiedad característica, deseada por

un implicado, del sistema a desarrollar o del proyecto de desarrollo asociado.
• Los objetivos pueden ser documentados en lenguaje natural o en forma de modelos.
220
Los dos tipos de descomposición de objetivos
• Una parte integrante de la documentación de objetivos es la descripción de relaciones

de refinamiento (relaciones de descomposición) entre objetivos superiores y
subordinados. A este respecto se distinguen dos tipos de descomposición:
– - “Descomposición de tipo Y” (se deben alcanzar todos los sub-objetivos para cumplir el
objetivo superior – llamado súper objetivo).
– - “Descomposición tipo O” (se debe cumplir al menos uno de los sub-objetivos para cumplir
el súper objetivo).
Estas relaciones de descomposición entre objetivos se modelan frecuentemente en la forma de

árboles Y/O
221
El modelado de objetivos en forma de árboles Y/O
• Usando árboles Y/O, se pueden distinguir dos tipos de descomposición de relaciones.
Con respecto a las relaciones de descomposición, uno puede diferenciar entre descomposición Y y
descomposición O. en caso de descomposición Y, cada sub-objetivo debe cumplirse para que el súper
objetivo (la raíz) se cumpla. De otro lado, en descomposición O, se necesita al menos uno de los sub
objetivos para dar cumplimiento al súper objetivo
222
Ejemplo:
• El objetivo “navegación confortable a destino” se refina en tres sub-objetivos:

– “cálculo dinámico de ruta con respecto a congestión de tráfico”,
– “entrada de destino confortable”, y
– “guía de ruta confortable” vía descomposición Y.
Esto muestra que todos los tres sub objetivos se deben cumplir para considerar satisfecho el
súper objetivo.
El sub objetivo “cálculo de ruta dinámica con respecto a congestión de tráfico” se define por dos
sub objetivos “entrada manual de condiciones de tráfico” y “actualización automática de datos
de tráfico” el tipo de relación de descomposición muestra que solo uno de los dos sub objetivos
se debe cumplir para considerar cumplido del súper objetivo.
223

224
Casos de uso
• Los Casos de uso fueron propuestos primero en [Jacobson et al. 1992] como un
método para documentar las funcionalidades de un sistema existente o planeado
basados en modelos simples. La aproximación de caso de uso se basa en dos
conceptos que se usan en conjunción entre sí:
• Diagramas de casos de uso

• Especificaciones de casos de uso
225
Qué es el modelado de casos de uso
• Es un procedimiento sistemático para formular problemas de ingeniería de

negocios, ingeniería de software o ingeniería de componentes.
• Define un sistema a partir de cómo se usa.
• Un caso de uso describe una forma particular de usar un sistema. La

combinación de todos los casos de uso describe un sistema completamente.
• La combinación de los casos de uso y actores de un sistema forman su modelo de

casos de uso.
• El modelo de casos de uso está compuesto por una combinación de símbolos de

UML y texto narrativo.
226
Por qué modelar casos de uso
• Los casos de uso representan los requisitos del sistema de una forma que puede ser
fácilmente entendido por cualquiera de los diferentes interesados de un proyecto.
• Al estar los requisitos de un sistema modelados, las adiciones o cambios de

funcionalidad se pueden hacer fácilmente a los modelos, lo que facilita su
entendimiento y medición de impacto.
227
Actor
• Es una entidad que interactúa con el sistema con el

propósito de completar una tarea.
• Los actores delimitan la frontera del Sistema. Son las

personas o sistemas externos quienes interactúan
directamente con éste.
228
¿Para qué definir los Actores de un Sistema?
• Los roles que juegan los actores proveen una perspectiva sobre por qué un caso de uso
se necesita y cuál debe ser su resultado.
• El comportamiento y las responsabilidades de un actor ante el sistema ejercen una

gran influencia en la definición de los casos de uso.
• Diferencias sutiles en el rol ante un mismo caso de uso del sistema determinan la
necesidad de identificar variaciones en la descripción de la interacción entre el actor y
el sistema.
• La identificación de los actores ayuda a refinar el contexto del sistema.
229
Fuentes de Identificación de los Actores
• Diagramas de Contexto
• Análisis de los interesados en un sistema
• Entrevistas con usuarios
• Documentación existente sobre los sistemas y los procesos de negocio actuales.
230
¿Cómo Identificar los Actores?
• Siempre que hay una interacción (intercambio de mensajes) entre el sistema y

una persona o un sistema externo, una abstracción de esta persona o sistema
define un actor del sistema.
• El mismo usuario puede jugar varios roles en el sistema y por tanto requiere
varias abstracciones (actores).
• Diferentes personas que usan el sistema de la misma forma se deben abstraer

como un solo actor.
231
¿Cómo Identificar los Actores?
• Realizar las siguientes preguntas:
– ¿Quiénes o qué inician eventos con el sistema?

– ¿Quiénes proveen, utilizan o eliminan información?
– ¿Quiénes soportan y mantienen el sistema?
– ¿A quiénes les interesa cierto requerimiento?
– ¿Con qué otros Sistemas interactúa?
– ¿Existen algún dispositivo de hardware o software adicional que interactue
con el sistema?
– Si ocurre un evento dentro del sistema ¿Quién debería ser informado?
232
¿Cómo Describir los Actores?
• El actor se describe con un nombre y una breve descripción.
• El nombre debe ser un sustantivo singular que represente el rol que el actor juega
en el sistema.
• La breve descripción debe dar una explicación sobre el rol del actor en el sistema.
– Nombre: estudiante
– Descripción: cualquier estudiante activo de la universidad que tiene la
posibilidad de inscribirse a los cursos ofrecidos para el semestre actual.
233
Guías de Calidad para los Actores
• Cada actor debe participar por lo menos en un Caso de Uso.
• Generalmente un rol (Actor) puede ser desempeñado por dos o mas personas.
• Evitar la definición excesiva de Actores. Los actores que jueguen roles similares
pueden unirse en uno solo.
• Usar nombres intuitivos. TODOS los interesados en un proyecto deben poder

entender los nombres de los Actores.
234
Caso de Uso
• Es la descripción de una secuencia de acciones,
incluyendo sus variantes, que llevan a un
resultado observable y de valor para un actor.
• Un caso de uso describe una meta y todas las

cosas que pueden pasar durante el tiempo que el
usuario trata de alcanzar la meta.
• En conjunto, los Casos de Uso describen

completamente la funcionalidad del sistema.
235
Ciclo de vida de un Caso de Uso
Solicitar Crédito
Identificado
• Breve descripción: Este Caso de Uso permite que un

usuario autorizado del Banco solicite una línea de crédito
Breve en un producto previamente determinado.
Descripción
• Esquema:
– Flujos de eventos.
Esquema • Flujos Básicos
• Subflujos
• Flujos alternos
Detallado
• Detallado:
– Detallar flujos de eventos
– requisitos especiales
– Pre-Condiciones y Post-Condiciones
236
Utilidad de los casos de Uso
• Los Casos de Uso son la base para todo el proceso de desarrollo.
• Se describen utilizando un lenguaje común entre el Cliente/Usuario y los

Desarrolladores.
• Al Cliente/Usuario le sirve para entender los servicios que el sistema le presta

para desarrollar una actividad específica.
• A los desarrolladores les facilita el descubrimiento de Clases y Objetos.
• Base para el análisis y diseño (realizaciones).
237
Utilidad de los casos de Uso
• Base para identificar casos y procedimientos de prueba.
• Información estructural para los manuales de Usuario.
• Base para definir las iteraciones del proyecto y por lo tanto su administración y
monitoreo.
• Cada caso de uso es un MICRO-PROYECTO cuyo alcance y criterio de

finalización está perfectamente definido y puede ser verificado por
CUALQUIER interesado en el proyecto.
238
¿Cómo Identificar Casos de Uso?
• Una vez identificados los actores, debemos preguntarnos qué metas requiere cumplir
cada actor al utilizar el sistema. Cada meta que defina un valor observable
corresponde a un caso de uso.
• Sesiones de trabajo en el sistema que se puedan derivar directamente de las

actividades dentro de un proceso de negocios.
239
¿Cómo Identificar Casos de Uso?
• ¿Qué tareas realiza cada actor?
• ¿Qué soporte y mantenimiento requiere el sistema?
• ¿Debe un actor informar o ser informado de un hecho importante?
240
Breve Descripción de los Casos de Uso
• El nombre de un caso de uso debe reflejar una meta que el actor cumple al usar el
sistema.
• Normalmente comienza con un verbo en infinitivo y se complementa con un

sustantivo sobre el que se aplica la acción.
• La identificación de cada caso de uso se debe acompañar de una breve descripción

que debe reflejar el propósito del caso de uso en el sistema.
241
Ejemplo de Identificación de Casos de Uso
Sistema de Procesamiento de Créditos
Solicitar un crédito
Solicitante
Chequear el estado de una

solicitud Analista
Entregar Información
adicional para el crédito
Aceptar el crédito
242
Relaciones entre Actores y Casos de Uso
• Entre un actor y sus caso de uso hay una relación de “asociación”.
• Semánticamente este tipo de asociación representa una “comunicación” entre el actor

y el sistema.
• La dirección de la asociación indica quién inicia la interacción.
243
Ejemplo
Sistema de Procesamiento de Créditos
Solicitar un crédito
Chequear el estado de una

solicitud
Solicitante
Solicitar información Analista

Entregar Información
Aceptar el crédito
244
Estructuración del Modelo de Casos de Uso
• Facilitan la documentación y la lectura de los Casos de Uso, y el entendimiento de los

requisitos
• La estructuración se realiza una vez el modelo de Casos de Uso se encuentra estable
• Necesaria para sistemas grandes
• Clarifica el modelo
• Reduce la complejidad
245
Estructuración del Modelo de Casos de Uso
• Inclusión
• Extensión
• Generalización de Casos de Uso
• Generalización de Actores
• Paquetes de Casos de Uso
246
Inclusión
• Los flujos de dos o más Casos de Uso coinciden en alguna secuencia de pasos
(subflujo)
• Se crea un nuevo Caso de Uso (abstracto) que corresponde al subflujo común
• Los casos de Uso hacen referencia al caso de Uso abstracto que incluyen
• El Caso de Uso abstracto no hace referencia a los Casos de Uso que lo incluyen
• La especificación de los Casos de Uso es incompleta si no se tiene en cuenta el Caso de

Uso abstracto
247
Inclusión
<<include>>
Caso de Uso A Caso de Uso B Caso de Uso A
<<include>>
Caso de Uso C
Caso de Uso B
248
Ejemplo
Sistema de audioconsulta en un Banco
<<include>>
Consultar saldo
<<include>>
Ingresar cuenta
y clave
Pagar servicios
249
Extensión
• Comportamientos complejos, opcionales o de excepción, que ocurren en

un punto específico del flujo (denominado Punto de extensión), bajo
condiciones particulares.
• Adiciona comportamiento al Caso de Uso que se está extendiendo.
• Se crea un Caso de Uso abstracto
• La especificación del Caso de Uso abstracto hace referencia al Caso de

Uso que se está extendiendo
• La especificación del Caso de Uso extendido no necesariamente hace

referencia a sus extensiones. Es completa sin tenerlos en cuenta
250
Ejemplo
<<extend>>
Realizar llamada
telefónica
Autorizar
llamada
Por cobrar
251
Generalización de Casos de Uso
• Un mismo Caso de Uso puede ser implementado de diversas formas
• Todas las implementaciones deben ofrecer los mismos servicios (comportamiento

observable) al actor
• El Caso de Uso general es un Caso de Uso abstracto
252
Ejemplo
Administrar Tabla
Administrar Países Administrar Ciudades Administrar Productos
253
Generalización de Actores
• Si dos (o mas) actores diferentes cumplen el mismo papel en un Caso de Uso, se crea
un Actor abstracto que los generaliza
• Asignar al nuevo Actor un nombre que se identifique claramente con lo que éste
realiza
254
Ejemplo
Supervisor Verificar cuadre

Verificar cuadre Revisor de caja
de caja de caja
Auditor
Auditor
Supervisor
255
Ejemplo
Prospecto Agente de
Afiliaciones
Verificar Tarjeta de Crédito
<<include>>
<<extend>>
<<extend>>
Solicitar Afiliación Revisar Cola de Solicitudes Revisar Solicitud Activar/Rechazar Afiliación
<<include>>
Configurar Tabla de Ciudades

Enviar Correo Electrónico
Configurar Tabla de Video Tiendas
Administrador del
Sistema
Configurar Marcas de Tarjetas de

Crédito
Configurar Motivos de Rechazo
256
Paquetes de Casos de Uso
• El concepto de paquete aplica en general para todos los diagramas en UML
• Reduce la complejidad
• Define fronteras
• Mejora la comprensión
• ¿Cómo agrupar? Está íntimamente ligado al concepto de modularización (Más

exactamente, al de BUENA modularización)
257
Buena modularización
• La modularización arbitraria puede ser peor a veces que la ausencia de modularización

(Grady Booch)
• Fuerte cohesión interna (agrupar abstracciones que guarden relación lógica)
• Acoplamiento débil (minimizar las dependencias entre módulos)
• Evitar dependencias circulares entre módulos (directas e indirectas)
258
Guías de modularización Casos de Uso
• Tener en cuenta la estructura propia del negocio. Un paquete de Casos de Uso puede
corresponder a un Proceso de Negocios.
• Agrupar en un paquete los Casos de Uso de propósito general, aún si son abstractos
(Ejemplo: Localizar cliente por nombre). Los nombres de dichos paquetes no
necesariamente guardan relación con el proceso de negocio
259
Ejemplo
Cobranzas Facturación
260
Identificando actores y casos de uso del sistema a partir de los
diagramas de actividades.
• Revisar el flujo de actividades y para cada actividad analizar:
– ¿Si esta actividad se soporta con el nuevo sistema se puede obtener una mejora
cuantificable o una ejecución óptima del proceso?
– Si la respuesta es sí, identificar quién o quiénes son los actores que utilizarán el
sistema, identificar los casos de uso y las características que se requieren para
“envisionar” una mejora en el proceso.
261
Ejemplo
Registrar Solicitud
Digitador Entregar Reporte
Central de Riesgo
262
Ejemplo
Registrar Solicitud Entregar Reporte

Digitador Central de Riesgo
Ordenar Emisión de Plástico Decidir Solicitud

Agente Comercial Analista
<<extend>>
Rechazar Solicitud
263
Estructuración de Casos de Uso
• RECOMENDACIÓN FINAL:
– Su sobreutilización dificulta el mantenimiento y entendimiento del modelo.
– Mantenga un sólo paquete y diagrama de casos de uso hasta que por su tamaño
ya no se pueda entender. En este momento se debe modularizar en paquetes.
264
Las especificaciones de casos de uso
• El esquema de la especificación de un caso de uso contiene los siguientes elementos:

– Breve descripción
– Flujo Básico
• Paso 1
• Paso 2
• Paso n
– A1 – Flujo Alternativo 1
265
Esquematizar un Caso de Uso
Escenarios de casos de
Inicio del caso de uso
Escenario 1
uso
Flujo básico
Flujo Escenario 2 Flujo básico Flujo alterno 1

Básico
Flujo Escenario 3 Flujo básico Flujo alterno 1 Flujo alterno 2
alterno 3
Flujo Escenario 4 Flujo básico Flujo alterno 3

alterno 1
Escenario 5 Flujo básico Flujo alterno 3 Flujo alterno 1
Flujo
alterno 4 Flujo
Escenario 6 Flujo básico Flujo alterno 3 Flujo alterno 1 Flujo alterno 2
alterno 2
Escenario 7 Flujo básico Flujo alterno 4

Fin del caso de Fin del caso de
uso uso
Escenario 8 Flujo básico Flujo alterno 3 Flujo alterno 4
Fin del caso de uso
266
Esquematizar un Caso de Uso
• La especificación de un caso de uso es un proceso incremental.
• El primer paso consiste en definir un esquema de los flujos. Este esquema

es un documento informal en el proyecto. Sirve de base para completar la
especificación posteriormente.
• El flujo básico presenta los principales pasos para lograr la meta del caso
de uso. Los flujos alternativos presentan manejo excepcional u opcional
dentro del caso de uso.
• La estructura de un caso de uso se compone de la enumeración de los

pasos del flujo básico y la enumeración (sin detalle) de los flujos
alternativos.
267
Ejemplo del esquema de un Caso de Uso – Solicitar un Crédito
Flujo Básico
1. Seleccionar ‘Solicitar un Crédito’
2. Verificar Información Básica
3. Registrar información del valor y
destinación del crédito
4. Anexar documentos ¿Qué otros flujos
5. Enviar la solicitud alternativos
Flujos Alternativos podríamos definir?
A1. Ingresar al Sistema
A2. Actualizar Información Básica
A3. Cancelar solicitud
…
268
¿Por Qué Esquematizar un Caso de Uso?
• El esquema de un caso de uso sirve para descubrir información que no se conoce al

identificar los casos de uso.
• La esquematización de los casos de uso es fundamental para la estructuración del

modelo. Al ver que un caso de uso es muy pequeño o muy grande se puede decidir
fusionarlo o descomponerlo en varios.
269
Flujo de Eventos
• Un Flujo Básico
– Escenario feliz.
– Describe un escenario satisfactorio desde el inicio del caso de uso hasta cumplir con la meta
del mismo.
• Varios Flujos Alternativos

– Variantes regulares dentro del flujo básico.
– Casos no permitidos.
– Flujos Excepcionales.
270
¿Cómo estructurar el flujo de eventos?
• Básico
– ¿Cuál evento inicia el caso de uso?
– ¿Cómo termina el caso de uso?
– ¿Cómo se repite cierto comportamiento en el caso de uso?
• Alternativos
– ¿Hay situaciones opcionales?
– ¿Qué casos raros se pueden presentar?
– ¿Qué variantes se pueden presentar?
– ¿Qué puede salir mal?
– ¿Qué no puede pasar?
– ¿Qué recursos pueden bloquearse?
271
Ejemplo
Sección Contenido
Designación UC-12-37
Nombre Diríjase al destino
Autores John Smith, Sandra Miller
Prioridad Importancia para el éxito del sistema: alta
Riesgo tecnológico: alto
Criticalidad Alta
Fuente C. Warner (experto en el dominio de sistemas de navegación)
Persona responsable J. Smith
Descripción El conductor del vehículo digita el nombre del destino.
El sistema de navegación guía al conductor al destino deseado.
Evento desencadenante El conductor desea dirigirse a su destino
Actores Conductor, servidor de información de tráfico, sistema satelital
GPS
Precondiciones El sistema de navegación es activado
Post-condiciones El conductor ha llegado a su destino
Resultado Ruta guía al destino
Escenario principal 1. El sistema de navegación pide el destino deseado
2. El conductor ingresa el destino deseado
3. El sistema de navegación señala el destino en su mapa
4. Basado en la posición actual y el destino deseado, el
sistema de navegación calcula una ruta adecuada
5. El sistema de navegación compila una lista de puntos
de referencia
6. El sistema de navegación muestra un mapa de la
posición actual y muestra la ruta al próximo punto de
referencia
7. Cuando se llega al último punto de referencia, el
sistema de navegación muestra “destino alcanzado” en
la pantalla.
Escenarios alternativos 4.a. El cálculo de la ruta debe respetar la información de
tráfico y evitar congestiones de tráfico.
4.a.1 El sistema de navegación le pide al servidor información
del tráfico actualizada
4.a.2 El sistema de navegación calcula una ruta que no
contiene congestiones de tráfico.
Escenarios de excepción Evento desencadenante: El sistema de navegación no recibe
una señal GPS del sistema satelital GPS
Cualidades  QR.04 (tiempo de reacción luego de entrada hecha por el
usuario)
 QR.15 (comodidad de uso)
(QR = requerimiento de calidad)
272

273
Las tres perspectivas de los requisitos documentados con Modelos
• Cuando se documentan requisitos basados en modelos, uno distingue típicamente tres

tipos de perspectivas:
– datos,
– funciones,
– Comportamientos
• 1 Perspectiva de datos: En esta perspectiva, las estructuras de entrada y salida de

datos así como los aspectos de estática estructural de las relaciones de dependencia y
uso del sistema en el contexto del sistema son documentados.
– Diagrama Entidad Relación
– Diagrama de Clases de UML
274
Las tres perspectivas de los requisitos documentados con Modelos
• 2 Perspectiva funcional: Esta perspectiva documenta qué información del contexto del
sistema está siendo manipulada por el sistema a desarrollar y qué datos están siendo
transmitidos al contexto del sistema por el sistema.
– Diagramas de Flujo de Datos
– Diagramas de Actividad UML
• 3 Perspectiva de comportamiento: En esta perspectiva el asentamiento del sistema en
el contexto del sistema se documenta basado en estados. Esto se hace, por ejemplo,
documentando la reacción del sistema a eventos dentro del contexto del sistema,
documentan las condiciones que desencadenan un cambio de estado, o documentan
los efectos que el sistema tiene en su entorno.
– Diagramas de Estado UML
275

276
El foco de la perspectiva de datos sobre requisitos
• Diagramas Entidad Relación

• Diagramas de Clases de UML
277
Los diagramas de entidad-relación
278
Diagrama de Clases en UML
<nombre de la clase>
atributo
atributo : tipo
atributo : tipo = <valor>
operacion () : return
operacion (argumento : tipo) : return
operacion (argumento1 : tipo, argumento2 : tipo = <valor>) : return
279
Atributos
• Los atributos definen la estructura estática de una clase

• Un atributo está compuesto por su nombre, tipo y valor inicial.
• El espacio de memoria que requiere un objeto durante la ejecución de un programa, es el que
requiere su lista de atributos.
280
Notación de Atributos
• Las características de un atributo se pueden notar total o parcialmente, dependiendo

de la fase del proceso de desarrollo.
• Durante el análisis se puede definir un atributo simplemente con su nombre:
– Nombre
– Telefono
281
Notación de Atributos
• Durante diseño se requiere que todo atributo quede tipificado y los que requieran
valores iniciales sean indicados:
– Nombre: String
– Telefono: Integer
– Saldo: Decimal = 0
282
Comportamiento de un Objeto
• Una operación es un servicio que una clase ofrece a sus clientes.

• Tipos de Operaciones:
– Modificador: Altera el estado del objeto

– Selector: Accede al estado del objeto sin alterarlo.
– Iterador: Accede a las partes de un objeto en un orden establecido.
283
Ejemplo de Operaciones
• La clase lista puede tener:
– Modificadores
• borrar, añadir, extraer, eliminar.
– Selectores
• numeroElementos, estaVacia, posicion.
– Iteradores
• primerElemento, siguienteElemento
284
Tipos de Operaciones
• Constructor
– Operación que crea un objeto y/o inicializa su estado.
• Destructor
– Operación que libera el estado de un objeto y/o destruye el propio objeto.
285
Relaciones
286
Asociación
• Una asociación es una conexión entre dos clases, signigicando alguna dependencia
semántica entre ellas.
• Pueden existir varias asociaciones entre dos clases.
287
Asociación
Nombre
Clases Asociación Roles
em plea
em pleador_de em pleado_de em pleado
com pañía
0..1 0..*
Cardinalidad
288
Cardinalidad
• La cardinalidad se especifica para responder preguntas como:
– Es la relación obligatoria (cero no está en el rango) u opcional (cero está incluida

en el rango)
– Cuál es el máximo número de instancias que se pueden vincular a una instancia de

otro objeto.
289
Cardinalidad: Indicadores Comunes
• 1: Exactamente 1
• 0..*: Cero o más
• 1..*: Uno o más
• 0..1: Cero o Uno
• 3..7: Rango específico
• 1..3,7: Combinación (1,2,3 ó 7)
290
Asociación
• Las asociaciones se consideran bidireccionales, sin embargo pueden definir

navegabilidad en un solo sentido.
facturado a
factura cliente
• La factura ve un atributo “facturado_a” que es un objeto de la clase

“cliente”; el cliente desconoce la existencia de facturas.
291
Agregación y Composición
• La relación entre un todo y sus partes representa una dependencia semántica más
fuerte, lo cual amerita un distintivo especial. Este tipo de relaciones se conocen como
agregación y composición.
Todo Parte
controles
ventana control
0..*
292
Composición
• La existencia de las partes depende de la existencia del todo. El constructor y

destructor del todo construye y destruye las partes.
controles
ventana control
0..*
293
Agregación
• La existencia de las partes es independiente de la existencia del todo.
vehiculo motor
294
Relación Reflexiva
• Un objeto de una clase puede tener relaciones con otros objetos de la misma clase.
Cuenta Contable
sub cuenta
295
Relaciones Durante Análisis
• Se establecen relaciones entre clases
• Donde sea claro, se especifica navegabilidad y agregaciones.
• Se hace un estimado inicial de cardinalidad, buscando exponer el modelo a

suposiciones ocultas.
• Se pueden especificar nombres de relaciones y/o roles.
296
Ejemplo de diagrama de Clases UML
1
Ships to
User 1 Billing CC
Atributos -User Name 0..3 0..*
-Credit Card Number
-Password Pays with -Billing Address
Métodos +Get Billing CC Info() -Expiration Date Shipping
+Get Shipping Info() 1
+Verify CC with Bank() -Shipping Address
+Get History() +Get Purchase Auth() -Last Used Date
Pays with
+Get PayPal() +Add CC() +Add New Address()
Buys +Update CC Exp Date() +Change Address()
1
0..* +Delete Address()
+Check Zip()
Purchase History PayPal
-Purchase Category -PayPal Account
-Purchase Item ID 0..1
+Verify Account()
-Quantity +Get Purchase Auth()
-Date Purchased
+Call Preference Engine()
297
El foco de la perspectiva funcional de requisitos
• Diagrama de Flujo de Datos
• Diagrama de Actividades de UML
298
Funcional: Diagrama de Flujo de Datos
• Brinda una representación visual de cualquier entidad externa que proporciona datos
o recibe datos del sistema
• Procesos que manipulan datos
• Flujos de datos que mueven datos
• Acumuladores de datos que mantienen la información por un periodo de tiempo
• Es una descomposición del diagrama de contexto y es un bloque de construcción en el

análisis estructurado
299
Componentes del Diagrama de Flujo de Datos
• Entidades externas (rectangulo)
• Almacén de datos (dos lineas paralelas)
• Proceso de datos (cículo o rectángulo redondeado)
• Flujo de datos (flecha)
• Fuentes/salidas de datos
300
Jerarquía del Diagrama de Flujo de Datos
• Debido a la complejidad de desarrollar un diagrama de flujo de datos completo, a

menudo se hace en niveles
• El primer nivel es el diagrama de contexto
• El segundo nivel es el nivel-0
• El tercer nivel es el nivel-1, y así sucesivamente
301
Diagrama de Flujo de Datos - Contexto
0
Hungry Order Food Order
Kitchen
Customer Donut
Ordering
Receipt
System
Management Reports
Donut Shop
Manager
Ummmm.
Donuts!
302
Diagrama de Flujo de Datos – Nivel 0
1.0
Hungry Order Food Order
Receive Kitchen
Customer
and
Receipt Transform
Order
Nota: Esto se
muestra algunas 2.0 3.0
veces con Donuts Inventory
Update Sold Data Update
rectángulos Donuts Inventory
redondeados. Sold File File
Formatted
Formatted
Donuts Sold
Inv. Data
Donuts Sold File Data Inventory File
4.0 Daily Inv Reduction Amts

Daily Donuts Sold Amounts Receive
and Mgmt Rpts Donut Shop
Transform Manager
Order
303
Funcional: Diagramas de Actividad UML
• Los elementos de un diagrama de actividades son:

– Estado inicial y final
– Actividades
– Condiciones de Guarda [ ]
– Actividades de Decisión
– Barras de Sincronización
304
• Los estados inicial y final, actividades y condiciones de guarda, tienen el mismo

significado que en los diagramas de transición de estados.
• Las barras de sincronización generan eventos que pueden suceder simultáneamente o
que su orden es irrelevante.
• Las actividades de condición tienen el mismo significado que en un diagrama de flujo.

• Los diagramas de actividades sirven para modelamiento de negocios y para programas
de procesamiento en paralelo.
• También pueden servir para describir casos de uso.
305
[ no hay café ] [no hay gaseosa]
Encontrar Bebida
[café encontrado]
poner café en filtro agregar agua al la jarra conseguir tasas conseguir lata de gaseosa
poner filtro en la máquina
prender la máquina
^cafetera.Prender
Hervir el café
la luz se apaga
servir café tomar bebida
306

307

308
Modelos desde el punto de vista de el comportamiento
• Diagrama de Transición de Estados de UML
309
Comportamiento: Diagramas de Estado UML
• Sirven para describir el comportamiento de un objeto a través de su participación en

diferentes casos de uso.
• Cada clase puede tener un diagrama de transición de estados para describir el ciclo de
vida de sus objetos.
310
Diagramas de Transición de Estados
<nombre>
entry: entrada
evento[ condición ] / acción exit: salida
do: actividad
on evento( argumentos )[ condición ]: accion
Estado Final
Estado Inicial Estado
Transición
311
Estado
• Identifica un período de tiempo del objeto en el cual está esperando alguna operación,
mantiene un estado característico o puede recibir estímulos de cierto tipo.
• Los estados inicial y final tienen una notación especial.
312
Transición Simple
• Es una relación entre dos estados que indica que un objeto en el primer estado puede
entrar al segundo y ejecutar ciertas operaciones.
• La sintaxis de la etiqueta de una transición es:

Event (args) [condition] / Action ^target.someEvent (args)
313
Transición Simple
• Event(args):
– Descripción del evento que da lugar a la transición
• Condition:
– Expresión que indica condiciones adicionales al evento necesarias para que la
transición ocurra.
314
Transición Simple
• Action:
– Mensaje que invoca una operación del objeto y es la que causa el cambio de
estado. La acción es una operación rápida y sin interrupciones.
• Target:
– Algún objeto que recibe la transición.
315
Funcionamiento Interno
• Dentro de un estado, pueden suceder algunos de los siguientes procesos:
– Acciones de entrada y salida: que pueden ser mensajes a otros objetos.
– Actividades: Procesos que pueden ocurrir dentro de un estado, pueden tomar

tiempos largos y pueden ser interrumpidos.
– Transiciones Internas: es una transición que no representa un cambio de estado.
316
Acciones y Actividades
• Las acciones y las actividades son procesos, normalmente implementados por alguna
operación de la clase.
• Una acción se considera una acción que se hace rápidamente y sin interrupciones.
• Una actividad puede tomar mayor tiempo y puede ser interrumpida por algún evento.
317
Diagrama de Transición de Estados
seleccionar siguiente
Chequeando item[ faltan items por
do: chequear item chequear ]
[ todos los item s chequeados

&& disponibles ]
&& algunos no disponibles ]
item recibido[ todos Despachando

Esperando
disponibles ]
do: iniciar despacho
item recibido[ algunos no

disponibles ] cancelado
despachado
cancelado
318
Diagrama de Transición de Estados
activo
seleccionar siguiente
Chequeando item[ faltan items por
do: chequear item chequear ]

&& disponibles ]
&& algunos no disponibles ]
item recibido[ todos

Esperando disponibles ] Despachando
do: iniciar despacho
item recibido[ algunos no

disponibles ]
cancelado
cancelado despachado
319
CONTENIDO DEL CURSO
320
Capítulo 7 Validación y negociación
de requisitos (2 ½ horas)
• 7.1.1 Conocer el significado de la validación requisitos

7.2.1 Conocer el significado de los conflictos con respecto a los requisitos
7.3.1 Conocer tres aspectos de calidad de los requisitos
7.3.2 Dominar y utilizar criterios de validación para los aspectos de calidad “contenido”,
“documentación” y “nivel de acuerdo”
7.4.1 Conocer los seis principios de la validación de requisitos
7.4.2 Dominar y utilizar los seis principios de validación de requisitos
7.5.1 Conocer técnicas para la validación de requisitos
7.5.2 Dominar y utilizar las técnicas de validación siguientes: comentarios (opinión de experto),
inspección, revisiones guiadas, lectura basada en la perspectiva, validación mediante prototipos y
el uso de listas de comprobación
7.6.1 Conocer actividades de negociación de requisitos
7.6.2 Conocer los tipos de conflictos entre requisitos
7.6.3 Conocer distintas técnicas de resolución de conflictos
7.6.4 Conocer la documentación para la resolución de conflictos
321
El significado de la validación requisitos
• Objetivo: Asegurar que los requisitos documentados cumplen el criterio de calidad

predeterminado.
• Calidad: Durante este capítulo se definirán los diferentes componentes de la calidad y

las técnicas que se utilizan para:
– Verificar la calidad
– Realizar los ajustes necesarios para que se cumpla el criterio de calidad deseado
• Proceso Configurable: De Acuerdo con cada entregable se deben definir las
actividades y técnicas requeridas para la validación
322
Cambios necesarios por un error no en los requisitos
323
El costo de corregir errores en los Requisitos
Costo $
ETAPA
.5 - 1 Levantamiento
2.5
Documentación
5
Validación
10
Programación
25
Pruebas
100
Mantenimiento
La regla 1-10-100:
El costo de corregir un error de requisitos en la etapa de Mantenimiento puede ser hasta
100 veces mas costoso
324

325
El significado de los conflictos con respecto a los requisitos
El Problema de los Conflictos:

• Los conflictos no resueltos en los requisitos pueden significar:
– que algunos requisitos de un grupo de implicados no puedan ser implementados
– que el sistema en operaciones sea poco o no aceptado o utilizado.
– que se tengan que invertir costos adicionales para resolver los conflictos de forma tardía
La Solución es la resolución de Conflictos:

• El objetivo de la negociación de requisitos consiste en alcanzar un entendimiento común y
consensuado de los requisitos del sistema a desarrollar entre todos los implicados relevantes
• Esta resolución se debe dar temprano en el proyecto como resultado de actividades de:
– Revisiones tempranas y planificadas que identifiquen los conflictos
– Una adecuada resolución de conflictos.
326

327
Los 3 Aspectos de Calidad de los Requisitos
Hay tres aspectos de calidad de los requisitos:
• 1 Contenido: Todos los requisitos relevantes han sido elicitados y documentados con
el nivel apropiado de detalle?
• 2 Documentación: Están documentados todos los requisitos con respecto a las guías y
estructuras de documento predeterminadas para documentación y especificación?
• 3 Concordancia: Concurren todos los involucrados con los requisitos documentados y
se han resuelto todos los conflictos conocidos?
Cada uno de los tres objetivos implica un acercamiento individual que se enfoca en
aspectos específicos de la calidad de los requisitos.
328
Criterio de Validación para Contenido
• La validación de requisitos con respecto al aspecto de calidad “contenido” es exitosa una vez la
validación de requisitos haya sido aplicada a los siguientes tipos de error y no se hayan detectado
errores significativos.
– Completitud: Están completos (grupo de todos los requisitos): Todos los requisitos relevantes al sistema a
desarrollar (para la siguiente entrega del sistema) se han documentado?
– Completitud: Están completos (requisitos individuales): Cada requerimiento contiene toda la información
necesaria?
– Trazabilidad: Todas las relaciones relevantes trazables se han definido? (e.g., a fuentes relevantes de
requisitos)?
– Exactitud/suficiencia: Reflejan los requisitos adecuadamente los deseos y necesidades de los
involucrados?
– Consistencia: Es posible implementar todos los requisitos definidos por el sistema para ser desarrollados
conjuntamente? No hay contradicciones?
– Sin decisiones prematuras de diseño: Hay algunas decisiones de diseño anticipado presentes en los
requisitos que no se hayan inducido a través de condiciones? (e.g., condiciones que especifican una
arquitectura específica de relación cliente-servidor que se vaya a usar)
– Verificabilidad: Es posible definir la aceptación y criterio de prueba basado en os requisitos? Se ha
definido el criterio?
– Necesidad: Contribuye cada requerimiento al cumplimiento de los objetivos definidos?
329
Validación de Criterio para Documentación
• La validación de la “documentación” es exitosa cuando han sido verificados los

requisitos en busca de los siguientes tipos de error y no se detectan defectos
significativos.
– 1 Conformidad con el formato de documentación: Están los requisitos documentados en

el formato de documentación predeterminado?
• Por ejemplo, se ha usado una plantilla específica de requisitos o un lenguaje de modelaje
específico?
– 2 Conformidad con las estructuras de documentación: Se ha mantenido la estructura de
los documentos de requisitos?
• Por ejemplo, se han documentado todos los requisitos en la posición adecuada en el documento?
– 3 Entendibilidad: Pueden entenderse todos los requisitos documentados en el contexto
dado?
• Por ejemplo, se han definido todos los términos empleados en el glosario?
– 4 No Ambigüedad: Permite la documentación de los requisitos solo una interpretación o
son posibles múltiples interpretaciones diferentes?
330
Criterio de Validación para Concordancia
• Definición: El aspecto de calidad “concordancia” tiene que ver con chequear los
requisitos por fallas en la conformidad de los requisitos entre involucrados.
• Criterio de Éxito: Validación de requisitos con respecto al aspecto de calidad

“concordancia” es exitoso cuando la validación de requisitos ha sido aplicada a los
siguientes tipos de error y no se detectan mayores errores significativos:
– Acordado: está cada requerimiento acorde para todos los involucrados relevantes?
– Acordado después de cambios: está cada requerimiento acordado con todos los
involucrados relevantes después de que se ha cambiado?
– Conflictos resueltos: se han resuelto todos los conflictos conocidos con respecto a los
requisitos?
331

332
Conocer los 6 principios de la validación de requisitos
• Considerar los siguientes seis principios de validación de requisitos incrementa la

calidad de los resultados de la validación.
– Principio 1: Participación de los involucrados correctos

– Principio 2: Separar la identificación y la corrección de errores
– Principio 3: Validación desde diferentes perspectivas
– Principio 4: Cambio adecuado del tipo de documentación
– Principio 5: Construcción de artefactos de desarrollo basándose en los requisitos
– Principio 6: Validación reiterada (repetitiva)
333
– Principio 1: Participación de los involucrados correctos
• Quienes? Depende de los objetivos de la validación así como de los requisitos que van
a ser auditados.
• Dos aspectos tienen que ser considerados al definir los involucrados que participarán:
– Evitar que el autor de un requerimiento sea también la persona que lo valide.
– Los auditores adecuados pueden identificarse dentro o fuera de la organización
desarrolladora.
• Auditorías internas se realizan por involucrados que son miembros de la organización desarrolladora
y pueden usarse para validar resultados intermedios o requisitos preliminares.
– Mas Fácil!
• Una auditoría externa requiere un nivel de esfuerzo más alto porque identifica los auditores y
(potencialmente) los contrata a cambio de un pago.
– Mas Difícil y mas costoso
– Deben familiarizarse con el contexto del sistema a desarrollar.
– Debería realizarse solo en requisitos que acusen un alto nivel de calidad.
334
– Principio 2: Separar la identificación y la corrección de errores
• Separar en diferentes grupos el identificar errores y arreglarlos funciona.

– Cada error identificado se revisa doblemente para determinar si realmente es un error.
– Permite a los auditores concentrarse en la identificación.
– Las medidas para corregir los errores se toman solo después de que las medidas de
identificación se hayan completado.
335
– Principio 3: Validación desde diferentes perspectivas
– Validar requisitos desde diferentes perspectivas es otro principio que se ha

probado a sí mismo en la práctica.
– En este principio, los requisitos son validados y acordados desde diferentes
perspectivas (probadores, usuarios, programadores etc).
336
– Principio 4: Cambio adecuado del tipo de documentación
– Buen entendimiento y expresividad son fortaleza de los textos en Lenguaje Natural, sin
embargo, su debilidad es ambigüedad potencial y la dificultad de expresar circunstancias
complejas.
– Los Modelos gráficos son capaces de describir circunstancias complejas de manera adecuada,
pero las construcciones de modelaje individual son restringidas en expresividad.
• Cambiar el tipo de documentación (entre modelos y lenguaje natural) durante la validación de

requisitos usa la fortaleza de un tipo de documentación para balancear la debilidad de otros tipos
de documentación.
• Transcribir un requerimiento que ya está documentado en otra forma de documentación
simplifica encontrar los errores.
– Por ejemplo, ambigüedades en requisitos en lenguaje natural pueden ser identificados

mucho más fácil transcribiéndolos en una representación basada en modelo.
337
– Principio 5: Construcción de artefactos de desarrollo basándose en los requisitos
– Construir artefactos de desarrollo apunta a validar la calidad de los requisitos que

pretender ser la base de crear artefactos de diseño, artefactos de prueba, o el
manual de usuario.
– Durante el curso de la validación, por ejemplo, el auditor trata intensivamente con

un requerimiento por medio de la creación de un caso de uso.
• De esta manera, errores (e.g., ambigüedad) puede identificarse en el requerimiento. Este tipo de
validación, sin embargo, demanda mucho recursos porque el desarrollo de actividades subsecuentes
debe ser ejecutado al menos en parte.
338
– Principio 6: Validación reiterada (repetitiva)
• La Validación de requisitos debería ocurrir múltiples veces en los siguientes casos

(entre otros):
– Cuando hay entregables con alto nivel de profundidad que pueden evolucionar y madurar a
lo largo del esfuerzo de requisitos
– Cuando muchas ideas y tecnología innovadoras son empleados en el sistema
– Cuando hay Adquisición significativa de conocimiento durante la ingeniería de requisitos
– En Proyectos de larga duración
– Cuando el Dominio es desconocido
– Cuando los requisitos que van a ser reutilizados en varios proyectos
NOTA: La Validación debe ser programada de forma independiente para cada

entregable en una matriz al iniciar el proyecto o cada etapa del mismo.
339

340
Técnicas para la validación de requisitos
• Técnicas más formales

– Comentarios en revisión (opinión de experto)
– Inspecciones
– Revisiones Guiadas
• Otras técnicas complementarias

– Lectura basada en perspectiva
– Validación a través de prototipos
– Uso de listas de comprobación (listas de chequeo)
341
3 Técnicas formales para la validación de requisitos
• 1 Comentarios de experto
• Objetivo: recibir la opinión de experto del compañero con respecto a la calidad de un
requerimiento.
• Metodologia: Al comentar, el autor pasa sus requisitos a otra persona (e.g., compañero de
trabajo).
– El compañero revisa el requerimiento con el objeto de identificar errores que deshabilitan la

calidad del requerimiento (e.g., ambigüedad o errores) con respecto a un criterio de calidad
predeterminado.
– Los errores identificados son marcados en el documento de requisitos y explicados en el
mismo (comentarios de word por ejemplo)
342
• 2 Inspección (También conocida como revisión técnica)
• Definición y Objetivo: Las inspecciones de software o cualquier otro tipo de producto son hechas
para chequear sistemáticamente artefactos de desarrollo por errores aplicando un proceso
estricto
• Fase 1 Planear,
– El objetivo de la inspección, los resultados de trabajo que van a ser inspeccionados, y los
roles y participantes
• Organizador: planea y supervisa el proceso de inspección
• Moderador: lidera la sesión y se asegura que el proceso de inspección predeterminado se siga. Es
recomendable seleccionar un moderador neutral porque el moderador puede potencialmente
balancear opiniones opuestas de autores e inspectores.
• Autor: el autor explica los requisitos que ha creado a los inspectores en la fase de vistazo general y
luego se hace responsable de corregir los errores identificados
• Lector: el lector introduce los requisitos a inspeccionar sucesivamente y guía los inspectores a través
de ellos. El rol del lector debe darse a un involucrado neutral de tal manera que los inspectores
puedan centrar su atención en los requisitos en lugar que en la interpretación de un autor. A
menudo el moderador también es el lector.
• Inspectores: los inspectores son los responsables de encontrar errores y comunicar lo que
encuentren a los otros miembros del equipo del proyecto.
• Tomador de minutas: esta persona toma las notas de los resultados de la inspección.
343
• Fase 2 Recorrido general

– El autor explica los requisitos que se van a inspeccionar a todos los miembros del equipo de
tal manera que haya un entendimiento común de los requisitos entre todos los inspectores
• Fase 3 Detección de defectos,
– En la fase de detección de errores, los inspectores buscan entre los requisitos por errores.
Detección de errores puede realizarse individualmente por cada inspector o de manera
colaborativa en un equipo. Durante el curso de la detección de errores, cualquier error
encontrado es documentado.
• Inspección individual tiene la ventaja que cada inspector se puede concentrar en los requisitos.
• Inspecciones en equipo tienen la ventaja que la comunicación entre los inspectores crea efectos de
sinergia durante la detección de errores.
• Fase 4 Corrección de defectos,
– En la fase de colección de errores, todos los errores identificados son corregidos.
– Junto con la corrección , los errores identificados y las medidas de corrección son
documentadas en una lista de errores.
344
• 3 Recorrido
• Objetivo: Identificar fallas de calidad dentro de los requisitos pro medio de un proceso
compartido y para ganar un entendimiento compartido de los requisitos entre todas las personas
implicadas. El Recorrido es menos estricto que una inspección
• Roles:
– revisor (comparable con inspector),
– autor,
– tomador de minutas,
– potencialmente el moderador, (Opcional)
• Preparación: Para prepararse para un ensayo, los requisitos a validar se entregan a los
participantes y se inspeccionan.
• Ejecución: Durante la sesión de ensayo, los participantes discuten los requisitos a validar paso a
paso, bajo la guía del moderador/lector. Usualmente, el autor del requerimiento es el que expone
el requerimiento a los otros participantes y se identifican requisitos alternativos, se toman
decisiones, y se explica el criterio para dichas decisiones).
• Resultado: Un tomador de minutas documenta las fallas de calidad que han sido identificadas
durante la sesión y se elabora un acta de acciones y fechas de compromisos.
345
3 Técnicas Complementarias para la validación de requisitos
• A) Lectura basada en perspectiva
• Definición: Los requisitos son chequeados adoptando perspectivas diferentes Típicamente,

lectura basada en perspectiva es aplicada en conjunción con otras técnicas de revisión (e.g.,
durante inspecciones o ensayos).
• Enfocarse en perspectivas particulares cuando se lee un documento verificable lleva a resultados
mejorados durante la validación de requisitos.
– Perspectiva cliente/usuario: los requisitos se chequean desde la perspectiva del cliente o del
usuario ya que ellas describen las funciones y cualidades deseadas del sistema.
– Perspectiva del arquitecto de software. Los requisitos se chequean desde la perspectiva del
arquitecto de software para comprobar si contienen toda la información necesaria para el
diseño arquitectónico (e.g., si todas las propiedades relevantes de desempeño se han
descrito).
– Perspectiva del probador: los requisitos son chequeados desde la perspectiva del probador
para comprobar si ellos contiene la información necesaria para obtener casos de prueba de
los requisitos.
» …………………..Continúa
346
• ……………. A) Lectura basada en perspectiva
– Los tres aspectos de calidad (contenido, documentación y concordancia) también describen

tres posibles perspectivas para validación de requisitos.
• Perspectiva de contenido: con la perspectiva de contenido, el auditor verifica el contenido de los
requisitos y se enfoca en la calidad del contenido del requerimiento documentado.
• Perspectiva de documentación, con la perspectiva de documentación, el auditor se asegura que
todas las guías de documentación para requisitos y documentos de requisitos se hayan cumplido.
• Perspectiva de concordancia: con la perspectiva de concordancia, el auditor chequea si todos los
involucrados están de acuerdo con un requerimiento, i.e., si los requisitos se han acordado y los
conflictos han sido resueltos.
• Además, perspectivas adicionales que surgen del contexto individual del desarrollo del
proyecto pueden ser creados en la medida que se necesiten.
…………………..Continúa
347
• ……………. A) Lectura basada en perspectiva

• Metodología:
– A Cada auditor se le asigna una perspectiva desde la cual lee y valida el requerimiento.
– Para cada perspectiva definida se establecen instrucciones detalladas para familiarizar al
auditor con todos los detalles relevantes de su perspectiva
– Se recomienda asociar preguntas con cada instrucción de validación que deben ser
respondidas por el contenido de los requisitos o por el auditor después de que haya leído los
requisitos.
– Se puede utilizar una lista de chequeo que resuma los aspectos de contenido más
importantes a los que se debe dirigir la lectura.
– Los resultados de la perspectiva escogida son analizados y consolidados
• respuestas a las preguntas predefinidas, y de otro lado,
• asuntos sin resolver que los auditores notaron mientras leían.
• Nota : Lectura basada en perspectiva puede ser ambas,

• Una técnica independiente para validación de requisitos y
• Una técnica de soporte para otras técnicas de validación, como inspecciones o revisiones de
documentos de requisitos por medio de una lectura basada en perspectiva.
348
• B) Validación a través de prototipos
• Definición: Permite a los auditores experimentar los requisitos y probarlos.

– Es el método más efectivo para identificar errores en requisitos.
– Los Involucrados pueden probar en prototipo y comparar su propia idea de cómo tendría que
implementarse el sistema con el prototipo a mano y así encontrar discrepancias entre sus ideas y la
implementación actual.
• Tipos de prototipos
– descartables
– evolucionarios [Sommerville 2007]. Son desarrollados con el objeto de ser desarrollados más adelante y
mejorados más tarde. El esfuerzo para crear prototipos evolucionarios es mucho más alto.
• Los requisitos que tienen que ser validados por medio del prototipo deben ser seleccionados.
• Elementos clave:
– Manual/Instrucciones:
– Escenarios de validación:
– Lista de chequeo con criterio de validación:
• Los resultados de la validación Sugerencias de cambio para los requisitos . Si son necesarios cambios
significativos a los requisitos, puede ser necesario revisar el prototipo y validar de nuevo.
349
• C) Usar Listas de Chequeo para Validar
• Definición: Una lista de chequeo para validación de requisitos contiene preguntas que ayudan a la
detección de errores y pueden usarse en todas las técnicas de validación de requisitos
previamente descritas
• Metodología:
– Antes de poder usar una lista de chequeo, cada pregunta o afirmación debe definirse
basándose en:
• Los tres aspectos de calidad de los requisitos .
• Principios de validación de requisitos .
• Criterio de calidad para documentos de requisitos .
• Criterio de calidad para requisitos individuales .
• Experiencias de los auditores de proyectos anteriores
• Estadísticas de error [Chernak 1996]
– Formas híbridas de aplicación de listas de chequeo también son posibles.
• Por ejemplo, una lista de chequeo puede contener preguntas obligatorias para lectura basada en
perspectiva y puede contener sugerencias que el auditor puede que siga o no.
– Una gran cantidad de preguntas puede hacer que sea más difícil de usar la lista de chequeo
– Es recomendable diseñar la lista de chequeo para que no sea más larga de una página [Gilb y Graham
1993].
350

351
4 Elementos de negociación de requisitos
1. Identificación de conflictos
2. Análisis y Tipos de Conflictos
3. Técnicas de Resolución de conflictos
4. Documentación de la resolución de conflictos
352
Identificación de Conflictos en los requisitos
• 1 Identificación de conflictos
• Los Conflictos pueden surgir durante todas las actividades de la ingeniería de

requisitos.
• Por ejemplo, diferentes involucrados pueden proporcionar requisitos
contradictorios durante la elicitación.
• Conflictos entre requisitos y conflictos entre involucrados no son siempre tan obvios
• El ingeniero de requisitos debería prestar atención a conflictos potenciales
para poder identificarlos, analizarlos, y resolverlos pronto.
353
Análisis y Tipos de conflictos entre requisitos
• 2 Análisis de conflictos y Tipos de Conflictos

– Durante el análisis de conflictos, se debe determinar la razón para un conflicto identificado.
De acuerdo a [Moore 2003], existen diferentes tipos de conflictos.
• El sujeto de conflicto entre dos o más involucrados se caracteriza por:

– un déficit de información (incompleta)
– falsa información (erronea)
– por diferentes interpretaciones de alguna información (ambigua)
• Ejemplo, tome el siguiente requerimiento:
– “R131: el tiempo de reacción del sistema planeado no debe exceder un segundo”.
– Un sujeto de conflicto entre dos involucrados con respecto a este requerimiento puede
surgir del hecho que un involucrado considera un tiempo de reacción de 1 s sea muy lento
mientras que otro involucrado no crea que tal tiempo de reacción de un segundo se posible
implementarlo (i.e., es muy corto).
354
Análisis y Tipos de conflictos entre requisitos
• Un conflicto de interés:
– Por ejemplo cuando un involucrado se enfoca primariamente en mantener los costos del sistema
planeado al mínimo, mientras otro involucrado, primariamente, desea un alto nivel de calidad.
• Un conflicto de valor: se caracteriza por diferencias en los valores fundamentales que los involucrados tengan
respecto a alguna circunstancia .
– Por ejemplo, un conflicto de valor surge cuando un involucrado favorece tecnologías abiertas y otro
involucrado favorece tecnologías cerradas
• Un conflicto de relación se caracteriza por fuertes emociones, conceptos estereotípicos de relaciones,
comunicación deficiente, o comportamiento interpersonal negativo entre involucrados (i.e., insultos, falta de
respeto).
– Por ejemplo, dos involucrados de igual rango o posición (e.g., líderes de departamento) rechazan los
requisitos del otro y tratan de distinguirse forzando sus propios requisitos en el proyecto.
• Un conflicto estructural: Niveles desiguales de autoridad o poder.
– Por ejemplo entre un empleado y su superior si el superior invariablemente rechaza requisitos que el
empleado ha definido.
• Combinaciones entre ellos:
– Por ejemplo, un conflicto puede ser un conflicto de relación con claros componentes estructurales.
Similarmente, un conflicto de interés puede ser un conflicto de valores también.
355
Técnicas de resolución de conflictos
• 3 Resolución de conflictos
• Justificación: Muy importante para negociación de requisitos porque la estrategia de resolución

de conflictos tiene una gran influencia en la disposición de la gente implicada
– Por ejemplo, una resolución de conflicto considerada injusta por al menos una de las partes
del conflicto puede llevar a disminución de compromiso y disposición por colaborar con el
proyecto.
– Independientemente de la estrategia de resolución seleccionada, es esencial implicar todos
los involucrados relevantes. Si no se consideran todos, algunas opiniones y puntos de vista
van a permanecer sin ser considerados. El conflicto va a ser resuelto solo de manera parcial o
incompleta.
» …..continua
356
a) Acuerdo, todas las partes en conflicto negocian una solución al conflicto.

b) Compromiso, En contraste a un acuerdo, el compromiso es una amalgama de diferentes partes de
soluciones alternativas.
c) Votación, todas las partes votan en las alternativas de solución.
d) Anulación, un conflicto se resuelve por medio de organización jerárquica. Esto significa que una
parte en conflicto con rango organizacional más alto gana el conflicto por anulación de objeciones
de partes organizacionales más bajas. Si ambas partes tienen el mismo rango organizacional, el
conflicto se resuelve por un involucrado superior o algún decisor de tercera parte.
– Solo se recomienda si otras técnicas de resolución han fallado (e.g., no se encuentra
compromiso) o no son aplicables por limitación de recursos (e.g., tiempo).
e) Consideración de todos los hechos todos los factores de influencia de un conflicto se ha
investigado de tal modo que se recoja tanta información del conflicto como se pueda. Esta
información se usa durante la resolución. Al priorizar los factores de influencia, se determina la
relevancia. Basados en los resultados de esta técnica, la técnica de resolución de conflictos más-
menos-interesante puede ser aplicada.
357
a) Más-menos-interesante , todas las repercusiones positivas y negativas de una solución alternativa

son investigados de tal modo que las repercusiones negativas y positivas pueden ser evaluadas.
a) Repercusiones positivas se colocan en la categoría “mas”
b) repercusiones negativas en la categoría “menos”.
c) Repercusiones que no son ni positivas ni negativas se colocan en la categoría “interesante”.
Repercusiones en la categoría “interesante”
a) no pueden ser evaluadas aun y deben ser investigadas en mayor detalle para determinar
si su influencia es positiva o negativa.
b) Matriz de decisión, se crea una tabla que contiene las soluciones alternativas en las columnas y
todos los criterios relevantes de decisión en las filas. Para cada combinación de criterios y
alternativa de solución, se hace una valoración,
a) por ejemplo por medio de una escala de puntuación que vaya de irrelevante (0 puntos) a
relevante (10 puntos).
b) Para encontrar una solución, se calculan las sumas de las columnas; i.e., la valoración del
criterio de cada solución alternativa se suma. La solución alternativa con el puntaje más alto
se acepta como la decisión.
358
Ejemplo de Matriz de Decisión
Alternativa Alternativa Alternativa

de solución de solución de solución
1 2 3
Criterio 1 3 6 2
Criterio 2 5 4 10
Criterio 3 10 3 5
Suma 18 13 17
359
Documentación para la resolución de conflictos
• Documentación de la resolución de conflictos
• Si una resolución de conflictos no se documenta adecuadamente, pueden surgir las siguientes 2 amenazas
principales (entre otras) para el proyecto.
– Manejo repetido de conflictos:
• Cierto conflicto puede surgir por segunda vez durante el proceso de ingeniería de requisitos.
• Sin la documentación apropiada de la resolución del conflicto, el conflicto debe ser analizado y
resuelto de nuevo..
– Resolución inapropiada de conflictos:
• El conflicto debe ser investigado y resuelto de nuevo.
• Sin la adecuada documentación, información relevante que haya sido considerada durante el
análisis inicial y resolución puede ser pasado por alto y la nueva resolución del conflicto puede llevar
de nuevo a resultados falsos.
En ambos casos, adecuada documentación del conflicto y su resolución soporta los procesos de ingeniería de
requisitos y asegura que información relevante ya conocida puede ser considerada
360
CONTENIDO DEL CURSO
361
Capítulo 8 Gestión de requisitos (2 ½ horas)
• 8.1.1 Conocer el propósito y definición de los esquemas de atributos

8.1.2 Conocer tipos importantes de atributos de los requisitos
8.2.1 Dominar y utilizar vistas sobre los requisitos
8.3.1 Conocer métodos para priorizar requisitos
8.3.2 Dominar y utilizar técnicas para priorizar requisitos
8.4.1 Conocer las ventajas de la trazabilidad de los requisitos
8.4.2 Dominar y utilizar distintos tipos de relaciones de trazabilidad
8.4.3 Dominar y utilizar formas de representación de las relaciones de trazabilidad
8.5.1 Dominar y utilizar el versionado de requisitos
8.5.2 Dominar y utilizar la formación de configuraciones de requisitos
8.5.3 Dominar y utilizar la formación de líneas de base de requisitos
8.6.1 Conocer la importancia de los cambios de requisitos
8.6.2 Conocer las funciones y miembros del comité de gestión de cambios
8.6.3 Dominar y utilizar los elementos de una solicitud de cambio de requisito
8.6.4 Dominar y utilizar distintos tipos de solicitudes de cambio
8.6.5 Dominar y utilizar un proceso para gestionar solicitudes de cambo.
362
Conocer el propósito y definición de los esquemas de atributos
• Para que asignar atributos a los requerimientos?

• La Información a cerca de los requerimientos debe ser documentada a través del ciclo de vida
entero del sistema.
– 3 Elementos básicos para la Definición de un Atributo
– nombre único
– descripción corta de los contenidos
– grupo de posibles valores que pueden ser asignados al atributo
– Plantilla de Requisitos
• La manera más simple de definir atributos de un requerimiento es por medio de una estructura
de tabla (plantilla).
– Esquema de atributos
• El grupo de todos los atributos definidos para una clase de requerimientos (e.g., requerimientos
funcionales, requerimientos de calidad) se llama un esquema de atributos.
363
Ejemplo de un Requisito y sus atributos
364
Conocer tipos importantes de atributos de los requisitos
• Los tipos mas frecuentes de atributos que se encuentran en proyectos y estándares

de ingeniería son:
Tipo de Atributo Significado

Corto, único identificador de un artefacto de
Identificador requerimiento del grupo de todos los requerimientos
considerados
Nombre Único, nombre caracterizador
Descripción Describe brevemente el contenido del requerimiento
Versión Versión actual del requerimiento
Autor Especifica el autor del requerimiento
Especifica la estabilidad aproximada del requerimiento.
La estabilidad es la cantidad de cambios que se esperan
Estabilidad
con respecto la requerimiento. Los posibles valores
pueden ser: “fijos”, “establecido”, y “volátil”.
En el sentido de un estimado de la cantidad de daño y
Criticalidad
pérdida y la probabilidad de ocurrencia.
Especifica la prioridad del requerimiento con respecto a
las propiedades escogidas de priorización, e.g.,
Prioridad “importancia para aceptación de mercado”, “orden de
implementación”, “costo de pérdida/oportunidad si no se
implementa”.
365
tipos importantes de atributos de los requisitos
366

367
Dominar y utilizar vistas sobre los requisitos
• Para mantener la complejidad de los requerimientos manejable para el equipo del proyecto, es
necesario consultar o acceder a la información de los requerimientos selectivamente y así
filtrarlos dependiendo de la tarea actual.
– Las Perspectivas o vistas de los requerimientos muchas veces son definidas para diversos
roles en el proceso de desarrollo.
• Ejemplos incluyen perspectivas para:
• el arquitecto,
• el programador,
• el gestor del proyecto, y
• el probador
• Dos tipos de Vistas Principales:
• Perspectivas selectivas en la fundación de requerimientos
• Perspectivas condensadas de los requerimientos
368
• Perspectivas selectivas de los requerimientos
En los tres casos de la figura las vistas son creadas al seleccionar los tipos de atributos, así como al determinar los atributos que deben
estar disponibles.
La definición de la primera perspectiva (1), por ejemplo, determina que solo esos requerimientos de los que “J. Locke” es responsable ,
son seleccionados, y que tienen la estabilidad de “fijos”.
De todos los requerimientos seleccionados, solo los atributos “identificador”, “nombre”, “descripción”, y “autor” están siendo
considerados.
369
• Perspectivas condensadas de los requerimientos
• Perspectivas condensadas pueden definirse al agregar los datos contenidos en la base de requerimientos. Una perspectiva
condensada puede, por ejemplo, contener información en el porcentaje de requerimientos que proceden de una fuente particular.
370

371
Conocer métodos para priorizar requisitos
• Debido a las diferentes priorizaciones en las diversas sub actividades, la prioridad de un

requerimiento puede determinarse por uno o más atributos (e.g., prioridad del contratista,
prioridad debido a la urgencia de implementación).
• Dependiendo del objetivo de la priorización, el criterio para priorizar los requerimientos (o la

combinación de dos o más criterios) es escogido.
– Los siguientes son ejemplos típicos de criterio de priorización:

• Costo de implementación
• Riesgo
• Diseño debido a implementación fallida
• Volatilidad
• Importancia
• Duración de la implementación (i.e., cuánto tarda en ser implementado).
372
Dominar y utilizar 4 técnicas para priorizar requisitos
1. Categorización y técnica de 10 primeros :

Un número de involucrados selectos organizan los requerimientos para ser priorizados con respecto a
un criterio específico. (por ejemplo impacto en el negocio)
Técnica de 10 primeros: Una vez categorizados (ver bullet anterior) los n requerimientos más
importantes para un criterio son seleccionados. Para estos requerimientos, un orden de categoría se
determina más tarde.
2. Clasificación de criterio simple:
• Este tipo de priorización se basa en asignar cada requerimiento a una de las siguientes clases de
prioridad [IEEE std. 830-1998].
– Obligatorio: Un requerimiento obligatorio es aquel que debe ser implementado a todo costo
o sino el éxito del sistema se ve amenazado.
– Opcional: Un requerimiento opcional es un requerimiento que no necesariamente necesita
ser implementado. Omitir unos cuantos requerimientos de esta clase no pone en riesgo el
éxito del sistema.
– Bueno tenerlo: requerimientos buenos de tener son requerimientos que no influencian el
éxito del sistema si no son implementados.
373
3. Clasificación Kano:
• El enfoque Kano introducido anteriormente también soporta la priorización de requerimientos.

– Insatisfactorios: un requerimiento especifica un insatisfactorio que el sistema debe tener
para ser introducido exitosamente en le mercado.
– Satisfactores: un requerimiento especifica un satisfactor si los clientes demanda

conscientemente la propiedad asociada. Satisfactores del sistema especifican el grado de
satisfacción del cliente. Un incremento en el número de satisfactores usualmente lleva a un
incremento en la satisfacción del cliente.
– Deleitador: un requerimiento especifica un deleitador si el involucrado no demanda

conscientemente la propiedad del sistema definida o el involucrado no espera la
implementación de la propiedad. La satisfacción del cliente se incrementa exponencialmente
al implementar deleitadores.
• Basado en los requerimientos clasificados de acuerdo a Kano, una priorización de los
requerimientos puede realizarse para planear las entregas del sistema..
374
4. Matriz de Priorización de acuerdo a Wiegers:

1. Determine los pesos relativos por beneficio, detrimento, costo, y riesgo.
2. Determine los requerimientos a priorizar.
3. Estime el beneficio relativo.
4. Estime el detrimento relativo.
5. Calcule los valores totales y los valores porcentuales de cada requerimiento.
6. Valor%(Ri)=Beneficio(Ri)*PesoBeneficio + Detrimento(Ri)*PesoDetrimento
7. Estime el costo relativo y calcule el costo porcentual para cada requerimiento.
8. Estime el riesgo relativo y calcule el riesgo porcentual para cada requerimiento.
9. Calcule las prioridades individuales de requerimientos.
10. Prioridad(Ri)= Valor%(Ri)/(Costo%(Ri)*PesoCosto + Riesgo%(Ri)*PesoRiesgo)
11. Determine la posición individual de los requerimientos.
…………………Ver ejemplo en la siguiente diapositiva
375
Este método es mas costoso en esfuerzo pero es mas exacto
376

377
Conocer las ventajas de la trazabilidad de los requisitos
• La trazabilidad de un requerimiento es la habilidad de seguir los requerimientos a lo largo del

curso del ciclo de vida del sistema.
Los beneficios que ofrece la trazabilidad de requisitos son:
1. - Simplificación de la verificabilidad. (muy útil en actividades de pruebas)
2. - Permite la identificación de características o requisitos del sistema que no son necesarias.
(cuando no trazan hacia ningún objetivo/necesidad del negocio)
3. - Apoyo al análisis de impacto. (al cambiar un requisito ayuda a poder ver a cuales otros
afecta dicho cambio)
4. - Apoyo a la reutilización.
5. - Apoyo a la identificación de responsabilidades. (en desarrollo, requisitos o pruebas)
6. - Apoyo al mantenimiento y administración del sistema.
378
Dominar y utilizar distintos tipos de relaciones de trazabilidad
Hay tres clases de relaciones de trazabilidad que se deberían tener en cuenta:
• 1- Trazabilidad pre-especificación de requisitos.
– Es trazar enlaces entre requerimientos y esos artefactos que son la base de los
requerimientos, e.g., artefactos como la fuente de origen de un requerimiento (artefactos
previos).
• 2- Trazabilidad pos-especificación de requisitos.
– Comprende la trazabilidad de información entre requerimientos y artefactos de actividades
de desarrollo subsecuente, por ejemplo, tales artefactos pueden ser componentes,
implementación, o casos de prueba que pertenecen a un requerimientos (artefactos
posteriores).
• 3- Trazabilidad entre requisitos. [Gotel y Finkelstein 1994]
– La trazabilidad entre requerimientos se refiere a mapear dependencias entre
requerimientos. Un ejemplo de este tipo de trazabilidad es la información que un
requerimiento refina otro requerimiento, lo generaliza o lo remplaza.
• Guía: Sólo se debería mantener aquella información de traza para la que exista un uso claro.
• Guía: La información a grabar debe ser escogida con respecto al propósito al que va a servir.
379
Dominar y utilizar formas de representación de las relaciones de
trazabilidad
• Algunas formas típicas de representar la trazabilidad son:
• Referencias basadas en texto e hipervínculos
– Esta manera simple de representar información de trazabilidad de un requerimiento consiste
en anotar el artefacto objetivo como una referencia textual en el requerimiento (artefacto
inicial) o establecer un hipervínculo entre el artefacto inicial y el artefacto objetivo.
• Matrices de rastreo
– Las filas en la matriz de rastreo contienen los artefactos iniciales (requerimientos). En las
columnas, los artefactos objetivo (e.g., fuentes de requerimientos, artefactos de desarrollo,
requerimientos) son representados. Si un vínculo de rastreo existe entre un artefacto inicial
en la fila n y un artefacto objetivo en la columna m, la celda (n,m) se marca en la matriz de
rastreo.
• Gráficas de Rastreo
– Una gráfica de rastreo es una gráfica en que tozos los nodos representan artefactos y todas
las aristas representan relaciones entre artefactos. La distinción entre diferentes artefactos y
tipos de trazabilidad pueden realizarse por medio de la asignación de diferentes atributos a
los nodos y aristas de la gráfica.
…. Ver ejemplos.
380
Dominar y utilizar formas de representación de las relaciones de
trazabilidad
Tipos de Trazabilidad de Requisitos
Trazabilidad entre
Requisitos
Artefactos que son la Artefactos que están

basados en los
base de los requisitos Requisitos Requisitos (artefactos
(artefactos previos)
Trazabiloidad Trazabilidad posteriores)
Origen o Pre- RS Post- RS
fuente de los Realizacion
Requisitos de los
Requisitos
381
Ejemplo de tres tipos distintos de Trazabilidad
Trazabilidad Pre-RS
“El cliente desea la R-11 El sistema de Navegación deberá

interacción mas simple estar en capacidad de recibir comandos
posible con el sistema de de voz del usuario
navegación”
es derivado de
Trazabilidad entre requisitos
se origina en
Interesados o R-14 El sistema de navegación deberá
Relacionados ofrecer al usuario la habilidad de
se origina en ingresar el destino a través de
comandos de voz.
“Queremos ganar liderazgo en Trazabilidad

Post-RS
el mercado tecnológico para el
año 2010”
Documento de Estrategia de Se cristaliza o
Empresa v. 1.2 realiza a través de Diseño Preliminar
Diseño Definitivo
Casos de Prueba
Implementación
382
Ejemplo de Matriz de Trazabilidad
Artefactos Objetivo
Derivados Req-1 Req-2 Req-3 Req-4 Req-5

Req-1 X
Req-2 X
Req-3 X
Req-4 X
Req-5
383
Ejemplo de una gráfica de trazabilidad
Req-1
Req-6 Comp-3
C-1
Req-2
C-2
C-4
Req-5
Req-3
C-3
Comp-2
Comp-1
Información a cerca del contexto del
sistema.
Requisitos
Componentes
384

385
Dominar y utilizar el versionado de requisitos
• El versionado y configuración de requisitos posibilita, a lo largo del ciclo de vida de un sistema o

producto, el registro de los estados de los requisitos y los documentos de requisitos disponibles.
• El número de versión de un requisito incluye al menos dos componentes:
– A) Versión.
– B) Incremento.
386
Dominar y utilizar la formación de configuraciones de requisitos
• Las configuraciones de requisitos se forman según dos dimensiones:

Dimensión del producto: los requisitos individuales como un conjunto
Dimensión de la versión: los diferentes estados de cambio de un requisito individual.
• - Una configuración de requisitos tiene varias propiedades típicas:

– - Vínculo lógico entre los requisitos de una configuración.
– - Consistencia de los requisitos de una configuración.
– - Existencia de un identificador único para la configuración.
– - Inmutabilidad de los requisitos de una configuración. (sólo puede haber como máximo una
versión de cada requisito individual.)
– - Punto de partida para la vuelta a versiones anteriores de la base de requisitos.
387
Dominar y utilizar la formación de líneas de base de requisitos
• Las líneas base de requisitos:

– Son configuraciones específicas de requerimientos que típicamente comprenden versiones
estables de requerimientos y también muchas veces definen una entrega del sistema. se
caracterizan por contener versiones estables de los requisitos .
– Frecuentemente definen los incrementos de distribución del sistema (entrega del sistema).
• Sirven para:
• Bases para planear la entrega:
• Estimar el esfuerzo implicado en la implementación.
• Comparación con productos competentes:
388
389
Conocer la importancia de los cambios de requisitos
• Los requisitos cambian y evolucionan a lo largo del ciclo de vida de un sistema. Los cambios en
los requisitos son gestionados y tratados en proceso de gestión de cambio sistemático.
• Cambios en los requerimientos per sé no son negativos.
• Las razones de cambio en los requerimientos pueden ser incontables:
– errores en los requisitos
– requerimientos incompletos,
– los involucrados,
– modificaciones de la ley,
– nuevas tecnologías,
– competencia adicional en el mercado, ….. Entre otras.
• Si los cambios en los requerimientos ocurren frecuentemente, el desarrollo del sistema que está
acordado con todos los involucrados implicados se hace casi imposible
• Si son muy poco frecuentes puede significar falta de interés o de patrocinio en el proyecto
• Cuando los cambios en requisitos se consideran necesarios, éstos deben documentarse en la
forma de solicitud de cambio y enviarse al comité de control de cambios.
390
Conocer las funciones y miembros del comité de gestión de cambios
• El Comité de control de Cambios es responsable de gestionar las solicitudes de cambio

entrantes.
• Actividades del Comité de Gestión de Cambios:
– - Clasificación de las solicitudes de cambio entrante.
– - Determinación del esfuerzo necesario para realizar el cambio.
– - Evaluación de la relación esfuerzo-beneficio de la petición de cambio.
– - Definición de nuevos requisitos en base a la solicitud de cambio.
– - Decisión de aceptar o rechazar una solicitud de cambio.
– - Priorizar la solicitudes de cambio aceptadas.
– - Asignar las solicitudes de cambio aceptadas a proyectos de cambio.
391
Conocer las funciones y miembros del comité de gestión de cambios
• Los Integrantes típicos del comité de control de cambios son:

– El gestor de cambio:
• El director de la junta de control de cambio es el gestor de cambio.
• El gestor de cambio tiene la tarea, entre otras, de mediar entre las partes en
caso de conflicto y negociar las decisiones con las respectivas partes. Además,
el gestor de cambio es responsable de comunicar y documentar las
decisiones.
– Clientes,
– Arquitectos,
– Representantes de los usuarios,
– El gestor de la calidad
– Los ingenieros de requisitos.
392
Dominar y utilizar los elementos de una solicitud de cambio de
requisitos
– Una solicitud de cambio incluye como mínimo la información siguiente:

• - Identificador de la solicitud de cambio.
• - Título de la solicitud de cambio.
• - Descripción del cambio necesario.
• - Motivos que justifican la necesidad del cambio.
• - Fecha de la solicitud de cambio.
• - Solicitante del cambio.
• - Prioridad del cambio según la percepción del solicitante.
393
Información adicional en la Solicitud de Cambio
• Además de la información del cambio acá presentada, la siguiente información para gestión de
cambio de requerimientos es de gran ayuda:
– Validador de cambios: la persona que verifica si el cambio se ha realizado correctamente.
– Estado de análisis de impacto: marca si un análisis de impacto ha sido realizado en la
solicitud de cambio
– Estado de decisión del CCB: marca si la junta de control de cambio ya ha decidido a cerca de
la solicitud de cambio.
– Prioridad del CCB: Documenta la prioridad de la solicitud de cambio asignada por la junta de
control de cambio.
– Responsable: documenta la persona que está a cargo de realizar la solicitud del cambio.
– Entrega del sistema: documenta en qué entrega del sistema tiene que estar implementado el
requerimiento a cambiar.
394
Dominar y utilizar distintos tipos de solicitudes de cambio
• Después de entregarse, la solicitud de cambio se clasifica por el gestor de cambios y la junta de

control de cambio. Típicamente, el gestor de cambio pre clasifica las solicitudes de cambio
presentadas que van a introducirse, adaptarse (si es necesario), y finalmente aprobarse (o
rechazarse) durante la próxima reunión de la junta de control de cambio.
• Una solicitud de cambio puede clasificarse de acuerdo a las tres siguientes categorías.
– Cambio correctivo de un requerimiento: una solicitud de cambio se clasifica así, si la razón
para la solicitud de cambio es una falla del sistema durante su operación y puede atribuirse a
un error en los requerimientos.
– Cambio adaptativo de requerimientos: una solicitud de cambio se clasifica así, si el cambio
requerido requiere que el sistema sea rectificado. Una posible razón para un cambio
adaptativo de requerimiento, puede ser un cambio en el contexto del sistema, e.g., una
nueva tecnología está disponible o el límite del sistema fue alterado (vea sección 2.2)
– Cambio excepcional (arreglo en caliente): una solicitud de cambio se clasifica como un
cambio excepcional si el cambio debe hacerse inmediatamente y a todo costo. Los cambios
excepcionales pueden ser correctivos o adaptativos.
395
Dominar y utilizar un proceso para gestionar solicitudes de cambo.
• El proceso de gestión de cambios contempla los siguientes pasos:
1. - Análisis de impacto y evaluación del cambio.

2. - Asignación de prioridad a la solicitud de cambio.
3. - Asignación del cambio a un proyecto del cambio.
4. - Respuesta al solicitante respecto de la aceptación o rechazo de su solicitud de cambio.
• El método para procesar cambios de requerimientos depende de su clasificación.

– Por ejemplo, cambios excepcionales deben ser analizados, evaluados, decididos, y
potencialmente implementados ya.
– En contraste, cambios de requerimientos de tipo adaptativo son procesados por partes en un
punto más adelante en el tiempo, típicamente, tan pronto como la entrega siguiente del
sistema (o alguna subsecuente) es inminente. De otro lado, cambios a los requerimientos de
tipo correctivo son usualmente analizados, evaluados, y si es necesario implementados, más
bien de manera pronta, luego de que la solicitud de cambio se haya presentado.
Gráfica de ejemplo de un proceso de Cambio
Analisis de Impacto
Evaluación de
lCambio
(Cambio aprobado) (Cambio rechazado)
Priorización al cambios
en Requisitos
Comunicación del
rechazo
Asignación del cambio
A un proyecto de cambios
397
CONTENIDO DEL CURSO
398
Capítulo 9. Apoyo de herramientas (1 hora)
• 9.1 Conocer las 8 características de una herramienta de gestión de requisitos

9.2 Conocer los cinco aspectos a tener en cuenta al introducir herramientas de requisitos
9.3 Conocer las siete vistas de las herramientas de gestión de requisitos
399
Beneficios de las Herramientas
• Presentación de los datos de manera acertada y legible
• Rastreo preciso y trazabilidad de la información
• Generación de versiones
• Uso múltiple por mucha gente
• Conexiones con otras herramientas
• Capacidad de generar reportes y presentaciones gráficas
400
Las 8 características de una herramienta de gestión de requisitos
Se pueden utilizar como apoyo a la IR muchas herramientas de desarrollo de sistemas, por ejemplo, herramientas de
gestión de pruebas, herramientas de gestión de la configuración, wikis, software de ofimática y herramientas de
visualización. También las herramientas de modelado son importantes para la IR con el propósito de crear y analizar
información en forma de modelos.
• Las herramientas de gestión de requisitos son herramientas desarrolladas específicamente para

la IR. Estas herramientas ofrecen las siguientes características :
1. - Gestionar distintos tipos de información.

2. - Gestionar las relaciones lógicas entre la información.
3. - Identificar artefactos de forma unívoca.
4. - Hacer que la información se accesible de forma flexible y segura, por ejemplo a través del
control de acceso.
5. - Soportar distintas vistas de los datos.
6. - Organizar la información, por ejemplo, mediante la asignación de atributos o la formación de
jerarquías.
7. - Generar informes sobre la información recopilada.
8. - Generar documentos a partir de la información.
NOTA : Las herramientas ofimáticas estándar ofrecen todas estas funcionalidades pero de manera limitada. Las
herramientas especializadas de IR refinan estas funcionalidades, por ejemplo, mediante gestión de trazabilidad.
401
Capítulo 9. Apoyo de herramientas (1 hora)
• 9.1 Conocer las ocho características de una herramienta de gestión de requisitos

9.2 Conocer los cinco aspectos a tener en cuenta al introducir herramientas de requisitos
402
Los 5 aspectos a tener en cuenta al introducir herramientas de
requisitos
• Sólo debe buscarse una herramienta de IR cuando ya se hayan implantado los procedimientos y
las técnicas de IR. La introducción de una herramienta requiere responsabilidades y
procedimientos en la IR claramente establecidos. En el proceso se deberían considerar los
siguientes aspectos:
1. - Considerar los recursos necesarios.

2. - Evitar riesgos utilizando antes la herramienta en proyectos piloto.
3. - Evaluar las herramientas utilizando criterios predefinidos. (ver las 7 vistas de evaluación
de herramientas en este mismo capítulo)
4. - Tener en cuenta los costes más allá de los costes de licencia.
5. - Formar a los empleados.
403
Capítulo 9 Apoyo de herramientas (1 hora)
• 9.1 Conocer las ocho características de una herramienta de gestión de requisitos

9.2 Conocer los cinco aspectos a tener en cuenta al introducir herramientas de
requisitos
404
Las 7 vistas de las herramientas de gestión de requisitos
Hay muchos aspectos que deben considerarse cuando se evalúa una herramienta de IR. Este proceso
puede estructurarse utilizando las siete vistas siguientes:
1. - Vista del proyecto (por ejemplo, apoyo a la planificación del proyecto).

2. - Vista del usuario (especialmente la usabilidad).
3. - Vista del producto (funcionalidad).
4. - Vista del proceso (soporte metodológico).
5. - Vista del proveedor de la herramienta (por ejemplo, servicios que ofrece el proveedor).
6. - Vista técnica (por ejemplo, interoperabilidad, escalabilidad).
7. - Vista económica (costes).
Nota: Para cada una de estas vistas se debería establecer una serie de criterios de evaluación claros.
405
Etapas – Fases y Flujos de Trabajo en
Ingeniería de Requisitos
Herramienta Indudata Plugins
406
Diagrama de Flujo Técnico de Requisitos
407
Fases de un Proyecto de Ingeniería de Requisitos
408
Modelo de Etapa de Definición de IR
Página 409
409
Modelo de Etapa de Validación o Realización de IR
410
Modelo de Etapa de Finalización de IR
411
IIBA
412
Servicios Indudata
Ingeniería de Requerimientos, Pruebas de Software

ITIL
PMP
COBIT
413
Preguntas, Comentarios,
y Discusiones sobre
el curso?
414
Gracias por su atención
y participación!
Esperamos que este curso sea útil en su carrera profesional
415
REFERENCIAS
416
Referencias
Adelman, Sid, Moss, Larissa, and Abai, Majid:, Data Strategy, Prentice Hall, 2005.
Ambler, S: Agile Analysis, Retrieved Apr. 08, 2005, from Ambysoft Web site:
http://www.agilemodeling.com/essays/agileAnalysis.htm.
Ambler, S: When Does(n't) Agile Modeling Make Sense?, Retrieved Apr. 08, 2005, from
Ambysoft Web site:
http://www.agilemodeling.com/essays/whenDoesAMWork.htm.
Ambler, Scott W:, The Object Primer: Agile Model-Driven Development with UML 2.0,
Third Edition, Cambridge University Press, 2004.
Armour, Frank, and Miller, Granville: Advanced Use Case Modeling: Software
Systems, Addison-Wesley, 2001.
Baird, Jim; Little, A. Ross; LeBlanc, Valerie, and Molnar, Louis: Business
Requirements Analysis: Applied Best Practices, Fourth Edition, The Information
Architecture Group, 2001.
417
Referencias
Bechtold, R: Essentials of Software Project Management, Vienna, VA, Management

Concepts, 1999.
Bittner, Kurt, and Spence, Ian: Use Case Modeling, Addison-Wesley, 2002.
The Carnegie Mellon University, Software Engineering Institute: The
Capability Maturity Model, Addison Wesley Longman, Inc., 1994.
Cockburn, Alistair: Writing Effective Use Cases, Addison-Wesley, 2000.
Constantine, Larry, and Lockwood, Lucy: Software for Use: A Practical Guide to
the Models and Methods of Usage-Centered Design, Addison-Wesley, 1999.
Davis, Alan M.: 201 Principles of Software Development, McGraw-Hill, 1999.
418
Referencias
Dye, Lowell D. and Pennypacker, James S: Project Portfolio Management, Selecting

and Prioritizing Projects for Competitive Advantage, Pennsylvania: Center for
Business Practices, 1999.
Dymond, K.M.: A Guide to the CMM, (1995) Process, Inc., Annapolis, MD.
Erikkson, Hans-Erik, and Penker, Magnus: Business Modeling With UML: Business
Patterns at Work, John Wiley & Sons, 2003.
Fowler, M.: The New Methodology, 1999, Retrieved Apr. 08, 2005, from
martinfowler.com Web site:
http://www.martinfowler.com/articles/newMethodology.html.
Fowler, Martin: UML Distilled Third Edition: A Brief Guide to the Standard Object
Modeling Language, Addison-Wesley, 2003.
Friedman, Dan P and Weinberg, Gerald M.: Handbook of Walkthroughs, Inspections,
and Technical Reviews: Evaluating Programs, Projects and Products, 3rd edition.
419
Referencias
Gottesdiener, Ellen: The Software Requirements Memory Jogger, GOAL/QPC,

2005.
Hadden, R.: Leading Culture Change in Your Software Organization. Vienna, VA:
Management Concepts, 2003.
Halpin, Terry: “Business Rules and Object-Role Modeling”, Database
Programming and Design, October 1996. Available at http://www.orm.net/.
Harmon, Paul: Business Process Change: A Manager’s Guide to Improving,
Redesigning,and Automating Processes. Morgan Kaufman Publishers, 2003.
Hass, Kathleen B.: Business Analyst as Strategest. Vienna, VA: Management
Concepts, 2006.
Hay, David C.: Requirements Analysis: From Business Views to Architecture.
Prentice Hall, 2003.
420
Referencias
IEEE Computer Society. IEEE Std. 830-1998: IEEE Recommended Practice for
Software Requirements Specifications, Institute of Electrical and Electronics
Engineers, 1998.
IEEE Computer Society. IEEE Std. 1233-1998: IEEE Guide for Developing System
Requirements Specifications, Institute of Electrical and Electronics Engineers, 1998.
Intervista Institute, Inc.: Managing Integration in a Federated Architecture
Environment, http://www.intervista-institute.com/articles/zachman-by-
kull.html, 2003.
Jackson, Michael: Software Requirements and Specifications: A Lexicon of Practices,
Principles and Prejudices, Addison-Wesley, 1995.
Jacobson, Ivar, and Ng, Pan-wei: Aspect-Oriented Software Development with Use
Cases, Addison-Wesley, 2004.
421
Referencias
Jalote, Pankaj: CMM in Practice, Addison Wesley Longman, Inc., Reading, MA, 2000.
Goodpasture, John C.: Managing Projects for Value, Vienna, VA: Management
Concepts, Inc., 2002.
Hertzel, Bill: The Complete Guide To Software Testing, Second Edition, Wiley-QED
Publication, 1993.
Kaplan, R. and Norton, D.: The Balanced Scorecard: Translating a Strategy into Action,
Boston: Harvard Business School Press, 1996.
Kit, Edward: Software Testing in the Real World, Addison-Wesley Publishing
Company, 1995.
Kovitz, Benjamin L.: Practical Software Requirements: A Manual of Content and Style,
Manning Publications Co., 1999.
Larman, Craig: Applying UML and Patterns: An Introduction to Object-Oriented Analysis
and Design and Iterative Development, Third Edition, Prentice-Hall, 2004.
422
Referencias
McConnell, Steve: Rapid Development, Microsoft Press, 1996.

Mooz, H., Forsberg, K., & Cotterman, H.: Communicating Project Management:
The Integrated Vocabulary of Project Management and Systems Engineering,
Hoboken, NJ: John Wiley and Sons, 2003.
Mooz, Hal, Forsberg, Kevin, and Cotterman, Howard: Communicating Project
Management, The Integrated Vocabulary of Project Management and Systems
Engineering, John Wiley and Sons, Inc., 2003.
Moss, Larissa T., and Atre, Shaktu: Business Intelligence Roadmap: The Complete
Project Lifecycle for Decision-Support Applications. Addison Wesley, 2003.
Myers, Glenford J.: Art of Software Testing, Second Edition, John Wiley and
Sons, 2004.
National Information Standards Organization: Understanding Metadata. NISO
Press, 2004.
423
Referencias
Nielsen, Jakob: Usability Engineering, Morgan Kaufmann. San Diego. 1993.

OSD Comptroller iCenter:
http://www.dod.mil/comptroller/icenter/learn/abcosting.htm
Página-Jones, Meilir: The Practical Guide to Structured Systems Design, Second Edition,
Yourdon Press, 1988.
Paul, Debra, and Yeats, Donald, eds.: Business Analysis, The British Computer
Society, 2006.
Project Management Institute, Inc.: A Guide to the Project Management Body of
Knowledge, Third Edition, Newtown Square, PA., 2004.
Rad, Parviz F. and Levin, Ginger: Advanced Project Management Office, CRC Press
LLC, Boca Raton, FL., 2002.
Rational Software Corporation: Rational Unified Process, 1987-2001.
424
Referencias
Robertson, Suzanne and James: Mastering the Requirements Process, Addison-

Wesley Inc., 1999.
Rumbaugh, James, Jacobson, Ivar, and Booch, Grady: The Unified Modeling
Language Reference Manual, Second Edition, Addison-Wesley, 2004.
Scholtes, Peter R.: The Team Handbook, How to Use Teams to Improve Quality,
Joiner Associates, Inc., Madison, WI. 1988.
Sharp, Alec, and McDermott, Patrick: Workflow Modeling: Tools for Process
Improvement and Application Development, Artech House, 2001.
Sodhi, J., & Sodhi, P.: IT Project Management Handbook, Vienna, VA:
Management Concepts, 2001.
Sodhi, Jag and Sodhi, Prince: Managing IT System Requirements, Management
Concepts, Inc. 2003
425
Referencias
Sommerville, Ian, and Sawyer, Pete: Requirements Engineering: A Good Practice Guide,
John Wiley and Sons, 1997.
The Standish Group: Unfinished Voyages: A Follow-up to the Chaos Report, Retrieved
Apr. 08, 2005, from The Standish Group Web site:
http://www.standishgroup.com/sample_research/unfinished_voyages_1.php.
Stevens, Richard; Brook, Peter; Jackson, Ken, and Arnold, Stuart: System
Engineering,Coping with Complexity, Pearson Education, 1998.
Thayer, Richard H. and Dorfman, Merlin: Software Requirements Engineering Second
Edition, IEEE Computer Society, 1997.
United States Department of Justice, The Department of Justice Systems Development
Life Cycle Guidance Document, http://www.usdoj.gov/jmd/irm/lifecycle/table.htm.
von Halle, Barbara, Business Rules Applied: Building Better Systems Using the Business
Rules Approach, John Wiley & Sons, 2003.
426
Referencias
Wiegers, K.: Software Requirements: Practical Techniques for Gathering and

Managing Requirements Throughout the Product Development Cycle. 2nd ed.
Redmond, WA: Microsoft Press, 2003.
Wiegers, Karl E., Software Requirements, Second Edition, Microsoft Press, 2003.
Young, R.: Effective Requirements Practices, Addison-Wesley Information
Technology Series. Boston: Addison-Wesley, 2001.
427
Referencias
IEEE Std 1362-1998 – Guide for Information Technology – System Definition – Concept of
Operations (ConOps) Document
IEEE Std 1233-1998 – IEEE Guide for Developing System Requirements Specifications
IEEE Std 830-1998 – IEEE Recommended Practice for Software Requirements Specifications
428

IREB OFICIAL Cap 1-9 FULL

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

IREB OFICIAL Cap 1-9 FULL

Cargado por

Copyright:

Formatos disponibles

1

Certificación de Profesional en Ingeniería de

• Este curso está basado en

• Los términos provienen del glosario

• Materiales de referencia, glosario y ayudas de estudio para aquellos en búsqueda de certificación

• Para uso en los ejercicios

• Un cuaderno para hacer los ejercicios

• En algunos ejercicios, usted se desempeña como Ingeniero de Requisitos del Proyecto

• Otros ejercicios se han adicionado para ilustrar puntos específicos

• Este material está diseñado para ayudarlo a convertirse en un

• Por favor pase los siguientes minutos escribiendo qué

• Use la página siguiente para sus objetivos

 No deje terminar el curso sin alcanzar uno solo de los objetivos!

Por favor únase a él

 Segundas opiniones y desacuerdos son

Por qué está aquí?

Qué quiere aprender, discutir y enseñar?

…así como de esto.

• 1.1 Conocer los síntomas y los motivos de una IR inadecuada

• Un requisito de poca calidad es aquel que no comunica efectivamente el comportamiento

• Algunos requisitos están mal

• El desarrollador no sabe qué implementar, entonces no se implementa nada

• El desarrollador adivina qué debe implementar

• El desarrollador se hace su propia idea

Como se documentó el El producto instalado Como le cobraron al Como se le brindó La verdadera

• Dependiendo de a quién le crea, requisitos incorrectos o no válidos representan entre 15 y

• Un mal requisito encarece mientras permanezca en el proyecto debido al esfuerzo perdido y la

• De cualquier manera, esto es un costo elevado!

– Costo del Ingeniero de Requsitos para reparar/remplazar el requisito

• Si un mal requisito es identificado durante el diseño de arquitectura/código, son de esperar

– El tiempo empleado por el desarrollador resolviendo el misterio del requisito problema

• Y no olvidar todos los costos previos incurridos!

– Tiempo de cada desarrollador generando código

• Y no olvidar todos los costos previos incurridos!

• Y no olvidar todos los costos previos!

• Y no olvidar todos los costos previos!

– Costos de soporte técnico y mesa de ayuda

• Posibilidad de perder ventas

• Y no olvidar todos los costos previos!

• Una consideración más de costos….

• Un mal requisito no impacta solamente el cronograma del proyecto actual

• Los equipos de trabajo se frustran!

• No se toma el suficiente tiempo en el análisis

• El representante del cliente no conoce a cabalidad las necesidades del cliente

• Se asumen requisitos como “obvios” y que no necesitan declararse

• Problemas de comunicación en cualquier etapa de desarrollo del proyecto

• Programación de tiempo inadecuada – apresurarse en generar código, o la etapa de pruebas,

• Se “explica por sí mismo”, generalmente no es así

• Errores de comunicación debido a diferentes niveles de conocimiento y experiencia

• Una clara comunicación entre las partes interesadas

• Un cronograma y presupuesto válidos

• Uso eficiente de los recursos sin repetir tareas

• Mantener el trascurso del proyecto bajo control

• Buenos requisitos son como buena tubería

• Cómo se comparan malos requisitos con mala tubería?

• Compare los costos de los siguientes casos:

– Un requisito no identificado de desempeño o eficiencia

• 1.1 Conocer los síntomas y los motivos de una IR inadecuada

Planeación, Administración y Control General de la Calidad

• 1.1 Conocer los síntomas y los motivos de una IR inadecuada

• El Ingeniero de Requisitos exitoso debe ser capaz de:

– Identificarse con las partes interesadas a lo largo del proyecto

• La teoría de la comunicación trata de entender la comunicación en términos de normas sociales,