Ingenieria Requisitos

Ingeniería de Requerimientos
Profesional
Formación para “Profesional certificado en ingeniería
de requerimientos – nivel básico ireb”
De acuerdo al programa de estudios versión 2.1
(O 1,03,20 11) ireb
Version esp 1,0
0 – generalidades
01 contenido
• Organización
– Agenda, descansos, cuide de las instalaciones
– Por favor, apague su móvil o manténgalo en silencio.
• Presentación de los participantes y el formador
– Datos personales (nombre, formación)
– Compañía, puesto y experiencia general (proyectos
actuales)
– Experiencia en ingeniería de software e ingeniería de
requisitos.
0 – generalidades
01 contenido
El Curso
• Presenta los conocimientos fundamentales de Ingeniería de
Requerimientos (IR)
• Conforma la base de la preparación del examen “Profesional
Certificado en Ingeniería de Requisitos – Nivel Básico” de aceurdo
con el IREB.
Principales objetivos de la formación del Profesional Certificado en IR
• Enseñar la función y alcance de la IR
• Desarrollar una comprensión general de la IR
• Adquirir los conocimientos necesarios en el ámbito teórico y
práctico
• Explicación de términos
• Los participantes del curso pueden asociar la IR con los aspectos
prácticos de su entorno de trabajo
0 – generalidades
02 estructura
El curso está dividido en nueve capítulos de acuerdo con

el sillabus del IREB
• Capítulo I Introducción
• Capítulo II Definición del Sistema y Contexto
• Capítulo III Obtención de requisitos
• Capítulo IV Documentación de requisitos
• Capítulo V Documentación en lenguaje natural
• Capítulo VI Documentación basado en modelos
• Capítulo VII Verificación y ajuste de requisitos
• Capítulo VIII Gestión de requisitos
• Capítulo IX Herramientas de apoyo
0 – generalidades
03 material
Documentos de apoyo
• Diapositivas de la presentación
• Ejercicios
• Lista de referencias (véase Capitulo X-
Apéndice)
I – introducción
00 contenido
Capítulo 1 - Introducción
• 1/01 Síntomas y razones de una Ingeniería de
Requisitos (IR) inapropiada
• 1/02 Las cuatro actividades principales de la IR
• 1/03 El papel de la comunicación en la IR
• 1/04 Características de un ingeniero de requisitos
• 1/05 Los tres tipos de requisitos
• 1/06 Entendiendo el rol de los requisitos de
calidad
I – introducción
01 síntomas y razones de una ingeniería de requisitos (ir) inapropiada
Causas de proyectos
fallidos 10,6%
falta de 13,1%
8,7%
recursos requisitos
problemas
incomplet
técnicos
9,9% 8,7% os 12,4%
requisitos cambio en falta de
no 8,7% falta implicació
requisitos
realistas de gestión n del
8,7%
8,1% ausencia de TI usuario
ausencia
de 7,5% el
de apoyo
planificación producto
de la
queda
dirección
obsoleto
Suma de las causas En algunos casos, la sum

asociadas a IR= 44,1% De las causas asociadas
Puede llegar al 60%
“… una buena gestión de requisitos fue el factor más decisivo de éxito”

I – introducción
Causas de proyectos
fallidos
Objetivos
Inciertos Requisitos en
constante
cambio
Diferentes
usos del Desafíos
lenguaje
para el Requisitos
análisis de de poca
requisitos calidad
Planificación
poco precisa
Atributos
Alta innecesari
complejid os
ad
I – introducción
Requisitos de poca calidad
Requisitos faltantes
• Porque es “obvio” (requisitos implícitos)
• Porque se debe hacer de inmediato…
• Porque no se han utilizado todas las fuentes de información
Requisitos incorrectos
• Porque se han utilizado fuentes de información incorrectas/equivocadas
Contradicciones
Redundancias
• Hacen más difícil el mantenimiento – los cambios en los requisitos se
deben mantener también de forma redundante
Ambiguos
Conducen a múltiples interpretaciones
Diferentes enfoques
Distintas características culturales y de formación (background)
conducen a interpretaciones distintas
I – introducción
Relevancia de la IR en proyectos
• Incremento de los costos de los defectos
– Definición de requisitos 1
– Programación 20
– Aceptación 100 según [BOEHM81]
• Requisitos completos y de alta calidad son la base
para el éxito de un proyecto
• Los requisitos faltantes deben ser detectados de
forma temprana
• A través de IR se identifican los riesgos y pueden ser
tratados de forma temprana
I – introducción
02 las cuatro actividades principales de la ir
Requisito (requirement) [IEEE Std. 610,12-1990]

Un requisito es:
(1) Una condición o capacidad requerida por un usuario, una persona
o un sistema, para resolver un problema o como un medio para
alcanzar un objetivo.
(2) Una condición o capacidad que debe cumplirse o estar presente en
el sistema o subsistema para cumplir con un contrato, estándar,
especificación y otros documentos formales
(3) Una representación documentada de una condición o capacidad
según se define en los puntos (1) o (2).
Interesados (stakeholder)
Un implicado de un sistema es una persona u organización con
influencia (directa o indirecta) sobre los requisistos del sistema.
I – introducción
Ingeniería de Requisitos (Requirements Engineering)

