Ingeniería de Software I

Validación y Administración
de Requisitos
Conferencia # 7
Curso 2022
Profesores:
MSc. Enier A. Barbán
 Facultad 5
RECORDANDO …

Ingeniería de Requisitos, Especificación de

requisitos, descripción textual de requisitos,
Descripción, Casos de Uso,
Historias de usuario,
Realizar especificación: informal, semi-informal,
Elaboración del documento de especificación de requisitos
…
Contenido

1. Validación de requisitos. Técnicas de validación de

requisitos.

2. Administración de requisitos. Trazabilidad.

Matrices de trazabilidad.
Bibliografía
• Pressman, Roger; 2010. “Ingeniería de Software: Un
enfoque práctico”. 7ma edición. Capítulos 6, 7, 8.
• Sommerville, Ian ; 2011. “Ingeniería de Software”.
9na edición. Capítulo 4.
• IEEE; 2004. Swebok: “Guía para el cuerpo del
conocimiento de la Ingeniería de Software”. Capítulo
2.
• Wiegers, Karl. 2003. “Software Requirements”.
Chapter 10
Objetivo
Caracterizar las etapas de Validación y Administración
de la Ingeniería de requisitos, a partir de sus
actividades y técnicas, como base para la reducción
de los efectos de la inestabilidad en los requisitos.
 Punto de partida
Ya se estudió el 71 % de las actividades de la Ingeniería de
Requisitos. ¿Qué pasos o actividades se han estudiado?

¿Por qué fracasaba el modelo en cascada?

¿Qué ocurre en un modelo iterativo?

¿Qué consecuencias puede tener que se acepten todos los

cambios?
Changes Happen
Poca definición del
Falta de claridad y alcance del Inestabilidad de
objetividad en las proyecto las políticas y
ideas del cliente reglas negocio

Necesidad de hacer Inestabilidad de Aumento de los

cambios los requisitos costos del desarrollo

Mitigar las consecuencias de los

Evitar inconsistencias en los cambios analizando su impacto
requisitos
Punto de partida
¿Cómo parte de la IR se han generado un conjunto de
artefactos, creando dependencias entre cada
resultado obtenido. ¿Cada resultado se corresponde
con lo que necesita y quiere el cliente?
• ¿Qué es validar?

• Aplicado al contexto de la Ingeniería de Software,

¿qué crees que sea la validación de requisitos de
software?
Validación de Requisitos
Examina la especificación para asegurar que todos los
requisitos de software se han establecido de manera
precisa; que se han detectado las inconsistencias,
omisiones y errores, y que estos han sido corregidos,
y que los productos de trabajo cumplen con los
estándares establecidos para el proceso, proyecto y
producto
[Pressman, 2010]
Validación de Requisitos
La validación de requisitos trata de mostrar que estos
realmente definen el sistema que desea el cliente.
Coincide parcialmente con el análisis ya que este
implica encontrar problemas en los requisitos.

[Sommerville, 2011]
 Requirements Validation
Validation assesses whether a product actually satisfies
the customer needs (doing the right thing)

[Wiegers, 2013]
 Chapter 17. Validating the requirements (Wiegers 2013)
Barry, a test lead, was the moderator for an inspection meeting whose
participants were carefully examining a software requirements
specification for problems. The meeting included representatives from
two user classes, a developer named Jeremy, and Trish, the business
analyst who wrote the SRS. One requirement stated, “The system shall
provide unattended terminal timeout security of workstations
accessing the training system.” Jeremy presented his interpretation of
this requirement to the rest of the group. “This requirement says the
system will automatically log off the current user of any workstation
logged into the training system if there hasn’t been any activity within
a certain period of time.”
 Traducing (Wiegers 2013)
