1. 1
Ingeniería de Requisitos
Tema 1: Fundamentos de
Ingeniería de Requisitos
(Dr. Ricardo Quintero)

2. 2
Temas
 Definición de Requisito
 Desarrollo y Administración de Requisitos
 Características de Requisitos excelentes
 Los Requisitos desde la perspectiva del
cliente
 Buenas prácticas de la Ingeniería de
Requisitos.

3. Definición de Requisito
 En el trabajo día a día suele
utilizarse el término “Requisito”*
sin clara distinción de un tipo
específico.
 Esto conlleva a la necesidad de su
definición más precisa.
* Requisito=Requerimiento
3

4. Definición de Requisito
 Def. IEEE: Incluye la vista del usuario –
stakeholder- (externa) y del desarrollador
(interna):
1. Una condición o capacidad necesaria por un
usuario para resolver un problema o alcanzar
un objetivo.
2. Una condición o capacidad que debe ser
satisfecha o poseída mediante un sistema o un
componente de un sistema para satisfacer un
contrato, especificación u otro documento
formalmente impuesto.
3. Una representación documentada de una
condición o capacidad tal como 1 o 2.
4

5. Definición de Requisito
 Def. Sommerville y Sawyer:
“Los Requisitos son una especificación de
lo que debe ser implementado. Son
descripciones de cómo el sistema se
debe comportar, o de una propiedad o
atributo del sistema. Podrían ser
restricciones sobre el proceso de
desarrollo del sistema”
5

6. Definición de Requisito
 Claramente no hay una definición universal
de lo que es un Requisito, para facilitar la
comunicación se necesita acordar un
conjunto de adjetivos que modifiquen el
término Requisito.
 Además es importante apreciar el valor de
registrar los Requisitos en una forma
compartida.
 IMPORTANTE: “El equipo debe establecer
claramente los tipos de requisitos a fin de
lograr comunicación común”
6

7. Niveles de Requisitos
 Tres son los niveles que se suelen
utilizar para los Requisitos software:
1. Requisitos del Negocio (Business
requirements).
2. Requisitos de Usuario (User
Requirements).
3. Requisitos Funcionales (Functional
Requirements).
 Además de los Requisitos No
Funcionales.
7

8. Niveles de Requisitos
8
Tipos de
Requisitos
Contenedores
de Requisitos

9. Requisitos del Negocio
 Son los Objetivos de Alto Nivel de la
organización o cliente que solicita el
sistema.
 Típicamente provienen del patrocinador del
proyecto, del cliente.
 Describen porqué la organización está
implementando el sistema.
 Suelen documentarse en un Documento
de Visión y Alcance.
9

10. Requisitos de Usuario
 Describen los Objetivos de
Usuario o Tareas que los usuarios
deben ser capaces de realizar con el
producto.
 Formas valiosas de representarlos
son: Casos de Uso, Escenarios y
Tablas Evento-Respuesta.
10

11. Requisitos Funcionales
 Especifican la Funcionalidad Software
que los desarrolladores deben construir en
el producto para habilitar a los usuarios
para que cumplan sus Tareas y al hacerlo
satisfacer los Objetivos del Negocio.
 Suelen llamárseles “Requisitos de
comportamiento”.
 Se documentan en el “Documento de
Especificación de Requisitos Software
(DERS)”
11

12. Otros Requisitos
 Requisitos de Sistema: describen
requisitos de alto nivel para un
producto que contiene múltiples
subsistemas (software, hardware,
personas)
12

13. Reglas del Negocio (RN)
 Incluyen las políticas corporativas,
regulaciones gubernamentales,
estándares de la industria, prácticas
contables, algoritmos
computacionales.
 IMPORTANTE: no son en sí mismas Requisitos
software porque existen fuera de las fronteras de
un típico sistema software. Sin embargo suelen
restringir quien puede realizar ciertos casos de uso o
dictan que el sistema contenga funcionalidad para
cumplir con las reglas pertinentes.
13

14. Reglas del Negocio (RN)
 Alguna veces las RN son el origen de
ciertos atributos de calidad que son
implementados en funcionalidad.
 Por lo que se debe poder trazar la génesis
de ciertos requisitos funcionales hacia
atrás a una cierta RN.
14

