1. 1
Ingeniería de Requisitos
Tema 3: Administración de
Requisitos
(Dr. Ricardo Quintero)

2. Temas
 Principios y prácticas de
Administración de Requisitos
 Administrando los Cambios de
Requisitos
 Trazabilidad de Requisitos
2

3. Introducción
 Una vez revisados y aprobados los
requisitos, estos constituyen la línea base
para el esfuerzo de desarrollo: un acuerdo
entre el grupo de desarrollo y los clientes.
 La Administración de Requisitos incluye
todas las actividades que mantienen la
integridad, exactitud y actualidad del
acuerdo de requisitos conforme el
proyecto progresa.
3

4. Actividades de Administración de
Requisitos
4

5. Actividades de Administración de
Requisitos
 Las actividades incluyen:
 Controlar los cambios a la línea base de
requisitos.
 Mantener los planes del proyecto
actualizados con los requisitos.
 Controlar las versiones tanto de los requisitos
individuales como de los documentos de
requisitos.
 Monitorear los enlaces lógicos entre
requisitos individuales y otros productos de
trabajo del proyecto.
5

6. Los cambios en requisitos
 Un equipo de desarrollo que acepta
nuevos cambios propuestos a requisitos
podría no ser capaz de cumplir con
los compromisos de tiempo y calidad.
 El líder del proyecto debe negociar
los cambios con estos compromisos
con los administradores, clientes y
stakeholders afectados.
6

7. Los cambios en requisitos
 El proyecto puede responder a nuevos
requisitos o cambios en varias formas:
 Diferir requisitos de baja prioridad
 Obtener nuevo personal
 Forzar trabajo extra, preferiblemente con pago,
por un periodo breve de tiempo
 Extender la calendarización para acomodar la
nueva funcionalidad
 Sacrificar la calidad con la presión de terminar en
la fecha comprometida (suele ser la reacción por
defecto).
7

8. La Línea Base de Requisitos
 Es el conjunto de RF y RNF que
el equipo de desarrollo se ha
comprometido implementar en un
release específico.
 La LB da a los stakeholders un
entendimiento compartido de las
capacidades y propiedades que
esperan ver en el release.
8

9. La Línea Base de Requisitos
 En el momento en que se establece
la LB ésta se debe colocar bajo el
Control de Cambios.
 Cambios posteriores se deberán
realizar sólo a través del Proceso de
Control de Cambios definido.
 Los requisitos que están en la línea
base se deben distinguir de
cualquier otro que no lo esté
(draft).
9

10. Control de Versiones de
Requisitos
 Lee la siguiente Historia.
 ¿Has tenido alguna experiencia
similar? Comenta con el grupo.
10

11. Control de Versiones de
Requisitos
 El Control de Versiones es un
aspecto esencial de la
Administración de la
especificación de Requisitos y
otros documentos del proyecto.
 Cada versión de los documentos
de requisitos deben identificarse
de forma única.
11

12. Control de Versiones de
Requisitos
 Cada miembro del equipo debe ser capaz
de acceder a la versión actual de los
requisitos y los cambios se deben
documentar y comunicar a todos los
afectados.
 Para minimizar confusión, conflictos o
errores de comunicación, permita que sólo
individuos designados actualicen los
requisitos y asegúrate de cambiar el
identificador de versión cada vez que un
requisito cambie.
12

13. Control de Versiones de
Requisitos
 Cada versión de los documentos de requisitos
deben incluir una historia de revisiones que
identifique los cambios hechos, la fecha del cambio,
el individuo que hizo el cambio y la razón del
cambio.
 Un posible esquema de numeración (manual):
 Version 1.0 draft 1
 Version 1.0 draft 2
 Version 1.0 draft x
 Version 1.0 aprobada
 Version 2.0 draft 1
 Se puede utilizar una herramienta también
(tipo CVS o SVN).
13

14. Atributos de Requisitos
 Piensa en cada requisito como un objeto
con propiedades que se distingue de
otros requisitos.
 Además de su descripción textual debería
contar con atributos asociados con el.
 Los atributos establecen el contexto y
trasfondo del requisito más allá de la
descripción de la funcionalidad esperada.
14

15. Atributos de Requisitos
 Considera, por ejemplo:
 Fecha de creación del requisito
 Número de versión actual
 Autor que escribió el requisito
 Persona responsable de asegurar que el requisito
se satisfizo.
 Persona propietaria del requisito o una lista de
