IDR Unidad 4: Validación y gestión de requisitos

Ingeniería de requerimientos Carrera de Software
Ph.D. Franklin Parrales 1
13/05/2021
Validación y gestión de
requisitos
Unidad 4
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Ingeniería de Requerimientos

13/05/2021
Objetivo general de la Unidad 4
Analizar la especificación a fin de garantizar que
todos los requerimientos sean enunciados sin
ambigüedades; detectar y corregir las
inconsistencias, las omisiones y los errores, y que
los productos del trabajo se presentan conforme a
los estándares establecidos para el proceso, el
proyecto y el producto.

13/05/2021
Verificación y validación de
requisitos
Unidad 4
Parte 1

13/05/2021
Contenido
• Definiciones
• Validación de requerimientos
• Gestión de requerimientos

13/05/2021
Proceso de Requisitos
Artefactos
Análisis Especificación Validación
Actividades
Especificación
de Requisitos
Documento
de
Requisitos
Modelo del
Sistema
Planificación Obtención Verificación
Documento
de
Visión

13/05/2021
Verificación vs. Validación
Verificación
¿Estamos construyendo el producto correcto?
(contra Productos)
Validación
entre Modelos ¿Estamos construyendo correctamente
el producto?
(contra Intención)
entre UdeD y Modelo
Modelo 1
Verificación
Modelo 2
Verificación
Validación
Universo
de
Discurso

13/05/2021
Verificación vs validación
• Verificación y Validación (V&V): Conjunto de
procesos de comprobación y análisis que aseguran
que el software que se desarrolla está acorde a su
especificación y cumple las necesidades de los
clientes.
• Verificación: Estamos construyendo el software
correctamente.
– Se comprueba que el software cumple los requisitos
funcionales y no funcionales de su especificación.
• Validación: Estamos construyendo el producto
correcto.
– Comprueba que el software cumple las expectativas que
el cliente espera
Importante: Nunca se va a poder demostrar que el
software está completamente libre de defectos

13/05/2021
Objetivos de la V & V
• Prevenir la infiltración de requerimientos: los
que entran al producto depués del proceso
de análisis de requerimientos.
• Prevenir la fuga de requerimientos: aquellos
cuya fuente se desconoce
• Estos incrementan desmesuradamente el
costo y el tamaño del producto.
• Se pueden usar métricas de función para
controlar la infiltración de requerimientos.
• El número de function points puede ser una
medida para limitar el tamaño del desarrollo.

13/05/2021
Quality Gateway
• Evaluación de los requerimientos
• Para incluirlos en la especificación cada requerimiento debe
pasar el umbral de calidad.
• Sirve para prevenir la infiltración y la fuga de requerimientos.
• Para pasar debe :
– Tener un criterio de evaluación
– Tener una identificación única y referencias a los eventos y
casos de uso
– Ser relevante
– Ser viable
– Tener un valor para el cliente
– No ser adorno
– Estar completo
– Usar la tecnología correcta
• Los requerimientos rechazados se regresan al interesado
• Ser mantendrá una lista de requerimientos rechazados y la
razón.

13/05/2021
Contenido
• Definiciones

13/05/2021
Validación de Requisitos
• Proceso por el cual se determina si la
especificación es consistente con las
necesidades del cliente
• Se verifica en el documento de requisitos:
– Validez: que el usuario valide qué es lo que quiere
• Planificar quién (qué stakeholder) va a
validar qué artefacto cómo (técnica).
• Ejecutar
• Registrar – Reporte de validación / Firma

13/05/2021
Los requerimientos deben de ser probados
V-model
Requerimientos
Análisis
Diseño del
Sistema
Diseño de
Objetos
Codificación
Pruebas de
Unidad
Pruebas de
Integración
Pruebas de
Aceptación
Menor
detalle
Mayor
detalle
build system validate system
is validated by

13/05/2021
Validación de Requisitos
• Proceso manual. Se revisa el documento
de requisitos buscando anomalías y
omisiones:
– Revisiones informales: discusión informal
– Revisiones formales: se hace una “recorrida”
del doc de req con el cliente, explicando
implicancias de cada requisito.

13/05/2021
Importancia de la validación de requisitos
• Si la validación es inadecuada, se
propagarán errores al diseño e
implementación.
• Evidentemente, tiene una fuerte
repercusión sobre el coste.

13/05/2021
Contenido
• Definiciones
– Criterios de validación
– Involucrados
– Técnicas

13/05/2021
IEEE Std. 830-1998
Calidad de requerimientos
• El IEEE Std. 610.12 define calidad como:
– Grado en que un sistema, componente o
proceso cumple las especificaciones.
– Grado en que un sistema, componente o
proceso cumple las necesidades o deseos de
clientes y usuarios.
• En la SRS, es vital llevar a cabo el control
de la calidad del documento ya debe
especificar “sin ambigüedades” al
desarrollador las necesidades del cliente.