15. Requisitos No Funcionales
 Incluyen Objetivos de Desempeño y
Descripciones de Atributos de Calidad.
 Los Atributos de Calidad aumentan la
descripción de la funcionalidad del producto
describiendo las características del
mismo en varias dimensiones
importantes a usuarios o desarrolladores.
 Las características incluyen: usabilidad,
portabilidad, integridad, eficiencia y
robustez.
15

16. Requisitos No Funcionales
 Otros Requisitos No Funcionales describen
interfases entre el sistema y el mundo
exterior y restricciones de diseño e
implementación.
 Las restricciones imponen límites en las
opciones disponibles al desarrollador para el
diseño y construcción del producto.
16

17. Features (Características)
 Es un conjunto lógicamente relacionado de
Requisitos Funcionales que proveen una
capacidad al usuario y le posibilita la
satisfacción de un objetivo de negocios.
 IMPORTANTE: Una lista de “Features” deseados de
un producto no es el equivalente a la descripción de
las necesidades y sus tareas-de-usuario
relacionadas. Un “Feature” puede abarcar múltiples
CU. Cada CU requiere la implementación de
múltiples Requisitos Funcionales para permitir que el
usuario realice la tarea.
17

18. Ejemplo-Todos los Requisitos
 Considere un “Procesador de
palabras (PP)”:
 RN: “El producto permitirá a los
usuarios corregir eficientemente
errores ortográficos en el
documento”
 Feature: el PP incluye un
“Corrector ortográfico”.
18

19. Ejemplo-Todos los Requisitos
 RU: “Buscar errores ortográficos”, “Agregar
una palabra al diccionario”.
 RF: “Buscar y resaltar una palabra con
error ortográfico”, “Desplegar un cuadro
diálogo con reemplazos sugeridos”,
“Reemplazar palabras erróneas con
correctas”.
 Atributo de calidad: usabilidad: ¿Qué se
entiende por “eficiente” en el RN?
19

20. Requisitos y roles
 Los niveles estratégicos y de gestión de la
organización definen los RN.
 Los RU se deben alinear a los RN.
 A partir de los RU el analista deriva los RF
que permitirán a los usuarios realizar sus
tareas con el producto.
 A partir de los RF y RNF los desarrolladores
diseñan las soluciones que implementan la
funcionalidad requerida y logran los objetivos
de calidad y desempeño, dentro los límites
que imponen las restricciones.
20

21. Lo que NO son Requisitos
 Los Requisitos no incluyen:
 Detalles de diseño o implementación
 Información de planeación del
proyecto.
 Información de pruebas.
 IMPORTANTE: Separe esta información de
los Requisitos de tal manera que las
actividades de Requisitos se enfoquen en
entender lo que los equipos intentan
construir.
21

22. 22
Temas
 Definición de Requisito
 Desarrollo y Administración de
Requisitos
 Características de Requisitos excelentes
 Los Requisitos desde la perspectiva del
cliente
 Buenas prácticas de la Ingeniería de
Requisitos.

23. Desarrollo y Administración de
Requisitos
 La Ingeniería de Requisitos
cubre todas las actividades
relacionadas con su Desarrollo y
Administración.
23

24. Desarrollo y Administración de
Requisitos-Gráficamente
24

25. Desarrollo de Requisitos
 Comprende todas las actividades
involucradas en la obtención, evaluación
y documentación de un sistema software,
incluyendo:
1. Identificar las clases de usuarios del
producto esperadas.
2. Levantar las necesidades de individuos que
representan cada clase de usuario.
3. Analizar la información recibida de los
usuarios para distinguir objetivos de requisitos
funcionales, no funcionales, reglas de negocio,
soluciones sugeridas e información extraña.
25

26. Desarrollo de Requisitos
 (Cont…):
4. Asignar porciones de los requisitos de alto nivel a
componentes software definidos en la arquitectura
del sistema.
5. Entender la importancia relativa de los atributos
de calidad.
6. Negociar las prioridades de implementación.
7. Traducir las necesidades de usuario recolectadas
en modelos de especificación de requisitos escritos.
8. Revisar los requisitos documentados para
asegurar un entendimiento común de los
requisitos de usuario y para corregir todos los
problemas antes de que el grupo de desarrollo los
acepte.
26