stakeholders
 Status del requisito
 Origen o fuente del requisito
 Justificación del requisito
15

16. Atributos de Requisitos
 Considera, por ejemplo:
 Subsistema (o subsistemas) a los cuales se
asigna el requisito
 Número de release al cual se asigna el requisito
 Método de verificación a utilizar o criterio de
aceptación
 Prioridad de implementación
 Estabilidad (un indicador de que tan probable es
de que cambie el requisito en el futuro)
 Selecciona el subconjunto más pequeño
de atributos que ayude a manejar los
requisitos lo mejor posible.
16

17. Monitoreando el Status de los
Requisitos
“¿Cómo vas con ese subsistema, Jackie?
Preguntó Dave”
“Muy bien, Dave. Llevo hecho un 90%”
“Pero, ¿No ere ese tu avance hace un par de
semanas? Pregunt desconcertado Dave”
“Así pensaba, pero ahora estoy seguro de que
he hecho un 90%”
17
Hay una tendencia común entre los
desarrolladores a ser muy optimistas
en los progresos logrados

18. Monitoreando el Status de los
Requisitos
 Monitorear el Status de cada RF a lo
largo del proyecto ofrece una
valoración más exacta del avance
del proyecto.
 Monitorea el Status de cada RF
contra lo que se espera sea
“completo”.
18

19. Status sugeridos
19
Status Definición
Propuesto El requisito ha sido solicitado por una fuente
autorizada
Aprobado El requisito ha sido analizado, se ha estimado
su impacto y se ha asignado a la línea base.
Los stakeholders clave han acordado
incorporar el requisito, y el grupo de
desarrollo se ha comprometido a
implementarlo
Implementado El código que implementa el requisito se ha
diseñado, escrito y probado. El requisito se ha
trazado a los elementos pertinentes de diseño
y código

20. Status sugeridos
20
Status Definición
Verificado El funcionamiento correcto del requisito
implementado se ha confirmado en el
producto integrado. El requisito se ha trazado
a los casos de prueba pertinentes. El requisito
se considera ahora completo
Borrado Un requisito aprobado se ha removido de la
línea base. Incluya una explicación de porqué
y quién tomó la decisión de eliminarlo
Rechazado El requisito fue propuesto pero no se planeó
su implementación en cualquier release
próximo. Incluya una explicación de porqué y
quién tomó la decisión de rechazarlo

21. Temas
 Principios y prácticas de
Administración de Requisitos
 Administrando los Cambios de
Requisitos
 Trazabilidad de Requisitos
21

22. Introducción
 Lea la siguiente Historia.
 ¿Ha vivido usted alguna experiencia
semejante? Comente
22

23. Introducción
 Muchos desarrolladores se han
encontrado en situaciones en las
que un cambio aparentemente
simple resulta más complicado
de lo esperado.
 Son casos en los que los cambios se
introducen “por la puerta
trasera” sin ser aprobados por los
stakeholders.
23

24. Introducción
 Una organización seria debería
asegurar que:
 Los cambios propuestos a requisitos
se evalúen cuidadosamente antes
de comprometerse a ellos.
 Los individuos apropiados toman
decisiones de negocio informadas
sobre las solicitudes de cambio.
 Los cambios aprobados se
comunican a todos los participantes
afectados.
24

25. Introducción
 A menos que los stakeholders del proyecto
manejen los cambios durante el desarrollo,
ellos no sabrán realmente que se les
entregará y esto conducirá a un “vacío de
expectativas”.
 Entre más cerca se esté de la fecha de
entrega, más se deben resistir los
cambios al release, porque las
consecuencias son más severas.
25

26. Introducción
 Los cambios propuestos deben incluirse
en el DERS para mantenerlo actualizado
conforme el producto evoluciona.
 Cuando se necesita hacer un cambio, inicia
al nivel de abstracción más alto que el
cambio toca y traza en cascada el
impacto del cambio a través de los
componentes relacionados.
 Ej.- Un cambio podría afectar al CU
y sus RF, pero no a un RN.
26

27. Gestión del Desplazamiento del
Alcance (Scope creep)
 El Desplazamiento del Alcance
(Scope creeping) se presenta cuando
surge nueva funcionalidad y
modificaciones significativas después
que se han “basificado” (line-based) los
requisitos del proyecto.
 El problema no es la aparición de
nuevos requisitos (algo normal). El
problema es la falta de control en el
crecimiento.
27