13/05/2021
Criterios de calidad para el
documento de requisitos
• Correcto: Contiene todas las secciones obligatorias, el
contenido de las secciones cumple con los estándares
del proyecto y las plantillas adecuadas se utilizan
correctamente.
• Completo: Contiene todos los requisitos conocidos
hasta el momento y todos los apartados obligatorios
están correctamente desarrollados.
• Internamente consistente: No contiene ningún
requisito u otra información incoherente entre sí, es
decir, no contiene contradicciones internas ni
redundancias innecesarias.
• Externamente consistente: No contiene ningún
requisito u otra información incoherente con otros
documentos del proyecto.

13/05/2021
Criterios de calidad para el
documento de requisitos
• Comprensible: Está escrito de manera que sea
fácilmente comprensible para todos los interesados en el
proyecto.
• Inequívoco: Está escrito de manera que solo se puede
interpretar de una manera y su significado no depende
de la subjetividad del lector.

13/05/2021
Criterios de calidad para los
requisitos individuales
• Gramaticalmente correcto: Está escrito de acuerdo con las
reglas gramaticales apropiadas del idioma.
• Ortográficamente correcto: Está escrito de acuerdo con las
reglas de ortografía del idioma apropiado, es decir, no
contiene errores ortográficos.
• Factible: Se puede implementar utilizando tecnología
existente y con un costo asequible dentro del presupuesto del
proyecto.
• Verificable: Está escrito de manera que se puedan definir
una o más pruebas con un costo y tiempo razonables para
verificar que el sistema de software desarrollado cumple con
los requisitos.
• Trazable: Las dependencias de requisitos se asignan a otros
requisitos o elementos de documentación de nivel superior de
los que depende.

13/05/2021
Criterios de Validación
• Es una meta numérica que la solución debe
cumplir.
• No se puede diseñar una solución a un
requerimiento sin una manera de saber si se
ha logrado resolverlo o no.
• Para los requerimientos funcionales el criterio
especifica cómo establecer si cumple sus
objetivos.
• Para los requerimientos no-funcionales, se
cuantifica el comportamiento resultante.

13/05/2021
Prueba de los criterios
El requerimiento…
• ¿Cumple con los objetivos y la intención del
producto?
• ¿Provoca el comportamiento correcto?
• ¿Puede ser probado?
– ¿Las pruebas son eficientes (costo)?
– ¿Es subjetivo el criterio?
• ¿Tiene definida la terminología?
• ¿Es ambiguo?

13/05/2021
Pruebas de Relevancia
El requerimiento…
• ¿Se encuentra dentro del contexto del
proyecto?
• ¿Cumple con las restricciones globales y
el plan estratégico del producto?
• ¿Es consistente con el producto?

13/05/2021
Pruebas de viabilidad
• ¿Los usuarios son capaces de usar el
producto?
• ¿Tenemos la habilidad tecnológica para
construir el producto?
• ¿Se tienen los medios y el tiempo para ello?
• ¿Es aceptable a todos los intersados?
• ¿Se puede hacer de manera eficiente?
• ¿Cuáles son las consecuencias del
requerimiento?

13/05/2021
Criterios de validación
• Se valida con el cliente que el documento de
requisitos disponga de:
– Consistencia: que no haya contradicciones
– Completitud: que no falte nada. Chequear por:
• Omisiones. Hacer árboles de decisión para ver que
estén todas las opciones detalladas.
• Límites. Más claro con tabla, ahí se ve que no falta
ninguno.
– Necesidad: que cubra lo que el cliente requiere
– Ambigüedades: que no de lugar a dobles
interpretaciones
– Realismo o Factibilidad: que se puedan
implementar con la tecnología, presupuesto y
calendario existentes.

13/05/2021
Criterios de validación
– Verificabilidad: que se pueda diseñar conjunto
de pruebas para demostrar que el sistema
cumple esos requisitos. Cuidado con adjetivos y
adverbios.
– Comprensibilidad: que los usuarios finales lo
entiendan
– Adaptabilidad: que el requisito se pueda
cambiar sin afectar a otros.
– Trazabilidad: que esté establecido el origen.
Incluye verificar trazabilidad entre la especific. y
el doc. de requisitos.

13/05/2021
Criterios de verificación
Verificaciones de validez
• Un usuario puede pensar que se necesita un sistema para llevar a cabo ciertas funciones.
Verificaciones de consistencia
• Los requerimientos en el documento no deben contradecirse
Verificaciones de completitud
• El documento debe incluir requerimientos que definan todas las funciones.
Verificaciones de realismo
• Los requerimientos deben verificarse para asegurar que se pueden implementar.
Verificabilidad
• Los requerimientos del sistema siempre deben redactarse de tal forma que sean
verificables.