La Ingeniería de Requisitos es un enfoque sistemático y disciplinado
para la especificación y gestión de requerimientos con los siguientes
objetivos:
(1) Conocer los requerimientos relevantes, asegurar un consenso
entre los dos implicados acerca de estos requerimientos,
documentarlos de acuerdo a los estándares establecidos, y
gestionarlos sistemáticamente.
(2) Entender y documentar los deseos y necesidades que los
implicados, especificar y gestionar los requerimientos para
minimizar el riesgo de poner en producción un sistema que no
cumple con los deseos y necesidades de los stakeholders.
I – introducción
1. Elicitar (elicit)
– Extraer información/requerimientos utilizando diferentes técnicas
– Identificar, detallar y refinar
2. Documentar (document)
– Definir la forma de documentar (lenguaje natural o modelado)
adecuado para el proyecto
3. Verificar y ajustar (verify and adjust)
– Asegurar la calidad en una fase tem`rana
4. Administrar (manage)
– Estructurar y organizar los requerimientos, gestionar su
disponibilidad, modificar los requerimientos de forma consistente e
implementarlos en el proyecto.
I – introducción
La IR en distintos modelos de proceso
Inicio
– Modelo de cascada
Análisis
• Proceso secuencial
• IR en fases tempranas del proyecto (antesDiseño
del diseño)
Implementa
• Baja volatilidad de requisitos ción
Desplieg
– Modelo Ágil (XP, Scrum…) ue
Uso
• Los requerimientos se obtienen cuando van a ser implementados
• Alta volatilidad de requisitos
• Incorporación (cercana) del cliente/consumidor al proceso
– Iterativo-incremental
• IR es una actividad continua
• La planificación del proyecto y los requisitos están fuertemente
vinculadas
• Por ejemplo: Rational Unified Proces (RUP)
I – introducción
03 el papel de la comunicación en la ir
Los requisitos deben ser comunicados

– El lenguaje como medio para comunicar
– La forma de comunicación elegida
– Elección de las expresiones más sencillas
– Conocimiento implícito
Influido por:
– Bagaje cultural (background)
– Experiencia y educación
– Aspectos sociales
La comunicación está caracterizada por procesos de
transformación que siempre pueden conducir a una pérdida
de información.
I- Introducción
04 Las cuatro actividades principales de la IR
Ingeniero de Requisitos (“Requirements engineer”)
• Puesto clave en un proyecto, punto central en la
recopilación y administración de información.
Organizaci Alcance del Proyecto
ón
Dirección Jefe de
Cliente
Proyecto
Marketing Ingeniero de Documentado

Requisitos res
Gestión de Desarrolla Arquitecto
la Calidad Probador
dor de sistema
Legislador /
Abogados
I- Introducción
Características necesarias del ingeniero
dePorrequerimientos (1) (autoconfianza)
una parte seguridad en sí mismo
1 • Justificada por su experiencia y sobre todo por su competencia en

el negocio.
• Determinación en el seguimiento y clarificación de puntos
abiertos (pendientes de aclaración)
Por otra parte no debe sobrestimar sus propias capacidades.
Como interlocutor en un debate con especialistas, no es posible

2 creer que tiene conocimiento de todo.
Deberá mediar entre los puntos de vista de los distintos interesados:
• Detectar y resolver conflictos.

I- Introducción
dePor
requerimientos (2)
una parte habilidad para convencer
• Comportamiento orientado a la solución.
3 • No está abierto a compromisos “corruptos”.
• Perseverancia.
Por otra parte habilidad para moderar y habilidad para empatizar.

• Disposición para ponerse en el lugar de la otra persona.
• Negocia entre implicados.
4 • Reconoce los deseos del cliente/usuario.
• Genera un proceso de aprendizaje común con el grupo de
trabajo.
• Asegura que se tomen decisiones y obtienen resultados.
I- Introducción
dePensamiento
requerimientos
analítico (3)
• Capturar conceptos (issues) complejos del negocio.
5 • Descomponer los conceptos de negocio en sus parte más básicas.
• Reconocer las conexiones entre elementos.
• Describir los conceptos del negocio sin dejar dudas o
suposiciones.
Habilidades de comunicación
6
• Ser capaz de expresarse en el lenguaje del cliente/usuario.
• También a nivel internacional.
I- Introducción
05 Los tres tipos de requisitos
• Requisitos Funcionales (“functional requirements”)

Un requisito funcional es un requerimiento relacionado con el
resultado del comportamiento que debería ser provisto por una
función del sistema.
• Requisitos de Calidad (“quality requirements”)

Un requisito de calidad define una característica que un sistema o
sus funciones deben tener y a menudo influyen en la decisión de la
arquitectura del sistema.
Especificación de la funcionalidad en términos de los requisitos de

calidad como: fiabilidad, usabilidad, portabilidad, eficiencia,
mantenibilidad. (ISO 9126 – ISO/IEC 25000).
I- Introducción
• Restricciones (“constraints”)
Una restricción es un requerimiento (de carácter técnico u
organizativo) que limita el enfoque de la solución.
• No pueden estar influenciadas por las personas involucradas en el
proyecto.
• Se refieren al sistema y a procesos de la organización.
• No son parte de la implementación pero la limitan/condicionan.
Otros ejemplos de restricciones:

• Prioridades, expectativa respecto al grado de completitud de los
requisitos, aspectos legales.
• FURPS, normas, procedimientos habituales y expectativas.
I- Introducción
• Requisitos no funcionales (“non functional

requirements”)
• Los requisitos de calidad y las condiciones o restricciones también
son llamados requisitos no funcionales.
Clasificaciones alternativas
Son posibles otras clasificaciones:

• Prioridad, nivel de detalle, restricción legal.
• Modelo-FURPS.
I- Introducción
06 Noción del rol de los requisitos de calidad
Significado y consecuencias
• Los requisitos de calidad normalmente son documentados por
medio de lenguaje natural.
• Normalmente integrados/incorporados en “requisitos
funcionales”
• Por ejemplo, parte de una frase en una
especificación de caso de uso,
restricciones en un diagrama UML.
• A pesar de estar implícitos, se debe asegurar la trazabilidad y
testeabilidad de los requisitos de calidad.
• La testeabilidad requiere la cuantificación de los requisitos de
calidad.
• Determina principalmente la arquitectura del sistema (fases
II- Definición de sistema y contexto
00 Contenido
Capítulo II – Definición de sistema y contexto
• II/01 Contexto del sistema, identificación de la diferencia entre

sistema y contexto.
• II/02 Especificación del límite del sistema y límite del contexto.
• II/03 Documentación del contexto del sistema.
• II/04 Resumen.
II- Definición de sistema y
contexto
01 Contexto del sistema, Identificación de la
diferencia entre sistema y contexto
Contexto del sistema (“Context of the system”)
Consiste en todos aquellos factores del entorno que son relevantes para
definir y comprender los requisitos del sistema.
• La forma en la cual se espera que el futuro sistema se integre/inserte en el
contexto.
• El contexto se considera como procedimiento de gestión de cambio.
• Los siguientes aspectos influencian al contexto del sistema: stakeholders,
sistemas en operación, procesos, eventos y documentos.
Alcance (“Scope”)
Todo aquello que se encuentre dentro del alcance está sujeto a cambio dentro del
proyecto.
• Las zonas grises entre el alcance y contexto hacen la delimitación del alcance lo
más importante.
EJERCICIO: Discutir los riesgos de una determinación inadecuada del

alcance y del contexto del sistema.
contexto
02 Especificación del límite del sistema y límite del
contexto.
Definición del límite del sistema y del límite del contexto
1. Determinar el límite del sistema:
• ¿Dónde termina el sistema?: Determinar qué aspectos se
encuentran dentro del alcance del sistema (aspectos cubiertos
por el sistema) y cuales no.
• Todos los aspectos no cubiertos son parte del ambiente del
sistema (“system environment”) o del contexto del sistema
(“system context”).
2. Determinar el límite del contexto:

• Determinar qué partes del ambiente tienen alguna relación con
el sistema (contexto del sistema).
• Todo lo demás es irrelevante {entorno irrelevante (“Irrelevant
environment”)}
contexto
02 Especificación de la frontera del sistema y frontera del
Alcance, contexto,
interfaces contexto.
Contexto del
sistema
Interfaces
• Físicas: por
Alcance del
ejemplo sistema
teclado,
pantalla. (futuro
• Lógicas: datos
de entrada, sistema)
datos de
Sistemas
Sistemas salida
vecinos
vecinos • Físicas: por ejemplo teclado,
pantalla.
• Lógicas: datos de entrada, datos de
salida
Entorno irrelevante Límite del contexto
contexto
contexto.
Límite del sistema (“system boundary”)
El límite del sistema separa el sistema de su ambiente. En él se definen los
aspectos que se pueden cambiar en el proceso de desarrollo en oposición a
aquellas partes de la realidad que no pueden ser modificadas durante la
implementación.
• Todo aquello dentro del límite del sistema es modificable.
• Las fuentes de información y los receptores de información pueden ser el
punto de inicio del sistema, por ejemplo, qué interacciones tienen lugar entre
la persona y la máquina o entre el software y el hardware.
Zonas grises
• Con frecuencia, el límite del sistema no puede ser determinado de forma
clara al comienzo del proceso de ingeniería de requerimientos.
• La zona gris puede desplazarse (cambiar) a lo largo del proyecto:
asuntos/elementos que fueron parte del contexto se transforman en
asuntos/elementos que debe tratar el sistema, por ejemplo una interface.
contexto
contexto.
Límite del sistema (“context boundary”)
El límite del contexto separa la parte relevante del ambiente de un
sistema a ser desarrollado de los aspectos irrelevantes (Los aspectos
irrelevantes no influyen en el futuro sistema y no es necesario
tenerlos en consideración durante la definición de requisitos).
• Con frecuencia, el límite del contexto no se puede determinar de
forma clara al comienzo del proyecto, también es una zona gris.
• Cuando se aborda un tema/asunto, no siempre está claro si tiene
alguna relación con el futuro sistema o no. Este hecho debe ser
tenido en cuenta para ser resuelto durante el proyecto.
• La zona gris se puede desplazar a lo largo del proyecto.
EJERCICIO: Discutir las dificultades de definir de forma completa la

frontera del contexto.
• ¿Es posible/viable definir todo aquello que es irrelevante para el
sistema?
contexto
contexto.
Incertidumbre en la definición del contexto
• Frecuentemente
• Los sistemas vecinos están en proceso de concepción.
• La configuración del sistema es desconocida.
• Los interesados (“stakeholders”) desean dejar el contexto
indefinido.
• El contexto debe ser definido en base a suposiciones
• Identificar con exactitud y hacer seguimiento de las suposiciones
realizadas.
Objetivo: Ajustar las suposiciones a la realidad e intentar verificarlas

rápidamente.
La definición del contexto debe mantenerse estable durante la

especificación e implementación del sistema. Una definición estable del
alcance del sistema es un factor decisivo para el éxito de todo proyecto.
contexto
03 Documentación del Contexto del Sistema
UML- Diagramas de casos de uso
El alcance del sistema se puede definir a partir de las interacciones
descritas por los casos de uso.
Estos casos de uso son también una forma de documentación de
requisitos.
Restaurant
e
Realizar
orden
Pagar
Cliente de factura
restaurante
Frontera del
sistema
II Definición de sistema y contexto
03 Documentación de Contexto del Sistema
UML – Diagrama de caso de uso

(notación)
Los casos de uso pueden estar
interrelacionados Nombre
-Relación “extend” de A a B
-A extiende (“extend”) a B en un punto
especifico (punto de extensión) Si se <<extends
ejecuta A tambien se puede ejecutar B <<include
>>
-Relación “include” de A a B >>
-A incluye las funcionalidades de B en cualquier <<sistem
caso a>>
-Generalización NOMBRE
Actores (“actors”) se encuentran más alla de la frontera del sistema
NOMBRE<<Sistema NOMBRE
>>
NOMBRE
II Definición de sistema y contexto
04 Resumen
• El limite del contexto es la parte de la realidad que influye sobre el
sistema a ser desarrollado y sus requerimientos (aspectos que son
relevantes al sistema y ala definición de los requisitos).
• El limite del sistema define el alcance del sistema que será
construido.
• La definición del alcance también define el contexto como la suma
de aspectos “no modificables” que influyen en los requisitos.
• Los cambios en el contexto afectan la definición de los requisitos
• Las zonas grises son aspectos difusos a lo largo del limite del
contexto o a lo largo de la frontera del sistema.
• Formas de documentar el contexto del sistema; Diagramas de Casos
de Uso, Diagramas de flujo de datos.
III- Obtención de requisitos
00 Contenido
Capitulo II – Obtención de requisitos
-III/01 Fuentes de requisitos

-III/02 Clasificación de requisitos según el
modelo de Kano
-III/03 Técnicas de elicitación de
requerimientos
-III/04 Resumen
01 Fuentes de requisitos
Fuentes de requisitos
• La elicitación de requisitos comienza con el análisis del contexto del
sistema y de las fuentes de requisitos
• Fuentes de requisitos
1. Interesados (stakeholders)
2. Documentos (documents)
3. Sistemas en operación (systems in operation)
El ingeniero de Requisitos debe identificar todas las fuentes
Las fuentes que no han sido identificadas conducen a, entre otras cosas a
conocimientos perdido/faltante.
Las fuentes identificadas deben estar accesibles. Ejemplos:
-Acceso a sistemas antiguos con el objeto de aprender de ellos.
-Un caso de negocio existe pero solo es accesible a la alta dirección.
El uso de listas de comprobación puede ser de ayuda.
III-Obtención de requisitos
Los interesados como fuentes de información
• Los interesados son la fuente de información mas importante para el
ingeniero de requisitos.
• Todos los implicados deben ser identificados con el objeto de asegurar que
los requisitos estén completos.
• Se debe crear una lista de interesados dentro del proyecto
-Dependiendo de la cultura corporativa
-Comprobar en términos de autoridad responsabilidades y tareas
• Tener en cuenta!: Interesados diferentes tienen objetivos diferentes que
sólo se podrán superponer de forma parcial (Conflicto de objetivos)
• Interesados no identificados
– Requieren una intervención posterior -> esfuerzo adicional /tiempo consumido en
solicitudes de cambio complicadas
– Problemas de aceptación
III-Obtención de requisitos
Información
Interesados Descripción Representante Disponibilidad Competencia
del contacto
H. Schmidt Teléfono Vacaciones Conoce al

Correo CW13 cliente desde
Interlocutor hace 4 años
con el cliente
Gestión de R. Schutze Teléfono Conocimiento
Responsable
producto Correo de los
del éxito del
negocio productos de
la
competencia
J. Doe Teléfono 11:00-14:00 Excelente
Correo horas conocimiento
Fuente de del mercado
recursos M. Smith Teléfono Solo conoce su
Cliente económicos Correo área de
Usuario del trabajo,
sistema responsable de
pruebas de
aceptación
Responsabilidades del Ingeniero de requisitos 1/2
• Expresarse en el mismo lenguaje que el intersado
• Familiarizarse con la materia/tema (*subject matter)
• Crear un documento de requisitos
• Es capaz de hacer que los resultados sean compatibles para
todos.
• Comunicarse con los interesados con debido respeto.
• Generar ideas, presentar un conjunto de alternativas y
formas de resolver problema.
• Apoya a los interesados a generar conceptos que hace al
sistema más simple y amigable para el usurario.
• Aboga por la implementación del sistema según se ha
especificado en los requisitos que reflejan las expectativas
del implicado.
Responsabilidad del ingeniero de Requisitos
2/2
• Elabora un plan de comunicaciones
• Calendariza actividades de ingeniería de
requerimientos que se realizarán en
colaboración con los stakeholders.
• La organización y el tipo de comunicación
son influenciados por las técnicas de
Responsabilidad del interesado
• Guía del ingeniero de requisitos en la materia/asunto/tema(“subject
matter”)
• Suministrada/aporta al ingeniero de requisitos la información respecto de
los requisitos.
• Orientado a los onjetivos y estados de los requerimientos
• Decide el tiempo/plazo
• Respeta la evaluación de costos y viabilidad realizada por el ingeniero de
requisitos
• Es capaz de asignar prioridades a los requisitos
• Mantiene revisiones del documento de requisitos
• Comunica cambias relevantes de forma inmediata
• Sigue el proceso de cambio que fuera acordado con el ingeniero de
requisitos.
02 Clasificación de requisitos según el modelo de Kano
Clasificación de Kano /1
• La clasificación de requisitos apoya su priorización
Por ejemplo: requerido (“required”), opcional (“optional”), conveniente
(“nice-to-have”)
La clasificación de acuerdo con el modelo de kano es mas apropiada por la
siguiente consideración.
-Dr. Noriaki Kano, Profesor de lo Universidad de Tokyo, 1978
Los atributos de calidad de producto se clasifican de acuerdo con el
modelo de Kano dependiendo de su influencia en el mercado.
-Atributos de calidad básicos (“basic”), de desempeño (“performance”) y
entusiasmo (“excitement”).
-Insignificante (“Insignificant”): no afecta a la satisfacción
-Atributos de rechazo (“reverse quality”): conduce a la insatisfacción (pero
no a la inversa)
X - Apéndice
01 Bibliografía (Alemán)
[Rupp01]
Chris Rupp: Requirements-Engenering und- Management,
2004 Carl Hanser Verlag Munchen Wien, 3.Auflage
[Wellkins]
Tim Wellkings; System Engineenig mit SysML/UML,
2006,dpunk verlag GmbH, I Auflage
[Oesterreich]
Bernd Oesterreich: Objektorientierte
Sotfwareentwckiung, 1998 R. Olden Boung Verlag:
[Kecher]
Christoff Kecher: UML 2.0 das umfassende Handbuch,
2006 Galileo Press Bonn 2. Auflage
X - Apéndice
01 Bibliografia (Ingles)
Klaus Pohi. Chris Rupo: Requirements Enginering Fundamentals,
Rocky Nook Inc, 1st Edition, 2011 ISBN 976-1-933952-81-9
Kent Beck, Martin Fowler: Planning Extreme Programing, 2001
Addison Wesley
http://www.augustan.ab.ca/-mohrj*courses/200.winter
lcsc22/O/papers/rup_best_practices/rup_bestpractices.html
http://Wikipedia.org/wiki/Waterfakk_model1
B Boehm: Software Engineering economics, Prentice Hall.
Englewood Cliffs. 1981
Karl E. Wiegers: More About Software Requirements: Thorny Issues
and Practical Advice
Suzanne Robertson, James Robertson: Mastering the requirements
Process publisher. Addison-Wesley professional (2006), Languaje:
English, ISBN-13: 9780321619491
X - Apéndice
01 Bibliografia (Ingles)
Suzanne Robertson, James
Robertson: Mastering the
requirements Process publisher.
Addison-Wesley professional (2006),
Languaje: English, ISBN-13:
9780321619491
Diagrama de
<<precondició actividad
n>> Insertar
CA en modo
operative Host
tarjeta Solución
Tarjeta Ejercicio:
en linea
Cajero
Seleccionar automático
transacción
Abortar Comprobar balance de

X crédito X
Retirar eféctivo <<poscondició
Host Comprobar n>>
autorización Autorización
Contador
incremental
Seleccionar
cantidad
Entregar Tomar
Eféctivo cantidad fotografía
01 Fuentes de requisites
Interesados (Ejemplos)
-Organización contratante/cliente
Espera una solución satisfactoria por dinero
Aporta las condiciones básicas/fundamentals (tiempo, esfuerzo, dinero)
Socio contractual con responsabilidad en la aceptación
Sub grupos usuario operador, comprador, controlador.
-Jefe de product (“Product manager”)
-Responsible del éxito del negocio (costos/beneficios)
-Evalua soluciones alternativas
-Marketing/ ventas
Introducción del producto en el mercado
Contacto con clientes potenciales, acuerdos con socios
Ejercicio: Discutir los objetivos de un jefe de calidad, un desarrollador, jefe de proyecto,..
¿Sus on¡bjetivos pueden ser divergentes?
Trabajo con los interesados
• Convertir a los participantes involucrados
en participantes comprometidos
• Descubrir las motivaciones individuales de
los implicados
• Aportar la atención adecuada a los
conceptos del negocio tratados
• Asegurar el flujo de información
• Formas de comunicación
III- Obtención de Requerimientos
02 Clasificación de requerimientos según el modelo
Kano
Clasificación del Kano/2
• La clasificación puede cambiar con el transcurso del tiempo

• entusiasmo> desempeño> básico
• No es una clasificación realizada por una persona, demanda una amplia base
(numero de personas para obtener los requisitos)
02 Clasificación de requerimientos según el modelo
Kano
Atributos
• Atributos básicos: requerimientos cuya implementación es necesaria para
introducirse en el mercado
• Son asumidos, no explicados
• Atributos de desempeño: explícitamente requeridos por el cliente

• Determinan el grado de satisfacción del cliente
• Atributos de entusiasmo: un requerimiento que no ha sido solicitado de forma

explicita pero cuya implementación genera entusiasmo
• La clasificación del cliente crece de forma desproporcionada
03 Técnicas de elicitación de requerimientos
Técnicas para la adquisición de conocimiento
• Objetivo: trasladar conocimientos a través de la Ingeniería de Requerimientos por
medio de una forma documentada
• La selección de una técnica apropiada depende de las condiciones especificas del
proyecto
• Diferencia entre requerimientos conscientes, inconscientes, subconscientes
• Restricciones de tiempo, presupuesto y disponibilidad de los interesados
• Experiencia del ingeniero de requerimientos con una técnica especifica
• Riesgos y oportunidades del proyecto
• Técnicas
• Técnica de entrevista
• Técnicas creativas
• Técnicas basadas en la documentación
• Técnicas de observación
• Técnicas de apoyo
Selección de la técnica /1
• Asegurar el flujo de la información
• Determinar los elementos/asuntos que imponen restricciones a las posibles
opciones del proyecto y factores de riesgo:
• Asunto de carácter personal
• Capacidades del Ingeniero de requerimientos
• Antecedentes/contexto social y dinámica de grupo
• Tipo de conocimiento (explicito/implicito)
• Asuntos referidos a la organización

• Desarrollo nuevo o viejo
• Asuntos de carácter contractual: precio o plazo y material fijos
• Disponibilidad física y limitaciones temporales
Selección de la técnica /2
• Asuntos relativos al contenido materia/tema
• Grado de detalle requerido/necesario
• En el caso de alta complejidad -> utilizar métodos que estructuren problemas
Es recomendable combinar métodos/técnicas

Técnicas de interrogatorio
• Se interroga al interesado respecto de sus requerimientos en diferentes niveles de
detalle
• Adecuada para
• Obtención de factores básicos y desempeño (conocimiento explicito)
• Inadecuada porque
• Los interesados deben ser consientes de sus requerimientos y deben ser capaces de
explicarlos
• Los interesados podrían no estar dispuestos a poner a disposición tiempo necesario
• Ejemplo
• Entrevista o cuestionario
• Lista de comprobación de Osborn (cuestionario especifico que se centra en la
experiencia adquirida con un producto)
• La lista de comprobación de Osborn según Alex F Obsborn es una guía para la creación
de nuevas ideas, especialmente para la generación de nuevos productos y procesos de
una forma sistemática.
Técnicas de interrogatorio – Entrevista, cuestionario
Entrevista: se presentan peguntas predefinidas al interesado donde

• Los puntos abiertos pueden ser resueltos de forma inmediata
• Adecuada porque
• La atención individual que se presta al interlocutor permite abordar todos los factores
que deben ser recogidos
• Requiere mucho tiempo
• Cuando hay una cantidad limitada de temas a preguntar
Técnicas de interrogatorio – Entrevista, cuestionario
Cuestionarios: preguntas predefinidas (papel, online) para que sean respondidas por
los interesados
• Adecuada porque
• Puede ser abordada una amplia base de interesados
• Bajo costo
• Requiere poco tiempo
• Captura solo conocimiento explicito
• Es necesario combinar con otras técnicas de elicitación
• Consume alto tiempo para la preparación
Técnicas creativas (“creative techniques”)
• La creatividad rompe el molde del pensamiento convencional.

• Creatividad orientada a objetos en lugar de caos creativo
• Adecuada porque
• Desarrollo de visión/planteamiento
• Recopilación de ideas innovadoras
• Descubrimiento de atributos de entusiasmo
• Para la elicitación de requisitos precisos/específicos
• Porque es necesario un esfuerzo relativamente alto por requisito.
Técnicas creativas (“creative techniques”)
Ejemplos
• Lluvia de ideas (paradoja) {Brainstorming (paradox)}: recopilación de ideas

(inalcanzables) y objetivos sin evaluación.
• Variante 6-3-5: cada uno de los 6 participantes desarrolla 3 ideas. Estas ideas se
transmiten a los otros participantes (5) para su comentario y desarrollo posteriores.
• Técnica de analogía (“analogy technique”)
• Se buscan posibles soluciones basadas en analogías a problemas encontrados en la
naturaleza con una estructura similar.
Técnica creativa – Cambio de perspectiva (1)
Ejemplos
• Consideración de un problema desde diferentes puntos de vista.

• Edward DeBono desarrolló la técnica PUNTOS DE VISTA DE OTRAS PERSONAS (“Other
People’ s Views”)
• Los participantes seleccionan un sombrero de un color como símbolo de una perspectiva
particular.
El sombrero blanco representa datos, hechos, objetivos condiciones marco
El sombrero rojo representa aspectos emocionales
El sombrero negro representa aspectos negativos / peligros, riesgos
El sombrero amarillo representa aspectos positivos, oportunidades
El sombrero verde representa creatividad ideas innovadoras
El sombrero azul representa visión general, imagen a vuelo de pájaro.
Resumen también es posible como una función desarrollada por un morador
• A continuación cambio de posiciones (6 ciclos)
• También Método de Walt Disney (“Walt Disney Method”) (soñador, realista, crítico)
Técnica creativa – Cambio de perspectiva (2)
• Después del cambio – evaluación y análisis de los resultados.
• Adecuada para
• Resolución de estado de tablas/ estancamiento/ punto muerto
• Requiere una muy buena moderación
• Difícil con participantes introvertidos, conservadores
Técnicas basadas en la documentación (Orientadas al pasado)
• Uso de soluciones/experiencias de otros sistemas.
• Emplear la funcionalidad detallada de un sistema existente
• Adecuada para
• Empelar todas las funciones
• Requisitos muy detallados, incluyendo factores básicos y factores de desempeño
• Se podrían tener en cuenta funciones ineficientes
• La validez de los requisitos se debe poner en duda / cuestionar
Arqueología de Sistemas
• Extracción de información requerida para construir un sistema nuevo de la
documentación o implementación (código) de un sistema anterior.
Lectura basada en la perspectiva

• Filtrado de la información para encontrar lo que es esencial desde la perspectiva de
un usuario, un probador, un programador.
Reutilización de requisitos
• Ahorro de costes cuando interesados previos y actuales son principalmente los
mismos.
• Ejemplo: desarrollo evolutivo de un producto

Técnicas de observación (“observation techniques”)
Técnicas de campo (“field observation”)
• Varias razones por las cuales las técnicas de entrevista o creativas no funcionan (no
se disponen de tiempo, interesados introvertidos,…).
• Observación de los implicados por parte del ingeniero de requisitos
• Documentación de las practicas que tienen lugar en el trabajo
• Participación activa o pasiva
• Adecuada para
• Escudriñar elementos desconocidos de tal manera que puedan ser identificados
procesos ineficientes {puntos débiles / puntos ciegos (“blind spots”)}
• Elicitación de requisitos muy detallados
• Percepción de factores básicos
• Peligro de que procesos ineficientes sean documentados
• Percepción de factores de desempeño tiende a ser difícil
Técnicas de observación (“observation techniques”)
Aprendizaje (“apprenticing”)
• El ingeniero se requisitos (aprendiz aprende las tareas desarrolladas por los
interesados y con ello adquiere un nivel de conocimiento detallado)
• Los requisitos son deducidos del conocimiento adquirido
• Adecuada cuando
• Los implicados no se encuentran bajo presión
• Los implicados no se pueden expresarse de forma adecuada
• El analista debe admitir “debilidad” (falta de conocimiento), ventaja psicológica
• Alto consumo de tiempo y costes
• Procedimientos de trabajo muy complejos que no son susceptibles de ser aprendidos
rápidamente o sometidos a peligros (por ejemplo la policía)
• Requiere un profesor / tutor adecuado
• III – Obtención de requisitos
Técnicas de apoyo (“supporting techniques”)
Complementan las técnicas discutidas en el presente capítulo
• Talleres de trabajo: apoyo a la funcionalidad del sistema, por
ejemplo la definición de interfaces de usuario para garantizar la
usabilidad del sistema
- Construcción del sistema de acuerdo a los flujos de trabajo
necesarios
• Tarjetas CRC (Class Responsibility Colaboration)
– Creación de una tarjeta por tema /asunto (índice) y determinación de
• Contexto, relaciones, atributos y responsabilidades
• Grabaciones: audio/video. Cuando el presupuesto es limitado o
cuando el sistema es altamente crítico
• Modelado de casos de uso (“use case modeling”)
• Prototipado(“prototyping”)
– Creación de GUI con tarjetas para los elementos del menú
– Creación de prototipos funcionales
III – Obtención de requisitos
tarjeta Sistema fuente
Estado de cuenta
Retirada de dinero
PIN autentificación
Cajero
automátic
o
mantenibilidad
Acero inoxidable
Prueba de carga Pantalla resistente al raya

03 Técnicas de elicitación de
requerimientos
Atributos Atributos de Atributos Observación
básicos desempeño de
Entusiasmo
Técnicas de -Recoge información especifica
interrogatorio
Entrevista 0 - 0 -Requiere la atención por parte
del entrevistado
Cuestionario + + -
Técnicas - + 0
creativas
Tecnicas + + - -Requisitos muy detallados se
Basadas en la pueden considerar al emplear
documentació funciones ineficientes
n
Técnicas de 0 0’ - - Elicitación de requisitos muy
Técnicas de apoyo
Observacion Símbolo detallados
Mind Mapping 0 Muy apropiada
Talleres (“Workshops, + Apropiada
Grabaciones de Audio/ - Menos apropiada
videos, Modelado de - *Cuando en curso
proceso / existencia de sistema
casos de uso,
legado
Prototipado, Tarjetas
• Las 3 fuentes de elicitación de requisitos son:
interesados, documentos y sistemas en operación.
• Los requisitos pueden ser clasificados de acuerdo con
su valor de mercado utilizando el modelo de Kano.
– El valor de mercado determina la satisfacción del cliente
• Hay varias técnicas disponibles para la elicitación de
requisitos
– Dependen de las condiciones.
– Depende de la clase de requisitos, especialmente cuande
se trata de atributos de entusiasmo.
– La elección de la técnica también esta determinada por la
efectividad y eficiencia de la elicitación de requisitos.
IV – Documentación de requisitos
00 Contenido
-IV/01 Diseño del documento

-IV/02 Formas de representación de requisitos
-IV/03 Estructura del documento
-IV/04 El uso de la documentación de requisitos
-IV/05 Criterios de calidad para el documento de
requisitos
-IV/06 Criterios de calidad para la descripción de un
requisito
-IV/07 Glosario
-IV/08 Resumen
01 Diseño del
documento
Diseño del documento
• Informal, semiformal o formal
– Orientado a objetivos con el propósito de mejorar la comunicación
– Establecimiento de niveles superiores de calidad en la documentación
• Documento de requisitos (“requeriment’s document”)
• El documento de requerimientos es una colección de requerimientos
sistemáticamente representada, típicamente para un sistema o
componente, que satisface los criterios establecidos.
• La documentación de requisitos es necesaria con el objeto de:
- Crear las bases para las actividades de desarrollo

- Establecer asuntos relevantes desde un punto de vista legal
- Reflejar la complejidad de los asuntos / temas a tratar
- Hacer los requisitos comprensibles a todos los individuos involucrados
02 Formas de representación de
requisitos
• Requisitos desde 3 perspectivas
1. Perspectivas estructural (“structural perspective”)
– Estructura de datos: entradas (“inputs”) y salidas (“outputs”)
– Estructura del sistema y del contexto del sistema: formas de uso y dependencias
2. Perspectiva funcional (“functional perspective”)
– ¿Cómo procesa el sistema la información? Datos tomados del
contexto y datos proporcionados de vuelta al contexto
– Secuencia de funciones
3. Perspectiva de comportamiento (“behavorial
perspective”)
– Documentación del sistema basada en estados y transiciones
de estado, también en relación con su entorno
– Como reacciona el sistema a eventos de estado y dependencias
de efectos en el contexto del sistema
02 Formas de representación de
requisitos
Formas de documentar requisitos
1. Lenguaje natural (“natural language”)
– Multipropósito, (aparentemente) fácil de entender
– Apropiado para las 3 perspectivas
– Pero: impreciso, las perspectivas se pueden combinar
2. Modelos conceptuales (“Conceptual models”)
– Precisos y comprensibles debido a una sintaxis conocida (formalismo)
– Individual para cada perspectiva.
– Pero: no aplicable en cualquier sitio dado que es necesario el
conocimiento de la notación.
3. Combinaciones de 1 y 2
– Combinando las posibilidades del lenguaje natural y los modelos
conceptuales se pueden reducir sus respectivas desventajas.
– Por ejemplo, descripción verbal de modelos de diagramas.
03 Estructura del documento
Estructura normalizada / estandarizada de documento

– Parte principal: requisitos
– En lo mas alto: contexto del sistema, criterios de
aceptación, condiciones relativas a la implementación
técnica, etc.
– Recomendable: una estructura uniforme y obligatoria con
una breve descripción del contenido esperado
– Hay varios estándares que pueden ser ajustados a las
necesidades relevantes del proyecto
Razones por las cuales es
• Variando la completitud
necesario adoptar las
• Variando la flexibilidad plantillas
Ejemplos
• Dominios del cliente
Volere
• Especificaciones de la
ISO/IEC/IEEE 29148:2011
IEEE 830- 1998
compañía
• Características del
proyecto
1. Guías del proyecto 4. Requisitos no

• El objetivo del proyecto
• Clientes y otros funcionales
interesados – Requisitos de aspecto
• Usuarios del producto visual y operacional
2. Restricciones del – Requisitos de usabilidad
proyecto – Requisitos de
• Restricciones obligatorias rendimiento
• Denominación de – Requisitos operativos y
acuerdos y definiciones de entorno
• Hechos relevantes y
suposiciones – Requisitos de
mantenibilidad y soporte
3. Requisitos Funcionales – Requisitos de seguridad
• El alcance del trabajo
• El alcance del producto – Requisitos culturales y
• Requisitos funcionales y
políticos
datos – Requisitos legales
Ejemplo- Plantilla de especificación de

requisitos – Volere /2
5.- Propiedades del proyecto
• Incidencias abiertas
• Productos comerciales de distribución masiva
(“COTS”)
• Nuevos retos
• Tareas
• Migraciones al nuevo producto
• Riesgos
• Costes
• Documentación de usuario y formación
• Lista de existencias
• Ideas para soluciones
Ejemplo – ISO/ IEC/ IEEE 29148:2011
1. Introducción
(Anexo A) 3. Capacidades, condiciones y
restricciones del sistema
1.1 Objetivo del sistema
3.1 Físicas
1.2 Alcance del sistema 3.1.1 Construcción
1.3 Definiciones, acrónimos y abreviaturas 3.1.2 Durabilidad
1.4 Referencias 3.1.3 Adaptabilidad
1.5 Visión general del sistema 3.1.4 Condiciones de entorno
3.2 Características de rendimiento del
2. Descripción general del sistema
sistema 3.3 Seguridad del sistema
2.1 Contexto del sistema 3.4 Gestor de la información
2.2 Alcance del sistema 3.5 Operaciones del sistema
2.3 Principales capacidades del sistema 3.5.1 Factores humanos del
sistema
2.4 Principales condiciones del sistema 3.5.2 Mantenibilidad del sistema
2.5 Principales restricciones del sistema 3.5.3 Fiabilidad del sistema
2.6 Características de los usuarios 3.6 Normativa y regulación
2.7 Suposiciones y dependencias 3.7 Mantenimiento de ciclo de vida del
sistema
2.8 Escenarios de operaciones
4. Interfaces del sistema
Ejemplo – IEEE 830 – 1998 (Anexo A) /1
1. Introducción
1.1 Objetivo
1.2 Alcance
1.3 Definiciones, acrónimos y abreviaturas
1.4 Referencias
1.5 Visión general
2. Descripción general
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características de usuario
2.4 Restricciones
2.5 Suposiciones y dependencias
Ejemplo – IEEE 830 – 1998 (Anexo A) /2
3. Requisitos específicos 3.2.m.n Requisito funcional
3.1 Requisitos de interfaces externas m.n
3.1.1 Interfaces de usuario
3.1.2 Interfaces hardware
3.3 Requisitos de
3.1.3 Interfaces software
rendimiento
3.1.4 Interfaces de 3.4 Restricciones de diseño
comunicación
3.2.1 Usuario clase 1 3.5 Atributos del sistema
3.2.1.1 Requisito funcional software
1.1
3.6 Otros requisitos
El estándar IEEE 830
…
3.2.1.n Requisito funcional
ofrece distintas
1.n posibilidades de
3.2.2 Usuario clase 2 estructurar el capitulo 3.
Ejemplo: Organización
3.2.m Usuario clase m
basada en clases de
3.2.m.1 Requisito funcional usuarios
m.1
EJEMPLO : Rational Unified Process

• La parte contratante (el cliente del proyecto) es
responsable de la descripción del modelo de
negocio
– Reglas y normativa del negocio, casos de uso del
negocio, planteamiento (“vision”) del futuro sistema
• La parte proveedora describe la Especificacion
de Requisitos de Software (ERS){Software
Requeriments Specification(SRS)} con una
estructura cercana a IEEE Std. 830 – 1998.
EJEMPLO: Modelo- V 2004 (modelo estándar para la

administración federal Alemana)
• La especificación de requisitos del cliente es
responsabilidad de quien solicita/ adquiere el futuro
sistema
– Sintetiza el funcionamiento del sistema y las entregas
– Requisitos desde el punto de vista del usuario y las condiciones
dadas
• La especificación de requisitos del sistema es
responsabilidad de la parte que provee el sistema (futuro)
• Substancia la especificación de requisitos y describe como
será construido el sistema.
20
25
V – Documentación en lenguaje
natural
01 Efectos relacionados con el lenguaje
Individuo
Percepción
Requisito Especificado
Expresión en un
• Características
lenguaje
• Imagen completa
Perdida de información
Realidad
• Sin sesgo
Transformación de lo Transformación en la
percibido expresión
Perdida de información
InnovaSys
natural
Transformación de la información Información
adicional
Transformación (de acuerdo PNL *, programación neurolingüística)
1. Generalización
2. Selección
3. Distorsión
La perdida de información se debe a la transformación que puede ser
compensada por técnicas de prospección adecuadas.
1. Generalización
Generalización de la experiencia
Ejemplo: El tren siempre llega tarde.
Pregunta: ¿El tren llegará un 10% mas tarde?
Pregunta: ¿El tren llego tarde todos los días de la semana pasada?
*NPL, neurolinguistic programming
InnovaSys
natural
Información
adicional
2. Selección
- El énfasis está dirigido sólo a una parte especifica de nuestra

experiencia. Otras experiencias / características son borradas.
• Ejemplo: El sistema debe incluir autenticación de usuario.
• Preguntas: ¿Cómo tendrá lugar la autenticación? ¿Quién crea los

usuarios en el sistema? ¿Qué medidas de seguridad serán aplicadas?
InnovaSys
natural
Información
adicional
3. Distorsión
- Remodelado de la experiencia.
- Todas las formas de trabajo creativo (palabra clave artístico) son
distorsiones.
- Todo aquello que no ha existido previamente es el resultado de un
trabajo creativo.
• Ejemplo: El medio de transporte más económico para ir desde aquí al

centro de la ciudad es el coche.
• Preguntas: ¿Qué datos conducen a esta afirmación? Es decir que ir

desde aquí hasta el centro de la ciudad en coche es el medio más
InnovaSys
económico. ¿Se tiene acceso a una evaluación de los datos que apoyen
esta afirmación?
natural
Procesos de transformación
- El efecto resultante de la transformación sigue un patrón definido.
- Estar familiarizado con este patrón puede ayudar a mejorar la calidad de la

definición de requisitos.
• Estructura de la superficie: los requisitos establecidos.
• Estructura subyacente: qué quiso expresar el autor.
- Elicitación de la estructura subyacente a través de la formulación de

preguntas.
- Procesos de transformación
1. Nominalización.
2. Uso de sustantivos sin una cualificación precisa.
3. Uso de cuantificadores universales.
4. Condiciones definidas de forma incompleta.
InnovaSys
5. Verbos especificados de forma incompleta.
natural
1. Nominalización
Por medio de la nominalización, un proceso prolongado (un verbo) se

convierte en un evento o incidente (sustantivo).
En caso de fallar el sistema, se debe reiniciar el sistema.
Los términos fallar el sistema y reiniciar describen un proceso que

debe ser analizado con mayor precisión.
Adicionalmente, los procesos nominalizados deben incluir:
• ¿Cuáles son los detalles del propio requisito?, o

• Referencia para relacionar entradas en el glosario.
InnovaSys
natural
2. Uso de sustantivos sin índice de referencia
- Al igual que con los verbos, los sustantivos se especifican de

manera incompleta. En lingüística se llama perdida o inadecuada
referencia de índice, utilizados sin una descripción de que
diferentes usos podría haber.
¿A que hace referencia este sustantivo?
• Palabras a las que hay que prestar atención: usuario, sistema,

datos, función, controlador, mensaje.
InnovaSys
V – Documentación en lenguaje natural
2. Uso de sustantivos sin índice de referencia
Ejemplos
Sustantivos sin índice de referencias.
Los datos se muestran al usuario en la terminal.
Las cuestiones que surgen son: Que datos exactamente? Qué usuario
exactamente? Qué terminal exactamente?
Sustantivos añadiendo índices de referencia.
El sistema deberá mostrar los datos de facturación al usuario registrado en el

terminal que está conectado.
InnovaSys
natural
3. Uso de cuantificadores universales
Los cuantificadores universales especifican cantidades o frecuencias. Se

agrupan un conjunto de objetos y hacen una declaración del
comportamiento de este conjunto.
Cuando se utiliza cuantificadores universales, existe el riesgo que el

comportamiento o la propiedad especificada no se aplica a todos los
objetos dentro del conjunto especificado.
Los stakeholders tienden a agrupar los objetos, a pesar de que algunos de

estos objetos pueden ser casos especiales o excepciones, donde el
comportamiento especificado no se aplica a todos los objetos de un
grupo.
Se debe verificar si el comportamiento especificado aplica realmente a

todos los objetos resumidos a través del cuantificador.
natural
3. Uso de cuantificadores universales
Los cuantificadores universales se pueden identificar fácilmente a través

de palabras claves como: nunca, siempre, no, ninguno, todos, algunos, o
nada.
Ejemplo
El sistema deberá mostrar todos los conjuntos de datos en cada submenú.
En este caso, se deben realizar las siguientes preguntas:
Realmente todos los conjuntos de datos?
Realmente en cada submenú?

InnovaSys
natural
4. Condiciones definidas de forma incompleta
Condiciones especificadas incompletamente son otro indicador de una

posible pérdida de información.
Los requisitos que contengan condiciones especificas del comportamiento

que debe ocurrir cuando se cumple la condición. Además, tienen que
especificar qué comportamiento debe ocurrir si no se cumple la condición
(la parte que a menudo falta).
Sobre todo en las estructuras condicionales complejas, tablas de decisión

pueden ser herramientas muy valiosas para encontrar variantes no
especificadas de condiciones o acciones.
Palabras a las que hay que prestar atención son: si, entonces, a
InnovaSys
continuación, en caso de.
natural
4. Condiciones definidas de forma incompleta
Ejemplo
Condiciones especificadas incompletas

El sistema de restaurante ofrecerá todas las bebidas a un huésped registrado mayor de 20
años.
Por lo menos un aspecto permanece sin especificar en el ejemplo anterior:

Qué bebidas se ofrecerán a un invitado que es menor de 20 años? Aclarar esta pregunta
puede dar lugar a la ampliación de los requisitos de la siguiente manera.
Condición especificada con más detalle

El sistema de restaurante ofrecerá.
Todas las bebidas sin alcohol a cualquier usuario registrado menor de 20 años.
Todas las bebidas, incluyendo todas las bebidas alcohólicas a cualquier usuario mayor de 20
años.
natural
5. Verbos especificados de forma incompleta
Algunos verbos de proceso requieren más de un sustantivo para ser

considerados completamente especificados. El verbo transmitir, por
ejemplo, requiere un mínimo de tres suplementos para considerarse
completo:
Que se está transmitiendo

Desde donde se está transmitiendo
A donde se está transmitiendo.
El uso de verbos de procesos especificados incompletamente en su

mayoría se pueden evitar o reducirse al mínimo si los requisitos están
formulados utilizando la voz activa en lugar de la voz pasiva.
InnovaSys
natural
5. Verbos especificados de forma incompleta
Ejemplo
Requerimiento usando voz pasiva
Para registrar un usuario, se introducen los datos de inicio de sesión.
Requerimiento usando voz activa
El sistema debe permitir que el usuario introduzca su nombre de usuario y

contraseña con el teclado del terminal.
InnovaSys
V – Documentación en lenguaje natural
Plantillas de requisitos
- Una plantilla de requerimiento es una base para la estructura sintáctica de

requerimientos individuales.
- Forma simple para reducir los efectos del uso del lenguaje para definir
requisitos.
- Ayuda a formular requisitos completos y no ambiguos.
- Las frases son aún más precisas cuando se combinan las plantillas con un
glosario (precisa desde el punto de vista del léxico).
- Reducen costos y tiempos.
- 5 pasos a seguir para seguir la plantilla de requisitos

1. Determinar la fuerza legal del vinculo.
2. Establecer el núcleo del requisito.
3. Caracterizar el comportamiento del sistema.
4. Identificar los objetos involucrados.
InnovaSys
5. Incluir las condiciones lógicas y temporales.
natural
5. Determinar la fuerza legal del vínculo
En el comienzo, se debe determinar el grado de obligación jurídica de un

requisito.
Por lo general, se distingue entre los requisitos:
Legalmente Obligatorios.
Recomendados como urgentes.
Futuros.
Para lograr esto dentro de un requisito, puede utilizar los verbos.

DEBE
Ejemplo 1: Debe
DEBERÍ
A
InnovaSys DEBERÁ
V- Documentación del lenguaje
natural
02 Construcción de requisitos utilizando plantillas de frase
2 Establecer el núcleo del requisito
• Utilizar verbos para describir una actividad o un
procedimiento.
• Solo se permitirá el uso de verbos para describir procesos.
• Ejemplos: imprimir, guardar, presentar.
• Todos los interesados deben comprender el significado del
verbo.
Ejemplo 2: “Deberá ser capaz de imprimir”

– Evitar la ambigüedad.
– Utilizar glosarios
– Utilizar distintos niveles de detalle.
natural
3 caracterizar el comportamiento del sistema.

• 3 tipos de comportamiento de sistemas:
– Actividad autónoma del sistema: sin intervención del usuario.
– Interacción del sistema: el sistema aporta, por ejemplo, una interfaz
de usuario.
– Requisitos sobre las interfaces del sistema: La funcionalidad del
sistema es una reacción, espera algún evento externo de otro sistema.
DEBE <proceso
>
EL Proporcionar <whom?>
DEBER
SISTE con la capacidad de
Á <proceso>
MA
SERÁ Ser capaz
de
– Ejemplo: El sistema deberá poder<proceso>
imprimir.
natural
Observaciones para el desarrollo de documentos.
• Los requisitos deberán ser claramente diferenciados respecto
de los requisitos relacionados con la información.
• Incidencias/ asuntos abiertos (a definir) son requisitos que aun
no deben ser definidos.
Reglas para la especificación de requisitos

1. Utilizar frases y párrafos cortos.
2. Solo un requisito por frase.
3. Terminología consistente sustentada por un
glosario.
4. Evitar generalizaciones, utilizar referencias
claras.
5. Utilizar “debe” y “puede”.
natural
03 Resumen
• El lenguaje natural es un medio útil para
especificar requisitos pero puede conducir a
malas interpretaciones.
• Los requisitos pueden ser interpretados de
diferentes formas debido a los diferentes
antecedentes del conocimiento de los
interesados.
• El uso de las plantillas de frase pueden reducir
esta desventaja.
natural
04 Identificar los objetos involucrados

• Previene el uso de verbos definidos de forma incompleta (efecto de lenguaje)
• La plantilla de requerimientos para el proceso imprimir es modificada por la
información de que se esta imprimiendo y donde se imprime, la modificación se
la puede ver en la figura:
DEBE PROCES
O Detalles
Proveer adiciona
EL
DEBER <quien> con <objeto les del
SISTE la habilidad > <objeto
ÍA para
MA <proceso>
>
DEBER Ser capaz de
Á <proceso>
• Ejemplo 4: El sistema deberá ofrecer posibilidades de imprimir recibos.
natural
05 Incluir las condiciones lógicas y
temporales.
• Condición temporal:
– Tan pronto como, después de, durante, antes.
• Condición lógica:DEBE PROCES
Detalles
O
– Cae (no;
Cuando, EL if) Proveer adiciona
Bajo que DEBER <quien> con <objeto les del
condicione
SISTE la habilidad > <objeto
ÍA para
s MA <proceso>
>
DEBER Ser capaz de
Á <proceso>
Ejemplo 5: “Tras concluir el registro y si el usuario cuenta con autorización el sistema deberá ofrecer la
posibilidad de imprimir la factura.”
Recordar: Solo es posible utilizar plantillas cuando el equipo está dispuesto a aceptarlas
Este método debe hacerse familiar a través de formación/ entrenamiento.
VI. Documentación basada en modelos.
00 Contenido
• Capitulo VI: Documentación basada en modelos.

• VI/01: El término “modelo”
• VI/02: Modelos de objetivo.
• VI/03: Casos de uso.
• VI/04: Tres perspectivas relacionadas con los
requerimientos.
• VI/05: Modelado desde la perspectiva estructural.
• VI/06: Modelado desde la perspectiva funcional.
• VI/07: Modelado desde la perspectiva del
comportamiento.
• VI/08: Resumen.
01 El término “modelo”
Modelo
Un modelo es una imagen abstracta de la realidad existente o de la realidad a desarrollar.
3 características de los modelos:
• Características de representación: representa aspectos de la realidad en los que se debe
centrar el foco
– Relacionadas con circunstancias existentes o dirigidas al futuro.
• Características de abstracción: Filtrado de factores de interés de la realidad:
– Extracción selectiva de aspectos particulares.
– Agrupar aspectos para representar una imagen conceptual.
• Característica pragmáticas: Los modelos son desarrollados para servir a un objetivo, fundamentalmente en
un contexto específico, con uso específico.
01 El término “modelo”
• Modelos de requisitos.
Describen aspectos específicos de problemas subyacentes, por ejemplo con UML*.
Ventajas de los modelos conceptuales:
1. La representación ilustrada mejora la comprensión de los aspectos mostrados al
lector.
2. Perspectiva dirigida: Los modelos particulares UML tienen un foco específico y
apoyan distintas perspectivas de documentación.
3. Apoyan la abstracción de la realidad: a través de la recomendación del modelo
abstracto del lenguaje modelado.
La combinación del lenguaje natural cuenta con las ventajas respectivas:
UML es el acrónimo de “Unified Modeling Languages”,

un estándar de carácter internacional. El “Object
Management Group” (OMG) es el responsable de la
defunción del lenguaje. El UML due desarrollado en
1995 como síntesis de las notaciones de los “tres
amigos” Grady Booch (Rational), James Rumbaugh e
Ivar Jacobson. La responsabilidad del UML recae sobre
la OMG desde 1997.
01 Modelos de objetivo
Modelos de objetivo
• Fundamento: Consideración de la intención de un único implicado.
– Esfuerzo reducido, amplio efecto.
• Objetivos: Descripción intencional de una característica de calidad
del sistema que es necesaria para un implicado especifico.
• Apropiado para detallar los objetivos por descomposición de
objetivos.
– Lenguaje natural, descomposición Y/O.
DESCOMPOSICION O DESCOMPOSICION Y
Objetivo Objetivo
Sub Ojetivo1 Sub Ojetivo2 Sub Sub Ojetivo1 Sub Ojetivo2 Sub
Ojetivo3 Ojetivo3
03 Casos de uso
Casos de uso
• Documentación de la funcionalidad de un sistema con la ayuda de los modelos
sencillos.
• Se basa en dos conceptos:
• Diagrama de casos de uso.
• Especificación de casos de uso.
• Un caso de uso presenta las funcionalidades (de un sistema) desde el punto de vista
del usuario sus relaciones recíprocas así como como relaciones entre el sistema y su
entorno.
• Un especificación de caso de uso describe las interacciones de un actor con el
sistema asociados a su secuencia temporal y orientadas a objetivos. Su comienzo
tendrá lugar a partir de un disparador funcional y al final se logrará un resultado
definido de valor funcional.
• En general, el caso de uso será iniciado por un actor.
• En general, el resultado es importante para el actor.
03 Casos de uso
Diagrama de casos de uso UML (cajero

automático).
03 Casos de uso
Especificación de casos de uso:

• Descripción del comportamiento del sistema desde una perspectiva
externa del usuario.
– Por lo tanto comprensible para el usuario.
• Refleja una parte del requisito
– Siempre describe un único proceso del negocio.
• Con frecuencia, utilizado en frases tempranas de la especificación del
sistema.
– Objetivos de alto nivel son divididos en partes gestionables.
– Si aplicara se puede utilizar para la definición del limite del contexto (lista
negativa de casos de uso).
– Razonable aproximadamente (máximo) 100 casos de uso.
• Atributos de los casos de uso
– Identificación única.
– Gestión (proyecto).
– Descripción funcional.
– Adicionalmente: atributos específicos de los casos de uso (por ejemplo
estereotipos)
03 Casos de uso
Uso de plantillas
• Descripción en forma de texto apoyada por atributos
a especificar.
• Atributos típicos (ejemplo de [BASIS]):
1. Identificador único.
2. Nombre del caso de uso
3. Autores
4. Prioridad Para la implementación, para el cliente.
5. Criticidad (valoración del daño por anomalía).
6. Fuente
7. Responsable
03 Casos de uso
1. Descripción (corta)
2. Evento desencadenante.
3. Actores.
4. Precondición.
5. Post condición.
6. Resultado.
7. Escenario principal
8. Escenarios alternativos.
9. Escenarios de excepción.
10.Calidad
11.Diseño de interfaz grafica(presentación).
03 Casos de uso
Evaluación
Apropiado
de casos de uso
• Descripción desde la perspectiva del usuario (contexto), hacer el
caso de uso legible para el usuario.
• Ideal para enfoques descendentes (“top-down”).
• Múltiples aplicaciones (procesos de negocio, descripción del
sistema).
• Medio de estructurar especificaciones del lenguaje natural.
No Apropiado
• No es posible un alto grado de detalle, de otro modo seria muy
complejo.
• Requiere detalle adicional con otras notaciones.
• Los requisitos no funcionales pueden ser representados en una
forma limitada (por ejemplo extensibilidad).
04 Tres perspectivas hacia requisitos
• Perspectivas de modelado
– Perspectiva estructural.
• Diagramas de clase UML.
• Diagrama entidad- relación.
• Glosario.
– Perspectiva funcional
• Diagrama de actividad UML.
• Diagrama de secuencia UML.
• Diagrama de flujo de datos.
• Cadenas de procesos dirigidas por eventos.
– Perspectiva de comportamiento
• Diagramas de estado
• Tablas de decisión.
– Las diferentes perspectivas son complementarias.
– Muestran información cuya completitud puede ser evaluada con
respecto a otras perspectivas
VI – Documentación basada en
modelos
05 Modelado desde la perspectiva estructural
Diagrama entidad relación

• Modela la estructura de los datos (vista estática)
• Utilizado en el mundo del diseño de bases de datos relacionales
Tipo de entidad
Vehículo
Representa un numero de entidades del mismo tipo
Tipo de relación
Representa un numero de relaciones similares
Número Atributo clave, atributo

Define características de un tipo de entidad o de n tipo de entidad
Tipo
Cardinalidad
M N Numero de instancias de la relación
(min, max) Cardinalidad (min, máx.) generalización
VI – Documentación basada en modelos
Ejemplo: Diagrama entidad relación
empleado Emp-Nombre
1
Emp- Número
toma
n
Pertenece 1 1
a
orden
contiene precio
n
(1,n)
mesa PLU-número
articulo
1
nombre nombre
Reservada
para
(1,n) reserva
cliente
comida bebida alcohólico
modelos
Diagrama de clases UML
• Presentación de las estructuras del sistema con los medios de UML
• Presentación de clases y las asociaciones entre ellas
• Elementos adicionales del modelo(atributos y su visibilidad,
operaciones)
vehículo Clase
Tipo coche: String
Numero coche: String
Atributos(opcional)
Peso: Integer
Propietario anterior: persona (0..4)[ordenado]
Aceleracion(): Integer Operaciones (opcional, también
Conducir (velocidad: Entero): Boolean denominados métodos)
Frenar(): Integer
modelos
Diagrama de clases UML – asociaciones
Las asociaciones representan la relación estructural entre dos clases
Son navegables en una o ambas direcciones
ruedas
Vehículo 0…4
rueda
ruedas
Vehículo 0…4
rueda
• La agregación identifica una clase
como una agregación y describe Multiplicidad
una jerarquía todo-parte, donde la roles
existencia de la parte es habitaciones
independiente del todo. habitación
vivienda
1…
• La composición representa una
relación estática donde la parte es
dependiente del todo.
modelos
Diagrama de clases UML – generalización
• La generalización es una relación de una clases especial a una clase
general
• Las características son heredadas de la clase general por la clase
especifica
Vehículo
Numero de chasis
Propietario
Auto Motociclista
Clase de seguro de coche Numero de chasis

Propietario
Diagrama de clase UML – generalización
Los atributos describen una característica de la estructura y se identifican por:
- Nombre
- Tipo (plan de construcción del atributo)
- Multiplicidad
Se puede definir más de un atributo del mismo tipo
- Valores característicos
Descripción adicional del atributo utilizando la propiedad de valores
predefinidos en UML (ordenado, no único, …)
- Visibilidad
¿La característica es visible para elementos externos a la clase?
+ Público
- Privado
- Paquete
# Protegido
Diagrama de clase UML – operaciones
Las operaciones definen un comportamiento de la clase y
están caracterizadas por:
- Nombre
+ Conducir (velocidad: entero) : booleano
- Visibilidad
- Parámetros
- Tipo de retorno
- El comportamiento real de una operación no es visible
- Puede ser descrito de forma más detallada con un
diagrama de actividad
Diagrama de clase UML – relación de dependencia
Las dependencias entre dos elementos muestran que
uno de los elementos necesita a otro para su
especificación o implementación
Vehiculo Motor
- Como con las asociaciones las dependencias también

pueden ser utilizadas con otros elementos de
modelado (por ejemplo, casos de uso)
- Las relaciones no incluyen un rol o multiplicidades
Diagrama de clase UML: Ejemplo

Empleado
- nombre :
- e_numero :
Articulo
- nombre :
- pla_numero :
1..* - precio :
0..*
Orden
Mesa
1..*
Comida
Bebida
+ alcoholica : boolean
0..12 + extraer () : int
Cliente
- nombre :
- reserva :
05 Modelado desde la perspectiva funcional
Diagrama de flujo de datos
- Describe el flujo de datos entre el sistema y su entorno
- Muestra una visión de conjunto de los alrededores del sistema
• Proceso central (círculo) describe el sistema
• Rectángulo describe las interfaces
• Los flujos de datos se muestran como flechas
proceso
CLIENTE orden
factura
Dirigir el
dinero restaurante
Terminador Almacén de datos
Flujo de datos Factura
Nota:
la nomenclatura debe ser comprensible para personas externas
los flujos de datos deben estar en el mismo nivel de abstracción
Diagrama de flujo de datos
- Procesos
- Presentan funciones del sistema relevante
- Transformación de los datos entrantes
- No es una especificación funcional como tal
- Almacén de datos
Los diagramas de flujo de datos pueden ser
- Datos persistentes complementados con otras descripciones estructuradas
con el objeto de especificar la funcionalidad
- Utilizados por procesos (flujos de trabajo interno)
- Terminadores
- Representan objetos en el entorno del sistema
- Flujo de datos
- Transportan datos entre procesos, almacenes de datos y terminadores
(flujo de información, flujos materiales)
Diagrama de actividad UML

El diagrama de actividad describe un procedimiento que resulta de distintas acciones
individuales. Un procedimiento puede tener lugar en paralelo o sincronizado con otros, o puede
ser dividido de acuerdo a condiciones particulares y ser construido.
- Los diagramas de actividades son gráficos que representn flujos de
trabajo.
- Se puede modelar: flujos alternaticos y vinculo de sincronización temporal
- Se puede definir áreas de responsabilidad (diagrama de calles de
natación)
- Diferentes áreas de aplicación, diferentes niveles de detalleTerminadores
- Modelado de proceso de negocio
- Visualización de flujo de caso de uso
- Descripción de algoritmos
modelos
Diagrama de actividad UML- generalización
Precondición>> Nodo Inicial
El camarero se Representa un evento
encuentra con el cliente
Acción
Poscondición>> Ordenar Jerarquía
El camarero se dirige a
la oficina Comida
Flujo de control Nombre
Condición
Tiempo de espera Nodo de decisión(Ramas), también:
Reunificación (fusión) flujos
alternativos.
Objeto
Ordenar Menú
Terminador del flujo de control Representa Datos
Comida
Solo finaliza el flujo de esta
condición
Flujo de objeto
Nodo final
Representa un evento
modelos
Notación de un diagrama de actividad UML
• Una acción es un paso ejecutable elemental en una actividad.

• Las aristas son relaciones dirigidas entre los nodos de una actividad.
Diferencia entre flujo de objeto y flujo de control
• El nodo inicial es el punto inicial del flujo
• El nodo final cierra la totalidad de la actividad, tan pronto como un flujo
individual alcanza este nodo.
• El nodo final cierra el flujo que alcanza este nodo.
• Un nodo de decisión divide un flujo simple en múltiples flujos opcionales
con diferentes condiciones de finalización (flujos alternativos)
• El nodo de reunificación (“merge”) combina distintos flujos alternativos
entrantes en un único flujo saliente.
modelos
07 Modelado desde la perspectiva del comportamiento
Diagramas de estado
 Descripción del comportamiento reactivo de un sistemas desencadenado por
eventos
 Basado en los principios de la maquina de estado finito
Una máquina de estado describe los posibles estados y transiciones de estado de una
estructura.
 Áreas habituales de uso

• GUI, protocolos de comunicación
 Notación Estado A Estado B Estado C
• Tablas de transición de estado
Condición X / / Estado B
• Diagrama de transición de estado
Condición Y Estado B / /
Condición Z Estado C Estado B Estado A
modelos
Diagramas de estado
• Diagramas de estado: desarrollados a partir de los diagramas de transición de
estado ((Professor David Harel en los años 80- siglo XX), sufrieron diferentes
mejoras, por ejemplo:
– Jerarquía con sub- máquinas de estado
– Composición para la representación de maquinas de estado en paralelo
– Conectores históricos, que guardan sub estados para la recuperación de este estado
– Acciones de entrada, salida, transcurso (“throughout”) de estado
Diagrama de estado UML

• Adopción de los diagramas de estado de UML
• Mejora de los diagramas de estado
– Define puntos de entrada y salida para estados jerárquicos
modelos
07 Modelado desde la perspectiva del
comportamiento
Diagrama de estado UML – notación [Estado]
• Estado: … (periodo de tiempo en el cual un
sistema presenta un comportamiento
especificado)
Máquina 1 Máquina 2
• Estado paralelos/ concurrentes
[Super Estado]
• Estados jerárquicos
[sub estado]
• Estado inicial (nodo inicial)
[sub estado]
• Estado final(nodo final)
• Los eventos conducen – bajo condiciones
definidas – a una transición de estado, desde un
estado a otro estado.
Evento [condición]/ Acción

modelos
07 Modelado desde la perspectiva del
comportamiento
Diagrama de estado UML – notación
Pseudo estados visibles externamente [Nombre]

para máquinas de estado parciales
• Punto de entrada
[Nombre]
• Punto de salida
Division (“fork”) y unión (“join”)

Diagramas de estado UML – notación

Información adicional
Notaciones de estado alternativas
Moler café Moler Café
Entrada/ errar puerta

Hacer / moler granos
Salida/ abrir puerta
• Distintos pseudo estados Puerta abierta (molino
activo)/ para molino
• Eleccion (“choice”) Medir tiempo
Tiempo< 30 ms Otro caso
• Confluencia (“junction”)
Tiempo > 1 ms Tiempo< 1 ms
modelos
Diagramas de estado UML – Ejemplo

El sistema es encendido y una luz parpadea de forma intermitente en un intervalo específico. En
paralelo se ejecuta una auto evaluación
Presionado interruptor de encendida

Sistema encendido
Se inicia proceso de parpadeo
Inicialización del sistema
Luz parpadea
Tiempo transcurrido /
Luz apagado
encendida Sistema en auto
evaluación
Luz
Tiempo transcurrido / apagada
encendido
Auto evaluación
completada
modelos
08 Resumen
• Con frecuencia se combinan las ventajas del lenguaje natural(prosa)

y la documentación basada en modelos de requisitos.
• La descripción visual mejora la comprensión de asuntos complejos
• Se utiliza, por ejemplo:
– Modelos de objetos (arboles y/o)

– Diagramas de casos de uso
– Diagramas ER y diagramas de clase (perspectiva estructural)
– Diagramas de flujo de datos y diagramas de actividad UML
(perspectiva funcional)
– Diagramas de estado y diagramas de estado UML (perspectiva del
comportamiento)
VII – Verificación y ajuste de requisitos
00 Contenido
• VII/01 Fundamentos de la validación de requisitos.

• VII/02 Fundamentos del ajuste de requisitos.
• VII/03 Evaluación de los aspectos de calidad de los
requisitos.
• VII/04 Validación de requisitos en la práctica
• VII/05 Técnicas para la validación de requisitos
• VII/06 Ajuste de requisitos en la práctica
• VII/07 Resumen
• 01 Fundamentos de la validación de requisitos
¿Por qué validar?
• Evaluación de la calidad de los requisitos a efectos de su aprobación
– Detección temprana de defectos en contenido o en documentación
• Tras haber alcanzado los objetivos de calidad tiene un lugar su aprobación para la siguiente
fase de desarrollo (cumplimiento de los criterios de calidad definidos)
• Evaluación respecto de los criterios de calidad

 Completitud, corrección
– Carencias en el contexto conducen a la carencia en funcionalidades o funcionalidades
mal implementadas –> vínculos legales
 Comprensibilidad, no ambigüedad y consistencia
– La depuración de inconsistencias implica un mayor esfuerzo
– Peligro de una mala implementación -> propagación de defectos
>>Aumento exponencial del coste de fallo
– Cambios en la base de los requisitos no son comunicados (por ejemplo a la gestión de
prueba)
• 01 Fundamentos de la validación de requisitos
¿Por qué validar?
Evaluación respecto de los criterios de calidad (continuación)
• Ponderación basada en criticidad/estabilidad
– Un énfasis erróneo conduce a la insatisfacción del cliente
• Verificabilidad
– Prueba de aceptación: requisitos ambiguos conducen a discusiones y
conflictos con el cliente
– Consecuencias legales por disputas contractuales
• Capacidad de ser modificado
– Una gestión complicada de requisitos conduce a la ineficiencia en el
transcurso del proyecto
– En el caso de haber redundancias, el cambio conduce a inconsistencias
• Trazabilidad
– Análisis de impacto: Cambios en requisitos conducen a una estimación
errónea de esfuerzo.
02 Fundamentos de la validación de requisitos
Si no hay consenso respecto de los requisitos entre los implicados
• Peligro de no realización de requisitos

• Peligro de no aceptación de requisitos (y sistema) debido a conflictos no
resueltos
• Resolución de conflictos como una oportunidad para desarrollar nuevas
ideas
• Objetivo: conformación de un entendimiento colectivo entre todos los
implicados relevantes involucrados
• Tipos de acuerdo asociados a requisitos
– De forma continua
– Tiempo y esfuerzo consumido
– Minimización del riesgo
03 Evaluación de los aspectos de calidad de los requisitos
3 aspectos para comprobar la calidad

– Las diferentes actividades en IR conducen a una descomposición en distintos
aspectos de calidad
– La totalidad de estos tres aspectos deben ser tratados
1. Contenidos
– Calidad de la información contenida en la descripción de los requisitos
– ¿Se han levantado y documentado todos los requisitos relevantes con el nivel
de detalle apropiado?
2. Documentación
– ¿Todos los requerimientos se han documentado con respecto a las guías de
documentación y especificaciones establecidas?
3. Nivel de acuerdo
– ¿Todos los implicados están de acuerdo con los requisitos documentados?
– ¿Han sido resueltos todos los conflictos?
8 criterios para evaluar el aspecto de calidad “contenido”
1. Completitud del documento de requisitos(alcance de los requisitos)

Todos los requerimientos relevantes para el sistema a ser desarrollado se han
documentado?
2. Completitud de cada requisito individual
3. Trazabilidad
4. Corrección y adecuación
¿los requisitos reflejan las necesidades y deseos del promotor?
5. Consistencia
¿no hay contradicciones entre requerimientos?
6. Sin decisiones de diseño prematuras
No se deben tomar decisiones de diseño antes de que sean establecidas las restricciones
relevantes
7. Necesidad
¿los requisitos que se están especificando contribuyen a alcanzar un objetivo definido?
8. Verificabilidad: criterios de aceptación y pruebas basados en los requisitos.
5 criterios para evaluar el aspecto de calidad “documentación”

1. Conformidad con el formato de documentación (recomendado)
¿Aplicación de plantillas obligatorias, notación,…?
2. Conformidad con la estructura de la documentación(recomendado)
3. Comprensibilidad
En el contexto dado, uso de un glosario
4. Claridad y no ambigüedad
Única interpretación del documento de requerimientos
5. Conformidad con las normas de documentación
Conformidad con la sintaxis del lenguaje de modelado aplicado
Consecuencias de la no conformidad
– Obstrucción de las actividades de desarrollo
– Requerimientos mal comprendidos
– Requisitos ambiguos/ incompletos
– Requisitos ausentes/ faltantes
VII – Verificación y ajustes de requisitos
3 criterios para evaluar el aspecto de calidad “nivel de acuerdo”

– Un proceso de acuerdo también es un proceso de aprendizaje
• Un nuevo conocimiento podría conducir a un cambio de requisitos en el contexto de
la evaluación.
1. Conciliación
• ¿Todos los requisitos han sido acordados con todos los interesados involucrados?
2. Conciliación tras el cambio
• ¿Todos los requisitos modificados han sido acordados por todos los implicados
(relevantes)
3. Conflictos resueltos
• ¿Han sido resueltos todos los conflictos conocidos respecto de los requisitos?
04 Validación de requisitos en la práctica
6 principios para comprobar requisitos /1
1. Involucrar a los implicados correctos

• Asegurar el principio de los 4 ojos para la revisión
• ¡Organizar revisores internos y externos para valorar las ventajas y desventajas!
• Evitar que el autor del requerimiento sea quien lo valide
2. Separar el descubrimiento de errores de la corrección de errores

• Principio: encontrar – evaluar – decidir – corregir
• Concentrarse en la detección de defectos
3. Comprobar desde distintos puntos de vista

• Diferentes implicados
• Lectura basada en la perspectiva.
VII- Verificación y ajuste de requisitos
04 Validación de requisitos en la practica
6 principios para comprobar requisitos/2
4. Adecuar el cambio del tipo de documentación.
– Evaluar los diferentes tipos de documentación – equilibrar los diferentes puntos
fuertes y débiles
– Pasos distintos cuando se aplica el conocimiento documentado, dependiendo del
tipo de documento.
5. Construcción de artefactos de desarrollo
– Evaluar la adecuación de un requisito dado para el desarrollo de artefactos.
6. Repetir comprobaciones
– En diferentes puntos durante la evolución del proyecto, con diferente
conocimiento.
Minizar el riesgo en las siguientes situaciones
- Sistemas innovadores - Conocimiento obtenido durante la
IR
- Proyectos de larga duración - Evaluación de requisitos en fases
muy tempranas
- Dominios desconocidos - Reutilización de requisitos
05 Tecnicas para la validación de requisitos
La revisión como una técnica de prueba (IEEE Std 1028)

- Los siguientes tipos de revisiones son utilizados como
técnicas de evaluación
– Informes de experto (“expert reports”), inspecciones (“inspections”),
revisiones guiadas (“Walk-throughs”)
- Son técnicas adicionales
– Lectura basada en perspectiva (“perspective based Reading”)
– Comprobación a través de prototipos(“validation through prtotypes”)
– Aplicación de listas de comprobación (“checklists”)
- Los tipos de revisiones se diferencian en su enfoque / forma de

mantener la revisión.
05 Técnicas para la validación de requisitos
La revisión como una técnica de prueba (IEEE

Std 1028)
Tipos de revisión basados en el IEEE Std 1028
Coste / Esfuerzo, Efectividad
1. Informes de experto 2. Revisión guiada 3.Inspeccion

1 a. Revisión informal (“informal review”)
1b. Revisión técnica (“technical review”)
Inspección: procedimiento altamente formal
- Enfoque estrictamente formal a través del seguimiento de fases
- Y roles claramente definidos
Presentac Detecció
Planificac Lista de hallazgos
ión n de
ión Consolidación de defectos
general defectos
- Organizador - Presentador (lector)

- Moderador (independiente, - Revisor (reviewer)
entrenado)
- Autor - Secretario
Inspección: procedimiento altamente formal
- Fase de presentación esquema general (“Overview phase”)
– Presentación del objeto bajo inspección por parte
del autor.
- Los revisores (normalmente pares) evalúan el objeto de
prueba bajo los criterios de evaluación según fueron definidos
en la fase de planificación.
- Listas de comprobación, métricas.
- Revisión de la preparación del objeto bajo inspección se
determina con antelación: determinación de los criterios de
entrada y salida para la inspección.
- El resultado es un informe de inspección / lista de hallazgos
formales
Inspección
- Ventajas
– Reunion bien organizada
– Deteccion de defectos estructurada
– De todas las técnicas de revisión es el tipo que detecta
la mayor cantidad de problemas
- Desventajas
– Alto nivel de esfuerzo para la preparación y
seguimiento
– Requiere una cantidad de tiempo para cada fase
especifica
– Requiere un moderador independiente y un escriba
Revisión guiada (“walkthrough”) procedimiento menos formal
- “Versión ligera” de la definición de roles
- Revisor (reviewer) - Secretario

- En -este tipo
Autor (=de revisión, el objeto- Moderador
moderador) de la revisión(=(el documento)
autor)
también es distribuido a los revisores con antelación.
- Análisis de los déficits de la calidad.
- Procedimiento de la revisión: Durante la presentación, paso a
paso, del objeto a evaluar por parte del autor (moderador), los
revisores observaran y discutirán defectos y problemas,
- Proceso centrado en la lectura: Los escenarios son
practicados/ensayados con el objeto de mejorar la
comprensión.
Revisión guiada
- Ventajas
– Menor esfuerzo de preparación – a pesar de que la reunión
puede durar menos que la de una inspección.
– La reunión puede ser iniciada con poca antelación.
– Los conflictos pueden ser resueltos durante la discusión
(dialogando)
- Desventajas
– El autor modera y puede tener una fuerte influencia sobre el
proceso
• Peligro, posiciones criticas que no sean discutidas con detalle suficiente
– Bajo grado de seguimiento dado que el autor también es el
responsable del seguimiento.
– Menos efectiva que una inspección.
Informes de experto: forma mas simple (también: revisión)
- Forma mas simple de una revisión, con frecuencia iniciada por el autor
- En lo que respecta a la elección de los revisores, solo es necesaria
competencia funcional
- No es necesaria una reunión.
- Los resultados son documentados y transferidos en listas / se hacen
observaciones en el documento.
- Normalmente se realiza en la forma de una lectura cruzada del objeto
bajo evaluación por pares (también denominada revisión entre pares)
basada en criterios de calidad.
- Ventajas Nota: Las revisiones informales y técnicas
– Ejecución rápida (basadas en el IEEE Std 1028 – Estándar
– Barata for Software Reviews and Audits) Se
• Desventajas distinguen por su grado de formalismo.
– No hay actas La revisión informal ofrece algunas
– Resultados de calidad variable simplificaciones, por ejemplo simple
lectura cruzada en lugar de una reunión
se realiza sin actas. Esto esta en línea con
Factores de éxito de las revisiones
- Las revisiones deben ser realizadas orientadas a los objetivos.
- Los autores de los documentos evaluados deberían ser “tratados de
forma positiva” por la revisión (“su documento esta mejorando” en
lugar de “su documento esta muy mal”)
- Se debe aportar un presupuesto adecuado (del 10% al 15% del
presupuesto total de desarrollo) para la ejecución de revisiones.
- Hacer énfasis en los efectos del aprendizaje (realimentación /
mejora continua) con la experiencia ganada en las revisiones
ejecutadas previamente.
- Duración de la reunión: máximo de 2 horas
- Formación cualificada para los participantes
- Es obligatoria la participación de implicados relevantes en las
revisiones
Otras técnicas – A) La lectura basada en perspectiva
- Uso en combinación con otras técnicas de revisión.
- Foco en aspectos de calidad relevantes de la perspectiva
relevante
- Perspectivas de calidad, por ejemplo, contenido, documentación,
aprobación.
- Perspectivas de implicados, por ejemplo
- Cliente / Usuario
- Arquitecto de Software
- Probador
- Requiere instrucciones detalladas con respecto o como evaluar
cada perspectiva
- Cuestionario, lista de comprobación.
- Consolidación de respuestas / lista de comprobación.
- Reunión de conclusión (“wrap-up”)
Otras técnicas – B) Comprobación a través de prototipos
- Prototipo evolutivo (desechable)
- Desarrollo a través de múltiples fases, alto consumo de tiempo
- (Único uso) prototipo desechable
- Enfoque
1. Selección de requisitos bajo evaluación
2. Realización del prototipo
3. Preparación de la evaluación
• Formación del usuario para que sea capaz de operar el prototipo
• Diseño de escenarios de prueba, incluido datos
• Diseño de lista de comprobación para evaluar criterios
4. Ejecución – autónoma, sin influencia
5. Pruebas experimentales (en el contexto de habilidades)
6. Documentación de los resultados de la evaluación
• Documentación por el revisor y el observador
7. Valoración – revisión de los requisitos.
Otras técnicas – C) Uso de listas de comprobación
- Las preguntas incluidas hacen mas fácil la detección de defectos,
especialmente en asuntos complejos
- Las listas de comprobación son desarrolladas antes de su uso en una
evaluación.
- Mejora continua de las listas de comprobación durante el curso del
proyecto.
- Las listas de comprobación no deben ser obligatorias, pero si de apoyo
- Medios para estructurar, por ejemplo entrevistas.
- Las listas de comprobación normalizan la evaluación de
contenido
- El uso eficaz de listas de comprobación depende de
- Complejidad moderada, una pagina de preguntas
propuestas.
- Concretas, preguntas sobre temas precisos.
06 Ajuste de requisitos en la practica
4 Tares durante la conciliación de requisitos
1. Identificación del conflicto.
– Durante la valoración, evaluación, sistematización…
– Entre los distintos implicados -> conflictos de objetivos
2. Análisis del conflicto
– Determinar el tipo de conflicto
– Elaboración de la resolución / conciliación de estrategias
3. Resolución del conflicto
– Factor clave de éxito para proyectos: mantener la disposición de
cooperar
4. Documentación de la resolución del conflicto
– Previene la “reaparición” de conflictos ya resueltos
– Conserva la información adquirida para ser reutilizada en otros
conflictos
Tipos de conflictos
• Tipos de conflictos diferentes requieren diferentes formas de tratar estos
conflictos
1. Conflictos sobre contenido
– Interpretaciones diferentes, falta información…
2. Intereses opuestos
– Por ejemplo: departamento del dominio versus departamento de TI
3. Conflictos sobre valores
– Valores personales, valoración diferente respecto de valores
comunes
4. Conflictos sobre relaciones
– Justificado emocionalmente (por ejemplo, situaciones de rivalidad)
5. Conflictos sobre estructura
– Basado en diferencias en poder y autoridad
Técnicas para resolver conflictos
1. Acuerdo, por ejemplo en el caso de conflictos de contenido:
• Acordar sobre una interpretación, obtener información faltante, dialogar
2. Compromiso
• Ejemplo clásico: intereses del dominio e interese del departamento de TI
3. Votar, decisión por mayoría
4. Generación de variantes, por ejemplo, permitir la parametrización
o diferentes ramas de la solución.
5. Solucionar en conflicto por situación jerárquica
6. Considerar todos los hechos
• Determinar todos los factores que influyen en el conflicto y
encontrar una soluciona través de la priorización
7. Mas-Menos-Interesante
• Lados positivos y negativos de escenarios de solución o consecuencias
interesantes unas respecto de las otras
8. Matriz de desicion
06 Ajustes de requisitos en la practica
Registro de ajuste
⁻ Las resoluciones de conflictos son documentadas
incluyendo:
– Causas de conflicto
– Personas involucradas / implicados y sus puestos
– Tipos de métodos de resolución de conflicto aplicado
– Posibles alternativas que fueron tenidas en cuenta
– La decisión y los factores que las motivaron
07 Resumen
⁻ La verificación asegura que los requisitos identificados y

documentados representan de forma adecuada las necesidades y
deseos de los implicados (aseguramiento de la calidad).
⁻ La evaluación de la calidad de contenido, documentación y
resolución de conflictos / conciliación.
⁻ La elección y uso de diferentes técnicas de evaluación esta
determinada de acuerdo a la situación especifica del proyecto.
⁻ El surgimiento de conflictos debe ser resuelto de forma
incondicional por la identificación, análisis y conciliación, habiendo
involucrado a todos los implicados.
⁻ De forma adicional, este proceso y sus resultados debe ser
documentados.
VIII – Gestión de requisitos
00 Contenido
⁻ VIII/01 Aportar atributos a un requisito

⁻ VIII/02 Diferentes vistas de requisitos
⁻ VIII/03 Priorización de requisitos
⁻ VIII/04 Trazabilidad de requisitos
⁻ VIII/05 Versionado de requisitos
⁻ VIII/06 Gestión de cambios en requisitos
⁻ VIII/07 Resumen
01 Aportar Atributos a un Requisito
Atributos
- Contiene información complementaria y describe detalles
- Las descripciones completamente a los requisitos con detalles
Como:
-[POHL], basado en INCOSE (Inernational Council on Systems Engineering)
– Identificación (ID único, categorías, nombre)
– Contexto (fuente, documento, entrega, ….)
– Propiedades de contenidos (tipo de requisito, descripción, ….)
– Propiedades de validación (estado de evaluación)
– Propiedades de gestión (estado legal, criticidad, estabilidad, prioridad)
– Propiedades de acuerdo (conflictos con implicados)
Se define una plantilla de atributos para cada tipo de requisitos
– Apoya a la definición de atributos a través de GUI / tablas
Define los atributos que deben ser utilizados para cada requisito
Definición de un tipo de atributo
- Nombre del atributo
– Identificador, auto explicativo si fuera posible
– Por ejemplo prioridad
- Semántica de los atributos

• Significa del atributo
• Ejemplo: la prioridad describe el significado o relevancia del requisito para
el cliente
- Rango
• Valores válidos para el atributo
• Ejemplo: “alto”, “medio”, “bajo”.
- Semántica
• Relevancia de los valores particulares.
Esquema de atributos /1
- Los tipos de atributos individuales se consolidan en un
esquema de atributos ara un tipo de requisitos
– Permite comparar requisitos del mismo tipo
- Normalmente, los esquemas son específicos de un proyecto, basado

en las necesidades concretas del proyecto
• Características de proyectos (tamaño del proyecto, riesgos del proyecto,
….).
• Estándares aplicables (en la compañía o en el proceso de desarrollo)
• Normativa del campo profesional de aplicación.
- Permite la estructura de requisitos y, por lo tanto, la

preparación de informes
Esquema de atributos /2
⁻ La definición basada en modelos de esquema de
atributos considera las relaciones entre distintos
atributos
– Previene, por ejemplo, la aplicación de atributos
erróneos en situaciones especificas
– Asegura la consistencia de atributos entre distintos
tipos de requisitos (con frecuencia soportados por el
modelo utilizado para estructurar la información con
herramientas de gestión de requisitos)
Esquema de atributos de requisitos (1)

⁻ ID: único, identificación del requisito relevante para el proyecto.
⁻ Nombre: permite una fácil identificación del tema de requisitos
⁻ Descripción: descripción corta del contenido
⁻ Obligatoriedad: debe, debería, se hará.
⁻ Versión: de acuerdo con la gestión de versiones
⁻ Autor, persona de contacto: nombre de las personas por parte del cliente
⁻ Fuente: origen del requisito
⁻ Criticidad: determinado por los riesgos técnicos de la implementación
⁻ Estabilidad: baja estabilidad si los requisitos son susceptibles de ser
objetos de cambio en el transcurso del proyecto
⁻ Prioridad: establecido desde el punto de vista del cliente o la gestión del
proyecto
Ejemplo de atributos de requisitos (2)

⁻ Tipo de requisitos: determina por ejemplo, la notación o la plantilla
del documento a utilizar.
⁻ Riesgo: determina desde el punto de vista de las gestión de
proyecto bajo consideraciones de aspectos de coste, plazos o
calidad
⁻ Esfuerzo: esfuerzo para la implementación del requisito
⁻ Coste: coste de la implementación del requisitos.
⁻ Historial: ¿ Cuando fue dado de alta el requisito por quién, cuándo
fueron realizados cambios?
⁻ Estado: estado dentro de un ciclo de vida predefinido de un
requisito
– Por ejemplo: nuevo, formulario / propuesto, aceptado
⁻ Entrega, configuración:
Atributos de especial relevancia para un sistema de gestión de
requisitos (SGR)
⁻ ID: (ver apartado anterior)
⁻ Tranzas: relaciones con otros requisitos (trazabilidad – ver apartado
“Trazabilidad de requisitos”)
• Se puede asignar atributos a la misma traza
Tipo de
Requisit Requisit traza
os 1 os 2 general
refinamient
o
Traza cumplimien
to
Estados: “sospechosa”, “no verificación
sopechosa” derivación
02 Diferentes vistas de requisitos
Creación de diferentes vistas de requisitos
⁻ Cada implicado tiene una vista especifica y

diferentes de los requisitos
– Basada en sus tareas y objetivos
⁻ Los clientes quieren ver el avance del proyecto
⁻ Los probadores necesitan información sobre los
requisitos iniciales para el diseño de casos de
prueba
Vista selectiva dependiente del tipo de requisito
⁻ Vitas de documentos prospectivos del tipo de requisito
– Vista de gestión muestra los objetivos básicos de un sistema y
las relaciones para requisitos inferidos / derivados
⁻ Vista de comportamiento
– Analista: transferir la descripción (por ejemplo diagrama de
estado) del comportamiento (actual) a una descripción con otra
forma (requisito funcional)
⁻ Vista de requisitos funcionales
– Vista de desarrolladores: base para la programación
– Vista del probador: diseño de casos de prueba (no-) funcionales
– Diseñador de GUI: diseña un sistema consistente de GUI basado
en la descripción del comportamiento del sistema
Vista selectiva de requisito
⁻ Resultados basados en valores de atributos
⁻ Ejemplo: vista con todos los requisitos de alta prioridad
– El jefe de proyecto identifica el orden de implementación de los
requisitos
⁻ Ejemplo vista con todos los requisitos que consumen altos
niveles de esfuerzo (atributos “esfuerzo” [días])
⁻ Posibilidades adicionales para vistas de atributo
– Editor técnico (documentación técnica): seleccionar todos los
requisitos relacionados a una entrega especifica de un producto
– Jefe de proyecto: seleccionar requisitos de criticidad alta en el
contexto de la gestión de riesgo
– Diseñador gráfico: busca requisitos relacionados con la GUI
Vista selectiva de dependencia de un requisito

⁻ Vitas grado de cobertura
– Jefe de prueba: cobertura de casos de prueba asegurando un
máximo de cobertura de los requisitos a través de casos de
prueba
⁻ Vista de la consistencia de la trazabilidad
– Ingeniero de requisitos: ¿ todos los requisitos educidos
cuentan con la información de sus respectivas fuentes?
⁻ Vista de estado de actualización de trazas
– ¿Los requisitos base han sido modificados? O ¿los requisitos
derivados requieren ser modificados?
-Atributos de la raza (no) sospechoso
Resumen de vista
⁻ Con frecuencia, las vista de requisitas combinan
la selección y agregación
⁻ Las vistas estructuradas son un prerrequisito para
la generación de informes (“reporting”)
– Generación de información que no es directamente
evidente en la base de los requisitos
⁻ Ejemplo
– Infirmes de avance (avance de proyecto, avance de
especificación)
– Tiempo, recursos, esfuerzo
– Determinación de la cobertura de prueba
Selección con herramientas de gestión de requisitos (1)
⁻ Vitas de atributos
– Presenta todos los requisitos de un cierto tipo
– Visualización de los valores de atributos específicos
⁻ Vista de traza
– Efectos de un requisito
– Importancia del análisis
de impacto cuando se
Planifican cambios en
requisitos
VIII- Gestión de Requisitos
02 Diferencias vistas de requisitos
• Selección con herramientas de gestión de

requisitos (02)
-vista matricial
– Independencia entre dos tipos de requisitos o dos
tipos
de implicados
– Tipos de relación (traza)
-¿en qué dirección?
-¿de qué tipo de relación?
VIII- Gestión de Requisitos
02 Priorización de requisitos
• Prioridades-usos práctico en proyectos
La mitad de todos los requisitos del sistema no son utilizados con
posterioridad.
INFORME CHAO 2003 del Standish Group [ RUPP01]
• Diferente significado / impacto de priorizacion
-Satisfacion del cliente a través del desarrollo de los “requerisitos más
importantes”.
– Portador de la satisfación del cliente y por o tanto del éxito del Proyecto.
– Influye en el orden de implementación.
• Especialmente importante en enfoques iterativos e incrementales
• Aportación de Atributos
• Habitualmente: necesario, deseado , opcional
-alto, medio, bajo son pocos específicos
De acuerdo con la clasificación de Kano : características básica
,desempeño, entusiasmo.
VIII-Gestión de requisitos
Técnicas
• Los requisitos ser priorizados en diferentes puntos temporales
del proyecto utilizando procedimientos:
1. Determinar los objetivos y restricciones de la priorización
2. Definir los criterios de priorización de acuerdo a
– Coste de la implementación
– Consideraciones de riesgo
– Daño causado por la implementación infructuosa
– Volatilidad
– Importancia
– Duración(tiempo)
3. Determinar los implicados que deben ser involucrados en la
priorización
4. Seleccionar los artefactos a priorizar
Con posterioridad, seleccionar la técnica de priorización.
Técnica de priorización
1. Técnicas ad-hac
– Clasificación (ranking)- determinar el orden de los
requisitos de acuerdo a un criterio de prioridad
– Técnica de los diez mejores (top-ten)- seleccionar un
numero limitado de requisitos (por ejemplo 10) que
tengan la más alta prioridad (con respecto a un único
criterio) Con posterioridad combinación con posible
clasificacón.
2. Clasificación por un criterio
– Clasificación respecto del valor de un requisito para el
éxito del sistema:
Obligatorio, opcional, es bueno tener.
3. Clasificación de Kano (ver capitulo 3.2)
4. Matriz de prioridad de Carl Wiegers
Matriz de prioridad de Carl Wiegers 1999
• Enfoque de priorización analítico
-alto grado de esfuerzo
-reduce la subjetividad
• Enfoque
1. Ponderación del factor determinante “impacto relativo”
2. Listado de los requisitos que serán objeto de priorización
3. Valoración
-Beneficio relativo “relative benfit”
-Desventaja relativa “relotive disadvantage”
-Coste relativo “relative cost”
-Riesgo relativo “relative risk”
4. Cálculo
5. Determinar el orden de la posición de cada requisito
Matriz de priorización de Carl Wiegers
1 1 0,5
icio Desventaja total Valor % Costo Costo % Riesgo Riesgo % Prioridad

vo Relativa Relativo Relativo
3 13 16,88 2 13,33 1 9,1 0,944
7 25 32,47 5 33,33 3 27,27 0,691
7 17 22,08 3 20 2 18,18 0,759
1 5 6,49 1 6,67 1 9,09 0,579
9 17 22,08 4 26,67 4 36,36 0,492
27 77 100 15 100 11 100
Prioridad= Valor %/ (Costo % + Peso de costo + Riesgo %*Peso riesgo)

Aspectos adicionales de la priorización
• También referido como la determinación de la criticidad

– Ejemplo: amenaza a la vida, prioridad, bienestar.
– Ejemplo: relevancia contractual / acuerdo legal
• Planificación de una gestión de recursos eficientes para el
desarrollo del sistema
• Las prioridades deben ser desarrolladas por consenso (talleres,
etc)
– Puntuación (“Scoring”) un número fijo de puntos es distribuido por
los
Participantes del taller sobre los requisitos.
– Preguntar sobre las relaciones identificadas
• Prioridades como un elemento amortiguador
• Suposiciones implícitas
• Detectar y resolver conflictos y compromisos
• Las prioridades pueden ser heredadas por los requisitos/
artefactos derivados
– Definir reglas de derivación
04 Trazabilidad de requisitos
Trazabilidad: Esla capacidad de trazar a los requerimientos

sobre el curso del ciclo de vida del sistema.
Beneficios de la traza:
1. Simplifican la verificabilidad/trazabilidad (por ejemplo análisis
de coberturas)
2. Permitir la identificación de exceso de tamañp
a) En el sistema (relacionando con las características del sistema)
b) En los requisitos (relacionando con los requisitos existentes)
3. Apoya el análisis de impacto (gestión de cambios)
4. Apoya la reusabilidad de la definición de requisitos
5. Apoya el aprovechamiento de recursos
– Asignación de esfuerzo de desarrollo de los requisitos
6. Apoya el mantenimiento del sistema
– Valoración de causa e impacto de fallos
• Clasificación de las dependencias de trazabilidad

requisitos
Artefactos Artefactos
Previos posterior a
A requisitos requisitos requisitos
Trazabilidad Trazabilidad Trazabilidad

pre-requisitos Entre requisitos pos-requisitos
• Clasificación de dependencias de trazabilidad

• Trazabilidad pre-requisitos(pre-requirement
specification traceability): relaciones de los
requisitos con sus fuentes (por ejemplo
documento de visión de negocio)
• Trazabilidad por-requisitos(“pos-requirement
specification traceability”): relaciones d elso
requisitos con artefactos que se desarrollan a
partir de ellos (por ejemplo cosos de prueba)
Área del
Requisitos del
cliente problema
Característica
s de la
solución Área de
la
Características del solución
software
Casos de
diseño sistema
prueba
• Representación de la trazabilidad
1. Referencias textuales e hipervínculos
2. Matrices de trazabilidad
– Creadas mantenidas de forman manual
– Para cada tipo de relación
3. Grafos de trazabilidad
– Nodos==artefactos
– Aristas ==relaciones
– Tipificación de nodos
– Cadenas de trazabilidad:
Presentación de las relaciones
Con cualquier profundad(ciclo de vida)
• Aseguramiento de la trazabilidad
-Identificador único, por ejemplo para la trazabilidad de un
ID
-Clasificación de los objetivos para la trazabilidad
-El esfuerzo adicional para el mantenimiento debe justificar el
sobre coste
-Desarrollo de modelos de trazas orientados a beneficios
– Tipos de trazas
– Estado de las trazas
– Concepto de autorización
-Definición procedimental de trazas
– ¿Quién tiene qué en la definición de trazas?
– QA de las trazas
• Retos de la implementación de la trazabilidad
Alto nivel de esfuerzo para el mantenimiento de las relaciones entre requisitos
– ¿Quién ejecuta y paga por el mantenimiento?
• ¿Cómo son transmitidos los requisitos a los interesados?
-En entornos alternamente complejos, mantener la
disciplina del mantenimiento de las trazas sólo puede ser
supervisado con la automatización: herramientas de
requisitos
-Los miembros del proyecto deben estar convencidos de la
necesidad
– Especialmente con diferentes “ejecutores” y “usuarios”
-La trazabilidad en diferentes medios
– Alto nivel de esfuerzo si no está soportado por
automatización
– Es necesario un identificador único de la información
05 Versionado de requisitos
• Construcción de versiones y gestión de versiones
• Cambio continuo de la base de requisitos durante el
curso de un proyecto
– Asegurar el acceso a los estados de cambio
– Los cambios están relacionados a estados específicos de
los requisitos designados por la versión.
-Un requisito tiene una única versión de estado
La versión de estado de un documento esta
comprendida por las versiones de los requisitos
asociados.
El sistema para determinar el
número de versiones debe ser
definido en forma especifica
para el proyecto.
05 Versionado de requisitos
• Construcción de versiones para requisitos y
configuraciones
• Cualquier alteración de un requisito conduce al
incremento de una nueva versión.
La numeración de
versiones consiste en 2
R1 R1 R1 partes :
V1,3 V1.4 V1,5 Versión e incremento
Versión: modificado como
consecuencia de grandes
R2 cambios
V1,0 Incremento: aumenta por
R3 cambios pequeños .
V1.3
Configuraci
Configuraci Configuraci
ón
ón ón
V1.2
V1.0 V1.1
VIII – Gestión de Requisitos
05 Versionado de Requisitos
Características de las configuraciones
Una configuración de requisitos incluye un numero de
requisitos, cada uno dado en una versión especifica.
-Características de una configuración de requisitos:
1. Relación lógica
-Los requisitos incluidos están conectados de forma
apropiada y lógica.
2. Consistente(no ambigua)
3. Identificador único
4. No modificable
5. La definición de una base para retorno (rollbacks) :
Retorno a una configuración anterior o rama de desarrollo
05 Versionado de Requisitos
Línea base de requisitos
-La entrega de un sistema (parcial o completo) ocurre en diferentes fases de un
proyecto.
Una línea base de requisitos(“requirement baseline”)
[entrega de requisitos (“requirement release”)] es una
configuración documentada de requisitos, que de
forma habitual, comprende versiones estables de
-requisitos
Se documentan requisitos de una madurez especifica
individuales.
– Registro (“check-in”) de la línea base de un requisito en una
herramienta de gestión de la configuración.
-Apoya las siguientes actividades en el proceso de desarrollo
– Base para la planificación de entregas (base de comunicación)
– Estimación del esfuerzo de desarrollo
– Comparación de productos con los que compite
-También: punto de inicio para las solicitudes de cambio
06 Gestión de cambios de requisitos
Causas de cambios en requisitos
- Las causas de cambios en requisitos son múltiples
- Frecuencia del cambio es un indicador de:
– Estudio (análisis) y discusiones intensivas sobre requisitos
– Estudio de requisitos (Stability of requirements)
- Razones
– Defectos, que fueron recopilados en el sistema de gestión de
defectos
‐ Defectos en producción
‐ Defectos en requisitos, por ejemplo identificación de
contradicciones
– Cambio de requisitos (cambios contractuales)
‐ Concernientes a requisitos existentes o adicionales (conocidos
hasta ahora)
‐ Cambios de requisitos de usuario, basados en un cambio de
motivación
– Cambio en requisitos debido a razones técnicas
Tareas del Comité de Control del Cambio

(CCC)
1. Estimación del esfuerzo para la implementación de un solicitud de cambio
2. Valoración del coste y beneficio
3. Definición de cambios necesarios en los requisitos / nuevos requisitos
4. Decidir si aceptar o rechazar una solicitud de cambio
5. Clasificación de las solicitudes de cambio ingresadas
6. Priorizar las solicitudes de cambio aceptadas
7. Asignación de cambios aceptados o líneas base de proyectos
Gestión del cambio

• Media en los conflictos y dirige la votaciones
• Comunica y documenta las decisiones tomadas
Comisionista Jefe de proyecto Gestor de la configuración
Representante del cliente Ingeniero de requisitos Gestor de la calidad
Representante del Arquitecto
usuario Desarrollador
Jefe de producto
Solicitud de cambio
- Comprende, al menos, esta información asociada al cambio:
1. Un único ID
2. Un título significativo
3. Una descripción
4. La justificación y
5. Fecha de la solicitud, solicitante
6. El solicitante
7. La prioridad dada ( desde el punto de vista del solicitante)
- De forma adicional comprende información de gestión
– Evaluador del cambio en el caso de que la solicitud de cambio sea
implementada
– Estado del análisis de impacto
– Estado de la decisión del CCC, si la solicitud de cambio será
implementada
– Prioridad en CCC asociada a la relevancia de la toma de decisión en el
CCC
– Responsable para la implementación de la solicitud de cambio
– Entrega del sistema determina l entrega objetivo para la implementación
Clasificación de una solicitud de cambio entrante
- Primer paso en el tratamiento de solicitudes de cambio
– Opcionalmente preclasificación antes de la reunión del CCC
- Clasificación en una de las tres categorías de solicitudes
de cambio:
1. Cambio correctivo del requisito
‐ Fallos en producción debidos a requisitos mal implementados
‐ Implementación rápida con respecto a la criticidad
2. Cambio adaptivo del requisito
‐ Son necesarios cambios en el sistema debido a cambios en las
suposiciones o en el contexto
‐ Implementación prolongada ,por ejemplo en el marco del
mantenimiento del sistema
3. Cambio excepcional (hot fix)
‐ Cambios correctivos o adaptativos con urgencia alta
‐ La categoría relevante decide la manera en que será
procesada la solicitud de cambio
06 Gestión de cambios en requisitos
Procedimiento básico (corriente / adaptativo)
- Análisis de impacto – estimación del esfuerzo también para artefactos a través del uso
de trazabilidad
- Valoración basada en consideraciones coste / beneficio (también riesgo)
- El gestor del cambio es responsable de la implementación
– Planificación
– Evaluación
1a. Análisis de
– Ejecución
impacto
– Validación
1b. Evaluación
del cambio
2. Priorización Comunicación
del cambio en del rechazo
requisito
3. Asignación del
cambio a un proyecto
de cambio
Observaciones de carácter práctico
- Definición de cambios en requisitos en el contexto de una
versión
– Considerar contexto a la entrega de producto
– Línea base asociada
- Diferentes formas de cambio
– Integración en un nuevo requisito
- Estimación de esfuerzo
– Borrado de un requisito existente
- Borrado de todos los requisitos derivados
– Cambio de un requisito existente
- ¿Cuál es el impacto del cambio en los requisitos derivados? ->
análisis de impacto
Enindustrias especificas, la trazabilidad de cambios
- Ejemplo: ajuste de casos de prueba
implementados debe ser aportada en cualquier
Información
adicional
• Trazado de cambios
- Industria farmacéutica: Food and Drug Administration
* FDA-Part 11, un requisito de la legislación Americana para
procesos basados en ordenador en la producción farmacéutica
* Documentación detallada de todos los procesos e instrucciones
de producción relevantes; en caso de revocación tendrá lugar
una evaluación detallada.
- Industria Aeronáutica: DO 178B – Estándar para el
desarrollo de software para equipamiento y provisión
en la industria aeronáutica y espacial
* Estándar de facto para el desarrollo de software en la
industria aeronáutica
* Pruebas basadas en requisito
Información
adicional
• Relación entre gestión de la configuración y

gestión del cambio
- La gestión de la configuración es una condición
para la gestión del cambio
Requisito V Requisito V
3.05 Solicitud de 3.06
cambio
Caso de Caso de
uso V 4.08 uso V 4.10
Documento de Documento de Documento de Documento de

diseño V 1.3 usuario V 1.02 diseño V 1.3 usuario V 1.03
07 Resumen
- La gestión de requisitos documentados (gestión de
requisitos) durante el ciclo de vida completo de un
sistema comprende muchas tareas distintas:
– Los requisitos deben estar disponibles
– Los requisitos deben estar desarrollados en forma
estructurada y útil
– Deben ser aportadas vistas selectivas de los requisitos
- Las técnicas utilizadas en la gestión de requisitos son:
– Aportación de requisitos - definición de atributos de los
requisitos
– Priorización - ocurre de acuerdo a objetivos y objetos de
priorización
– Trazabilidad - información sobre relaciones y dependencias
– Versionado - hace disponible diferentes estados de madurez
– Gestión del cambio - responsabilidad del CCC
IX – Herramientas de Apoyo
00 Contenido
Capitulo IX – Apoyo de herramientas
- IX/01 Herramientas
- IX/02 Introducción de herramientas en una

organización
- IX/03 Evaluación de herramientas
- IX/04 Resumen
01 Herramientas
Beneficios del uso de herramientas
- Herramientas apoyan el proceso de IR
– Definición independiente de herramienta de un proceso
- Actividad, implicados, artefactos
- Requisitos adicionales, por ejemplo restricciones de acceso
“Un tonto con una herramienta sigue siendo

un tonto”
- Herramientas de apoyo
– Captura (plantillas) y tratamiento de grandes volúmenes de
datos
– Automatización de ciertos procedimientos
- Seguimiento de las actividades definidas en el proceso
– Comunicación especifica de requisitos dentro del equipo
– Capacidad de localizar y trazabilidad de información
– Seguimientos del estado de los requisitos
01 Herramientas
1) Herramientas de propósito general
 Herramientas generales usadas para el apoyo de
desarrollo de sistemas, que no fueron desarrollados
originalmente para la gestión de requisitos
• Facilitan la integración de artefactos específicos de la
herramienta y requisitos (por ejemplo herramientas de
gestión , bug traking, test managment, configuration
managment)
 Procesador de texto, hoja de calculo, base de datos,
presentación
 Tecnologías Wiki son adecuadas para el
establecimiento de glosarios o para involucrar a los
implicados en la definición de requisitos
• Implementación Wiki para la gestión de casos de prueba:
FitNesse
 Simuladores (gráficos de estado), prototipos GUI
01 Herramientas
1) Herramientas de propósito general para

desarrollo de sistemas
Ventajas Ventajas (especificas de las
herramientas)
Aportación de Plantillas Facilidad de búsqueda de
información
Barato y fácil de aprender (estructura de datos) acceso
simultaneo
Fácil de modificar Gestión de ID
01 Herramientas
2) Herramientas de modelado
- CASE - Computer Aided Software Engeneering
- Presentación de requisitos en la forma de modelos
• Datos, comportamiento, UML
- Selección basada en criterios similares a las
herramientas de gestión de requisitos
• Gestión de ID, trazabilidad, acceso multiusuario
• Capacidad de versionado de los elementos del modelo
01 Herramientas
• Beneficios de Uso de herramienta
• Herramientas apoyan el proceso de IR
– Definición independiente de herramientas de un proceso
• Actividad, implicados, artefactos
• requisitos adicionales, por ejemplo restricciones de acceso
“Un tonto con una herramienta sigue siendo tonto”
• Herramientas de apoyo
– Captura (pantallas) y tratamiento de grades volumenes de
datos.
– automatización de ciertos procedimientos
• Seguimiento de las actividades definidas en el proceso
– Comunicación especifica de requisitos dentro del equipo
– Capacidad de localizar y trazabilidad de información
– Seguimiento del estado de los requisitos
01 Herramientas
1) Herramientas de propósito generales
• Herramientas generales usadas para el apoyo de
desarrollo de sistemas, que no fueron desarrolladas
originalmente para la gestión de requisitos.
– Facilitan la integración de artefactos específicos de la
herramienta y requisitos (por ejemplo herramientas de
gestión, bug tracking, test management)
• Procesador de texto, hoja de calculo, base de datos,
presentación.
• Tecnologías wiki son adecuadas para el
establecimiento de glosarios o para involucrar a los
implicados en la definición de requisitos.
– Implementación wiki para la gestión de casos de prueba
• Simuladores (gráficos de estado), prototipos GUI.
01 Herramientas
1) Herramientas de propósito generales para
desarrollo de sistemas
Ventajas Ventajas (Especificas de
las herramientas)
Aportación de plantillas Facilidad de búsqueda
de información
Barato y fácil de (Estructura de datos)
aprender acceso simultaneo
Fácil de modificar Gestión de ID
01 Herramientas
2) Herramientas modelado
• Case – Computer aide software engineering
• Presentación de requisitos en la forma de
modelos
– Datos, comportamiento, UML
• Selección basada en criterios similares a las
herramientas de gestión de requisitos
– Gestión ID, trazabilidad, acceso multiusuario
– Capacidad de versionado de los elementos del
modelo
01 Herramientas
2) Herramientas de modelado
Ventajas Especifica de Desventajas

le Herramienta (Especificas de las
herramientas)
Capacidad sofisticadas Capacidad limitada de
de modelado presentación texto
Uso de estadales (UML, En ciertas
SysML) hace mas fácil el circunstancian la
aprendizaje trazabilidad solo puede
ser soportada de forma
01 Herramientas
Herramientas de gestión de requisitos (Gr) (2)
• Herramientas especificadas para la GR
– Basada en base de datos
– Cubre las funcionalidades requeridas en gran medida
• Líneas base: trazabilidad, versionado automático con
historia
– Debe hacer formación
• Aplicaciones de oficina
– Aportan solo parcialmente las características requeridas
• Positivo: plantillas hipervínculos
• Negativo: trazabilidad gestión ID, versionada, multiusuario
• Alta disponibilidad
• Bajo nivel
– Bajo coste, familiaridad debido a las difusión y extensión
de su uso
01 Herramientas
Herramientas de gestión de requisitos (Gr) (2)
• Herramientas especificadas para la GR
– Basada en base de datos
– Cubre las funcionalidades requeridas en gran medida
• Líneas base: trazabilidad, versionado automático con
historia
– Debe hacer formación
• Aplicaciones de oficina
– Aportan solo parcialmente las características requeridas
• Positivo: plantillas hipervínculos
• Negativo: trazabilidad gestión ID, versionada, multiusuario
• Alta disponibilidad
• Bajo nivel
– Bajo coste, familiaridad debido a las difusión y extensión
de su uso
02 introducción de herramientas en una
organización
Introducción de la herramientas en una organización
• Condiciones
– Están establecidos y definidas las responsabilidades para la IR
– Proceso de IR definido y establecido
• Considerar los siguientes aspectos clave
1. Planificar los recursos necesarios
2. Minimizar los riesgos realizando un piloto en
circunstancias reales
• Proyecto poco critico basado en gastos y tiempos adicionales
3. Evaluar respecto a un catalogo de criterios (específicos
del proyecto)
• Criterios duros y suaves
4. Considerar todos los coste: inicio, año a año, para
formación
5. Formación del usuario en la herramienta y en el
método
03 Evaluación de herramientas
Selección de una herramienta: criterios de
evaluación
• Definición clara de objetivos asociados con la introducción de la
herramientas
• Planificación de presupuesto, tiempo y personal
para la selection de la herramienta
• Análisis de las herramientas disponibles en el
Mercado
• Debe ser definido un marco de evolución con los
criterios de evolución
– Asegurar objetividad
– Requiere análisis sistemático desde diferentes
perspectivas
• Priorizar los criterios (criterios K.O)
04 Resumen
• Las herramientas tiene por objeto dar soporte al
ingeniero de requisitos y/o usuario en el almacenamiento
de los requisitos formulados bajo un proceso de IR
documentado
• Las Herramientas se pueden dividir en diferentes grupos
con ventajas y desventajas espaciales
– Herramientas GR
– Herramientas de modelado
– Herramientas Generales (herramientas de desarrollo de
sistemas, aplicaciones de oficina estándar)
• La introducción de una nueva herramienta tiene en efecto
importante en el trabajo de un Proyecto (tiempo,
esfuerzo)
• Antes de decidir sobre una herramienta, debería tener
lugar un proceso de toma de decisión sistemático y
orientado a objetivos
Muchas gracias por su atención
Y
Le deseamos éxito en su examen
Para
Profesional certificado en ingeniería de
requisitos
(nivel Básico)
Certifieed professional for requirements
engineering
(foundation level)

Ingenieria Requisitos

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ingenieria Requisitos

Transféré par

Droits d'auteur :

Formats disponibles

Ingeniería de Requerimientos

El curso está dividido en nueve capítulos de acuerdo con

Suma de las causas En algunos casos, la sum

“… una buena gestión de requisitos fue el factor más decisivo de éxito”

Requisito (requirement) [IEEE Std. 610,12-1990]

Ingeniería de Requisitos (Requirements Engineering)

Los requisitos deben ser comunicados

Marketing Ingeniero de Documentado

1 • Justificada por su experiencia y sobre todo por su competencia en

Por otra parte no debe sobrestimar sus propias capacidades.

Como interlocutor en un debate con especialistas, no es posible

• Detectar y resolver conflictos.

Por otra parte habilidad para moderar y habilidad para empatizar.

• Requisitos Funcionales (“functional requirements”)

• Requisitos de Calidad (“quality requirements”)

Especificación de la funcionalidad en términos de los requisitos de

Otros ejemplos de restricciones:

• Requisitos no funcionales (“non functional

Son posibles otras clasificaciones:

Capítulo II – Definición de sistema y contexto

• II/01 Contexto del sistema, identificación de la diferencia entre

EJERCICIO: Discutir los riesgos de una determinación inadecuada del

2. Determinar el límite del contexto:

EJERCICIO: Discutir las dificultades de definir de forma completa la

Objetivo: Ajustar las suposiciones a la realidad e intentar verificarlas

La definición del contexto debe mantenerse estable durante la

UML – Diagrama de caso de uso

-III/01 Fuentes de requisitos

H. Schmidt Teléfono Vacaciones Conoce al

Abortar Comprobar balance de

• La clasificación puede cambiar con el transcurso del tiempo

• Atributos de desempeño: explícitamente requeridos por el cliente

• Atributos de entusiasmo: un requerimiento que no ha sido solicitado de forma

• Asuntos referidos a la organización

Es recomendable combinar métodos/técnicas

Entrevista: se presentan peguntas predefinidas al interesado donde

• La creatividad rompe el molde del pensamiento convencional.

• Lluvia de ideas (paradoja) {Brainstorming (paradox)}: recopilación de ideas

• Consideración de un problema desde diferentes puntos de vista.

Lectura basada en la perspectiva

• Ejemplo: desarrollo evolutivo de un producto

Prueba de carga Pantalla resistente al raya

-IV/01 Diseño del documento

- Crear las bases para las actividades de desarrollo

Estructura normalizada / estandarizada de documento

1. Guías del proyecto 4. Requisitos no

Ejemplo- Plantilla de especificación de

EJEMPLO : Rational Unified Process

EJEMPLO: Modelo- V 2004 (modelo estándar para la

*NPL, neurolinguistic programming

- El énfasis está dirigido sólo a una parte especifica de nuestra

• Ejemplo: El sistema debe incluir autenticación de usuario.

• Preguntas: ¿Cómo tendrá lugar la autenticación? ¿Quién crea los

• Ejemplo: El medio de transporte más económico para ir desde aquí al

• Preguntas: ¿Qué datos conducen a esta afirmación? Es decir que ir

- El efecto resultante de la transformación sigue un patrón definido.

- Estar familiarizado con este patrón puede ayudar a mejorar la calidad de la

- Elicitación de la estructura subyacente a través de la formulación de

Por medio de la nominalización, un proceso prolongado (un verbo) se

En caso de fallar el sistema, se debe reiniciar el sistema.

Los términos fallar el sistema y reiniciar describen un proceso que

Adicionalmente, los procesos nominalizados deben incluir:

• ¿Cuáles son los detalles del propio requisito?, o

2. Uso de sustantivos sin índice de referencia