28. Gestión del Desplazamiento del
Alcance (Scope creep)
 El primer paso en manejar el Scope
creep es documentar la visión, alcance y
limitaciones del nuevo sistema, como
parte de los RN. Cada requisito o
característica propuesto se debe evaluar
contra los objetivos del negocio, visión
del producto y alcance del proyecto.
 CLAVE: Según (Weinberg,1995) la
técnica más efectiva para controlar el
SC es ser capaz de decir NO.
28

29. El Proceso de Control de Cambios
 Un Proceso de Control de
Cambios permite a los líderes de
proyectos tomar decisiones
informadas que provean el valor
mayor al cliente mientras controlan
los costos del ciclo de vida.
29

30. El Proceso de Control de Cambios
 El proceso permite monitorear
todos los cambios propuestos y
ayuda a asegurar que no se pierdan
o sobrepases.
 Una vez estable (linebased) un
conjunto de requisitos, se debe
seguir este proceso para todos
los cambios propuestos a la
línea base.
30

31. El Proceso de Control de Cambios
 Un PCC es un mecanismo de filtro
para asegurar que el proyecto
incorpora los cambios más
apropiados.
 El Proceso de Cambios debe ser
bien documentado. Tan simple
como sea posible y, sobre todo,
efectivo.
31

32. Políticas de Control de Cambios
 Todos los cambios de requisitos deben
seguir el proceso.
 Ningún trabajo de diseño o
implementación, distinto a exploración de
factibilidad, se deberá hacer sobre
cambios no aprobados.
 Una petición de cambios no garantiza que
se hará. La decisión la tomará el Change
Control Board (CCB).
 El contenido de la base de datos de
cambios estará visible a todos los
stakeholders.
32

33. Políticas de Control de Cambios
 Cada cambio incluye un Análisis de
Impacto.
 Cada cambio de requisito incorporado
deberá trazarse a una petición de cambio
aprobada.
 La justificación detrás de cada petición de
cambio aprobada o rechazada se deberá
registrar.
33

34. Políticas de Control de Cambios
 En teoría todas las peticiones de
cambios (grandes o pequeñas) deberían
pasar por el PCC.
 En la práctica, el proceso debería incluir un
“Fast-path” para peticiones de cambios
expeditas, de bajo riesgo en un ciclo de
decisión reducido.
34

35. Plantilla para definición del PCC
 La definición del PCC se puede
describir mediante esta plantilla.
 Adecúe la plantilla a sus
necesidades.
35

36. El Change Control Board (CCB)
 El CCB es el cuerpo de personas,
una o más, que decide cuales
cambios de requisitos y nuevas
características sugeridas aceptar
para incluir en el producto.
 El CCB también decide cuales
defectos reportados corregir y
cuando corregirlos.
36

37. El Change Control Board (CCB)
 El CCB revisa y aprueba cambios a
cualquier producto de trabajo “basificado”.
 No debe ser una estructura “burocrática”,
más bien efectiva.
 Un CCB efectivo considerará los
cambios propuestos y tomará las
decisiones basado en el análisis de los
impactos potenciales y beneficios de cada
propuesta.
37

38. Miembros del CCB
 No todos toman decisión, pero si deben
estar informados (busca grupo reducido):
 Líder de proyecto.
 Analista de sistema.
 Desarrollo.
 Pruebas o QA
 Representantes del cliente
 Documentación de Usuario
 Soporte técnico o Help desk.
 Gestión de Configuración
38

39. Los cambios no son
gratuitos:Análisis de Impacto
 Debido a que a las personas no les
gusta decir que “no”, es fácil
acumular una gran cantidad de
peticiones de cambios aprobadas
pendientes.
39

40. Los cambios no son
gratuitos:Análisis de Impacto
 El Análisis de Impacto ofrece un
entendimiento exacto de las
implicaciones de un cambio propuesto.
 Esto ayuda a que el equipo haga
decisiones de negocios informadas
sobre las propuestas a aprobar.
 El análisis examina el cambio propuesto
para identificar los componentes que
podrían crearse, modificarse o
descartarse y estimar el esfuerzo
asociado con la implementación del cambio.
40

41. Procedimiento del Análisis de
Impacto
 El Jefe del CCB pide a un
desarrollador con experiencia
que realice el Análisis de Impacto
para una propuesta específica de
cambio.
41

42. Procedimiento del Análisis de
Impacto
 El A. de I. tiene tres aspectos:
1. Entender las posibles implicaciones de
hacer el cambio.
2. Identificar todos los archivos, modelos
y documentos que podrían tener que
ser modificados si el equipo incorpora la
petición de cambio.
3. Identificar las tareas requeridas
para implementar el cambio y estimar
el esfuerzo necesario para completar las
tareas.
42

43. Checklist y Procedimientos para
ayudar a el A. de I.
 Estas listas pueden ayudar al
Analista de Impacto a entender las
implicaciones del cambio
propuesto.
 Este procedimiento puede ayudar a
evaluar el impacto de un cambio
propuesto
43

44. Temas
 Principios y prácticas de
Administración de Requisitos
 Administrando los Cambios de
Requisitos
 Trazabilidad de Requisitos
44

45. Introducción
 Lea esta Historia.
 Comente la importancia de la
trazabilidad en el proceso de
Análisis de Impacto en los Cambios
de Requisitos.
45

46. Introducción
 El Análisis de Impacto es mucho
más fácil si se tiene un mapa que
muestre donde fue
implementado en software cada
requisito o regla de negocio.
 El Trazado de Requisitos
documenta las dependencias y
enlaces lógicos entre requisitos
individuales y otros elementos
del sistema.
46

47. Introducción
 La información de Trazabilidad
facilita el Análisis de Impacto
ayudando a identificar todos los
productos de trabajo que
tendrían que modificarse para
implementar el cambio propuesto
de requisitos.
47

48. Trazando los requisitos
 Los Enlaces de Trazabilidad permiten
seguir la vida del requisito tanto hacia
adelante como hacia atrás: del origen
a la implementación.
 Para permitir la trazabilidad, cada
requisito deberá ser etiquetado de
forma única y persistente de tal
forma que pueda referenciarse sin
ambigüedad a lo largo del proyecto.
48

49. Trazando los requisitos
 Escriba los requisitos en estilo de grano
fino, en lugar de crear párrafos grandes
(con muchos RF que conduzcan a una
explosión de elementos de diseño y
código).
49

50. Tipos de enlaces de requisitos
50

51. Algunas implicaciones de estos
enlaces
 Los Casos de Prueba se derivan
–se trazan- a requisitos
individuales.
 Si un “tester” detecta funcionalidad
no esperada sin un requisito
correspondiente, pudiera entonces:
 El Analista agregar esta funcionalidad
legítima
 O podrían ser código “Gold Plating”.
51

52. Algunas implicaciones de estos
enlaces
 Los enlaces de Trazabilidad ayudan a
seguir la pista del antecesor,
interconexión y dependencia entre
requisitos individuales.
 Esto ayuda a revelar la propagación
resultante de un cambio cuando un
requisito se borra o modifica.
 Si existe trazabilidad entre el requisito y
una unidad de trabajo, esas tareas se
verán afectadas cuando el requisito se
cambie o borre.
52

53. Algunos posibles enlaces de trazabilidad de
requisitos
53

54. Motivaciones para la Trazabilidad
de Requisitos
 La Trazabilidad de Requisitos es una
tarea manual intensa que requiere
compromiso organizacional.
 Mantener la información actualizada de
los enlaces conforme se desarrolla y
mantiene el sistema demanda disciplina.
 Si la información de trazabilidad se torna
obsoleta, lo más probable es que nunca se
reconstruirá.
54

55. Motivaciones para la Trazabilidad
de Requisitos
 Beneficios de implementar trazabilidad de
requisitos:
 Certificación: demostrar que los requisitos
fueron implementados (lo cual no garantiza que
fueron implementados correctamente).
 Análisis de Impacto de Cambios: sin
Trazabilidad lo más probable es que se pase por
alto elementos de sistema afectados por cambios
en requisitos.
 Mantenimiento: se facilita la elaboración de
cambios correctos y completos durante el
mantenimiento. Esto, a su vez, mejora la
productividad.
55

56. Motivaciones para la Trazabilidad
de Requisitos
 Mas Beneficios :
 Monitoreo del Proyecto: permite mantener un
monitoreo exacto del estado de la
implementación de la funcionalidad planeada.
 Reingeniería: registrar las funciones de
sistemas legados que se están reemplazando y
su enlace a los nuevos requisitos y componentes
software.
56

57. Motivaciones para la Trazabilidad
de Requisitos
 Mas Beneficios :
 Riesgos: cuando un miembro clave del equipo
se va y su conocimiento queda en los enlaces de
trazabilidad.
 Pruebas: cuando una prueba lleva a un