27. La importancia del enfoque
iterativo
 En el caso de proyectos nuevos el
enfoque iterativo es clave para el
éxito.
 Se debe planear para múltiples
ciclos de exploración de requisitos,
refinamiento de requisitos de alto
nivel en detalles y confirmar su
certeza con los usuarios.
27

28. Administración de Requisitos
 Abarca “establecer y mantener
un acuerdo con el cliente sobre
los requisitos del proyecto
software”
 El acuerdo está en las
especificaciones escritas y los
modelos.
28

29. Administración de Requisitos
 La aceptación del cliente es la
mitad de la ecuación necesaria para
la aprobación de los requisitos, la
otra mitad es la aceptación de la
especificación y el acuerdo de
los desarrolladores para
construirlos en el producto.
29

30. Actividades de la Administración
de Requisitos
1. Definir la línea base de los Requisitos
(una “foto en el tiempo” que representa el
cuerpo de los requisitos acordados para el
release actual).
2. Revisar los cambios propuestos a los
requisitos y evaluar el impacto de cada
cambio antes de aprobarlo.
3. Incorporar de forma controlada los
cambios aprobados al proyecto.
4. Mantener los planes del proyecto
actuales con los Requisitos.
30

31. Actividades de la Administración
de Requisitos
5. Negociar nuevos compromisos basados
en el impacto de los cambios de
Requisitos.
6. Trazar los Requisitos individuales a los
diseños, código fuente y casos de prueba
correspondientes.
7. Monitorear el status de los Requisitos
y su actividad de cambio a lo largo de todo
el proyecto.
31

32. Desarrollo y Administración de
Requisitos
32

33. 33
Temas
 Definición de Requisito
 Desarrollo y Administración de Requisitos
 Características de Requisitos
excelentes
 Los Requisitos desde la perspectiva del
cliente
 Buenas prácticas de la Ingeniería de
Requisitos.

34. Características de Requisitos
Excelentes
 En un “mundo ideal” cada RN, RU y RF
debería exhibir las siguientes cualidades:
 Completo: debe describir completamente
la funcionalidad a entregar. Debe
contener toda la información necesaria para
que el desarrollador diseñe e implemente
esa fracción de funcionalidad. Si algo faltare
señálelo (TBD-”To be determined”).
34

35. Características de Requisitos
Excelentes
 Correcto: debe describir exactamente
la funcionalidad a ser construida.
Solamente representantes de usuarios
pueden determinar la exactitud de los RU
(por eso la importancia de su
participación).
35

36. Características de Requisitos
Excelentes
 Factible: debe ser posible implementar
cada requisito dentro de las
capacidades y limitaciones del sistema
y su ambiente operativo. Para esto es
importante que el desarrollador trabaje con
el analista a lo largo del proyecto. Él puede
determinar lo que se puede hacer o no
técnicamente o de lo que se puede hacer
solamente a un costo muy alto. Las
“pruebas de concepto” pueden ayudar en
este rubro también.
36

37. Características de Requisitos
Excelentes
 Necesario: cada Requisito debe
documentar una capacidad que los
clientes realmente necesiten o uno que
es requerido para satisfacer un requisito de
sistema externo o un estándar. Cada
requisito debe partir de una fuente
autorizada. Traza cada requisito una
“entrada de voz autorizada de cliente” (CU,
RN o algún otro origen).
37

38. Características de Requisitos
Excelentes
 Priorizado: se debe asignar una prioridad
de implementación a cada RF, Feature o CU
para indicar que tan esencial es para un
cierto release.
 Si todos tuvieran la misma prioridad será
difícil para el líder de proyecto responder a
recortes de presupuesto, tiempos
“ajustados”, pérdida de personal o nuevos
requisitos agregados durante el desarrollo.
38

39. Características de Requisitos
Excelentes
 No ambiguos: todos los lectores del requisito
deben llegar a una única interpretación
consistente de él, pero el lenguaje natural es muy
propenso a la ambigüedad.
 Los requisitos se deben escribir de forma simple,