13/05/2021
Verificación de Requisitos NO Funcionales
• Son difíciles de verificar
• Se deben expresar de manera cuantitativa utilizando
métricas que se puedan probar de forma objetiva (esto
es IDEAL)
• Para los usuarios es difícil especificarlos en forma
cuantitativa
Propiedad Medida
Rapidez Transacciones por seg
Tamaño KB
Fiabilidad Tiempo promedio entre fallas
Portabilidad Número de sistemas, especificar
Facilidad de uso Tiempo de capacitación

13/05/2021
Más Métricas…
Tipo de requerimiento Escalas de evaluación
Apariencia y sensación Cumple con el estándar?
especificar quién/cómo probarlo
Usabilidad Tiempo requerido para aprender
Tiempo de entrenamiento
Realización de funciones en tiempo planteado
Performance Tiempo para completar la acción
Operabilidad Cuantificación del tiempo/facilidad de uso
Mantenibilidad Tiempo permitido
Esfuerzo requerido para portarlo
Seguridad Cuantificar quién ha tenido acceso
Requerimientos Políticas Quién los acepta (no son cuantificables)
Requerimientos legales Opinión del abogado

13/05/2021
Contenido
• Definiciones
– Involucrados
– Técnicas

13/05/2021
Involucrados
• Definir quiénes, cómo, cuándo.
• Cómo:
– revisiones formales (en grupo)
– revisiones por pares
– listas de comprobación(checklists)

13/05/2021
Involucrados
• Participan representantes:
– del cliente: operadores, quienes realicen entradas, utilicen
salidas, y sus gerentes
– del equipo de desarrollo: analistas de requisitos,
diseñadores, encargados de pruebas y gestión de
configuración
• Incluye:
– revisar objetivos del sistema
– evaluar alineamiento de requisitos con los objetivos
(necesidad)
– revisar el ambiente de operación y las interfaces con otros
sistemas
– funciones completas, restricciones realistas
– evaluar riesgos
– considerar:
• pruebas del sistema
• cambios en los requisitos en el proyecto, su verificación y
validación
¿Cómo asegurar que la reunión es efectiva?
Moderador, secretario y responsables por
acciones

13/05/2021
Contenido
• Definiciones
– Involucrados
– Técnicas

13/05/2021
Verificación vs. Validación
Técnicas de Verificación
✓ análisis de consistencia
✓ chequeo contra
estándares
✓ análisis de checklists
✓ inspecciones
Técnicas de Validación
✓ comprobación informal
✓ uso de prototipos
✓ análisis de puntos de
vista
✓ Animación de modelos,
simulaciones,
storyboards, etc.

13/05/2021
Técnicas de verificación
• Verifican que no solo los documentos de
requisitos, sino también los requisitos
individuales cumplan con los estándares de
calidad del proyecto, es decir, con el modelo de
calidad de requisitos del proyecto.
• Las principales técnicas de verificación de
requisitos son:
– Checklists
– Inspecciones

13/05/2021
Revisión de requisitos
• Es la forma más común de verificación de
requisitos.
• Implica una lectura atenta de la documentación
para identificar no conformidades con el modelo
de calidad.
• La automatización de este proceso, es decir, el
uso de herramientas para identificar
automáticamente palabras, frases o atributos de
documentos sospechosos que pueden generar
defectos en los requisitos, es muy útil.
• Se recomienda utilizar listas de verificación.