Barry, un líder de prueba, fue el moderador de una reunión de
inspección cuyos participantes estaban examinando cuidadosamente
una especificación de requisitos de software para detectar
problemas. La reunión incluyó un desarrollador llamado Jeremy y
Trish, el analista de negocios que escribió el SRS. Un requisito decía:
"El sistema debe proporcionar seguridad de tiempo de espera de
terminal desatendida de las estaciones de trabajo que acceden al
sistema de capacitación". Jeremy presentó su interpretación de este
requisito. "Este requisito dice que el sistema cerrará
automáticamente la sesión del usuario actual de cualquier estación
de trabajo que haya iniciado sesión en el sistema de capacitación si
no ha habido ninguna actividad dentro de un cierto período de
tiempo".
Objetivo de la Validación
Comprobar que los requisitos planteados definen
el sistema que el cliente necesita.
Técnicas de Validación de Requisitos.
• Revisiones de requisitos

• Generación de casos de pruebas.

• Validación del modelo de análisis.

• Construcción de prototipos.*

* (Aplicar en los Trabajos de Curso)

Revisiones de Requisitos.

• Los requisitos son revisados por un equipo de

revisores.
• Se comprueban criterios tales como: verificabilidad,
comprensibilidad, rastreabilidad y adaptabilidad.
• Existen 2 tipos de revisiones: formales y no formales.
Revisiones de Requisitos.

Informales
• Implican que los contratistas deben tratar los
requisitos con tantos stakeholders del sistema como
sea posible.
Revisiones de Requisitos.
Formales
• El equipo de desarrollo “conduce” al cliente a través
de los requisitos del sistema.
• Se verifica cada requisito para inconsistencia
además de completitud.
• Los resultados quedan formalmente registrados en el
informe de revisión.
Generación de Casos de Prueba
◼ Un caso de prueba o test case es, en la ingeniería
del software, un conjunto de condiciones o variables
bajo las cuales un analista determinará si una
aplicación, un sistema software (software system), o
una característica de éstos es parcial o
completamente satisfactoria.
Generación de Casos de Prueba
◼ Un caso de prueba o test case es, en la ingeniería
del software, un conjunto de condiciones o variables
bajo las cuales un analista determinará si una
aplicación, un sistema software o una característica
de éstos es parcial o completamente satisfactoria.
Dale taller...
• Si las pruebas se conciben como parte del proceso
de validación, a menudo revela problemas.
• Si una prueba es imposible de diseñar, normalmente
significa que los requisitos serán difíciles de
implementar y deberían ser considerados
nuevamente.
Validación del Modelo de Análisis

Implica la actualización de los modelos

realizados
DCUS
Modelo conceptual
Construcción de Prototipo
• ¿Qué es un prototipo?
Construcción de Prototipo
• ¿Qué es un prototipo?
Una versión inicial de un sistema de software que se
utiliza para demostrar conceptos, probar opciones de
diseño y, en general, informarse más del problema y
sus posibles soluciones.

[ Sommerville, 2011]
Prototipos
¿QUÉ HEMOS VISTO?
Dale taller...
• ¿Cuál es el propósito de la validación de requisitos?
• ¿Qué técnica de las que hemos visto consideras más
efectiva?
¿Qué prototipos hemos realizados del caso de estudio?
Dale taller...
La validación de requisitos es importante porque:
• Los errores en el documento de requisitos pueden
conducir a importantes costos al repetir el trabajo
cuando son descubiertos tarde.
• El costo de arreglar un problema en los requisitos es
más alto al final que al principio del proceso de
desarrollo de software
 Validación de requisitos.
ACTIVIDADES
◼ Aplicar técnicas de
ENTRADAS validación SALIDAS
◼ Especificación de ◼ Casos de pruebas
requisitos. ◼ Prototipos
◼ Historias de usuarios ◼ No conformidades
◼ Descripciones
textuales de casos de
uso
Contenido

1. Validación de requisitos. Técnicas de validación de

requisitos.

2. Administración de requisitos. Trazabilidad.