concisa, en un lenguaje directo apropiado al
dominio del usuario. “Comprensibilidad” es un
atributo de calidad relacionado con la “no
ambigüedad”: los lectores deben ser capaces de
entender lo que cada requisito está diciendo.
Defina los términos especializados y términos que
puedan confundir a los lectores en un glosario.
39

40. Características de Requisitos
Excelentes
 Verificable: busque definir pruebas
o estrategias de verificación
(inspección o demostración) para
determinar si un producto
implementa apropiadamente cada
requisito.
40

41. Características de Especificación
de Requisitos
 Además de requisitos individuales
excelente, se requiere que en
conjunto exhiban otras
características excelente.
41

42. Características de Especificación
de Requisitos
 Completo: ningún requisito o
información necesaria debería estar
ausente. Enfocarse en tareas de
usuario más que en funciones de
sistema puede ayudar a evitar falta
de completitud.
42

43. Características de Especificación
de Requisitos
 Consistente: requisitos
consistentes no tienen conflicto con
otros del mismo tipo o con otros de
más alto nivel (RN, RS o CU).
 Los desacuerdos entre requisitos se
deben resolver antes de proceder al
desarrollo.
43

44. Características de Especificación
de Requisitos
 Modificable: debes ser capaz de
revisar el DERS y mantener una
historia de los cambios hechos a
cada requisito. Esto implica
etiquetar de forma individual cada
requisito y expresarlos de forma
separada a otros requisitos. En
lugar de duplicar establezca
referencias cruzadas.
44

45. Características de Especificación
de Requisitos
 Trazable: un requisito trazable se
puede enlazar hacia atrás a su
origen y hacia adelante a sus
elementos de diseño y código
fuente que lo implementan y a los
casos de prueba que verifican que
su implementación es correcta.
45

46. Siguientes pasos …
 Escribe los problemas relacionados
con requisitos que has encontrado
en tus proyectos. Clasifícalos como
de desarrollo o administración de
requisitos. ¿Cuál ha sido el impacto
que han tenido cada problema y sus
causas raíz?
46

47. 47
Temas
 Definición de Requisito
 Desarrollo y Administración de Requisitos
 Características de Requisitos excelentes
 Los Requisitos desde la perspectiva
del cliente
 Buenas prácticas de la Ingeniería de
Requisitos.

48. Introducción
 Lea la siguiente historia.
 ¿Ha tenido usted alguna experiencia
similar? Comente en el grupo.
48

49. Introducción
 Parte del problema que presenta Gerhard es
que no distingue entre RN, RU y RF, porque
finalmente él no será un usuario del sistema.
 Los usuarios, en cambio, pueden describir
las tareas que realizarán con el sistema, pero
quizá no podrán describir todos los RF que
los desarrolladores deben implementar para
posibilitar dichas tareas.
 El involucramiento comprometido del
usuario es fundamental para el éxito del
sistema (práctica común en métodos ágiles).
49

50. ¿Quién es el cliente?
 Def.- Es el individuo u organización quien
deriva directa o indirectamente beneficios del
producto.
 Los clientes software incluyen los stakeholders del
proyecto que solicitan, pagan, seleccionan,
especifican o reciben la salida generada por un
producto software.
 Los clientes pueden estar a diferente nivel:
 Ejecutivo: los que definen los RN.
 Usuario final: los que usan directamente el producto (RU)
 El gran problema es que suele ser común que
ambos “nunca tengan tiempo” y todo se deja al
analista con consecuencias finales fatales: requisitos
pobres.
50

51. ¿Quién es el cliente?
 En ocasiones ambos tipos de usuarios
presentan conflictos porque: el usuario final
desconoce el trasfondo de los RN del
Ejecutivo y suelen tener conflictos con los
desarrolladores que pueden no entender
cabalmente las razones del usuario final.
 Clara comunicación acerca de los objetivos
del proyecto y sus restricciones pueden ayudar
a disminuir las tensiones.
 El analista de sistemas debe trabajar con
representantes claves de usuarios y
patrocinadores del producto para reconciliar
cualquier conflicto.
51

52. La paternidad cliente-desarrollador
 Excelentes productos software
son el resultado de diseños bien
ejecutados basados en excelente
requisitos.
 Requisitos de alta-calidad
resultan de la comunicación y
colaboración efectiva entre
desarrolladores y clientes (una
paternidad).
52