13/05/2021
Revisión de requisitos
• Después de escribir la especificación de requerimientos se
debe realizar una revisión, para asegurar la calidad y
completitud de la especificación
• Hasta este punto los requerimientos individuales ya pasaron
el punto de control de calidad (quality gateway).
• La revisión de la especificación busca requerimientos
faltantes, chequea consistencia, conflictos y ambigüedad.
• Uso de un filtro de requerimientos (conjunto de reglas para
determinar si los requerimientos van conforme a la
especificación.
• Análisis de riesgos
• Determinar el esfuerzo contando function points por cada
evento/caso de uso

13/05/2021
Revisión (cont.)
• Determinar el valor para el cliente (suma de
los valores de satisfacción del cliente)
• Mantener una base de datos de los
requerimientos rechazados
• Realizar un post-mortem al proceso de
requerimientos
• El proceso de revisión es iterativo hasta que
se resuelven todas las inconsistencias,
conflictos y ambigüedades.

13/05/2021
Listas de verificación de requisitos
(checklist)
• Son conjuntos organizados de preguntas para
comprobar si un producto cumple o no con su
modelo de calidad.
• Durante la verificación de los requisitos, una
lista de verificación facilita la identificación de las
no conformidades:
– Ejemplo de no conformidad: ambigüedad.
– Ejemplo de pregunta en una lista de verificación: ¿Se
puede interpretar el ítem de más de una manera?

13/05/2021
Lista de verificación del documento de
requisitos
• ¿Contiene todas las secciones obligatorias de
conformidad con los estándares de la
organización?
• ¿El contenido de las secciones cumple con los
estándares de la organización?
• ¿Se utilizan correctamente las plantillas de
requisitos adecuadas?

13/05/2021
Lista de verificación de requisitos
individuales
• ¿La descripción del elemento es correcta en
gramática y ortografía?
• ¿La descripción del artículo está escrita de
manera que sea fácil de entender?
• ¿La descripción del artículo está escrita de
manera que solo se pueda interpretar de una
manera?
• ¿Se utilizan conceptos del glosario de
elementos en la descripción del elemento?
• ¿Se registran las trazas a otros elementos de
los que depende?

13/05/2021
Lista de verificación de requisitos
individuales
• Requerimientos generales
– ¿El requisito general describe un servicio de valor
para algún usuario?
• Casos de uso
– ¿El caso de uso describe una interacción no trivial
entre uno o más actores con el sistema a desarrollar?
– ¿El caso de uso está libre de referencias explícitas a
elementos específicos de la interfaz de usuario?

13/05/2021
Gestión de no conformidades de
requisitos
• Como resultado del proceso de verificación de
requisitos, se obtiene un conjunto de no
conformidades.
• Los ingenieros de requisitos son responsables
de resolver las no conformidades en la
documentación de requisitos.
• Para registrar y gestionar las no conformidades,
se puede utilizar un sistema de seguimiento de
errores.

13/05/2021
Análisis Post-Mortem
• El objetivo es aprender del proyecto.
• Revisar la eficiencia de les técnicas de
requerimientos utilizadas
• Qué aspectos deberían hacerse de manera
diferente?
• Usar un evaluador ?
• Buscar los principales errores (sin buscar
culpables)
• Buscar los principales éxitos (sin premiar a nadie)
• Escribir un reporte que se distribuye entre los
miembros del equipo y administración.

13/05/2021
Técnicas de verificación
• Verifican que no solo los documentos de
requisitos, sino también los requisitos
individuales cumplan con los estándares de
calidad del proyecto, es decir, con el modelo de
calidad de requisitos del proyecto.
• Las principales técnicas de verificación de
requisitos son:
– Checklists
– Inspecciones

13/05/2021
Técnicas de Verificación
• Inspecciones del Software:
– Se analizan las diferentes representaciones del sistema
(diagramas de requerimientos, diagramas de diseño y
código fuente) en búsqueda de defectos.
– Son técnicas de validación estáticas => No requieren que
el código se ejecute
– Debe realizarse durante todo el ciclo de desarrollo.
• Pruebas del Software:
– Se contrasta dinámicamente la respuesta de prototipos
ejecutables del sistema con el comportamiento
operacional esperado.
– Técnicas de validación dinámicas => El sistema se ejecuta
– Requiere disponer de prototipo ejecutables, por lo que
sólo pueden utilizarse en ciertas fases del proceso

13/05/2021
Inspecciones del software
• Consisten en revisiones sistemáticas tanto de los
documentos generados como de los códigos fuentes con el
único objetivo de detectar fallos.
– Las inspecciones se pueden aplicar a la detección de fallos en
cualquiera de los documentos generados
– Permiten detectar entre un 60 y un 90% de los fallos a unos costes
mucho más bajos que las pruebas dinámicas.
– Permiten detectar múltiples defectos en una simple inspección,
mientras que las pruebas solo suelen detectar un fallo por prueba.
– Permite utilizar el conocimiento del dominio y del lenguaje, que
determinan los principales tipos de fallos que se suelen cometer.
– Las inspecciones son útiles para detectar los fallos de módulos,
pero no detectan fallos a nivel de sistema, que ha de hacerse con
pruebas.
– La inspecciones no son útiles para la detección de niveles de
fiabilidad y evaluación de fallos no funcionales.

13/05/2021
Lista/Modos de fallos (1)
• Fallos de datos:
– ¿Las variables se inicializan antes que de que se utilicen los valores?.
– ¿Todas las constantes tienen nombre?
– ¿El límite superior de los arrays es igual al tamaño de los mismos?
– Las cadenas de caracteres tienen delimitadores explícitos.
– ¿Existe posibilidad que el buffer se desborde?
• Fallos de control:
– Para cada instrucción condicional ¿Es correcta la condición?
– ¿Todos los ciclo terminan?
– ¿Los bloques están delimitados correctamente?
– En las instrucciones case ¿Se han tomado en cuenta todos los casos?
– Si se requiere un break ¿Se ha incluido?
– ¿Existe código no alcanzable?
• Fallos de entrada/salida:
– ¿Se utilizan todas las variables de entrada?
– Antes de que salgan ¿Se le han asignado valores a las variables de salida?
– ¿Provocan corrupción de los datos las entradas no esperadas?

13/05/2021
Lista/Modos de fallos (2)
• Fallos de la interfaz:
– ¿Las llamadas a funciones y métodos tienen el número correcto
de parámetros?
– ¿Concuerdan los tipos de los parámetros formales y reales?
– ¿Están los parámetros en el orden adecuado?
– ¿Se utilizan los resultados de las funciones?
– ¿Existen funciones o procedimientos no invocados?
• Fallos de gestión de almacenamiento:
– Si una estructura con punteros se modifica, ¿Se reasignan
correctamente todos los punteros?
– Si se utiliza almacenamiento dinámico, ¿se asigna
correctamente el espacio?
– ¿Se desasigna explícitamente la memoria después de que se
libera?
• Fallos de gestión de las excepciones:
– ¿Se toman en cuenta todas las condiciones de errores
posibles?.

13/05/2021
Técnicas de validación
• Las principales técnicas de validación de
requisitos por parte de clientes y usuarios
que se proponen para su uso en el área
de Ingeniería de Requisitos son:
– Prototipado de interfaz de usuario
– Recorrido de casos de uso
– Auditorías
– Matriz de trazabilidad

13/05/2021
Prototipado de interfaz de usuario
• Algunas propuestas se basan en obtener de
la definición de requisitos prototipos que, sin
tener la totalidad de la funcionalidad del
sistema, permitan al usuario hacerse una
idea de la estructura de la interfaz del
sistema con el usuario.
• Esta técnica tiene el problema de que el
usuario debe entender que lo que está
viendo es un prototipo y no el sistema final.

13/05/2021
• Por qué usar prototipos?
– Algunos requerimientos no son obvios o no están
completos
– Algunos usuarios tienen dificultades para formular
sus deseos
– Algunos desarrolladores tienen dificultades para
entender los que se está pidiendo
– Darles a los usuarios la oportunidad de "usar" el
requerimiento
– Determinar la factibilidad o necesidad del
requerimiento
– Permite encontrar mas requerimientos escondidos.

13/05/2021
• Es una técnica de representación aproximada de la
interfaz de usuario de un sistema software que
permite a clientes y usuarios entender más fácilmente
la propuesta de los ingenieros de requisitos para
resolver sus problemas de negocio.
• Los dos tipos principales de prototipos de interfaz de
usuario son:
– Desechables: se utilizan sólo para la validación de los
requisitos y posteriormente se desechan. Pueden ser
prototipos en papel o en software.
– Evolutivos: una vez utilizados para la validación de los
requisitos, se mejora su calidad y se convierten
progresivamente en el producto final.

13/05/2021
Mismos datos, pero…
Ingrese
año: ____
mes: ____
día: ____
Julio 1998
1998 2025
1 31
Ene Dic
Martes 16 Oct. 2002

13/05/2021
Estrategia de desarrollo por prototipos
de aplicaciones.
• El prototipo es una aplicación que funciona.
• La finalidad del prototipo es probar varias
suposiciones formuladas por analistas y
usuarios con respecto a las características
requeridas del sistema.
• Los prototipos se crean con rapidez,
evolucionan a través de un proceso
interactivo y tienen un bajo costo de
desarrollo.

13/05/2021
Prototipos de baja fidelidad
• Baratos
• No requiere habilidades de programación
• Util como medio de comunicación
• Identifica mercado y requerimientos de
usuario
• Genera ideas de funcionalidad
• Demostración general del funcionamiento
del producto

13/05/2021
Construcción de un prototipo
de baja fidelidad
• Se hace en una etapa temprana en el
ciclo de desarrollo
• Restringir el prototipo a las tareas más
comunes
• La meta es evaluar alternativas-no invierta
mucho ego
• Enfoque de brocha ancha
• Enfoque en aspectos del producto no del
prototipo

13/05/2021
Prototipos de alta fidelidad
• Navegación y flujo
• Interactivo
• Demostración fiel del comportamiento
• Provoca el surgimiento de requerimientos de
usabilidad
• Pretenden ser como el producto final
• Completa funcionalidad de la interfaz
• "La interfaz es el producto"
• Exploración interactiva de las funciones del producto
• Se realiza junto con una especificación escrita
• Sin embargo es un prototipo desechable
• No hay compromiso de entregar exactamente la
misma interfaz

13/05/2021
Herramientas asistidas por computadora
para el desarrollo de sistemas (CASE).
• La CASE (Computer Aided Software Engineering,
Ingeniería de Software Asistida por Computadora) se
emplea con bastante frecuencia en la comunidad de
sistemas de información para diseñar la ingeniería de
sistemas asistida por computadora o la ingeniería de
software asistida por computadora.
• Componentes de CASE: Las herramientas de tipo
CASE incluyen los siguientes cinco componentes:
– Herramientas para diagramación
– Un deposito de información
– Generadores de interfaces
– Generadores de código
– Herramientas de administración
https://www.enter.co/especiales/enterprise/genexus-permite-crear-apps-sin-saber-de-codigo/

13/05/2021
– Auditorías

13/05/2021
Modelado de Situaciones
• Prototipos son generales, situaciones son
específicas
• Situaciones: relatos que ilustran acciones para un
caso especíifico
• Cada situación debe tratar un punto específico
• Trata un (o parte de uno) evento / caso de uso a
la vez
• Esclarecen implicaciones de un requerimiento
• Ayudan a encontrar requerimientos faltantes
• Utilizar medios flexibles (texto, figuras, modelos)

13/05/2021
Revisión o recorrido de casos de uso
• Está técnica consiste en la lectura y corrección
de la completa documentación o modelado de la
definición de requisitos.
• Con ello solamente se puede validar la correcta
interpretación de la información transmitida.
• Más difícil es verificar consistencia de la
documentación o información faltante.

13/05/2021
Revisión o recorrido de casos de uso
• El recorrido o walkthrough es una técnica de revisión de
productos tradicionalmente asociada a la inspección de
código fuente.
• Su principal objetivo es encontrar conflictos en el producto
que se revisa, de forma que puedan plantearse alternativas y
los participantes aumenten su conocimiento del producto en
cuestión.
– Durante las sesiones de recorrido, el autor del producto recorre
el producto a revisar en detalle, permitiendo que los
participantes pongan de manifiesto sus opiniones sobre el
mismo.
– El recorrido permite a clientes y usuarios comprender el
significado de cada requisito y manifestar su acuerdo o
desacuerdo con los mismos.
– Además, aplicando esta técnica a los casos de uso se puede
validar de manera natural la secuencia de pasos de un caso de
uso al recorrerlos por todos los participantes.

13/05/2021
Utilizando un prototipo
Descrito
• Ranura tarjeta
• Ranura papel
• Ranura dinero
• Pantalla
• Panel numérico

13/05/2021
Casos de Uso
CU Concreto

13/05/2021
Casos de Uso
CU Esencial

13/05/2021
¿Qué puedo extraer?
• Objetos, atributos, acciones

13/05/2021
– Auditorías

13/05/2021
Auditorías
• Consiste en un chequeo de los resultados
contra una checklist predefinida o definida
a comienzos del proceso, es decir sólo
una muestra es revisada.
• Se valida que los resultados obtenidos se
correspondan con la necesidad del cliente.

13/05/2021
– Auditorías

13/05/2021
Trazabilidad
• Información de rastreo que se debe
mantener
– La fuente: Quién propuso el requerimiento y
porqué
– Requisitos dependientes: Vincula los requisitos
dependientes entre sí, se usa para el análisis del
cambio
– Trazabilidad entre artefactos distintos, qué
versión se corresponde con cuál. Pe.:
• Rastreo reqs - CU
• Rastreo al diseño: Vincula el req con los módulos de
diseño que lo implementan
• Uso de matrices de trazabilidad

13/05/2021
Trazabilidad de los Requisitos
Traceability
Componente
Fuente
Forward
Traceability
Requisito
Backward
Traceability
Overhead en desarrollo y mantenimiento
Soporte automatizado de traceability
Pre-traceability Post-traceability

13/05/2021
Matriz de trazabilidad
• Las políticas de traza deben llevar cuenta de
diversa información de traza:
– De origen. Liga el requisito al stakeholder.
– De requisitos. Determina las dependencias entre
requisitos.
– De diseño. Liga los requisitos a los módulos de
diseño.
• La información de traza de requisitos puede
representarse mediante una matriz de traza
D: depende de
R: relacionado con
Req.id 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2
1.1 D R
1.2 D R D
1.3 R R
2.1 R D D
2.2 D
2.3 R D
3.1 R
3.2 R

13/05/2021
Gestión de requisitos
Unidad 4
Parte 2

13/05/2021
Contenido
• Definiciones

13/05/2021
Ingeniería de Requerimientos
Proceso de los Requerimientos
Obtención Análisis Validación
Administración de los Requisitos
Línea
Base
de
Requerimientos
Línea base actual
Línea base corregida
Planificación
Administración
del Cambio
Cambios en
requerimientos
Cambios
en el proyecto
Planifica-
ción Verificación
Trazabilidad
Especifica-
ción

13/05/2021
Administración de los Requisitos
• Los requisitos cambian, debido a:
– Muchos usuarios
– Quienes pagan por el sistema y los usuarios no son las mismas
personas
– Cambios en el negocio
– Cambios en la tecnología
• Proceso de comprender y controlar los cambios en los
requisitos del sistema
• Se hace en paralelo con el Proceso de Requisitos.
• Tres etapas:
– Planificación: Se realiza al comenzar el análisis de requisitos
– Administración del cambio: Comienza una vez que se tiene una
primera versión del documento de requisitos
– Trazabilidad: Se mantiene a lo largo del proceso de requisitos

13/05/2021
Contenido
• Definiciones
– Requerimientos duraderos y volátiles
– Planificación de la gestión de requerimientos
– Gestión del cambio de los requerimientos

13/05/2021
Requerimientos duraderos y volátiles
• Desde un punto de vista evolutivo los
requisitos pueden ser:
– Estables. Se derivan de la actividad principal
del sistema y están directamente
relacionados con el dominio.
– Volátiles. Probablemente cambiarán durante
el desarrollo del sistema o después de su
entrega.

13/05/2021
Requerimientos volátiles
• A su vez los volátiles pueden ser:
– Mutables. Cambian debido a cambios en el
entorno en el que la organización opera (e.g. un
nuevo sistema de numeración de asignaturas de
las bibliotecas).
– Emergentes. Aparecen durante el desarrollo del
sistema por el mayor entendimiento por parte del
cliente.
– De consecuencia. Aparecen por la introducción
del sistema.
– De compatibilidad. Dependen de los procesos de
negocio de la organización.

13/05/2021
Contenido
• Definiciones

13/05/2021
Planificación
• Muchas actividades son tomadas de las técnicas de SCM*
• Se debe decidir sobre:
– Identificación de Requisitos: Cada requisito debe identificarse en
forma única, para poder ser referenciado por otros.
• Ejemplo:
– <Tipo> < nro> donde Tipo: F – Funcional, D- Datos, etc.
– Ejemplo: F12
– Proceso de Administración del Cambio: Actividades que evalúan
el impacto y costo del cambio
– Políticas de Trazabilidad: Definen qué relaciones entre reqs. y
con el diseño se deben registrar y cómo se van a mantener.
– Herramientas CASE: De soporte para:
• Almacenar los requisitos
• Administrar el cambio
• Administrar de la trazabilidad
*SCM=Supply Chain Management = Gestión de la cadena de suministro

13/05/2021
Trazabilidad
• Información de rastreo que se debe
mantener
– La fuente: Quién propuso el requerimiento y
porqué
– Requisitos dependientes: Vincula los requisitos
dependientes entre sí, se usa para el análisis del
cambio
– Trazabilidad entre artefactos distintos, qué
versión se corresponde con cuál. Pe.:
• Rastreo reqs - CU
• Rastreo al diseño: Vincula el req con los módulos de
diseño que lo implementan
• Uso de matrices de trazabilidad

13/05/2021
Trazabilidad de los Requisitos
Traceability
Component
e
Fuente
Forward
Traceability
Requisito
Backward
Traceabilit
y
Overhead en desarrollo y mantenimiento
Soporte automatizado de traceability
Pre-traceability Post-traceability

13/05/2021
Contenido
• Definiciones

13/05/2021
Administración del Cambio
• El cambio va a ocurrir.
• Objetivos del control de cambios:
– Manejar el cambio y asegurar que el
proyecto incorpora los cambios correctos por
las razones correctas.
– Anticipar y acomodar los cambios para
producir la mínima disrupción y costo.
• Si los requerimientos cambian mucho
después de Línea Base →
– relevamiento incompleto/inefectivo
– o acuerdo prematuro

13/05/2021
Gestión de Requisitos
Analizar
Validez
Evaluar
Impacto
Estimar
tiempo y costo
Determinar
Aprobación o
Rechazo
Identificar
Cambios
Modificar
Modelos
Verificar
Modelos
Validar
Modelos
Realizar los Cambios
Analizar y Costear Cambios

13/05/2021
Administración del Cambio
• Cuando se propone un cambio, debe evaluarse el
impacto.
• Etapas:
1. Especificación del cambio
2. Evaluar impacto - Análisis del cambio y costo:
▪ Se usa la información del rastreo
▪ Se calcula el costo en términos de modificaciones a:
– Docs de requisitos
– Diseño e implementación
3. Discutir costo con cliente.
4. Implementar el cambio: se modifican los artefactos necesario
• Siguiendo estos pasos se logra
– Todos los cambios se tratan en forma consistente
– Los cambios a los docs de requisitos se hacen en forma
controlada

13/05/2021
Procedimiento de control de cambios
• Establecer procedimiento de control de
cambios:
– quién - Comité de Control de Cambios (CCC)
– documentar:
• integración del CCC
• alcance de autoridad
• procedimientos operativos (pe. evaluar impacto)
• proceso de toma de decisiones

13/05/2021
Ejemplo de procedimiento de control
de cambios
Para brindar un mejor servicio a sus requerimientos es necesario de su
colaboración. Adjunto podrán encontrar un formato para solicitud de
requerimientos al departamento de tecnología, también deben seguir el
siguiente proceso:
1. Todo requerimiento debe ser conocido, aprobado y enviado por el jefe
inmediato del área antes de realizar su solicitud.
2. Debe ser enviada con la prioridad sugerida, dicha prioridad debe estar
enfocada desde el punto de vista empresarial.
3. Una vez que el Gerente de Tecnología haya recibido el requerimiento,
será canalizado por el equipo de tecnología para ser evaluar el mismo.
Posteriormente se solicitará una reunión con todo el equipo funcional y
técnico relacionado en torno al requerimiento, para complementar
información funcional y específica de la solicitud (Validar el alcance del
requerimiento)
4. Dpto. Tecnología realizará un análisis y presentará una propuesta de
solución la misma que será validada y aprobada por el jefe y/o jefes
relacionados con el requerimiento.
5. Se realizarán reuniones con las jefaturas para informar del estado de
avances de los requerimientos, del manejo de prioridades y fechas de
entrega.

13/05/2021
Llenar
Solicitud
Requer.
Análisis
Requer.
Aprobar
Requer.
Evaluar
Requer.
Solicitar
Reunión
Información
Funcional y
Técnica
Análisis de
Solución
Propuesta de
Solución
Aprobación
Jefe Inmediato Gte. Tecnología Equipo Tecnología
Departamento Solicitante Tecnología

13/05/2021
Ejemplo
de
procedimiento
de
control
de
cambios

13/05/2021
• Tiene que haber un responsable
• Control de versiones: Definir:
– Ítems de configuración
– Procedimientos
• Línea Base (LB). Definición:
– Conjunto de especificaciones y /o productos que
han sido revisados formalmente y acordados,
que sirven de base para desarrollo futuro, y que
solo pueden ser cambiados a través de
procedimientos formales de control de cambios.
Gestión de la Configuración de los Requisitos

13/05/2021
Línea Base de Requisitos
• LB de reqs, arranca cuando se decide que
son suficientemente buenos como para
arrancar diseño y construcción.
• Sobre LB planifico cronograma y costo.
• Asociada a la liberación de un producto.
Debo poder recomponer la liberación.
• Definir:
– qué artefactos van en Línea Base
– cuándo entran

13/05/2021
Medir y Evaluar Requisitos
• Medir características de los requisitos para
obtener detalles
– Proceso de los Requisitos
– Calidad de los Requisitos
• Las mediciones van a estar relacionadas con:
– Producto (de los requisitos)
• tamaño, calidad, atributos técnicos, ....
– Proceso
• actividades,...
– Recursos
• personas, equipos, tiempo, dinero,...

13/05/2021
Medir y Evaluar Requisitos
• Medir
– # Requisitos
• Entrada para estimación del producto
– # Cambios introducidos
• Requisitos Agregados, Modificados, Desechados en el
tiempo
• Estabilidad
– # Requisitos por tipo de requisitos
• Permite luego ver en qué parte se encuentra el cambio
– # Requisitos validados
• Tamaño del producto y del proyecto (ej.:PF,
LoC)
• planificar

13/05/2021
Claves para la IDR
• IDR no puede hacerse de manera aislada a la
organización y el contexto social en el cual
operará el sistema.
– Esto hace que IDR deba aplicar técnicas de las
ciencias sociales, antropológicas, entre otras.
• IDR no sólo se enfoca en especificar la
funcionalidad del nuevo sistema, sino también en
modelar el ambiente en el cual estará inserto.
– Solo al conocer el ambiente y expresar al sistema de
software en ese ambiente, se podrá definir el
propósito de nuestro SS y razonar si el diseño de
nuestro sistema lo podrá alcanzar.

13/05/2021
Claves para la IDR
• IDR no debe pretender construir un modelo de
requisitos consistente y completo y debe considerar
muy seriamente la necesidad de analizar y negociar
los conflictos, negociar con los stakeholders y razonar
sobre modelos que contendrán inconsistencias
• IDR no es necesariamente un proceso secuencial , se
continua a través de todo el proceso de desarrollo
• La definición del problema no debe ser considerada
fija. Los cambios son inevitables y necesarios. Es
indispensable tener en cuenta una estrategia para su
gestión.

13/05/2021
Validación y gestión de
requisitos
Unidad 4
Final de la unidad
Y del curso…. !Muchas gracias
a todos!

IDR Unidad 4: Validación y gestión de requisitos

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to IDR Unidad 4: Validación y gestión de requisitos

Similar to IDR Unidad 4: Validación y gestión de requisitos (20)

More from Franklin Parrales Bravo

More from Franklin Parrales Bravo (20)

Recently uploaded

Recently uploaded (20)

IDR Unidad 4: Validación y gestión de requisitos