resultado inesperado, los enlaces entre pruebas,
requisitos y código apuntan a las partes del
código que hay examinar para buscar los
defectos.
57

58. Motivaciones para la Trazabilidad
de Requisitos
 Muchos de los beneficios son a largo plazo,
reduciendo los costos del ciclo de vida
aunque incrementen el costo de desarrollo (por
el esfuerzo de mantener los enlaces).
 La Trazabilidad de Requisitos es una inversión
que pagará dividendos cuando tengas de
extender, modificar o reemplazar el
producto.
 En realidad no es mucho trabajo si
recolectas la información conforma
procede el desarrollo; pero es tediosa y cara
para un sistema completo sin trazabilidad
previa.
58

59. Matriz de Trazabilidad
 Es la forma más común de
representar enlaces entre
requisitos y otros elementos del
sistema.
59

60. Ejemplo de Matriz de Trazabilidad
60
RU RF Elemento
de Diseño
Módulo de
Código
Caso de
Prueba
CU-28 Catalog.query.sort Clase
Catalogo
Catalog.sort() Search.7
Search.8
CU-29 Catalog.query.sort Clase
Catalogo
Catalog.sort() Search.12
Search.13
Search.14
Esta información se debe ir incluyendo conforma avanza
el proyecto

61. Cardinalidad entre enlaces
 Uno a Uno: un elemento de diseño
implementado en un módulo de
código.
 Uno a Muchos: un RF verificado
con múltiples Casos de Prueba
 Muchos a muchos: un CU que
deriva múltiples RF y ciertos RFs a
comunes a varios CU.
61

62. Variantes entre las Matrices de
Trazabilidad
 Una Matriz de Trazabilidad puede definir
diferentes tipos de enlaces entre
requisitos:
 Requisito-Requisito (del mismo tipo)
 Requisito-Requisito (de tipo distinto)
 Requisito-Caso de Prueba
 Estos tipos de matrices pueden definir
varios tipos de relaciones: “especifica/es
especificada por”, “depende de”, “es padre
de”, “restringe/es restringida por”
62

63. Matriz de Trazabilidad: CU-RF
63
Req.
Funcionales
Casos de Uso
CU-1 CU-2 CU-2 CU-3
RF-1 <-
RF-2 <-
RF-3 <-
RF-4 <-
RF-5 <-

64. Responsables de mantener la
trazabilidad-quién tiene la información
64
Tipo de Objeto
Fuente
Tipo de Objeto
Destino
Fuente de
Información
Caso de Uso Requisito Funcional Analista
Requisito Funcional Requisito Funcional Analista
Requisito Funcional Caso de Prueba Ingeniero de
Prueba
Requisito Funcional Elemento de la
Arquitectura
Software
Arquitecto de
Software
Requisito Funcional Otros elementos de
Diseño
Diseñador o
desarrollador
Elemento de Diseño Código Desarrollador
Regla de Negocio Requisito Funcional Analista

65. Procedimiento para Trazabilidad
de Requisitos
1. Seleccionar las relaciones de
enlace que deseas definir (usa el
diagrama de relaciones posibles)
2. Selecciona el tipo de matriz de
trazabilidad que desea usar: 1 o
más matrices.
3. Identifica las partes del
producto para las cuales deseas
mantener información de
trazabilidad.
65

66. Procedimiento para Trazabilidad
de Requisitos
4. Modifica tus procesos y checklist para
recordar a los desarrolladores que
actualicen los enlaces después de
implementar un requisito o un cambio
aprobado.
5. Define convencionalismos de
etiquetas que utilizarás para identificar
de forma única todos los elementos del
sistema de tal forma que se puedan
enlazar entre sí.
66

67. Procedimiento para Trazabilidad
de Requisitos
6. Identifica los individuos que
proveerán la información de enlace y la
persona que coordinará las actividades de
trazabilidad y gestión de datos.
7. Educa al equipo sobre los conceptos e
importancia del trazado de requisitos, los
objetivos de la actividad, donde se
almacenarán los datos de trazabilidad y
las técnicas para definir enlaces.
Asegúrate que todos se comprometan en
sus responsabilidades
67

68. Procedimiento para Trazabilidad
de Requisitos
8. Conforme avanza el desarrollo, que cada
participante provea la información de
trazabilidad por cada unidad pequeña de
trabajo.
9. Audita periódicamente la información
de trazabilidad para asegurar que está
actualizada.
68