53. La paternidad cliente-desarrollador
 La “Carta de los Derechos de los
Clientes Software” lista las 10
expectativas que los clientes pueden tener
legítimamente respecto a sus interacciones
con los clientes y los desarrolladores
durante las actividades de Ingeniería de
Requisitos.
 Cada derecho del cliente implica una
responsabilidad de los desarrolladores o
analistas.
53

54. Carta de los Derechos de los
Clientes Software-Tiene derecho a…
1. Esperar que los analistas hablen su lenguaje.
2. Esperar que los analistas aprendan sobre el
negocio y objetivos del sistema.
3. Esperar que los analistas estructuren la
información que les presentas (en especificación
de requisitos software) durante el levantamiento
de requisitos.
4. Que los analistas expliquen todos los work-
products creados durante el proceso de
requisitos.
5. Esperar que los analistas y desarrolladores te
traten con respeto y mantener una actitud
colaborativa y profesional a través de las
interacciones
54

55. Carta de los Derechos de los
Clientes Software-Tiene derecho a…
6. Que los analistas y desarrolladores provean ideas y
alternativas para tus requisitos y para la
implementación del producto.
7. Describir las características del producto que lo
harán fácil y disfrutable de utilizar.
8. Dar oportunidades para ajustar tus requisitos para
permitir el reuso de componentes software existentes.
9. Recibir estimaciones de “buena-fe” de los costos,
impactos y negociaciones cuando solicites un cambio en
los requisitos.
10. Recibir un sistema que satisfaga tus necesidades
funcionales y de calidad en la medida en que tales
necesidades han sido comunicadas y acordadas con los
desarrolladores.
55

56. Carta de las Responsabilidades de los
Clientes Software-Eres responsable de…
1. Educar a los analistas y desarrolladores sobre
el negocio y definir los términos del dominio.
2. Invertir el tiempo que requiere la provisión de
requisitos, clarificarlos e iterativamente obtenerlos.
3. Ser específico y preciso cuando ofrezcas
entradas sobre los requisitos del sistema.
4. Tomar decisiones a tiempo sobre los requisitos
cuando se te pida.
5. Respetar la evaluación de los desarrolladores
sobre el costo y factibilidad de los requisitos.
56

57. Carta de las Responsabilidades de los
Clientes Software-Eres responsable de…
6. En colaboración con los desarrolladores,
establecer prioridades para requisitos
funcionales, características del sistema o casos de
uso.
7. Revisar los documentos de requisitos y evaluar
prototipos.
8. Comunicar cambios en los requisitos tan pronto
como sabes de ellos.
9. Seguir el procedimiento indicado para la
solicitud de cambios de requisitos.
10. Respetar los procesos que los analistas utilizan
para Ingeniería de Requisitos.
57

58. ¿Qué con respecto a la firma del
“documento de requisitos”?
 Muchas organizaciones utilizan una firma
del compromiso del documento de
requisitos como una señal de la aprobación
del cliente de tales requisitos.
 Es importante que todos los que firman
tengan claro el significado de tal firma,
de lo contrario pueden surgir problemas
(evitar problemas como “firmé sin leer lo
que firmaba…”)
58

59. ¿Qué con respecto a la firma del
“documento de requisitos”?
 Igualmente problemático es el jefe de
desarrollo que ve la firma como una
forma de “congelar los requisitos”.
 Una actitud así de ambas partes ignora la
realidad de que es imposible conocer
todos los requisitos desde el inicio del
proyecto y que los requisitos cambiarán
sin lugar a duda.
59

60. ¿Qué con respecto a la firma del
“documento de requisitos”?
 Más importante que firmar es el concepto
de establecer una línea base del acuerdo
de los requisitos: una imagen de ellos en el
tiempo (un milestone).
 Con esto se establece que el documento
es “el mejor entendimiento actual de
los requisitos” y que cualquier cambio
tendrá que pasar por el proceso
definido de cambios y que implicará una
renegociación de los compromisos de
costos, tiempos y recursos.
60

61. ¿Qué con respecto a la firma del
“documento de requisitos”?
 Es decir después que el analista define la
línea base, colocará los requisitos bajo el
control de cambios.
 Esto permitirá al equipo modificar el