Matrices de trazabilidad.
Administración de Requisitos
• ¿Qué es administrar?
• Aplicado al contexto de la Ingeniería de Software,
¿qué crees que sea la administración de requisitos
de software?
• ¿Qué pasa cuando, por medio de la validación se
detecta una inconsistencia en los requisitos? ¿Puede
siempre implementarse los cambios propuestos?
Administración de Requisitos
• La gestión de requisitos es el proceso de comprender
y controlar los cambios en los requisitos del sistema.

[Sommerville, 2011]
Administración de Requisitos
• Es el conjunto de actividades que ayudan al equipo
de proyecto a identificar, controlar y rastrear los
requisitos y los cambios en estos en cualquier
momento mientras se desarrolla el proyecto.

[Pressman, 2010]
Administración de Requisitos
• Its function is to maintain the integrity, accuracy and
validity of the agreed requirements, throughout the
development of the project.

[Wiegers, 2013]
Activities

[Wiegers, 2013]
Trazabilidad

◼ La Trazabilidad de requisitos es la asociación de

un requisito con otros requisitos y las diferentes
instancias o artefactos con que se relaciona,
describir y seguir el ciclo de vida completo de
un requisito.
Matriz de Trazabilidad
Matriz de trazabilidad de rastreo de la fuente.
• Vincula los stakeholders y clientes que propusieron
dichos requisitos y la razón.
• Cuando se propone un cambio esta información se
utiliza para encontrar y consultar a los stakeholders
y clientes sobre el cambio.
Ejemplo
Matriz de Trazabilidad
Matriz de trazabilidad de rastreo de requisitos
(Dependencia)

• Vincula los requisitos dependientes en el documento

de requisitos.

• Esta información se utiliza para evaluar cómo es

probable que muchos requisitos se vean afectados
por un cambio.
Ejemplo
Matriz de Trazabilidad
Matriz de trazabilidad de rastreo de diseño
(Seguimiento)
• Vincula los requisitos a los módulos del diseño en
los cuales son implementados.

• Esta información se utiliza para evaluar el impacto

de los cambios de los requisitos propuestos en el
diseño e implementación.
Ejemplo
Conclusiones
¿Cuál es el propósito de la administración de
requisitos?
¿Cuáles son las actividades que se llevan a cabo
durante la administración de requisitos?
¿Qué técnicas se utilizan para la administración de
requisitos?
¿Qué es la trazabilidad de requisitos?
Conclusiones
¿Qué matrices de trazabilidad conoces en este punto?
¿Por qué son importantes las matrices de trazabilidad?
¿Cómo contribuyen la validación y la administración de
requisitos a la reducción de costos de desarrollo de
software?
Estudiar los modelos, vistas, estilos y patrones
arquitectónicos.
❑ Bibliografía:
Perry D. E., Wolf A. L., ―Foundations for the Study of Software
Architecture,‖ ACM Software Engineering Notes, 17, 4, October 1992, 40-
52.
K.P. Birman and R. Van Renesse, Reliable Distributed Computing with the
Isis Toolkit, IEEE CS Press, Los Alamitos, Calif. 1994
 Estudio independiente

A partir de la especificación y descripción de uno de

los requisitos de su trabajo de curso, diseñe los
prototipos necesarios:
Valide estos requisitos a través de este prototipo en
consulta con el cliente.
[Sommerville, I.: “Ingeniería del Software”, 9na Edición,
Ed. Pearson – Addison Wesley, Madrid 2011. Cap. 4.]
 Trabajo independiente

a) Lleve al laboratorio el archivo del Visual Paradimg en

qué modeló el negocio y el sistema del Caso de
Estudio “Cafeteria el OK”.
b) Estudiar cómo realizar en el Visual Paradigm la
construcción de prototipos y el diseño de matrices de
trazabilidad.
Para ello consulte los materiales compartidos por su profesor
correspondientes al Laboratorio 1, Semana 9.
 Ingeniería de Software I
Validación y Administración
de Requisitos
Conferencia # 7
Curso 2022
Profesores:
MSc. Enier A. Barbán