alcance del proyecto cuando sea necesario
de una forma controlada que incluya
analizar el impacto de cada cambio
propuesto.
61

62. Siguientes pasos …
1. Identifica los clientes responsables de los
RN y los RU de tus proyectos. ¿Cuáles
puntos de las cartas de derechos y
responsabilidades practican? ¿Cuáles no?
¿Porqué?
2. Discute con tus clientes las cartas de
derechos y responsabilidades. Ajústala a
tu contexto.
3. Escribe una definición de lo que significa la
firma para la aprobación de tu documento
de requisitos.
62

63. 63
Temas
 Definición de Requisito
 Desarrollo y Administración de Requisitos
 Características de Requisitos excelentes
 Los Requisitos desde la perspectiva del
cliente
 Buenas prácticas de la Ingeniería de
Requisitos.

64. Buenas prácticas de la Ingeniería
de Requisitos
 Se pueden dividir en las siguientes:
 Conocimiento
 Elicitación de requisitos.
 Análisis de requisitos
 Especificación de requisitos.
 Validación de requisitos.
 Administración de requisitos.
 Administración de proyectos.
64

65. Conocimiento
 Los analistas deben recibir entrenamiento
en IR.
 Todos los stakeholders del proyecto
deberían entender los conceptos y
prácticas de la IR.
 Un buen analista de requisitos es
paciente y bien organizado, tiene
habilidades interpersonales y de
comunicación efectivas, entiende el dominio
de la aplicación y tiene un buen bagaje de
técnicas de IR.
65

66. Buenas prácticas de Elicitación de
requisitos
 Definir el proceso de desarrollo de requisitos:
como se levantarán, analizarán, especificaran y
validarán los requisitos.
 Escribir el documento de visión y alcance:
centrado en los RN.
 Identificar clases de usuarios y sus
características.
 Seleccionar un campeón de producto por cada
tipo de usuario.
 Trabaja con representantes de usuarios para
identificar los CU.
66

67. Buenas prácticas de Elicitación de
requisitos
 Manejar talleres de requisitos.
 Observar a los usuarios
realizando sus trabajos.
 Examinar reportes de problemas
de los sistemas actuales para
ideas de requisitos.
 Reutilizar requisitos a través de
todos los proyectos.
67

68. Buenas prácticas de Análisis de
requisitos
 El Análisis de Requisitos implica refinar los
requisitos para asegurarse de que todos los
stakeholders los entienden y escudriñan para
localizar errores, omisiones u otras deficiencias.
 El Análisis incluye descomponer requisitos de
alto-nivel en detalles, construir prototipos,
evaluar factibilidad y negociar prioridades.
 El objetivo es desarrollar los requisitos con
suficiente calidad y detalle que los
administradores puedan construir estimaciones
realistas del proyecto y el staff técnico pueda
diseñar, construir y probar.
68

69. Buenas prácticas de Análisis de
requisitos
 Frecuentemente es útil representar los
requisitos en múltiples formas (textual o
gráfica). Estas vistas diferentes revelan
aspectos internos y problemas que una sola
vista no puede proveer.
69

70. Buenas prácticas de Análisis de
requisitos
 Las múltiples representaciones
conllevan a las prácticas de
Análisis de Requisitos:
 Construir el Diagrama de Contexto.
 Crear el Diccionario de Datos.
 Modelar los requisitos.
 Crear prototipos técnicos e interfases de usuario.
 Priorizar los requisitos.
 Asignar los requisitos a los subsistemas.
70

71. Buenas prácticas de
Especificación de requisitos
 No importa como se obtienen los
requisitos, se deben documentar de
una forma consistente, accesible
y revisable.
71

72. Buenas prácticas de
Especificación de requisitos
 Adoptar una plantilla del Documento de
Especificación de Requisitos Software
(DERS).
 Identificar las fuentes de los requisitos.
 Etiquetar de forma única cada requisito.
 Registrar las Reglas del Negocio.
 Especificar los Atributos de Calidad
(desempeño, eficiencia, confiabilidad,
usabilidad, etc.).
72

73. Buenas prácticas de Validación de
requisitos
 La Validación asegura que los estatutos de
requisitos son correctos, que demuestran
las características de calidad deseadas y
que satisfacerán las necesidades de los
usuarios.
73

74. Buenas prácticas de Validación de
requisitos
 Inspección de los documentos de
requisitos: un pequeño equipo
multidisciplinario (analistas, clientes,
desarrolladores y testers) examina el DERS,
modelos, etc. buscando defectos.
 Probar los requisitos: crear, ejecutar los
casos de prueba para validar los requisitos.
 Definir el criterio de aceptación: pedir a
los usuarios que describan como
determinarán si el producto satisface sus
necesidades.
74

75. Administración de Requisitos
 Una vez que se cuenta con el cuerpo inicial
de requisitos, lo siguiente es definir
mecanismos que permitan manejar de
forma organizada los inevitables cambios.
 La Administración efectiva de Cambios
demanda un proceso para proponer
cambios y evaluar su potencial costo e
impacto en el proyecto.
75

76. Administración de Requisitos
 La figura del Change Control Board (CCB)
decide cuales cambios incorporar.
 El CCB está compuesto por stakeholders
clave.
 También es importante monitorear el status
de cada requisito conforme pasa del
desarrollo a las pruebas (su ciclo de vida).
 Aquí se pueden utilizar las mismas prácticas de
gestión de configuración (control de
cambios) que se utilizan para el código.
76

77. Buenas prácticas de
Administración de Requisitos
 Definir un proceso de control de
cambios de requisitos.
 Establecer un CCB.
 Realizar análisis de impacto de los
cambios de requisitos.
 Establecer líneas base y control de
versiones de los documentos de requisitos.
 Mantener una historia de los cambios de
requisitos.
 Monitorear el status de cada requisito.
77

78. Buenas prácticas de
Administración de Requisitos
 Medir la volatilidad de los requisitos.
 Usar una herramienta de gestión de
requisitos.
 Crear una matriz de trazabilidad de
requisitos.
78

79. Administración de Proyectos
 Los procesos de Administración de
Proyectos están muy relacionados con
los procesos de Administración de
Requisitos.
 Basa los recursos del proyecto, sus
cronogramas y compromisos en los
requisitos que se van a implementar.
 Como los cambios de requisitos afectarán
los planes del proyecto, los planes
deberían anticipar cambios de
requisitos y alcance.
79

80. Buenas prácticas de Admon. De
Proyectos (en relación con requisitos)
 Selecciona un ciclo de vida de desarrollo de
software apropiado (cascada, iterativo, etc.).
 Basa los planes del proyecto en los requisitos.
 Renegocia los compromisos del proyecto cuando
los requisitos cambien.
 Documenta y gestiona los riesgos relacionados
con los requisitos.
 Monitorea el esfuerzo invertido en IR.
 Revisa las lecciones aprendidas respecto a los
requisitos de tus proyectos.
* Muchas de las prácticas que sugiere PMP soportan estás
buenas prácticas.
80

81. Iniciando con las Buenas Prácticas
 Aunque todas las prácticas pueden
ser benéficas, se puede empezar
con aquellas que tienen alto
impacto y que resultan fáciles de
implementar.
 Revise la siguiente tabla.
81

82. Un proceso de Desarrollo de
Requisitos
 No se espera que todas las
prácticas se realicen de forma
secuencial.
 En la práctica se realizan
entrelazadas, incrementales e
iterativas
82

83. Un proceso de Desarrollo de
Requisitos
 Típicamente, como analista:
1. Haces preguntas, escuchas
respuestas. Ves lo que se hace
(elicitación).
2. Procesas la información para
entenderla, la clasificas en categorías
y relacionas necesidades y requisitos
software (análisis).
83

84. Un proceso de Desarrollo de
Requisitos
 Además, como analista:
3. Estructuras la entrada del cliente y
derivas requisitos como documentos
escritos y diagramas
(especificación).
4. Finalmente pedirás a representes de
clientes que confirmen que lo que has
escrito es correcto y completo y
corriges cualquier error (validación)
84

85. Un proceso de Desarrollo de
Requisitos iterativo-Gráficamente
85

86. Un proceso de Desarrollo de
Requisitos basado en CU priorizados
86
Realizar por cada
incremento o
release
Realizar 1 vez al
inicio del proyecto