Ingeniería de Requerimientos

Ingeniería de requerimientos
Ingeniería de requerimientos
Vanesa Carolina Loaiza Carvajal

Laura Catalina Zorro Jiménez
Miguel Eduardo Torres Moreno
Rafael Andrés González Rivera
María Patricia Amórtegui Vargas
Colección Libros de Investigación
Vicerrectoría de Investigación
Reservados todos los derechos Corrección de estilo:

© Pontificia Universidad Javeriana Ella Suárez
© Miguel Eduardo Torres Moreno, Rafael Andrés González
Rivera, Vanesa Carolina Loaiza Carvajal, Laura Catalina Diagramación y montaje de cubierta:
Zorro Jiménez, María Patricia Amórtegui Vargas Nathalia Rodríguez
Primera edición: Bogotá, D. C., febrero de 2018 Impresión:

ISBN: 978-958-781-172-8 Javegraf
Número de ejemplares: 300
Impreso y hecho en Colombia Pontificia Universidad Javeriana |
Printed and made in Colombia Vigilada Mineducación. Reconocimiento como
Universidad: Decreto 1297 del 30 de mayo de
Editorial Pontificia Universidad Javeriana 1964. Reconocimiento de personería jurídica:
Carrera 7 n.° 37-25, oficina 1301 Resolución 73 del 12 de diciembre de 1933 del
Teléfono 3208320 ext. 4752 Ministerio de Gobierno.
www.javeriana.edu.co/editorial
editorialpuj@javeriana.edu.co
Bogotá, D. C.
Torres Moreno, Miguel Eduardo, autor

Ingeniería de requerimientos / Miguel Eduardo Torres Moreno [y otros cuatro]. -- Primera edición. -- Bogotá : Editorial
Pontificia Universidad Javeriana, 2017. (Colección libros de investigación)
182 páginas : ilustraciones ; 24 cm

Incluye referencias bibliográficas.
ISBN : 978-958-781-172-8
1. Ingeniería de requisitos. 2. Ingeniería de software. 3. Desarrollo de programas para computador. I. González Rivera,
Rafael Andrés, autor. II. Loaiza Carvajal, Vanesa Carolina, autora. III. Zorro Jiménez, Laura Catalina, autora. IV. Amórtegui
Vargas, María Patricia, autora. V. Pontificia Universidad Javeriana.
CDD 001.6425 edición 19
Catalogación en la publicación - Pontificia Universidad Javeriana. Biblioteca Alfonso Borrero Cabal, S.J.
inp 05 / 12 / 2017
Prohibida la reproducción total o parcial de este material sin la autorización por escrito de la Pontificia Universidad
Javeriana.
ContenIDO
Prólogo 13
Capítulo 1
Introducción y justificación 17
Laura Catalina Zorro Jiménez, Vanesa Carolina Loaiza Carvajal
y Miguel Eduardo Torres Moreno
Capítulo 2
Recolección y análisis 37
Laura Catalina Zorro Jiménez, Vanesa Carolina Loaiza Carvajal,
Miguel Eduardo Torres Moreno y Rafael Andrés González Rivera
Capítulo 3
Especificación, verificación y validación 103
Miguel Eduardo Torres Moreno y Rafael Andrés González Rivera
Capítulo 4
Administración de requerimientos 119
Miguel Eduardo Torres Moreno y María Patricia Amórtegui Vargas
Capítulo 5
Herramientas 157
Miguel Eduardo Torres Moreno y María Patricia Amórtegui Vargas
Capítulo 6
Caso de estudio 4-Med 169
María Patricia Amórtegui Vargas y Miguel Eduardo Torres Moreno
Autores 181
figuras
Figura 1.1. Clasificación de requerimientos 25

Figura 2.1. Procesos generales de la ingeniería de requerimientos 38
Figura 2.2. Peeling the onion 41
Figura 2.3. Ejemplo de los resultados del cuestionario 59
Figura 2.4. Proceso para emplear los prototipos en la recolección de requerimientos 61
Figura 2.5. Diagrama de flujo de interfaces 63
Figura 2.6. Roles de los talleres 65
Figura 2.7. Ciclo de los talleres 66
Figura 2.8. Entregables generados por el taller 67
Figura 2.9. Procedimiento de una sesión de grupos focales 70
Figura 2.10. Participantes en una sesión jad 71
Figura 2.11. Representación de un proceso 83
Figura 2.12. Representación de un almacén de datos 84
Figura 2.13. Representación de una entidad externa 84
Figura 2.14. Un dfd completo 84
Figura 2.15. Diagrama de contexto o cero 85
Figura 2.16. Diagrama de nivel 1 85
Figura 2.17. Relación de los diccionarios de datos con flujos de procesos
y almacenes de datos 87
Figura 2.18. Pasos para el diseño de un diagrama entidad-relación 88
Figura 2.19. Elementos del modelo del dominio 90
Figura 2.20. Árbol de decisión 91
Figura 2.21. Evaluar un árbol de decisión 92
Figura 2.22. Componentes de las tablas de decisión 93
Figura 2.23. Actividad 95
Figura 2.24. Decisión 95
Figura 2.25. Sincronización 95
Figura 2.26. Flujo de trabajo 96
Figura 2.27. Ejemplos de un diagrama de estados 97
Figura 3.1. Proceso de verificación de requerimientos 109
Figura 3.2. Desarrollo y prueba productos de trabajo 112
Figura 4.1. Proceso de administración de requerimientos 120
Figura 4.2. Localización dentro del proceso de ingeniería 135
Figura 4.3. Trazabilidad prerrequerimientos y trazabilidad posrequerimientos 137
Figura 4.4. Tipos de trazabilidad hacia adelante y hacia atrás 138
Figura 4.5. Plantilla de requerimientos 3: ejercicio de localización y trazabilidad 146
Figura 5.1. ermt: página principal 160
Figura 5.2. ermt: selección de atributos 161
Figura 5.3. ermt: priorización 161
Figura 5.4. ermt: grafos 162
Figura 5.5. ermt: reportes 163
Figura 5.6. ermt: línea base 163
Figura 5.7. ermt: seguimiento a cambios 164
Figura 5.8. ermt: gestión de riesgos 165
Figura 5.9. ermt: problemas en los requerimientos 165
Figura 5.10. ermt: reporte, problemas de requerimientos 166
Figura 5.11. ermt: reporte de trazabilidad 167
Figura 6.1. Características asociadas a la complejidad de sistemas e-health 171
Figura 6.2. Vistas de 4-Med 173
Figura 6.3. Fases de 4-Med 176
tablas
Tabla 1.1. Comparación requerimientos de negocio vs. sistema 28

Tabla 2.1. Posibles tipos de roles 42
Tabla 2.2. Influencia de los stakeholders 45
Tabla 2.3. Análisis de stakeholders 46
Tabla 2.4. Tipos de prototipos 60
Tabla 2.5. Resultado del proceso de lluvia de ideas 74
Tabla 2.6. Comparativo de técnicas de grupos 75
Tabla 2.7. Decisión final 94
Tabla 3.1. Lista de chequeo para el proceso de verificación 110
Tabla 3.2. Ejemplo de V&V: parte 1 115
Tabla 3.3. Ejemplo de V&V: parte 2 115
Tabla 4.1. Distribución de los atributos de los requerimientos 122
Tabla 4.2. Criterios de priorización de requerimientos 126
Tabla 4.3. Ejemplo de datos para la priorización del requerimiento 133
Tabla 4.4. Tabla de trazabilidad 139
Tabla 4.5. Matriz de trazabilidad 141
Tabla 4.6. Lista de trazabilidad 141
Tabla 4.7. Reglas del ejercicio de localización y trazabilidad 142
Tabla 4.8. Casos de uso del ejercicio de localización y trazabilidad 143
Tabla 4.9. Componentes del ejercicio de localización y trazabilidad 143
Tabla 4.10. Requerimientos del ejercicio de localización y trazabilidad 144
Tabla 4.11. Pruebas del ejercicio de localización y trazabilidad 145
Tabla 4.12. Plantilla de requerimientos: ejercicio de localización y trazabilidad 145
Tabla 4.13. Plantilla de requerimientos 2: ejercicio de localización y trazabilidad 146
Tabla 4.14. Posibles atributos para el control de cambios 150
Tabla 4.15. Ejercicio de control de cambios 151
Tabla 6.1. Matrices de trazabilidad en 4-Med 178
Prólogo
La ingeniería de requerimientos es, al igual que la ciencia que la agrupa (la ingeniería
de software), una ciencia bastante joven con quizás no más de cuarenta años. Si bien
la problemática de los requerimientos de software siempre fue relegada a ser una
parte no muy trascendental del proceso de construcción, donde dependiendo del
paradigma de desarrollo que se use se aplicaban algunas técnicas que buscaban dar
una visión de alto nivel para el equipo de desarrollo y de alguna manera clarificar los
resultados esperados por parte del cliente, solo hasta los años ochenta, con el trabajo
tanto de Alexander y Stevens [1] como de Wiegers [2], se comenzó a profundizar
en el papel de los requerimientos en el momento de comprender, abstraer y mode-
lar el problema y, por supuesto, usarlos como herramienta de gestión y control del
proyecto. Esto abrió un nuevo mundo a los ingenieros de software, quienes ahora
debían acercase más al negocio y a las necesidades reales de los clientes, con lo cual
podían dar una respuesta más acertada a dichas necesidades.
La profesionalización de la ingeniería de software durante los años setenta y
ochenta dio como resultado la aparición de estándares (por ejemplo, los de ieee/iso) y
mejores prácticas (Modelo de Capacidad y Madurez [cmm], Mejoramiento de Procesos
de Software [spice], Proceso Unificado Racional [rup], etc.), tendientes a mejorar la
calidad de los productos, así como asegurar la repetición exitosa de los procesos y su
estandarización. Estos estándares y prácticas proporcionan recomendaciones y solucio-
nes a problemas comunes del desarrollo de software, que para el caso de la ingeniería
de requerimientos es frecuentemente la traducción de un problema de negocio a una
solución de software, de tal manera que el equipo de desarrollo entienda cuál era el
comportamiento deseado del producto final.
_13
14_ Ingeniería de requerimientos
Más recientemente, gracias a las metodologías de desarrollo ágil, se propuso

acercar al cliente al equipo de desarrollo, de manera que esa comprensión del ne-
gocio siempre estuviera al alcance del equipo; sin embargo, aún se siguen usando
modelos y abstracciones basadas en paradigmas de desarrollo que acercan el negocio
al software esperado.
Observamos entonces dos caminos para llegar al desarrollo de software actual:
los tradicionales y los ágiles, que si bien filosóficamente se perciben diferentes, son
simplemente formas de ver la vida de un proyecto de desarrollo de software, siempre
pensando en el “depende”: del cliente, del alcance, de la tecnología, de los atributos
de calidad esperados del producto y tantas otras variables que llevan a preguntarse:
¿cuál es la mejor solución?
Otro elemento que ha puesto la atención en la gestión de requerimientos de software
es el uso extendido del Project Management Institute (pmi) y su cuerpo de conocimien-
to (Project Management Body of Knowledge [pmbok]) [3] alrededor de la gestión de
proyectos y en el cual el principal elemento que da forma y caracteriza un proyecto es
su alcance (scope). Este concepto conecta perfectamente con la idea de la ingeniería de
software, donde antes de desarrollar un producto de software, debe existir una verdadera
problemática de negocio enmarcada en sus procesos, las personas y sus roles en dichos
procesos y el rol de las tecnologías de información que respaldan dichos procesos. El
análisis inicial de la organización se desarrolla a partir del concepto análisis de negocio,
el cual busca comprender las organizaciones, sus problemáticas y la caracterización de
su subsistencia en el entorno. Se observa entonces una relación innegable entre los
“requerimientos de negocio”, el “alcance” en el contexto de la gestión de proyectos y
los requerimientos de software.
Este trabajo busca precisamente ayudar a ingenieros industriales y de procesos
a comprender de mejor manera cómo expresar sus necesidades en el momento de
buscar una solución con tecnologías de la información. Por otra parte, está dirigido
a ingenieros de sistemas y de software que están comenzando a comprender que
la construcción de software requiere un diálogo más fluido y constante entre las
necesidades de un negocio y lo que la tecnología le puede aportar para solucionar
dichas necesidades.
Aun cuando no hay una receta o secuencia de pasos totalmente cierta y válida
para todos los casos, es importante conocer diferentes estrategias y los aportes que
ellas pueden brindar al contexto del proyecto, idiosincrasia del cliente y compleji-
dad del problema. Este es uno de los fuertes del presente texto: mostrar diferentes
métodos y estrategias para la identificación, la especificación, el análisis y la gestión
aplicable tanto a los requerimientos de negocio como de software.
Prólogo _15
Este texto presenta, inicialmente, en el capítulo 1 una introducción y justifica-

ción de estado del arte alrededor del área de conocimiento de la ingeniería de reque-
rimientos, descrita de tal forma que su uso y aplicación pueda ser más eficiente por
parte de un equipo de analistas de sistemas, arquitectos de software o ingenieros
industriales.
Posteriormente, los capítulos 2 y 3 presentan los procesos recomendados para
la recolección, el análisis, la especificación y la validación de los requerimientos, así
como técnicas aplicables y recomendaciones para un uso más eficiente y adecuado
de ellas.
A continuación, los capítulos 4 y 5 presentan acciones encaminadas a apoyar la
gestión de los requerimientos para asegurar el correcto desarrollo de la solución, así
como la descripción de una herramienta de gestión de requerimientos.
Finalmente, se presenta un modelo basado en los elementos presentados a lo
largo del texto con el fin de mostrar que los procesos planteados son generales y que
pueden y deben ser adaptados en contexto del problema, la tecnología, el usuario,
el negocio y la idiosincrasia de la organización, al aplicarlo en un caso de estudio
que típicamente se estima como uno de los más complejos, como lo es el entorno
hospitalario.
Referencias
[1] I. Alexander y R. Stevens, Writing Better Requirements, 1.a ed. Londres: Addison-
Wesley Professional, 2002.
[2] K. Wiegers, “First things first”, Softw. Dev., vol. 7, no. 9, pp. 48-53, set. 1999.
[3] Project Management Institute, A Guide to the Project Management Body
of Knowledge (pmbok® Guide)–Fifth Edition, 5.ª ed. Newtown Square,
Pennsylvania: Project Management Institute, 2013.
Capítulo 1
Introducción y justificación
La ingeniería de requerimientos, como área de conocimiento, ha evolucionado en la

última década. Originalmente, desde la ingeniería de software y luego desligándose
de ella hacia otras áreas, debido a las diversas aplicaciones que presenta para dife-
rentes tipos de proyectos de implementación o implantación de productos. Desde
la construcción de software, con el paso del tiempo, ha comenzado a identificarse
como una disciplina clave para el éxito en los proyectos de software, pues apoya
diferentes procesos como los que se exponen a continuación:
• Mostrar qué resultados quieren los stakeholders1 (clientes, usuarios o participantes)
y stockholders2 (inversionistas o personas de la alta gerencia que no necesariamente
serán usuarios del producto final).
• Darles oportunidad de opinión a los stakeholders.
• Representar diferentes puntos de vista.
• Verificar el diseño del producto.
• Permitir que el cliente pueda aceptar los productos con criterios precisos y medibles.
• Posibilitar que el equipo de desarrollo esté seguro de que está resolviendo los
problemas importantes.
• Permitir que los probadores sepan qué probar del producto en contexto de las
necesidades reales del cliente.
1
Stakeholder: dícese de cualquier persona involucrada en el proceso de desarrollo del sistema [1].
2
Stockholder: dícese de cualquier persona interesada (típicamente desde el punto de vista económico
o financiero) en el proceso de desarrollo e implantación del sistema [1].
_17
• Asegurar que los gerentes de proyecto puedan tener información adecuada de

su estado y avance.
Para poder presentar la ingeniería de requerimientos es necesario introducir algunos

conceptos y elementos que permitan contextualizar esta área. El presente capítulo pre-
senta diferentes conceptos que serán luego puestos en contexto en los capítulos 2 y 3.
1.1. ¿Qué es un requerimiento?
A través de los años se han expuesto diferentes definiciones de la palabra reque-

rimiento dentro del campo de la ingeniería de software, que además ha mostrado su
permanente evolución. A continuación, se presentan algunas de estas definiciones:
Según Karl E. Wiegers [2], en la industria del software existe un problema: la
falta de definiciones que describan aspectos del trabajo de los ingenieros que sean
comunes para todos; por lo tanto, no existe una definición universal acerca de qué
es un requerimiento. Una definición la presenta Ralph R. Young en su libro The
Requirements Engineering Handbook, quien menciona que un requerimiento “es un
atributo necesario dentro de un sistema, una declaración que identifica la capacidad,
característica o factor de calidad de un sistema para que tenga valor y utilidad a un
cliente o usuario” [3].
En este caso se tomará como base la definición dada por Sommerville [4], la
cual especifica que los requerimientos son la descripción de lo que debería ser im-
plementado [2], de los servicios proporcionados [4] y de cómo debería comportarse
el sistema que se va a desarrollar.
Adicional a la anterior definición, se tiene la de Wohlin et ál., la cual indica que
un requerimiento es:
(1) Una condición o capacidad que necesita un usuario para resolver un pro-
blema o alcanzar un objetivo, (2) Una condición o capacidad que se debe
cumplir o que posea un sistema o componente para satisfacer un contrato,
norma, especificación, u otros documentos, impuestos formalmente. Una re-
presentación documentada de una condición o capacidad como en (1) o (2). [5]
Los autores ya mencionados indican que no solo son necesidades de usuario las
que se deben documentar, sino que también se deben tener en cuenta las políticas
organizacionales, el gobierno y los estándares del sector donde se desempeñan. En
algunos casos también es útil indicar qué no hace el sistema, con el fin de apoyar la
Introducción y justificación _19
definición del alcance que se dará al sistema o al producto que se está implementando.
Adicionalmente, es importante tener un conocimiento claro de por qué es necesario
el sistema o producto y cómo este afectará a la organización que lo usará; esto ge-
neralmente se realiza por medio de estudios de análisis de negocio (business analysis).
Finalmente, es importante aclarar que, en la lengua castellana, el término re-
querimiento, según la Real Academia Española, se define como: “la acción y efecto
de requerir” [6]; mientras que requisito se define como “circunstancia o condición
necesaria para algo” [6]. Sin embargo, desde el uso técnico, estos dos términos se
usan indistintamente (pero sí de manera consistente); por tanto, en ese contexto
y para la lectura subsecuente de este texto usaremos el término requerimiento para
hacer referencia a una necesidad o un atributo del sistema propuesto.
1.2. Atributos de calidad del requerimiento
La mayor dificultad al usar los requerimientos como el elemento guía en la construc-

ción de un proyecto es precisamente su naturaleza ambigua, dada por la forma en
que están representados (típicamente, lenguaje natural). Para que los requerimientos
sean realmente útiles en el contexto del desarrollo y gestión de un proyecto, deben
exhibir una serie de cualidades que permitirán asegurar la calidad del requerimien-
to y del producto generado. Algunos atributos de calidad esperados de un reque-
rimiento son [3], [7], [8]-[10]:
1. Completo: cada requerimiento debe describir completamente la funcionalidad
esperada. Debe contener toda la información necesaria para diseñarla e imple-
mentarla.
2. Correcto: debe describir exactamente la funcionalidad que se va a construir (la
mejor fuente para definir la correctitud de un requerimiento es el usuario final
o un requerimiento de negocio de más alto nivel).
3. Independiente de la implementación (abstracto): el requerimiento no describe
ni incluye restricciones de diseño o arquitectura al sistema, esto es, “el requeri-
miento expresa lo que se requiere, no como el requerimiento debe cumplirse” [1].
4. Factible: debe ser posible implementarlo dentro de las capacidades y limitaciones
del sistema y su entorno operativo, financiero y legal.
5. Necesario: el requerimiento debe documentar una capacidad o funcionalidad
que el cliente realmente necesite. En ese sentido, los requerimientos deben ori-
ginarse de una fuente que efectivamente tenga la autoridad para ello y, además,
debe poder trazarse (seguir) su origen hacia una regla de negocio, caso de uso o
proceso que dé valor agregado al cliente.
6. Priorizado: asignar una prioridad a cada requerimiento, característica o caso de uso

indica qué tan esencial es para una entrega o versión particular del producto. Si
todos los requerimientos fueran tratados de la misma forma, sería muy difícil para
el gestor del proyecto poder responder a cortes de presupuesto, atrasos en el cro-
nograma, pérdidas de personal o nuevos requerimientos solicitados por el cliente.
7. No ambiguo (claro): cualquier lector del requerimiento debe llegar a la misma
conclusión, entendimiento o interpretación. Por ello, los requerimientos deben
escribirse en sentencias cortas y directas, usando un lenguaje apropiado al domi-
nio del problema, típicamente apoyado por un glosario de términos.
8. Único (singular, atómico): el requerimiento debe expresar una única idea que
permita ser trazada a lo largo del proyecto y los artefactos producto de él. Típi-
camente esto se logra identificando conjunciones (y, o, además, etc.) y analizan-
do el contexto de uso de ellas para si es el caso separar el requerimiento en dos
nuevos requerimientos.
9. Verificable: se busca que la estructura del requerimiento permita a un ingeniero
probador diseñar casos de prueba o cualquier aproximación de verificación que
permita recolectar información que demuestre que el sistema satisface efecti-
vamente el requerimiento, así como determinar si el requerimiento está siendo
correctamente implementado.
Cuando los requerimientos se agrupan, bien sea en una especificación de reque-

rimientos o en subconjuntos para ser lanzados o usados en una iteración de desarrollo,
estos deben además presentar las siguientes características [1], [2], [9]:
1. Completo: ningún requerimiento o información necesaria está ausente de la es-
pecificación. Adicionalmente, se entiende que en el conjunto de requerimientos
no hay requerimientos ambiguos o por determinar (tbd: to be determined) por
parte de los stakeholders.
2. Consistente: no existen conflictos entre requerimientos (se soluciona identifican-
do las fuentes originales de los requerimientos bien sea personas o documentos) y
no hay requerimientos repetidos. De manera complementaria, el lenguaje usado
para expresar el conjunto de requerimientos usa siempre los mismos términos y
definiciones (por ejemplo, evitar el uso de sinónimos).
3. Modificable: esto no solo implica que debe poderse reescribir un requerimien-
to, sino que, además, debe existir un historial de cambios hecho a los requeri-
mientos. De ello también deriva que un requerimiento pueda ser identificado y
diferenciado de otros.
4. Delimitado: el conjunto de requerimientos se mantiene dentro de un alcance

específico en contexto del sistema y sus resultados esperados (esto es, no hace
más de lo exigido o estipulado en el contrato para satisfacer las necesidades de
los stakeholders). Esta característica permite controlar el crecimiento indiscrimi-
nado de las especificaciones, así como del calendario, el presupuesto y la calidad
del sistema [1].
5. Factible: la especificación o el conjunto de requerimientos pueden ser satisfechos
con una solución que es posible producir dentro de las restricciones dadas del
proyecto y del ciclo de vida del sistema (esto es, costo, calendario, técnico, legal,
operativo, regulatorio, etc.) [1].
6. Trazable: el requerimiento es trazable hacia su origen, esto es, se puede relacionar
de manera única con documentos de especificación de necesidades de usuario,
procesos de negocio, etc., y hacia “abajo” a otros artefactos resultantes del pro-
ceso de construcción del sistema, como son: requerimientos derivados, elemen-
tos de diseño (modelos estáticos y dinámicos, arquitectura, etc.), construcción
y pruebas del sistema.
7. Estructurado y modular: la especificación está debidamente organizada y es-
tructurada, de tal manera que los requerimientos estén, además, agrupados
en subsistemas que permitan relacionar y encontrar requerimientos que deben
presentarse o tratarse de manera conjunta [1].
1.3. Documentos de especificación de requerimientos
Los requerimientos son generalmente agrupados en especificaciones. Documen-

tos que agrupan y organizan los requerimientos para que puedan ser fácilmente
gestionados y actualizados por los desarrolladores del proyecto. Al igual que los
requerimientos, estas especificaciones deben estar completas y ser consistentes,
modificables o trazables.
Estas especificaciones son la base del trabajo posterior de desarrollo, pues sin
una especificación de requerimientos no se podría:
• Diseñar el software, porque no será claro qué debe hacer.
• Validar el software, porque no será claro qué debe hacer.
• Gestionar el proyecto de software, porque cuando los requerimientos cambian
(y lo hacen muy a menudo), el incremento del costo y el calendario asociado son
difíciles de determinar y justificar.
En particular, el Estándar iso/iec/ieee 29148 de 2011 [1] presenta una descrip-

ción general de los procesos que deben llevarse a cabo en contexto de ingeniería de
sistemas y de productos de software, así como su ciclo de vida; de igual manera,
presenta un conjunto de buenas prácticas para la ejecución de procesos relacionados
con los requerimientos.
El Estándar 29148 también describe tres documentos asociados a dichos procesos:
1. Documento de especificación de requerimientos de stakeholder: describe los reque-
rimientos de negocio y la motivación tras la construcción del sistema (en este
contexto el sistema implica no solo software, sino también hardware, infraestruc-
tura y personal). Incluye descripciones de procesos, políticas y reglas de negocio
que serán afectados por él.
2. Documento de especificación de requerimientos de sistema: describe el sistema, su entorno
y las formas en las cuales interactuará con los usuarios y otros sistemas. Incluye
elementos asociados a restricciones, requerimientos no funcionales (usabilidad,
desempeño, seguridad, etc.).
3. Documento de especificación de requerimientos de software: es el documento de uso más
común y se centra exclusivamente en la descripción del software, sus restricciones,
operaciones y requerimientos. En el contexto de este texto, cuando se mencione
el Documento de especificación o La especificación se hace referencia al Documento de
especificación de requerimientos de software.
Estos documentos pueden usarse como base para la gestión y control del pro-
yecto, así como para asegurar el cumplimiento del contrato. Los diferentes modelos
presentados a lo largo de este texto pueden apoyar la definición de estos documentos.
1.4. Atributos de un requerimiento
Con el fin de construir, organizar, evaluar, cuantificar y gestionar los requerimientos,

algunos autores han propuesto elementos adicionales descriptivos que pueden ser
de utilidad [2], [3], [11], [12]:
1. Identificador único: este elemento permite realizar un mejor seguimiento de los
requerimientos a medida que se ejecuta el proyecto.
2. Origen: identifica documentos legales, de procesos y normativos, bien sea de
la organización o del gobierno que rigen la organización. En algunos casos es
recomendable identificar roles de personas dentro de la organización que pue-
dan ser entrevistados acerca de la validez de lo indicado en dichos documentos.
3. Razón de ser: descripción que permite justificar el requerimiento en contexto del

objetivo del negocio, así como de los documentos que lo originan.
4. Prioridad: elemento cuantitativo o cualitativo que permite ordenar y relacionar
los requerimientos de acuerdo con la importancia dada por el cliente, la com-
plejidad técnica percibida o por riesgos de negocio o del producto relacionados
con el requerimiento.
5. Dueño: en contraste con el origen, este atributo hace referencia a una persona
dentro de la organización que desarrolla el producto, la cual se responsabiliza
de realizar el respectivo seguimiento y gestión del requerimiento durante el de-
sarrollo del proyecto.
6. Versión: este atributo se utiliza para llevar un historial de los cambios realizados
a un requerimiento, generalmente cuando dichos cambios son producidos por
el cliente, cuando posee conflictos con otros requerimientos o cuando diferentes
clientes aún no están de acuerdo con él. Este atributo es útil para asegurar el
cumplimiento del contrato y el historial de negociación de requerimientos alta-
mente volátiles o conflictivos.
7. Estado: este atributo identifica, como su nombre lo indica, el estado del reque-
rimiento y sus cambios durante las diferentes fases de desarrollo del producto,
indicando si el requerimiento ha sido tenido en cuenta en las diferentes etapas
de construcción del sistema, por ejemplo: diseño del sistema, diseño detallado,
construcción, pruebas, entrega al cliente, etc. Este atributo es actualizado y
mantenido por el dueño del requerimiento.
8. Trazabilidad: es un mecanismo que permite hacerle seguimiento al requerimiento
(estado), así como identificar dónde se encuentra en los diferentes artefactos ge-
nerados durante la ejecución del proyecto (véase sección “4.2.2.2. Trazabilidad”).
9. Criterio de aceptación: es una descripción que indica las características que
debe cumplir el sistema para indicar que efectivamente el requerimiento está
siendo cumplido por él. Este elemento es de gran ayuda para los probadores
del sistema e incluso para apoyar el conocimiento y entendimiento del sistema
por parte del cliente y del equipo de desarrollo.
10. Conflictos: este atributo permite identificar qué conflictos tiene el requerimien-
to con otros requerimientos o con elementos externos, por ejemplo, reglas de
negocio, procedimientos, etc.
El uso de estos atributos no es enteramente obligatorio, pero su uso en contex-

to de la dificultad y envergadura del proyecto puede marcar la diferencia entre el
éxito y el fracaso.
1.5. Tipos de requerimientos
Para construir la especificación de requerimientos que plasma los servicios que pres-
tará el sistema, es necesario que el analista de requerimientos defina cuáles son los
que él va a utilizar en el proyecto [3]. Existen diferentes maneras de clasificar los
requerimientos, pues depende del ámbito de alcance del sistema mismo. De hecho,
en algunas ocasiones los grupos de proyecto crean su propia clasificación con base
en las clasificaciones estándar que proponen varios autores como Ralph Young [3]
o Aybüke Aurum y Claes Wohlin [11].
En el contexto de este libro se presenta una forma de clasificación de reque-
rimientos basada en las clasificaciones dadas por autores como Karl Wiegers [2],
Ian Sommerville [12] y Martin Glinz en The Guide to the Business Analysis Body of
Knowledge [13] (figura 1.1).
1.5.1. Requerimientos de negocio
Antes de definir los tipos de requerimientos, es necesario definir qué son las reglas
de negocio. Estas se refieren a políticas, condiciones, restricciones, conocimientos o
estándares de la industria donde se desenvuelve la compañía [17], leyes guberna-
mentales o aspectos del negocio, los cuales deben ser respaldados por el sistema. Las
reglas de negocio permiten identificar los requerimientos de negocio [4].
De ellos se describen dos elementos muy importantes para la organización del
cliente. En primer lugar, se tiene la visión del producto [1], la cual representa lo que
es en sí mismo el producto y lo que podrá ser para la organización, especificando
además el contexto de las decisiones que se deben tomar alrededor de la construc-
ción, implantación, uso y mantenimiento del producto, lo que permite alinear los
deseos y necesidades de los stakeholders. El otro elemento es el alcance del proyecto, el
cual define la porción de la visión que el proyecto actual busca implementar [9].
A partir de dicho origen se definen los requerimientos de negocio como los reque-
rimientos de alto nivel que describen los objetivos de la organización y cuyo cum-
plimiento le dará valor agregado, ya que se derivan de las reglas de negocio. Estos
indican por qué se está desarrollando el proyecto. Además, permiten observar cuál
es el contexto general donde se va a desarrollar el proyecto [3]. Adicionalmente,
los requerimientos de negocio pueden abarcar uno o más proyectos dentro de la
organización.
Figura 1.1. Clasificación de requerimientos
Requerimientos de negocio
Requerimientos de usuario
Requerimientos de sistema
Requerimientos Requerimientos
no funcionales funcionales
Requerimientos Requerimientos Requerimientos

del producto organizacionales externos
Funcionalidad Requerimientos Requerimientos

de entrega de seguridad
Fiabilidad
Requerimientos de Requerimientos
implementación éticos
Usabilidad
Eficiencia Requerimientos
Interoperabilidad
de estándares
Mantenibilidad
Portabilidad
Fuente: elaboración propia a partir de [3], [4], [13]-[16].

Según Karl Wiegers, este tipo de requerimientos “describen cómo mejoraría el

mundo para ciertas comunidades si el producto estuviera disponible” [17]. Para que
el concepto de requerimiento de negocio sea aún más claro, es necesario revisar el
siguiente ejemplo (tomado de Lam [18]):
Se tienen las siguientes reglas de negocio:

• El conductor de un vehículo debe tener una licencia de conducir válida.
• La licencia debe tener una fecha de expiración posterior a la fecha de inspección.
De las anteriores reglas de negocio se derivan los siguientes requerimientos:

• El oficial de policía debe revisar la licencia de conducir del conductor.
• El escáner debe leer la fecha de expiración de la licencia.
1.5.2. Requerimientos de usuario
Como se nota en la figura 1.1, los requerimientos de negocio permiten identificar

el entorno de la organización, sus procesos de negocio y, ante todo, los roles de las
personas o entidades intervinientes, bien sea como usuarios o como beneficiarios de
alguna acción del sistema. Es entonces cuando se definen los requerimientos de usua-
rio. Una vez se han identificado los usuarios del sistema y sus beneficiarios, se pueden
definir los requerimientos de usuario, que en líneas generales describen las tareas
que realizarán los usuarios y que respaldará el sistema o producto en construcción.
Estos requerimientos deben ser descritos de tal manera que todos los stakeholders del
proyecto los puedan entender aun sin tener un conocimiento técnico detallado. Se
debe tener en cuenta que solo deben describir el comportamiento del sistema [4].
El objetivo de recolectar los requerimientos de usuario es entender cuáles son las
clases de usuarios del sistema y qué es lo que el sistema debe permitirles hacer, con-
sultar, etc. para que se puedan apoyar y cumplir los requerimientos de negocio [17].
Para una mejor comprensión de cuáles pueden llegar a ser los requerimientos
de usuario, se presentan los siguientes ejemplos basados en la construcción de un
videojuego:
• El sistema debe permitir reanudar un juego que se encuentra guardado.
• El sistema debe permitir al jugador realizar movimiento de partida, únicamente
cuando este se encuentre en su turno.
1.5.3. Requerimientos del sistema
Estos requerimientos son versiones ampliadas de los requerimientos de usuario,

que les permiten a los ingenieros de software agregar detalles al diseño del sistema.
Deben reflejar el comportamiento y las restricciones del sistema en términos de lo
que hará como un todo (hardware y software) y su relación con las reglas y proce-
sos de negocio, pero deben evitar a toda costa describir el diseño [4]. Esto se debe
a que existe un punto en los proyectos donde los procesos de análisis y recolección
de requerimientos se tornan caóticos y se pierde el alcance de lo que realmente el
cliente quiere y necesita [14]. Por esto, es de vital importancia tener en cuenta los
requerimientos de usuario, ya que son la base de los requerimientos del sistema,
pues contienen la visión y las necesidades del usuario y, además, permiten acabar
de definir a cabalidad el alcance del sistema.
Por lo tanto, los requerimientos del sistema permiten definir qué es lo que el
sistema debe hacer; pero no solo hacen referencia a las características funcionales,
las cuales se conocen como los requerimientos funcionales (véase sección “1.5.4. Re-
querimientos funcionales”), sino que también se deben definir las cualidades del
sistema, las cuales se denominan requerimientos no funcionales (véase sección “1.5.5.
Requerimientos no funcionales”) [19].
Algunos ejemplos de requerimientos de sistema se aprecian a continuación:
• El sistema debe validar que el nombre de usuario y la contraseña coincidan con
los datos almacenados en el sistema mismo.
• El sistema debe conocer en todo momento la cantidad de barcos que ocupan
una isla.
La tabla 1.1 presenta una breve diferenciación de los requerimientos de negocio
y de sistema.
1.5.4. Requerimientos funcionales
Los requerimientos funcionales son un tipo de requerimiento del sistema, y son los
encargados de describir las necesidades reflejadas en los requerimientos de negocio
y los requerimientos de usuario de tal manera que los desarrolladores tengan todos
los detalles de cada funcionalidad, necesaria para implementar de manera correcta
el sistema. Es decir, describen cuál es el comportamiento que debe tener el sistema
(producto de software). Este comportamiento se expresa en forma de los servicios
o funcionalidades que prestará el sistema a los usuarios [20]. También se conocen
con el nombre de requerimientos operacionales, ya que indican cuáles son las entradas
y salidas del sistema y el comportamiento de las relaciones entre ellas [3].
Tabla 1.1. Comparación requerimientos de negocio vs. sistema
Característica Requerimiento de negocio Requerimiento de sistema

Lenguaje Negocio/vista de usuario Producto/operacional
Concreto, descripción de alto nivel del pro-
Nivel Conceptual
ducto
Qué resultados de negocio de- Cómo debe funcionar el producto (indepen-
ben ser generados que permi- diente de elementos de diseño) que permita
¿Qué?
tan cumplir los objetivos del cumplir con los requerimientos de negocio
negocio esperados
¿Quién? Ya existen dentro del negocio Son especificados por el grupo de analistas
Posible solución Muchas posibles soluciones Representa una posible solución
Fuente: adaptado de Young [3].
Se recomienda que la especificación de este tipo de requerimientos sea completa

[1], lo que significa que todos los servicios que el usuario quiere que preste el sistema
deben estar claramente definidos y ser consistentes, lo cual indica que no debe verse
ningún tipo de contradicción entre los requerimientos [4].
Algunos ejemplos de requerimientos funcionales son:
• El sistema debe permitir que únicamente un anfitrión cree una nueva partida.
• El sistema debe establecer el uso de dos dados en el momento de defenderse con
más de dos barcos.
Koelsch [21] propone, además, diversos tipos de requerimientos funcionales que

permiten estructurar y agruparlos, entre ellos: reglas de negocio, transacciones, fun-
ciones administrativas, autenticación, auditoría, interfaces externas, certificaciones,
búsqueda y reportes, datos históricos, archivado, etc.
1.5.5. Requerimientos no funcionales
Otro tipo de requerimiento de sistema son los requerimientos no funcionales, tam-

bién conocidos como atributos de calidad, ya que hacen referencia a las propiedades
que debe cumplir el sistema al prestar sus servicios. Estos se derivan, al igual que los
requerimientos funcionales, de los requerimientos de negocio y los requerimientos
de usuario. Sin embargo, se diferencian de los funcionales debido a que cada uno de
estos afecta a un conjunto de funciones o al sistema como un todo [11].
No obstante, no solo hacen referencia al sistema que se va a desarrollar, también

pueden considerar algunas restricciones, es decir, se encargan de definir aspectos
como qué estándares de calidad se deben seguir en el desarrollo del sistema o en qué
tipo de hardware o entorno operacional debe funcionar el producto [4].
Este tipo de requerimientos, como se ve en la figura 1.1, también se pueden cla-
sificar en tres diferentes categorías que son: requerimientos del producto [4] (véase
sección 1.5.6), requerimientos organizacionales (véase sección 1.5.7) y requerimien-
tos externos [3] (véase sección 1.5.8) [2].
1.5.6. Requerimientos del producto
Estos requerimientos sirven para describir cómo debe ser el comportamiento del
sistema [4] cuando está realizando alguna funcionalidad [11]. Este tipo de reque-
rimientos, como se ve en la figura 1.1, también se pueden clasificar en seis dife-
rentes categorías. Cada una de estas representa un atributo de calidad referente
al comportamiento del sistema, los cuales se encuentran definidos en el estándar
iso 25010:2011 [15].
Estos seis atributos son:
• Funcionalidad (véase sección 1.5.6.1).
• Fiabilidad (véase sección 1.5.6.2).
• Usabilidad (véase sección 1.5.6.3).
• Eficiencia (véase sección 1.5.6.4).
• Mantenibilidad (véase sección 1.5.6.5).
• Portabilidad (véase sección 1.5.6.6).
1.5.6.1. Funcionalidad
Este atributo de calidad hace referencia a los requerimientos que permiten que el
sistema provea las funciones descritas con los requerimientos funcionales [22] (véase
sección “1.5.4. Requerimientos funcionales”), bajo condiciones de uso especificas
[16]. Las características que se deben cumplir con los atributos de funcionalidad son:
• Idoneidad (suitability): indica que se deben tener las funciones necesarias para
cumplir las tareas requeridas.
• Precisión (accuracy): proveer los resultados esperados o acordados con el grado de
precisión delimitado por el usuario. Un ejemplo de un requerimiento de precisión
puede ser: “El sistema debe realizar los cálculos de los intereses de los créditos
teniendo en cuenta dos números decimales significativos”.
• Interoperabilidad (interoperability): la habilidad que debe tener el sistema para

interactuar con uno o más sistemas, por ejemplo: “El sistema debe utilizar el
motor de base de datos Oracle”.
• Seguridad (security): es la habilidad que debe tener el sistema para evitar accesos
no autorizados [22], por ejemplo: “El sistema debe cerrar automáticamente la
sesión de un usuario cuando esté inactivo por un tiempo igual o superior a 15
minutos”.
1.5.6.2. Fiabilidad
Los requerimientos que reflejan la fiabilidad hacen referencia a la capacidad que debe
tener el sistema para mantener un nivel de rendimiento [22] bajo las condiciones
como velocidad o uso de memoria, precisión [23], establecidas por el cliente en los
requerimientos de negocio y lo requerimientos de usuario [16].
Las características de la fiabilidad son:
• Madurez (maturity): es la habilidad que tiene el producto para evitar fallos [16].
• Tolerancia a fallos (fault tolerance): es la habilidad que debe tener el sistema para
mantener un nivel de rendimiento especificado [16], sin importar las fallas que
puedan aparecer [23]; por ejemplo: “El sistema debe estar disponible el 99,99 %
de las veces que uno de los usuarios lo solicite”.
• Recuperable (recoverability): esta característica trata dos aspectos: la capacidad
de recuperar los datos y la capacidad de reestablecer el rendimiento del sistema
[16], después de un fallo; por ejemplo: “El sistema debe realizar un backup de la
información cada ocho días”.
1.5.6.3. Usabilidad
Los requerimientos de usabilidad deben mostrar la capacidad que debe tener el sis-
tema de ser comprendido, aprendido y utilizado bajo las condiciones de uso estipu-
ladas en los requerimientos del sistema [16]. Las características que se deben tener
en cuenta al especificar los requerimientos de usabilidad son:
• Comprensibilidad (understandability): es la capacidad que presenta el sistema para
que el usuario lo pueda entender; por ejemplo: “El producto deberá ser fácil de
usar por los miembros de la organización que no leen en idioma inglés”.
• Aprendizaje (learnability): “la capacidad que tiene el sistema para permitir que
el usuario lo aprenda a utilizar” [16]; por ejemplo: “El sistema debe permitir
que usuarios expertos aprendan a utilizarlo en un tiempo máximo de tres horas”.
• Operabilidad (operability): “la capacidad que tiene el sistema para permitir que
el usuario lo opere y lo controle” [16]; por ejemplo: “El producto permitirá in-
teracción con usuarios invidentes”.
1.5.6.4. Eficiencia
Los requerimientos de eficiencia deben especificar cuál es el rendimiento esperado,

teniendo en cuenta la cantidad de recursos y las condiciones establecidas por los
stakeholders [16]. Las características para definir los requerimientos no funcionales
de eficiencia son:
• Tiempo de respuesta: es la capacidad que tiene el sistema de responder de manera
correcta ante alguna solicitud de algún usuario; por ejemplo: “El sistema debe
responder a una petición en un tiempo promedio de 7 segundos”.
• Utilización de recursos: son los recursos que utiliza el sistema en el momento
de realizar alguna funcionalidad [22]; por ejemplo: “El sistema debe usar como
máximo 512 Mbps para la gestión de transacciones”.
1.5.6.5. Mantenibilidad
La mantenibilidad debe reflejar la capacidad que debe tener el sistema de ser mo-
dificado, ya sea para actualizar el sistema, incluir correcciones o cambiarlo para
adaptarlo a algún cambio del entorno o de los requerimientos funcionales por parte
de un equipo capacitado de desarrollo [23]. Dentro de las características de la man-
tenibilidad se deben tener en cuenta:
• Cambios (changeability): capacidad que debe tener el sistema para especificar e
implementar una modificación [16], por ejemplo: “El código fuente de la aplica-
ción debe ser documentado con ayuda de la herramienta JavaDoc. Asegurando
la correcta compresión, orden y sintaxis de este”.
• Estabilidad (stability): capacidad que tiene el sistema para evadir los efectos in-
esperados debidos a las modificaciones realizadas sobre el sistema [16].
• Pruebas (testability): capacidad que debe tener el sistema para ser verificado me-
diante pruebas [16].
1.5.6.6. Portabilidad
La portabilidad refleja la capacidad del sistema de cambiar de un ambiente a otro. El

ambiente puede ser organizacional, de hardware o de software [22]. Por esto, los reque-
rimientos no funcionales de portabilidad deben especificar las siguientes características:
• Adaptación (adaptability): los requerimientos que quieran reflejar la adaptación

deben especificar cómo se debe adaptar el sistema a un nuevo ambiente; por
ejemplo: “El sistema debe permitir la instalación por parte del usuario sin nin-
gún tipo de entrenamiento”.
• Coexistencia: capacidad que debe tener el sistema para convivir con otros sistemas
que existan en el ambiente [16]; por ejemplo: “El sistema debe poder ejecutarse
bajo la plataforma de Windows”.
1.5.7. Requerimientos organizacionales
Este tipo de requerimientos “son la consecuencia de políticas y procedimientos or-

ganizacionales” [4] que existen tanto en la organización del cliente como en la de los
desarrolladores del sistema y que típicamente restringen el proceso, las herramientas
o el desarrollo mismo del producto. Estos requerimientos también se pueden dividir
en las siguientes tres categorías [4], [12]:
• Requerimientos de entrega: deben describir las fechas límites para realizar la
entrega del sistema y la documentación de este.
• Requerimientos de implementación: deben especificar cuál es el lenguaje de
programación que se va a utilizar o cuál es el método de diseño que es manda-
torio utilizar.
• Requerimientos provenientes de las normas: describen cuáles son los estándares de
calidad, estándares de documentación y estándares en los procesos de desarrollo.
Un ejemplo de un requerimiento organizacional es: “El proceso de desarrollo

del sistema y los documentos que se van a entregar deberán ajustarse al proceso y a
los productos definidos en la organización” [4].
1.5.8. Requerimientos externos
Como su nombre lo indica, son los requerimientos “que se derivan de factores que
son externos al sistema y su proceso de desarrollo” [4]. Se pueden clasificar en tres
ítems que son [4], [12]:
• Requerimientos éticos: se deben especificar, para asegurar que los usuarios acep-
tarán el sistema [24]. También, corresponden a comportamientos que se espe-
ran del sistema —éticamente—, por ejemplo, el uso correcto de la información
personal de los usuarios.
• Requerimientos de interoperabilidad: definen cómo el sistema debe interactuar

con otros sistemas de otras organizaciones.
• Requerimientos de seguridad (safety): especificarán cuál es la protección que debe
tener el sistema en caso de modificaciones o destrucción. Además, debe asegurar
la integridad física de los usuarios que interactúan con el sistema en caso que
el sistema controle algún dispositivo de hardware (por ejemplo, un torno auto-
matizado) [23].
Ian Sommerville da un ejemplo de un requerimiento externo: “El sistema no

deberá revelar al personal de la biblioteca que lo utilice ninguna información per-
sonal de los usuarios del sistema aparte de su nombre y número de referencia” [4].
Después de que los equipos de desarrollo deciden cuál es la clasificación de reque-
rimientos que usarán durante el desarrollo del proyecto, se deben empezar a definir
roles, procesos, actividades y herramientas para aplicar en general en un proceso de
ingeniería de requerimientos (véanse los capítulos 2 y 3).
Referencias
[1] “iso/iec/ieee International Standard - Systems and software engineering -

Life cycle processes - Requirements engineering”, isoiecieee 291482011E,
pp. 1-94, dic. 2011.
[2] K. Wiegers y J. Beatty, Software Requirements, 3.a ed. Redmond, WA: Microsoft
Press, 2013.
[3] R. R. Young, The Requirements Engineering Handbook. Boston: Artech House
Print on Demand, 2003.
[4] I. Sommerville, Software Engineering, 9.a ed. Boston: Pearson, 2010.
[5] C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell y A. Wesslén,
Experimentation in Software Engineering. Berlín, Heidelberg: Springer Berlin
Heidelberg, 2012.
[6] Real Academia Española. Diccionario de la lengua española. [Online]. Disponible:
http://dle.rae.es/?w=diccionario. Consultado en: 29 de marzo de 2017.
[8] K. E. Wiegers, “Writing quality requirements”, Softw. Dev., vol. 7, no. 5,
pp. 44-48, 1999.
[9] E. Hull, K. Jackson y J. Dick, Requirements Engineering, 3.a ed. Londres:

Springer, 2010.
[10] P. Bourque y R. Fairley, eds., Guide to the Software Engineering Body of Knowledge.
ieee Computer Society, 2014.
[11] A. Aurum, Engineering and Managing Software Requirements. Londres: Springer.
[12] I. Sommerville y P. Sawyer, Requirements Engineering: A Good Practice Guide.
Haboken, NJ: John Wiley & Sons, 1997.
[13] International Institute of Business Analysis. babok® Guide. [Online].
Disponible: https://www.iiba.org/babok-guide.aspx. Consultado en: 20 de
febrero de 2017.
[14] R. R. Young, Project Requirements: A Guide to Best Practices, 1.a ed. Vienna, Va:
Management Concepts, 2006.
[15] International Organization for Standardization. “iso/iec 25010:2011: Systems
and Software Engineering -- Systems and Software Quality Requirements and
Evaluation (SQuaRE) -- System and Software Quality Models”. [Online].
Disponible: https://www.iso.org/standard/35733.html. Consultado en: 4 de
abril de 2017.
[16] F. Losavio, L. Chirinos, N. Lévy y A. Ramdane-Cherif, “Quality characteristics
for software architecture”, J. Object Technol., vol. 2, no. 2, pp. 133-150, 2003.
[17] K. Wiegers, More about Software Requirements: Thorny Issues and Practical Advice,
1.a ed. Redmond, WA: Microsoft Press, 2005.
[18] G. Lam, “Business rules vs. business requirements”. Business Rules Community.
[Online]. Disponible: http://www.brcommunity.com/articles.php?id=b290.
Consultado en: 4 de abril de 2017.
[19] I. Alexander, “Being clear: Requirements are either needs or specifications”,
Requirenautics Q. Newsl. Requir. Eng. Spec. Group Br. Comput. Soc., vol. 25,
pp. 10-12, 2002.
[20] R. Malan y D. Bredemeyer, “Functional Requirements and Use Cases”.
[Online], 2001. Disponible: http://www.bredemeyer.com/pdf_files/functreq.pdf
[21] G. Koelsch, Requirements Writing for System Engineering. Nueva York: Apress,
2016.
[22] I. Padayachee, P. Kotze y A. van Der Merwe, “iso 9126 external systems
quality characteristics, sub-characteristics and domain specific criteria for
evaluating e-Learning systems”. [Online], 2015. Disponible: https://www.
researchgate.net/publication/228987388_ISO_9126_external_systems_
quality_characteristics_sub-characteristics_and_domain_specific_criteria_
for_evaluating_e-Learning_systems
[23] M. Barbacci, M. H. Klein, T. A. Longstaff y C. B. Weinstock, “Quality

attributes”. [Online] Pittsburgh: Carnegie Mellon University, 1995.
Disponible: https://www.google.com.co/url?sa=t&rct=j&q=&esrc=s&so
urce=web&cd=1&cad=rja&uact=8&ved=0ahUKEwilx72P3eHVAhWCw
iYKHaTpAoIQFggmMAA&url=http%3A%2F%2Fwww.dtic.mil%2Fget-
tr-doc%2Fpdf%3FAD%3DADA307888&usg=AFQjCNGwxo2lHgEp9EX
HduSdGKZEh6OAPQ
Capítulo 2
Recolección y análisis
Laura Catalina Zorro Jiménez,
La ingeniería de requerimientos es una disciplina de la ingeniería de software que

se ocupa de todas las actividades relacionadas con el ciclo de vida de los requeri-
mientos de un proyecto. Wiegers [1] propone una división en dos grandes grupos
de actividades: desarrollo de requerimientos y administración de requerimientos
(véase sección “4.1. ¿Qué es la administración de requerimientos?”). La figura 2.1
muestra qué procesos componen la ingeniería de requerimientos.
El desarrollo de requerimientos tiene como objetivos principales identificar, acor-
dar, especificar y validar los requerimientos de cualquier tipo, que le permitan al
equipo de desarrollo del sistema acordar con el cliente y construir un sistema que
cumpla con los objetivos del negocio [2]; para ello se definen los siguientes procesos
generales: recolección (véase sección 2.1), análisis (véase sección 2.2), especificación
(véase sección 3.1) y verificación (véase sección 3.2).
Tales actividades típicamente son realizadas por un equipo de analistas y arqui-
tectos de software, que deben trabajar colaborativamente con clientes, usuarios,
arquitectos y diseñadores para identificar los requerimientos reales, facilitar discu-
siones, mediar en conflictos e identificar procedimientos y acciones para gestionar
requerimientos nuevos y antiguos, con el fin de mantener el proyecto bajo control,
así como definir los mecanismos de dicho control [3].
Por otro lado, el analista debe estar alerta a cambios tecnológicos que le permi-
tan recomendar posibles alternativas de solución, al igual que conocer los diferentes
repositorios de componentes desarrollados en la organización que provee el servicio,
a fin de facilitar la reutilización de artefactos.
_37
Figura 2.1. Procesos generales de la ingeniería de requerimientos
Recolección
Análisis
Desarrollo de
requiremientos
Especificación
Verificación
Ingeniería de
requerimientos
Captura
Trazar
Administración de
requerimientos
Monitoreo y reporte
Administración del cambio
Fuente: adaptado de Wiegers [1].
Desde el punto de vista de la gestión de los requerimientos, el analista debe estar

en capacidad de recomendar al cliente y al proyecto métodos, técnicas y herramientas
para apoyar el proceso. Así mismo, debe usar métricas para monitorear y controlar
actividades relacionadas con los requerimientos.
A continuación, se presentan los procesos y las actividades genéricas recomen-
dadas en un proceso de ingeniería de requerimientos.
2.1. Recolección
La recolección (en algunos contextos se usan los términos elicitación o abducción;

sin embargo, la primera se considera un anglicismo de elicitation y no se encuentra
definido en el Diccionario de la lengua española [4]) es el proceso de descubrimiento de
información, fuentes y conocimiento tanto organizacional como de las personas
mediante el cual se busca identificar los objetivos del proyecto y, a su vez, transfor-
marlos en los requerimientos del proyecto [5], para lo cual es necesario agrupar la
Recolección y análisis _39
información acerca del negocio (entorno, objetivos, etc.) y de las necesidades de los
usuarios. El fin último de la recolección es hacer que los usuarios entiendan cuáles
son sus necesidades reales para que estas se transmitan a los desarrolladores del
proyecto [6]. Además de identificar las necesidades de los usuarios, la recolección
también permite identificar y establecer cuáles son los límites del nuevo sistema y
cómo afectará en contexto a toda la organización [7].
Para iniciar la fase de la recolección de requerimientos es necesario identificar y
analizar los stakeholders del proyecto.
2.1.1. ¿De dónde vienen los requerimientos?
Una primera fuente de conocimiento básico que permitirá darle un contexto al

proyecto es precisamente identificar qué tipo de proyecto se está construyendo.
En principio, ello puede ayudar a identificar requerimientos de negocio, su origen
en los procesos mismos del negocio, así como alguna entidad o rol tanto externo
como interno a la organización a quien se le está prestando el servicio. Por ejemplo,
Alexander y Beus-Dukic [8] proponen diferentes tipos de proyectos en los cuales
los requerimientos y su origen están claramente diferenciados:
• Desarrollo in-house: desarrollado por el departamento de tecnologías de la infor-
mación de la organización, las fuentes principales de requerimientos están dentro
de la misma organización.
• Desarrollo de un producto o servicio: para el mercado de consumo masivo. El
área de mercadeo será uno de los mayores contribuyentes a los requerimientos,
así como expertos en disciplinas particulares del contexto del producto que se
va a desarrollar.
• Desarrollo customizado: para un único cliente. La fuente principal de requeri-
mientos será el cliente en sí mismo.
De lo anterior se identifica que el primer paso es precisamente conocer la orga-

nización para la cual se va a realizar el proyecto, y puede ir desde el conocimiento
de las políticas organizacionales, como:
• Las políticas internas de funcionamiento (procedimientos).
• Obstáculos para el desarrollo interno de software.
• Calendario de trabajo (horario y normas).
• Stockholders: personas de la alta gerencia o incluso dueños y accionistas de la
organización.
También ayuda el análisis de religión o etnografía, para casos particulares cuando

el equipo de desarrollo no está familiarizado con la cultura del país o región de la
organización cliente. Por ejemplo, puede indicar o alertar el uso de colores, pictogra-
mas o, incluso, aplicación de horarios de trabajo que afecten los horarios definidos
para el culto religioso de los empleados del lado del cliente.
2.1.2. Análisis de stakeholders
Hoy en día, el conocimiento es equivalente a tener poder, y para este caso, el cono-
cimiento son hechos, información, habilidades y costumbres que tienen las personas
y las organizaciones en el momento de interactuar con un sistema [9]. Teniendo
en cuenta lo anterior, el objetivo de este método es encontrar esa información con
ayuda de los stakeholders (personas involucradas) del proyecto, para así descubrir las
necesidades e intereses que afectan el proyecto y la viabilidad de cumplimiento de
dichas necesidades por parte del sistema [10].
El análisis de stakeholders depende de varios factores, por lo que se recomienda
tener en cuenta los objetivos organizacionales, objetivos del sistema, consideraciones
políticas y recursos (tiempo, personas y dinero), ya que se busca identificar las reglas
de negocio (véase sección “1.5. Tipos de requerimientos”) y los requerimientos de
usuario (véase sección “1.5.2. Requerimientos de usuario”) [10].
Durante el análisis de stakeholders se busca hallar una respuesta a preguntas co-
mo: quiénes son los stakeholders, cuáles son sus metas, cómo contribuirán durante
el proyecto y cuáles son los riesgos que ellos identifican asociados al proyecto [5],
pues cada tipo de stakeholder aporta su propio punto de vista a los requerimientos y
ello puede conducir a la aparición de conflictos entre las diferentes partes (clientes,
usuarios y requerimientos).
Para realizar el análisis de los stakeholders se recomienda seguir los siguientes
pasos:
2.1.2.1. Planear el proceso
Se debe definir cuál es el propósito de realizar este análisis dentro del proceso de re-
colección de los requerimientos del proyecto. Después de esto, es preciso organizar
un grupo de analistas, encargado de coordinar el calendario de actividades para las
diferentes entrevistas (véase sección “2.1.4.1. Entrevistas”), o talleres y el análisis
resultante de dichas actividades. Se recomienda que todos los miembros del equipo
de desarrollo se involucren en este proceso, ya que es necesario que cada uno conozca
a cabalidad cuáles son las necesidades que debe suplir el proyecto [11].
2.1.2.2. Identificar stakeholders
La identificación de stakeholders es una tarea importante dentro del desarrollo del

proyecto, de eso depende en parte el éxito del proyecto, dado que si se hace una co-
rrecta selección, es posible obtener una visión completa de las necesidades reales, de
los procesos que se contemplan, de los riesgos que se pueden presentar y así lograr
una gestión asertiva. Para ello se incluyen algunas características que se recomiendan
evaluar en cada uno de los stakeholders que participaran en el proyecto [10]:
• Informado: tiene el conocimiento y la experiencia necesaria para la toma de
decisiones.
• Comprometido: está dispuesto a participar activamente en el proyecto.
• Autorizado: asegurar que tiene la capacidad de tomar decisiones sin ser revertida
por otra persona, más tarde.
• Representativo: si es un grupo de stakeholders, este ha escogido su representante, es-
tán alineadas las necesidades del grupo, su representante tiene conocimiento de que
será un canal de comunicación entre su grupo y los demás stakeholders del proyecto.
Para la identificación de stakeholders existen diferentes técnicas, dentro de las

cuales se encuentran peeling the onion y brainstorming.
Peeling the onion. Esta técnica comienza con un contacto principal de la organiza-
ción, por medio del cual se genera una primera lista de stakeholders; después de gene-
rada esta primera lista, el analista de requerimientos debe preguntarle a cada uno de
estos por una nueva lista [8], ya que dentro de las organizaciones las personas se es-
pecializan en diferentes campos de acción. La figura 2.2 representa el uso del modelo.
Figura 2.2. Peeling the onion
Fuente: [11].
Al finalizar proceso, Helen Sharp et ál. [11] proponen definir cuatro grupos de
stakeholders principales: 1) los usuarios, que son los grupos de personas o compañías
que interactúan y usarán los productos del proyecto; 2) los desarrolladores, que,
como su nombre lo indica, son las personas encargadas del desarrollo del proyecto;
3) los legisladores, los cuales se “encargan de las restricciones legislativas y avalan
que el sistema sea legalmente posible” [8], y 4) los tomadores de decisiones, dentro
de los cuales se encuentran el(los) director(es) del equipo de desarrollo, gerentes e
interventores de la organización [12].
Una vez definidos estos grupos, se debe explorar la red de cada uno, para lo
cual es necesario identificar cómo se lleva a cabo el trabajo dentro de la organiza-
ción. Esto debido a que, dentro del nuevo sistema, está la posibilidad de modificar
o crear nuevos roles, los cuales no se pueden observar en la organización, puesto
que no existen [12].
Brainstorming. En esta técnica los analistas de requerimientos se reúnen con un
grupo inicial de stakeholders, y realizan una lluvia de ideas que les permitirá iden-
tificar a todas las personas que deberían hacer parte del proceso de recolección de
requerimientos [8].
Otras fuentes. Otras fuentes identificación de posibles stakeholders son:
• Preguntando a su patrocinador o cliente.
• Mediante el examen de qué hay y qué no hay en el organigrama de la organi-
zación.
• Comparando con proyectos similares.
• Analizando el contexto del proyecto (entorno de la organización, área de negocio,
área de procesos misionales, etc.).
La tabla 2.1 presenta una lista de posibles tipos de roles que pueden surgir en
un proyecto:
Tabla 2.1. Posibles tipos de roles [13]
• Operaciones normales • Control, gestión, administración

Roles
• Mantenimiento • Capacitación
operativos
• Soporte • Planificación, programación
• Beneficiarios funcionales
• Beneficiarios financieros
Beneficiarios • Beneficiarios sociales, etc. (si existen
• Beneficiarios políticos
beneficios indirectos)
• Propietario del sistema de interco-

Roles de nexión (intercambio de datos, etc.) • Interoperabilidad de servicios (com-
interfaz • Vecinos de negocio (beneficio mu- partiendo instalaciones/equipo)
tuo)
• Campeón
• Desarrollador
• Comprador (roles aquí varían am-
• Analista de requerimientos
pliamente y a menudo se super-
• Diseñador
ponen)
• Diseñador de la interfaz de usuario
• Cliente interno
• Programador
• Contratación
• Probador (muy útil en el trabajo de
Roles de • Promotor del proyecto
requisitos)
sustitución • Marketing (en representación de los
• Redactor técnico
(que consumidores)
• Fabricante/subcontratista/proveedor
representan • Gerente de producto
o trabajan en • Regulador
nombre de • Experto/consultor • El Parlamento, la ley estatutaria
otros) • Factores humanos/ergonómicos • Los departamentos gubernamenta-
• Ingeniero de seguridad les, las regulaciones
• Ingeniero de safety • Legislación orgánica
• Expertos en simulación/modelado • Normas de los organismos (nacio-
• Opiniones legales nales e internacionales)
• Traductor, asesor cultural, etc. • Los reguladores de voluntarios/in-
dustria
• Proveedor de servicios (= soporte
operativo + mantenimiento +
• Usuario (= operador habitual + • mesa de ayuda, y a veces desarrolla-
Roles beneficiario funcional) dor, subcontratista, fabricante)
híbridos • Consumidor (= comprador genéri- • Socio de riesgo y participación com-
co + usuario) partida (= desarrollador + fabri-
cante +
• beneficiario financiero), etc.
• Empleado descontento
• Vándalos, artista “grafitero”
• Sindicatos
• Ladrón
• Opositores políticos
Roles • Hacker, creador de virus
• El público, la asociación de veci-
negativos/ • Competidor
nos, etc.
hostiles • Espionaje industrial (a través de ma-
• Activista, grupo de presión del me-
lware, etc.)
dio ambiente, etc.
• Defraudador
• Enemigo militar o terrorista
De esta primera aproximación a los stakeholders del proyecto es la construcción

de relaciones de confianza y conocimiento, a partir de una comunicación clara y
adecuada, donde el analista escuche las necesidades, los deseos y la visión de las
personas relacionadas con el proyecto. Generalmente, ellos se sienten felices cuando
su punto de vista y opiniones son oídas; también es recomendable dar seguimiento
adecuado a las preguntas o sugerencias de cada persona.
Es necesario hacer un seguimiento de su relación/acuerdos con las partes intere-
sadas, para analizar su influencia en el proyecto; esto permitirá que efectivamente
el analista negocie y revise los conflictos que puedan surgir durante el proyecto.
Alguna información relevante respecto a los stakeholders puede ser [13]:
• Rol del stakeholder.
• Nombre/organización.
• Información de contacto (correo electrónico, teléfonos, dirección, horarios, etc.).
• Acciones con respecto al proyecto (si es necesario negociar, mediar en algún
conflicto, acordar, aprobar, etc.).
• Problemas asociados al stakeholder que puedan afectar el proyecto (es importante
tener presente que no necesariamente todos los stakeholders tienen las mejores
intenciones para el proyecto).
El análisis de influencia se refiere al poder que tiene un stakeholders sobre el pro-

yecto, en cuanto a las decisiones que son tomadas y los efectos negativos o positivos
que él puede ejercer [12]. El impacto que tiene cada stakeholder se puede ver de ma-
nera formal —es decir, depende de la organización, por ejemplo, la junta directiva
(organigrama)— o informal —su capacidad para influir, su grado de participación
y su interés en el éxito del proyecto— [14].
2.1.2.3. Priorización de stakeholders
La priorización de stakeholders consiste en clasificarlos teniendo en cuenta quiénes

son las personas que se ven afectadas por el proyecto, quiénes son los que toman
decisiones y quiénes se involucrarán directamente en el proyecto. Se puede utilizar
una clasificación de alto, medio o bajo (cualitativa). También, algunos autores como
Alexander y Beus-Dukic [8] sugieren utilizar una matriz que permita identificar estas
influencias positivas o negativas y clasificarlas según el impacto, ya sea débil o fuerte.
Para empezar, se deben listar todos los stakeholders que se identificaron, por
ejemplo, en el proceso peeling the onion o en el brainstorming. Después de esto se debe
analizar cuál es el impacto y la razón de por la cual se clasifican así. De esta forma se
va llenando una tabla como la presentada en la tabla 2.2, que mostrará al final de
este proceso cuáles son los stakeholders más importantes del proyecto, para así darles
prioridad a sus necesidades.
Tabla 2.2. Influencia de los stakeholders
Positivo Negativo
Stakeholder
Fuerte Débil Fuerte Débil
Fuente: [8].
Una vez definida y priorizada la lista de stakeholders, se debe reunir toda la in-
formación necesaria para preparar, ya sean los cuestionarios (véase sección 2.1.4.3),
entrevistas (véase sección 2.1.4.1) o talleres (véase sección 2.1.6.1) [11].
Así mismo, se recomienda consignar en una tabla (tabla 2.3) la información re-
levante de los stakeholders, la cual permite tener una visión clara del análisis realizado
sobre ellos. Para esto es necesario realizar el siguiente proceso:
• Establecer los principales grupos de stakeholders: ubicar los identificados en el
paso 2 del proceso de análisis en grupos, de acuerdo con los efectos que tiene el
proyecto sobre estos.
• Impacto: hace referencia a la priorización de los stakeholders, dependiendo de su
influencia, participación e interés en el proyecto.
• Necesidades e intereses: una vez se tenga la lista de stakeholders, se deben identi-
ficar las necesidades e intereses que tengan en el proyecto. Se precisa considerar
preguntas como: ¿qué beneficio del proyecto obtiene el stakeholder?, ¿qué cambios
debe hacer el stakeholder para que contribuyan con el proyecto? Y ¿qué actividades
del proyecto pueden causar conflicto o daño en el stakeholder? [15]. Para identificar
y recolectar las necesidades de los stakeholders, es decir, los requerimientos de negocio y
requerimientos de usuario es necesario utilizar las entrevistas y cuestionarios, brain-
storming y los talleres.
• Potenciales estrategias para involucrar al stakeholder: se deben definir cuáles son
los enfoques, con el fin de reducir la oposición que el stakeholder puede presentar
o para que este apoye y se involucre en el desarrollo del proyecto [15].
Tabla 2.3. Análisis de stakeholders
Establecer los Potenciales estrategias

Necesidades e
principales grupos Impacto para involucrar al
intereses
de stakeholders stakeholder
Al concluir el proceso de análisis de stakeholders se logran identificar:

• Los stakeholders clave, es decir, los vitales durante del desarrollo del proyecto.
• Las actuales y futuras necesidades de todos los stakeholders del proyecto [16].
Es importante aclarar que dichas necesidades aún no son requerimientos en sí
mismos, pues todavía no han sido refinadas ni especificadas.
• Los riesgos, no solo los que pueden surgir en el proyecto de acuerdo con las ne-
cesidades expuestas por los stakeholders, sino las actitudes que pueden tomar los
stakeholders frente al riesgo [14].
• Los conflictos y los riesgos que surgen cuando los stakeholders describen cuáles
son sus necesidades.
• Los grupos en los cuales se pueden agrupar los stakeholders [9], de tal manera
que se puedan crear estrategias de comunicación y compromiso para facilitar la
gestión de estos grupos durante el proyecto [14].
• Las estrategias que le permitan al grupo de desarrollo obtener el compromiso
del cliente [10].
Para recolectar los requerimientos existen varios métodos que se pueden utili-
zar, por ejemplo, introspección, entrevistas, cuestionarios, análisis de stakeholders,
brainstorming, etc. [6]. A continuación, se presentan algunas técnicas de recolección,
sus características y usos más relevantes.
2.1.3. Análisis de documentos
Al inicio de proyecto es posible que el equipo de analistas no posea un conocimiento

profundo acerca del problema que se va a tratar, asociado al sistema que se va a de-
sarrollar; por esta razón es importante el análisis de documentos en la parte inicial
del proceso. Se recomienda comenzar con textos relacionados al proceso de negocio
del cliente; esto implica lectura de libros de texto, revistas especializadas, sitios web,
conferencias, entrenamiento particular en el área, descripciones de productos o
servicios de los competidores del negocio o de la organización cliente [13].
Además, a medida que se avanza en el proceso de requerimientos, la información
que debe ser analizada ya no será solamente de la literatura general del negocio de
la organización (típicamente normativa externa a la organización), sino también
de la organización en sí misma (desde sus políticas, procesos de negocio, reglas de
negocio hasta su filosofía misma). Algunos de los documentos relevantes en esta
instancia del proceso pueden ser [13], [17]:
• Descripción de procesos de la organización y planes de negocio: permiten iden-
tificar roles y responsabilidades (también es un buen insumo para la identifica-
ción de stakeholders), así como información (bien sea formal o informal) que es
transmitida entre procesos. Además, puede ayudar a identificar cuáles de di-
chos procesos pueden ser automatizados o el grado de supervisión humana que
deben presentar. En ese sentido, es importante tener en cuenta que aunque la
organización tenga procesos definidos, no necesariamente se están ejecutando
en la forma en que han sido especificados; por ello, parte de la labor del analista
está enmarcada en la confirmación y definición de los procesos de negocio que
se verán afectados por el sistema o producto propuesto.
• Reportes: típicamente permiten no solo asociarlos a un proceso de negocio, sino a
una estructura de datos esperada, que da a su vez indicios de cómo será usada en
otros procesos; por todo esto, es recomendable no solo analizar los reportes, sino
analizarlos en el contexto de un proceso que haya sido ejecutado y los reportes de
ejecución hayan sido tramitados, esto permitirá también llevar a cabo un análisis
más detallado con el cual se identificarán los campos que pueden producir errores
en el proceso, los que no son usados, e incluso la validación esperada de algunos
campos del reporte; además, permitirá el seguimiento de la información para así
detectar cuál es innecesaria o relevante en el proceso.
• Documentos no estructurados: dentro de este grupo pueden identificarse los
documentos de uso común en la organización y que generalmente se utilizan
como medios de comunicación, por ejemplo: páginas web, memorandos, correos
electrónicos, anuncios publicitarios o de mercadeo. Estos documentos pueden
dar información relevante no solo en términos de los requerimientos, sino de
la forma en que la organización se comunica con los stakeholders y las diferentes
metáforas usadas desde el punto de vista motivacional para los empleados de la
organización.
2.1.4. Entrevistas y cuestionarios
2.1.4.1. Entrevistas
“Las entrevistas son la técnica más utilizada para la recolección de información

durante el proceso de recolección de requerimientos” [18]. Este método permite
conocer cómo se lleva a cabo el trabajo y cuáles son sus problemas actuales, al igual
que los factores culturales de la organización. La información que se recolecta por
medio de esta técnica revelará la opinión de múltiples stakeholders afectados por el
desarrollo del nuevo sistema, todo esto teniendo en cuenta qué, cómo y a quiénes
(esto habiendo realizado los dos primeros pasos del análisis de stakeholders) se les
realizan las entrevistas [5].
Un limitante durante la recolección de requerimientos por medio de las entre-
vistas es que el analista de requerimientos debe integrar toda la información (inter-
pretaciones, metas y objetivos) en un conjunto simple de requerimientos, para lo
cual no existe un procedimiento estandarizado [5].
Las entrevistas permiten involucrar a los stakeholders en el proceso y lo hacen
sentir que es escuchado y tenido en cuenta en el momento de tomar decisiones du-
rante el desarrollo del proyecto.
La entrevista, en sí misma, también presenta desventajas como [19]:
• El stakeholder tiene una visión limitada del proyecto o proceso que se va a analizar,
lo cual puede afectarlo negativamente; por ello, es importante complementar
las entrevistas con otro tipo de métodos como son los prototipos y los workshops
(donde se analicen los diferentes escenarios de los procesos organizacionales).
• Generalmente el stakeholder conoce el hacer, pero le es difícil describirlo, por
ejemplo: montar en bicicleta.
• En una entrevista no se solucionan conflictos, pero sí pueden identificarse muchos.
Para realizar esta tarea el ingeniero o analista de requerimientos debe ser un exce-
lente comunicador y debe utilizar el lenguaje del stakeholder al que le está realizando
la entrevista, ya que tiene que obtener los requerimientos de usuario por medio de
esta técnica [20] (véase sección “2.1.3. Análisis de documentos”).
Para realizar una entrevista exitosa es necesario seguir los siguientes lineamientos:
1. Leer la documentación relacionada con la organización y con el proyecto [21];
esto con el objetivo de preparar y organizar la entrevista.
2. Planear la entrevista teniendo en cuenta cuáles son los stakeholders a los que va
dirigida (el o los stakeholders) y cuál es el objetivo [22].
3. Definir qué tipo de entrevista se quiere realizar [17], [23]:

* Entrevista no estructurada: se desarrolla sin preparación, lo cual significa que
no se tiene una lista de preguntas preparadas (para este tipo de entrevista,
como es lógico, no se deberían seguir los pasos 4, 5, 6 de este proceso); solo
se tiene una idea básica del tema y las preguntas que se hacen surgen de las
respuestas del entrevistado.
* Entrevista estructurada: debe tener una lista de preguntas que se aplican en
el orden estipulado.
* Entrevista semiestructurada: cuenta con una lista de preguntas elaboradas
previamente; pero se pueden modificar o se pueden anexar preguntas se-
gún como se desarrolle la entrevista. Este método es recomendado por Ian
Alexander, ya que le permiten al entrevistado hablar con libertad.
4. Preparar adecuadamente su entrevista. Esto incluye material adicional que pue-
da serle de utilidad como son: modelos, documentos, prototipos, definiciones,
manuales, etc.
5. Hacer una lista de preguntas relacionadas con el objetivo de la entrevista. Para es-
to también es necesario decidir qué tipo de preguntas se van a realizar [17], [22]:
* Preguntas abiertas: están diseñadas para que los stakeholders respondan con
sus propios conocimientos lo que se les preguntó. Un ejemplo de este tipo
de preguntas puede ser: “¿Qué procesos están involucrados?”.
* Preguntas cerradas: pueden ser contestadas con una simple palabra o con
una frase corta. Algunos ejemplos son: ¿puede usted recrear el problema?,
¿qué edad tiene?
* Preguntas contextuales: le ayudan al entrevistador a conocer cuál es la infor-
mación global acerca del problema y de las posibles soluciones potenciales, ya
que estas preguntas no cuentan con un contexto en particular. Un ejemplo
de este tipo es: “¿Qué problemas puede crear este producto?”.
6. Organizar las preguntas de tal manera que al empezar la entrevista cubran el
tema de manera general y a medida que va avanzando la entrevista se dirijan a
los temas específicos. En ese sentido, es importante insistir en la diferencia entre
lo operativo en contraposición con lo administrativo. Por ello es importante iden-
tificar algunos tipos de preguntas que pueden ayudar a especificar la entrevista:
* ¿Qué es el proceso?
* ¿Para qué se creó?
* ¿Cuándo no se hace?
* ¿Cómo funcionaría?
* ¿Quién lo usará?
* ¿Dónde está? La ejecución, el documento, donde la gestión, etc.
7. Proporcionar la lista de preguntas a los stakeholders a los cuales se les realizará

la entrevista, para que puedan preparar sus respuestas y, a la vez, entender el
objetivo de la entrevista [21].
8. Al momento de realizar la entrevista, realizarla en no más de una hora, y deben
estar presentes, además del entrevistador y el entrevistado, al menos una perso-
na adicional que tome nota y que, a su vez, también participe en caso de que la
entrevista se salga de curso.
9. Incluir en el resultado del análisis de la entrevista no solo conclusiones textuales,
sino cualquier elemento de modelado visual que ayude a entender más rápida-
mente la información, por ejemplo:
* Mapas mentales.
* Casos de uso.
* Diagramas de flujo.
* Organigramas.
* Diagramas de Venn.
* Tablas de decisión.
* Diagrama de metas.
* Modelo de datos.
10. Una vez terminada la entrevista, revisar las interpretaciones que el entrevistador
ha capturado con los stakeholders, para así corroborar que la información es la
correcta; por esto el documento que recopila la información debe ser entregado
al stakeholder para que este lo revise y apruebe. Sin embargo, la información se
puede ir confirmando según avanza la entrevista, haciendo preguntas como: “Si
entendí bien, ¿usted empieza el proceso…?” [24].
La planeación de la entrevista debe incluir los tiempos necesarios para la pre-

paración, los desplazamientos, el análisis y la revisión de conclusiones con los
entrevistados.
Kendall y Kendall [17] recomiendan que la entrevista se desarrolle en un am-
biente que no dé lugar a distracciones; además, con anticipación debe ser enviado
al entrevistado el texto de la entrevista o un resumen ejecutivo de esta, con el fin de
permitirle prepararse y conocer el contexto de lo que será estudiado. De la misma
manera, cuando ha sido analizada la entrevista, se recomienda presentar los resul-
tados del análisis a el(los) entrevistado(s) para corroborar o complementar temas
que hayan quedado incompletos.
Cuando se requiere obtener información de grupos de stakeholders y no es posible
usar la entrevista como herramienta, se sugiere utilizar cuestionarios, que pueden ser
de dos maneras: 1) preguntas cerradas que permiten obtener datos que corroboren
alguna suposición hecha por los analistas; 2) preguntas abiertas que generarán opi-
niones y sugerencias en cuanto a las características y funciones que debería tener el
sistema [5].
2.1.4.2. Ejemplo de entrevista
La siguiente entrevista fue hecha en el 2010 para el desarrollo del proyecto de grado
Herramienta para la administración de requerimientos de los proyectos de las asignaturas de
ingeniería y arquitectura de software de la Pontificia Universidad Javeriana.1
Esta entrevista es de tipo semiestructurado, ya que algunas preguntas surgieron
de acuerdo con algunas de las respuestas dadas por el entrevistado, y cuenta con un
objetivo definido. Las preguntas abarcan el tema desde lo general a lo específico.
Para finalizar se encuentran las conclusiones, las cuales resaltan los aspectos más
relevantes de la entrevista.
Objetivo: La entrevista tiene como objetivo identificar las necesidades ob-

servadas por el ingeniero Miguel Eduardo Torres, encargado de impartir la
asignatura de Ingeniería de Software de la Pontificia Universidad Javeriana,
con el fin de obtener los requerimientos que debe suplir la herramienta de
administración de requerimientos, para que esta sea útil en el desarrollo del
proyecto de la asignatura. Tenga en cuenta que las preguntas que encontrará
a continuación son de tipo abierto, ya que era necesario conocer el contexto de
la situación sin limitar al entrevistado.
Pregunta 1. ¿Cree que el proceso de administración de requerimientos es im-
portante dentro de su asignatura? ¿Por qué?
Ing. Miguel: es importante porque les permite a los estudiantes hacer toda
la gestión de los requerimientos, hacer el proceso y el seguimiento, porque
finalmente mucho del ejercicio tiene que ver con el tema de las métricas, es
decir, que a partir de un buen análisis y gestión de requerimientos se pueda
hacer el tema de estimación, no necesariamente de tiempos o calendarios, sino
que los estudiantes puedan hacer estimaciones sobre el porcentaje de avance del
proyecto a partir de la priorización y de la complejidad de los requerimientos.
1
Laura Zorro y Vanesa Loaiza, “Herramienta para la administración de requerimientos de los proyectos de las
asignaturas de ingeniería y arquitectura de software de la Pontificia Universidad Javeriana”. Disponible en:
http://pegasus.javeriana.edu.co/~CIS1010IS05/ [Consulta: 11 de abril de 2016].
Pregunta 2. De las actividades de la administración de requerimientos (tra-

zabilidad, identificación de requerimientos, priorización, control de cambios),
¿cuál cree usted que es la que más puede influir en el desarrollo de las etapas
posteriores del proyecto? ¿Por qué?
Ing. Miguel: en el contexto de la asignatura, todos; la trazabilidad porque
permite calcular el estado del proyecto bien sea por avance, por complejidad
de los requerimientos, etc.
La identificación es absolutamente necesaria.
La priorización. Se ha visto que cada semestre que pasa la van desarro-
llando mejor, ya que cuando llega la hora de la entrega final del proyecto, los
estudiantes pueden decir “hicimos el 90 % del producto”; pero por la misma
priorización que hicieron, al momento de presentar el prototipo o la aplicación,
esas falencias de requerimientos, ese 10 % no se nota.
En cuanto al control de cambios, pensaría que no es tan relevante, porque
se parte del principio de que el cliente no va a cambiar los requerimientos, ya
que es el profesor quien les dice a los estudiantes cuáles son los requerimien-
tos mínimos, después de analizar el proyecto, entonces el tema de control de
cambios es más a nivel interno de ellos y no sé, nunca ha habido un grupo que
al final del curso haga esas conclusiones acerca de si fue o no importante hacer
control de cambios. Se podría decir que, ya que el proyecto en el contexto de los
estudiantes es relativamente grande y complejo, el tema de control de cambios
se debe manejar más en el contexto de “ese requerimiento no está claro, como
lo arreglamos” o “ese cambio va a afectar la arquitectura”.
Pregunta 3. ¿Qué buenas prácticas de administración de requerimientos les
recomienda a los estudiantes?
Ing. Miguel: administración del cambio, trazabilidad, localización, métricas
(pero esto es más transversal que debe realizarse a lo largo de todo el proceso,
no solo en requerimientos), verificación y validación, que es algo que debe
hacer un humano, ya que consiste en leer, pero si puede haber herramientas
que apoyen esa verificación y validación, por ejemplo, la localización, la traza-
bilidad y listas de chequeo, ya que son herramientas muy fuertes que apoyan
la verificación y validación.
Pregunta 4. ¿Listas de chequeo, por ejemplo, las cxone [25]?

Ing. Miguel: sí, y tipo nasa, pero creo que esas son listas muy genéricas, hay
que pensar en algo que sea más relevante al contexto del proyecto que es lo
que se debe hacer en la vida real, no tiene sentido en la vida real decir que se
va a hacer verificación y validación de un proyecto con las plantillas cxone. Se
debería ver el contexto del negocio y escoger una lista de verificación adecuada.
Conclusiones
• Existen actividades no tan relevantes dentro del contexto del curso, ya
que no hay suficiente tiempo para su desarrollo, por ejemplo, el control de
cambios y el almacenamiento de requerimientos rechazados; sin embargo,
se pueden implementar de manera sencilla para que los estudiantes tengan
conocimiento de ese tipo de actividades.
• Se necesita reforzar procesos como el de verificación y validación dentro del
proceso de ingeniería de software que realizan los estudiantes.
• Dentro del proceso de verificación y validación se necesitan más herra-
mientas para realizar una revisión completa, pues las que se están usando
actualmente son muy genéricas (listas de chequeo cxone [25]).
• El grafo de requerimientos se ha vuelto, últimamente, una herramienta im-
portante dentro del proceso de ingeniería, ya que permite una visualización
más general del estado del proyecto.
• Los procesos de la ingeniería de software que son necesarios dentro del
contexto de la asignatura, son:
* Trazabilidad
* Localización
* Métricas
* Priorización
* Identificación
La clasificación de requerimientos escogida por el docente para manejar en

la asignatura es la sencilla que incluye (requerimientos del negocio, sistema y
usuario), dándole más importancia a los requerimientos funcionales.
Ya que en el ejemplo anterior solo se formularon preguntas de tipo abierto, se

hubiesen podido agregar algunas preguntas tanto cerradas como abiertas (en caso
de que la pregunta cerrada requiera más información) para acotar las respuestas del
entrevistado. Por ejemplo:
1. ¿Cree que los estudiantes saben identificar los riesgos, como la falta de planeación,
cuando están implementando el proyecto que deben realizar en su asignatura?
2. ¿Cree que la falta de planeación en el momento de ejecutar el proyecto les causa
problemas durante la implementación?
3. En los últimos dos años qué tan frecuente es que los estudiantes no detecten
este riesgo:
a. Siempre
b. Casi siempre
c. Algunas veces
d. Casi nunca
e. Nunca
4. ¿Cree usted que los resultados que obtienen los estudiantes al final de la imple-
mentación están directamente relacionados con una buena administración de
requerimientos, sí o no? ¿Por qué?
5. ¿Cree usted que con una herramienta de administración de documentos los es-
tudiantes podrían agilizar el proceso de trazabilidad de requerimientos, sí o no?
6. Mencionó anteriormente que la priorización de requerimientos se ha venido
desarrollando en los proyectos de los últimos semestres, ¿qué métodos de prio-
rización se han popularizado con los estudiantes?
a. Wiegers
b. Numérica
c. Otra. ¿Cuál?
2.1.4.3. Cuestionarios
Los cuestionarios son documentos compuestos por un conjunto de preguntas, cuyo

objetivo es obtener información específica. Se utilizan como técnica de recolección
de requerimientos, ya que conceden ventajas económicas cuando se trata de hacer
recolección de requerimientos sobre un grupo extenso de stakeholders [13] o cuando
estos stakeholders no disponen de tiempo suficiente para aplicar otra técnica, como
la entrevista.
Los cuestionarios les permitirán a los analistas de requerimientos, en caso de ser

un nuevo proyecto [17]:
• Identificar los stakeholders y sus características.
• Conocer las necesidades de los stakeholders y qué esperan del nuevo sistema.
• Determinar a grandes rasgos como se llevan a cabo los procesos dentro de la
organización.
Si se trata de un producto existente, los cuestionarios les permiten a los analis-

tas [17]:
• Aprender sobre los usuarios finales y cuáles son sus características.
• Identificar qué les gusta y qué no a los usuarios del sistema que va a ser modi-
ficado.
• Conocer cómo se utiliza actualmente el sistema.
Para hacer un cuestionario se deben seguir los siguientes pasos:

1. Identificar los objetivos del cuestionario y a quiénes va dirigido el cuestionario,
qué información se está buscando, cómo será aplicado y quiénes estarán involu-
crados [12] en el proceso de análisis y entrega de conclusiones.
2. Realizar una lluvia de ideas con el grupo de analistas que permita identificar
preguntas potenciales para incluir en el cuestionario. Una vez se tenga la lista,
esta debe ser examinada con detenimiento para asegurar que se incluyan todas
las preguntas necesarias para obtener la información deseada [13].
3. Reducir el conjunto de preguntas, debido a que los cuestionarios deben ser cortos
para evitar que las personas desistan de diligenciarlos debido a su extensión [12].
4. Definir el formato en el cual se van a realizar las preguntas. Para esto, puede
seleccionarse cualquier tipo de pregunta. Entre las más comunes se encuentran
[17], [26], [27]:
* Preguntas abiertas: este tipo de preguntas les permitirá a los stakeholders re-
dactar sus respuestas. Un ejemplo podría ser: ¿qué tipo de reportes se generan
en su área? Esta clase preguntas, aunque son fáciles de redactar, cuentan con
ciertas desventajas, ya que como las personas utilizan sus propios términos,
sus respuestas pueden ser confusas. Además, el análisis de resultados puede
tornarse complicado.
* Preguntas cerradas: estas se pueden generar teniendo en cuenta que la re-
spuesta puede ser única, múltiple, preguntas en las cuales las personas dan
su opinión por medio de una escala o binarias.
Un ejemplo de una pregunta de selección única puede ser: ¿cuántos

libros lee al mes?
a. 1
b. 2
c. 3
d. Otro ______
Un ejemplo de una pregunta cerrada con múltiple respuesta puede ser:
¿qué tipo de tiquetes de viaje ha comprado en línea? Seleccione uno o más.
a. Tiquetes aéreos
b. Tiquetes de tren
c. Tiquetes de bus
d. Ninguno
Una pregunta de tipo binario es simplemente una pregunta en la cual
la persona tiene solo dos opciones para contestar, bien sea sí o no, falso o
verdadero, o de acuerdo/en desacuerdo.
Finalmente, un ejemplo de una pregunta con respuesta en escala puede
ser: ¿cómo clasificaría su experiencia en la adquisición de tiquetes en línea?
1 2 3 4 5 6 7 8 9 10
Mala Muy buena
5. Seleccionar las palabras que se van a utilizar de manera cuidadosa en el momento

de redactar las preguntas, porque se debe utilizar un lenguaje claro e imparcial.
Autores como Baxter y Courage [13] recomiendan que las preguntas no conten-
gan más de veinte palabras y que solo traten un asunto a la vez.
6. Organizar las preguntas por grupos, de tal manera que el cuestionario siga un
orden lógico.
7. Incluir, una vez redactadas las preguntas:
* Título del cuestionario
* Instrucciones
* Información de contacto (a menos que el cuestionario esté definido como
anónimo)
* Propósito
* Tiempo estimado para la solución del cuestionario
8. Determinar cómo se va a llevar a cabo el análisis de resultados. Para hacer esto,
es necesario preguntarse:
* ¿Qué análisis se va a realizar? Para esto, revisar cada pregunta y determinar
qué se va a hacer con la información recolectada.
* ¿Existen preguntas en las que usted no sabe cómo analizar los resultados? Si
es así, estas preguntas deben ser eliminadas.
* Con las preguntas existentes, ¿se obtiene toda la información necesaria? Si
no es así, es posible que falten preguntas.
9. Seleccionar la forma en la que se va a distribuir el cuestionario, ya sea por correo
electrónico, por la web o en papel.
Una vez creado y aplicado el cuestionario, es preciso analizar los resultados, para
lo cual se sugiere el siguiente procedimiento:
1. Verificar que las preguntas fueron contestadas. En caso de que exista alguna pre-
gunta sin responder por parte de la mayoría de las personas, esta no se debería
incluir dentro del análisis, ya que se puede generar información incorrecta [26].
2. Inspeccionar los datos con el fin de validar que no sean inconsistentes, por ejem-
plo, una fecha de nacimiento 1889, seguramente se refiere a 1989 [28].
3. Calcular el porcentaje de personas que contestó el cuestionario, con el fin de saber
si los resultados reflejarán la opinión de la mayoría, ya que si el cuestionario no
es contestado por los stakeholders a los que va dirigido, es posible que se queden
requerimientos sin identificar [28].
4. Es posible que usted requiera clasificar las respuestas en subgrupos. Por ejemplo,
es necesario conocer el resultado de una pregunta dependiendo de la edad de
los encuestados [28].
5. Crear conjuntos que agrupen las respuestas dependiendo de una característica,
por ejemplo, un grupo asociado al departamento de recursos humanos y otro al
de finanzas [26].
6. Generar una codificación numérica para las preguntas, por ejemplo, si la respues-
ta es no, esto equivale a 0, y si la respuesta es sí, equivale a 1 [28].
7. Ingresar las respuestas de los cuestionarios en una herramienta de análisis, por
ejemplo, Excel, para generar gráficos que permitan una mejor interpretación de
las respuestas de los cuestionarios [29].
2.1.4.4. Ejemplo de cuestionarios
El siguiente cuestionario fue realizado durante la elaboración del trabajo de grado

titulado Herramienta para la administración de requerimientos de los proyectos de las asig-
naturas de ingeniería y arquitectura de software de la Pontificia Universidad Javeriana,
como parte de la recolección de los requerimientos para elaborar el producto final.
Para este cuestionario se definió el objetivo y la población a la cual iba dirigido, así
como el tipo de preguntas que se realizarían. Debido a la clase de información que

se requería, se decidió que los tipos de preguntas más adecuados para este eran las
preguntas abiertas, cerradas y binarias.
A continuación, se encuentra un resumen del cuestionario final.
Objetivo
El siguiente cuestionario tiene como objetivo conocer la opinión de estudiantes
acerca de los procesos de administración de requerimientos que se llevan a cabo
en los proyectos de la asignatura de Ingeniería de Software.
Población objetivo
Estudiantes de la Pontificia Universidad Javeriana que ya hayan cursado y
aprobado la asignatura Ingeniería de Software.
Forma de aplicación
Cuestionario en línea.
Preguntas
1. Cuando se hizo la especificación de requerimientos, ¿qué atributos se tu-
vieron en cuenta? (Por ejemplo: id, autor, etc.).
2. ¿Cuánto tiempo se involucró al cliente durante la especificación de los re-
querimientos?
a. Una a dos veces por semana
b. Cada dos semanas
c. Solo en la preentrega
d. No lo involucraron
3. En cuanto al cambio de requerimientos, ¿se definió algún protocolo para
la petición de cambio de requerimientos? Sí o no, ¿por qué?
4. ¿Realizó usted la priorización de los requerimientos?
a. Sí
b. No
5. ¿Realizó usted la trazabilidad?
a. Sí
b. No
6. ¿Realizó algún gráfico para representar los requerimientos?

a. Sí
b. No
¿Cuál era el objetivo? ______________________________________
7. Teniendo en cuenta las actividades que se realizaron para la entrega del
srs, ¿cuáles considera que fueron las actividades que contribuyeron con el
éxito de la entrega?
Ejemplo del análisis de resultados
Ya que los resultados de este cuestionario son extensos, se mostrará a conti-
nuación uno de los gráficos generados por la herramienta utilizada para la dis-
tribución. Estos tipos gráficos son útiles cuando las preguntas son cerradas, lo
cual le permite al grupo de analistas revisar con mayor certeza cuáles son los
resultados del cuestionario (figura 2.3).
Figura 2.3. Ejemplo de los resultados del cuestionario

¿Cuánto tiempo se involucró al cliente durante la especificación de los requerimientos?
0
Una o dos veces Cada dos semanas Solo en la preentrega No lo involucraron Otro
por semana (por favor especifique)
Análisis técnico Conclusiones destacadas
Media 1,941 El 82,35 % eligió:
Intervalo de confianza (95 %) [1,452-2,430] Cada dos semanas
Tamaño de la muestra 17 Una o dos veces por semana
Desviación típica 1,029 La opción “No lo involucraron” no fue elegida por nadie
Error estándar 0,250
Fuente: elaboración propia.

2.1.5. Prototipos
Los prototipos constituyen una de las técnicas más conocidas dentro del desarrollo
de sistemas y la recolección de requerimientos tanto de negocio como de usuario,
dado que es una forma de “visualización” [18] de las características que el cliente
necesita de su producto y de las que no. También se considera otra forma de comu-
nicación entre el grupo de desarrollo y los stakeholders, ya que al ser presentado, se
puede estimular la concertación y visualización de requerimientos, así como permitir
la identificación de requerimientos faltantes [8].
Esta técnica [8], [12], [13], [18] debe manejarse adecuadamente, ya que el ob-
jetivo de realizar prototipos, dentro de este contexto, es recolectar requerimientos
y validarlos, así como permitir validar posibles soluciones, bien sean tecnológicas
o de arquitectura, y en algunos contextos, por ejemplo, el del desarrollo evolutivo,
transformar el prototipo en una versión inicial del producto de software esperado.
Si se desea de esa forma, el grupo de proyecto debe tener claro cuál es el objetivo
del prototipo, ya que de eso depende el tipo de prototipo que se va a realizar y el
esfuerzo invertido en ello. A partir de lo anterior, los prototipos se pueden clasificar
según el objetivo, además del alcance que se quiere tener con ellos. En la tabla 2.4
se presentan de manera breve las clasificaciones más comunes [17], [30].
Tabla 2.4. Tipos de prototipos
Criterio Evolutivo “Usar y Tirar”

Como su nombre lo indica, el prototipo
Este tipo de prototipo se usa exclusiva-
se va desarrollando con el tiempo hasta
Objetivo mente para comunicarse con el cliente y
convertirse en el producto final. Por lo
por recolectar los requerimientos. Por lo tan-
tanto, requiere más tiempo para su ela-
cumplir to, su elaboración es rápida comparado
boración, ya que es una versión inicial del
con el evolutivo.
sistema que se va a entregar.
Horizontal Vertical
A diferencia del horizontal, el vertical
“Plano pero amplio” [30]. Es decir, es
se caracteriza por ser angosto pero pro-
una vista de las funcionalidades del siste-
Alcance fundo, es decir, se enfoca en porciones
ma, sin entrar en detalle. Aquí lo impor-
funcional pequeñas del sistema, pero tendrá más
tante es saber si todos los requerimientos
detalle. Un ejemplo de ello es un caso de
están incluidos.
uso que se vaya a implementar.
Para emplear los prototipos, Alexander y Beus-Dukic [8] recomiendan seguir

los pasos que se presentan en la figura 2.4.
Figura 2.4. Proceso para emplear los prototipos en la recolección de requerimientos
Escuchar
cuidadosamente
Definir el
objetivo del
prototipo
(tipo)
Presentar el Elaborar el
prototipo,
prototipo a los dependiendo
stakeholders del objetivo
Fuente: adaptado de [27], [30].
• Definir el objetivo del prototipo: como se ha mencionado, al emplear esta técnica

es importante tener claro cuál es el objetivo y qué tipo de prototipo se requiere
usar, ya que de ello dependen los criterios a la hora de registrar y evaluar los re-
sultados obtenidos durante la demostración. En este contexto, el modelo de ciclo
de vida elegido para el proyecto puede ser de utilidad para tomar esta decisión.
• Escuchar cuidadosamente: el propósito de las técnicas de recolección es conocer
e identificar las necesidades reales del cliente, así como la perspectiva que él mis-
mo tiene del producto. La tarea de los analistas es observar cómo los stakeholders
reaccionan frente al prototipo, los comentarios, los gestos; cómo manejan el
prototipo. En resumen, se debe ir al detalle [31] en cuanto a la observación en
los primeros minutos de la demostración del prototipo.
Para tener un mejor registro de todas las reacciones y comentarios sobre el
prototipo, se pueden utilizar técnicas de observación. Una de ellas, y la más reco-
mendable, es registrar la demostración en video; de esta forma, se pueden captu-
rar las diferentes reacciones y grabar los comentarios hechos por los stakeholders.
• Elaborar el prototipo, dependiendo del objetivo: la elaboración del prototipo es

un proceso iterativo e incremental, debido a que después de la primera iteración,
el grupo de proyecto puede ir agregando detalles que son resultado de lo regis-
trado en las demostraciones.
Se usan diferentes técnicas y herramientas en la elaboración de un prototipo,
dependiendo del alcance y tipo definido. Un ejemplo de ello es cuando el grupo
del proyecto tiene como objetivo saber cómo los stakeholders reaccionan frente a
la navegabilidad del sistema; en este caso se trata de un prototipo tipo horizon-
tal, donde no se enfoca en funcionalidades específicas, sino en el cubrimiento
de todos los requerimientos de negocio y la relación entre ellos (alto nivel). Para
esto, se pueden realizar interfaces (no funcionales) y referenciarlas para que in-
teractúen entre ellas.
• Presentar el prototipo a los stakeholders: según Mead [32], hay que tener en cuenta
los siguientes aspectos para que la demostración sea exitosa para los analistas y
llevadera para los stakeholders:
* Realizar la demostración de manera sencilla.
* Asegurarse de que funciona lo que se quiere evaluar.
* Escribir un paso a paso de su demostración.
* El prototipo debe ser abierto, casi que incompleto para permitir y dar espacio
a los comentarios de los stakeholders.
* Retomar el objetivo del prototipo y definir los criterios a evaluar con respecto
a las reacciones y comentarios de los stakeholders.
Un ejemplo de prototipos donde su objetivo se limita a la recolección de reque-

rimientos es una interfaz de usuario sencilla donde se muestra la navegabilidad entre
las diferentes pantallas. Con esta clase de prototipos, se puede obtener información
acerca de la relación entre los requerimientos funcionales y los no funcionales. Esto
se debe a que el cliente, mientras está viendo el prototipo de la interfaz gráfica e
interactuando con ella, va mencionando desde las funcionalidades que debe desem-
peñar una pantalla específica hasta el color e imágenes que se deben incluir.
Otros modelos complementarios a los prototipos son los propuestos por Chen
y Beatty [33]:
• Diagramas de flujo de interfaces: muestra cómo los usuarios navegarán por las
interfaces definidas, por medio de un diagrama de flujo que representa las pan-
tallas, los eventos que disparan la apertura de otra venta y las decisiones que
pueden llevar a nuevas ramas o caminos de flujo (figura 2.5).
• Modelo dar de Display-Action-Response (presentar-acción-respuesta): a partir

de una tabla permite documentar las formas válidas en la que el sistema debe
presentar elementos y transformaciones de datos en pantalla y cómo el sistema
responde a acciones tomadas por el usuario.
Figura 2.5. Diagrama de flujo de interfaces
Interfaz 1
Evento disparador de IU
Decisión Interfaz 2
Sí
No
Interfaz 2
2.1.6. Técnicas para grupos
En general, al recolectar información de grupos de personas, es relevante contestar

tres preguntas básicas:
• ¿Qué se quiere alcanzar?
• ¿Qué conflictos hay y cómo se van a solucionar?
• ¿Cómo se pueden formar los grupos?
Estas preguntas guiarán el proceso de definición, ejecución y cierre del ejercicio,

pues permiten identificar los grupos de personas, sus diferentes intereses y posibles
conflictos que deban ser solucionados en el proceso de recolección.
Adicionalmente, pueden ayudar a generar grandes volúmenes de información
útil para el proyecto, por ejemplo:
• Casos de uso y mal uso del producto que se va a implementar.
• Mapas mentales.
• Diccionarios de datos.
• Modelos de flujo de procesos.
• Riesgos y amenazas del proyecto.
• Formalización de solución de conflictos y negociaciones.
• Recomendaciones de diseño.
2.1.6.1. Workshops o talleres
Los talleres son eventos planeados y estructurados con un grupo de stakeholders o ex-
pertos en temas relacionados con el proyecto (de los que se identificaron en el análisis
de stakeholders), los cuales trabajan juntos [34], ya que comparten un objetivo [35],
para descubrir, crear, verificar y documentar una lista preliminar de requerimientos
de usuario y requerimientos de negocio. Además de recolectar los requerimientos, los
talleres también tienen como objetivo que el equipo de desarrolladores y encarga-
dos del proyecto conozcan los stakeholders del proyecto [36], con el fin de mejorar la
comunicación, la toma de decisiones y el entendimiento mutuo.
Para no convertir los talleres en encuentros improductivos, es necesario que los
analistas involucrados tengan definido ya su rol dentro del taller, de esta forma cada uno
sabe cuál es su objetivo y logran así que las actividades de los talleres influyan y sean
útiles tanto para el grupo de proyectos como para los clientes. La figura 2.6 presenta
algunos roles importantes [37] con los cuales cumplir con el objetivo de los talleres.
• Para preparar un taller exitoso, es necesario tener en cuenta los siguientes ítems:
* Definir cuáles son las personas que van a participar dentro del taller. Además
del grupo de stakeholders es necesario contar con personas que desempeñen
diferentes roles, así como expertos técnicos en temas relacionados al proyecto
(véase figura 2.6).
* Escoger un lugar tranquilo para que las personas no se vean perturbadas por
el trabajo. Si no es posible, se debería escoger un lugar fuera de la empresa
para realizar el taller un fin de semana [24].
Figura 2.6. Roles de los talleres
Patrocinador
• Autoriza y legitima el taller
Facilitador o moderador
• Los planes y diseños del taller
• Conduce el proceso, lo cual incluye:
* Hace cumplir la disciplina, estructura y las reglas base del encuentro
* Introduce los objetivos y la agenda
* Maneja el encuentro y los mantiene por buen camino (los participantes están activos
frente a cualquier actividad o ítem)
* Facilita el proceso de decisión, evitando participar en el contenido de la discusión
* Asegura que todos los stakeholders participan
* Hace preguntas acertadas
Participantes
• Crean productos del taller
Dueño del diccionario

• Construye listas de problemas
• Diccionario de términos y procesos
• Construye y refina el modelo de datos del negocio
Miembros del equipo de planificación (un subconjunto de los participantes)

• Funciona con el facilitador para planificar el taller
• Crea entradas del taller
• Como participante, crea productos del taller
Grabador
• Graba el grupo de trabajo
Observador
• Escucha y aprende
Expertos en la materia
• Están disponibles para cualquier pregunta

* Evite interrupciones de teléfono móvil; en vez de eso, permítale comunicarse

a través de mensajes, de esta forma no se pierde la concentración ni el flujo
del taller.
* Los refrigerios o comidas ligeras son de ayuda para que las personas puedan
expresarse en un ambiente más ameno (compartiendo una comida con otras
personas); de esta forma pueden hablar cómodamente sobre las necesidades
que les interesan a los analistas [24].
* Identifique los stakeholders críticos que deberían participar en el taller; de esta
forma se asegura obtener información relevante (necesidades, características
deseadas, etc.) [38].
* Clarifique los términos que va a a usar en los entregables del taller [30].
* Envíe material relacionado con el taller previamente; para así poder tener
un avance con respecto a la contextualización de la actividad. De esta forma
se incrementa la productividad del taller [30].
• Para la ejecución del taller, Alexander y Stevens [24] proponen un curso de las
acciones en general, que debería existir en los talleres. La figura 2.7 muestra
dicho ciclo.
Figura 2.7. Ciclo de los talleres
Presente a los Plantee varias

stakeholders un preguntas acertadas
documento de que permitan a
requerimientos o un los stakeholders
conjunto de casos discutir sobre el
de uso requerimiento o
Proposición Acción escenario
El moderador Reflexión Reacción

Los stakeholders
induce a los participan
participantes a y proponen,
llegar a una conclusión dependiendo del
Elaboración de uno de tema que se vaya a
los entregables del taller desarrollar

• Entregables: una de las diferencias existentes entre un encuentro y un taller es

que el taller tiene unos entregables específicos y predefinidos que se deben rea-
lizar al finalizar un ciclo (figura 2.8). Los talleres producen productos tangibles
como los modelos de requerimientos o su relación entre ellos; también se ob-
tienen productos intangibles, como el aprendizaje mutuo, mayor comprensión,
conocimiento de la idiosincrasia de la organización, lo cual ayuda a la toma de
decisiones, motivación y trabajo en equipo.
En la figura 2.8 se presentan entregables genéricos que pueden surgir de lo
general (al inicio del taller) hasta lo específico (al final), como es el caso de “los
objetivos y metas”, las cuales se transforman al finalizar el proceso en reque-
rimientos de negocio.
Figura 2.8. Entregables generados por el taller
• Objetivos, metas
• Vision del proyecto
• Plan de comunicación
Visión
• Glosario de términos del negocio

• Nombre de los casos de uso
Alcance
• Breve descripción de los casos de uso

• Reglas de negocio
• Amenazas, riesgos y obstáculos
Alto nivel
• Requerimientos de negocio
• Casos de uso paso a paso
• Escenarios de mal uso del producto
Detalles • Mapas mentales
• Priorizaciones
• Decisiones de diseño
Fuente: adaptado de Ellen Gottesdiener [38].

No todas las técnicas de recolección pueden ser útiles en los diferentes proyectos.
Más adelante, la tabla 2.6 presenta las ventajas y desventajas de usar los talleres
como técnica de recolección. De esta forma, se pueden tener los suficientes criterios
para escoger una o más técnicas para aplicar en el taller.
2.1.6.2. Grupos focales
Los grupos focales son una técnica similar a los talleres; sin embargo, se diferencian
en lo siguiente:
• El manejo del tiempo.
• Los participantes involucrados.
• El objetivo mismo del grupo.
En un grupo focal se reúnen de 6 a 10 personas para discutir sus experiencias,

opiniones e ideas sobre un tema propuesto por el moderador [13]. También permite
a los participantes expresar sus expectativas con respecto al producto en general,
dando al grupo de analistas información sobre nuevos requerimientos o modificación
en ellos. Esta técnica puede ser utilizada en diferentes fases, desde la recolección
hasta producción; además, permite la recolección desde diferentes puntos de vista.
Las fases propuestas para los grupos focales son las siguientes:
• Preparación: durante esta fase se deben decidir las personas a participar. Para
esto es mandatorio determinar qué tipo de stakeholders deberían asistir. Baxter y
Courage [13] los clasifican en dos grupos:
* Homogéneos: son personas con características similares o que trabajan en
la misma área.
* Heterogéneos: a diferencia del homogéneo, en este grupo se encuentra diver-
sidad en las características, perspectivas y cargos dentro de la organización.
Cada uno tiene sus ventajas y desventajas, por ejemplo, los grupos hete-
rogéneos pueden aportar diferentes puntos de vista con respecto a un tema
específico; mientras que uno homogéneo, no. Sin embargo, se podrían realizar
varios encuentros con diferentes grupos homogéneos para así poder obtener los
diferentes puntos de vista [24].
Otro aspecto que se debe preparar son los temas que se van a discutir. Al-
gunos aspectos propuestos son [13]:
* Descripción de un típico día de trabajo de un usuario.

* Las tareas que los usuarios hacen y cómo las hacen.
* Temas generales propios de la organización.
* Gustos y disgustos frente al proceso que desempeña.
* Deseos o metas.
* Reacciones, opiniones o actitudes frente a un concepto/producto nuevo o
modificado.
Al igual que los talleres, se tienen diferentes roles que se deben desempeñar
durante la ejecución de los encuentros de grupos focales. Los roles propuestos
son los siguientes:
* Moderador: dada la similitud entre los talleres y los grupos focales, se pro-
ponen como tareas del moderador introducir un tema de discusión, realizar
preguntas para permitir a los asistentes dar su opinión y al finalizar inducir
al grupo a concluir y terminar la sesión. Sin embargo, como es un grupo más
pequeño, una de las funcionalidades que tiene el moderador es recolectar
todas las respuestas del grupo y examinarlas para verificar que cada uno de
los participantes ha comprendido. Esto asegura obtener información válida
y útil para la recolección.
* Anotador: su responsabilidad consiste en colaborar al moderador, anotando
las principales conclusiones y sugerencias que puedan ser de utilidad para
la recolección. La persona que vaya a desempeñar este rol debe tener cono-
cimiento sobre el tema a tratar durante la sesión [17].
Con ayuda del anotador se puede evitar repetir algunos temas, haciendo
un uso más eficiente del tiempo. Además, esto motiva al asistente a parti-
cipar de forma activa, porque demuestra a los participantes que sus opinio-
nes, sugerencias e ideas se están teniendo en cuenta y que está ayudando al
grupo de analistas.
* Grabador: este rol es útil para mantener un registro de todas las reacciones y
comentarios de los participantes, para después de terminada la sesión analizar
los diferentes comportamientos de los participantes.
• Ejecución: el proceso de ejecución es similar al de los talleres, con la diferencia de

que se omiten los entregables, ya que esta finaliza cuando se concluye un tema
y no cuando los participantes terminan de elaborar los entregables. La duración
de una sesión oscila entre una y dos horas. En la figura 2.9, Baxter y Courage
[13] proponen la distribución de los tiempos de la siguiente manera:
Figura 2.9. Procedimiento de una sesión de grupos focales
Bienvenida (introducción)
1
Ejercicio creativo (romper el hielo)

2
Discusión
3
Recapitulación (distribución de incentivos,

agradecimientos)
4
Fuente: adaptado de [13].
• Resultados: la recolección de resultados está a cargo del grupo de analistas después

de haber registrado las respuestas, las grabaciones y los comentarios de los parti-
cipantes. Se realiza un análisis cuantitativo y cualitativo de los datos recolectados.
A partir de los análisis se hace un reporte que es comunicado a los participantes
del encuentro.
2.1.6.3. Diseño de un conjunto de aplicaciones
jad es la sigla de Joint Application Design (diseño de un conjunto de aplicaciones).

Fue desarrollada por ibm en 1977 [15]. Consiste en una técnica que promueve la
cooperación, la comprensión y el trabajo en equipo entre los usuarios, los clientes y
los desarrolladores [17].
A pesar de que el nombre sugiere que la técnica está orientada a la fase del diseño
de software, existen dos tipos de sesiones jad:
• jad/Plan: Donde el objetivo es recolectar y especificar requerimientos.
• jad/Design: como su nombre lo indica, el objetivo es la elaboración del diseño.
La construcción colectiva del proyecto permite a los stakeholders, especialmente

a los clientes y a los usuarios, tener un “sentido de propiedad” [12]; de esta forma
se facilita la colaboración dentro del grupo que, a la vez, incrementa la comunica-
ción entre los stakeholders, asegurando así una recolección de información útil para
el grupo de analistas. Sin embargo, dado que el contacto con los clientes y usuarios
es constante, el tiempo invertido en esta técnica es mayor que el invertido por otras;
por lo tanto, es más costoso implementarla y depende en gran medida del compro-
miso y la colaboración de la organización.
Los autores coinciden en que las fases de jad son: preparación de la sesión de jad,
sesión jad y recapitulación de jad [17], [39] (el cual incluye entregables). Además,
existen seis tipos de participantes en una sesión jad. En la figura 2.10 se muestran
cada uno de los participantes y su funcionalidad dentro de una sesión.
Figura 2.10. Participantes en una sesión JAD
Es la persona a la que Dirige la sesión para que

le interesa que esté Encargado de realizar
los objetivos se cumplan.
construido el sistema. los entregables de la
Encargado de mediar en
Como su nombre lo indica, sesión. No contribuye en
las diferentes discusiones
proporciona recursos y los temas tratados en la
y dirigir al grupo para
apoyo al proyecto. Toma sesion jad.
cerrar cada tema tratado.
de decisiones.
Patrocinador Líder de sesión/

Analista
ejecutivo facilitador
Como su nombre lo Es la persona a la que

Una persona especialista indica, persona con le interesa que esté
en alguno o varios temas conocimiento en los construido el sistema.
tratados en la sesión, el sistemas de información Como su nombre lo indica,
cual pueda ser consultado de la empresa que pueda proporciona recursos y
durante ella. indicar a los usuarios qué apoyo al proyecto. Toma
es posible y qué no. de decisiones.
Representante Representantes
Especialista
de si de usuarios
Fuente: adaptado de [11], [17], [39].

• Preparación de la sesión de jad: como las técnicas anteriores, la preparación

de una sesión jad incluye la selección de los participantes, ya que ellos deben
ser personas que puedan aportar información útil para los analistas, además de
tener la disponibilidad y querer participar en el proceso [39]. Esto influye en la
fluidez y en el enfoque que pueda tener la sesión.
Otro de los aspectos para tener en cuenta es el número de sesiones que se
precisan en la organización para recolectar los requerimientos, el tiempo de cada
una y los entregables que se van a manejar durante una sesión. Por último, se
deben preparar los materiales que se van a utilizar durante la sesión [15].
• Sesión jad: al principio de una sesión jad se debe explicar de manera breve la
razón por la cual se lleva a cabo este tipo de encuentro, cómo se va a llevar a
cabo, los objetivos y el alcance de la reunión; además, si es necesario, establecer
las “reglas del juego” [17].
Después de una parte introductoria, se busca definir los requerimientos de nego-
cio y se inicia desde las preguntas más importantes: ¿cuál es el objetivo? ¿Cómo
la aplicación va a ayudar a la organización a futuro? [15]. Luego se empiezan a
definir requerimientos a partir de que estas preguntas, aparte de indagar sobre
las restricciones y supuestos. Con esto se busca comenzar a establecer el alcance
del sistema, dependiendo de los requerimientos que se acaban de definir y del
presupuesto de la organización [15].
La planeación del jad/diseño se realiza durante la sesión para establecer los
recursos necesarios para su ejecución, desde personal hasta documentos que se
requieran.
Por último, se concluye el tema para cerrar la sesión y se revisan los entre-
gables realizados durante el encuentro, para saber si todos están de acuerdo con
lo plasmado por el analista en los documentos o si se debe cambiar algo.
• Recapitulación de jad: el objetivo de esta fase es formalizar todos los entrega-

bles. Generalmente, se tienen diferentes plantillas que se utilizan para registrar
y llevar un historial de la información. Además, facilita la entrega de los reportes
a los diferentes stakeholders. Para tener una sesión jad exitosa, es necesario tener
en cuenta las siguientes recomendaciones [11]:
* Utilizar facilitadores con experiencia y conocimientos; de esta forma, se
asegura el cumplimiento de los objetivos dentro de un tiempo ya definido.
* Obtener el compromiso y apoyo del patrocinador ejecutivo. Es una de las
más importantes; sin este apoyo, es casi imposible que se disponga de los
participantes y de la información de la organización.
* Establecer claramente los objetivos, así se puede llevar el curso de la sesión

en esa dirección. Si en algún caso se llegara a desviar, es obligación del faci-
litador retomar el camino para cumplir con el objetivo.
* Contar con un programa detallado y seguimiento riguroso. Esto se debe a
que el tiempo es un recurso importante y costoso para la organización.
* Evitar usar el lenguaje técnico o reducir su uso.
* Producir el documento final rápidamente. Los entregables deben ser con-
cretos, ya que su elaboración debe realizarse durante la sesión para poder
revisarlo a final de ella.
Las sesiones jad son de utilidad ya que involucran stakeholders de todos los nive-
les, de esta forma se asegura capturar diferentes puntos de vista, desde las reglas de
negocio, su objetivo y estrategia hasta la perspectiva operativa del producto.
2.1.6.4. Lluvia de ideas (brainstorming )
Consiste en reunir a un grupo de personas en un lugar adecuado, a fin de que com-

partan sus ideas sin sentir temor alguno. La persona encargada de dirigir la reunión
debe anotar todas las ideas sin importar si son o no realizables [18], de manera
que muchas cobrarán fuerza y otras serán rechazadas al finalizar el ejercicio (cuan-
do los analistas estén revisando la información en privado). Este proceso necesita
dos tipos de participantes: el moderador, quien es parte del equipo de desarrollo,
y los stakeholders, seleccionados con anterioridad, teniendo en cuenta el análisis de
stakeholders.
Este tipo de actividades consiste en las siguientes fases:
1. Generación: en esta etapa, el participante debe compartir todas las ideas que
tenga sin discutirlas. Una herramienta poderosa para realizar todo el ejercicio
puede ser el uso de herramientas generadoras de mapas mentales, por ejemplo,
FreeMind [40], MindManager [41].
2. Agrupar ideas: se deben agrupar las ideas que estén relacionadas. Para esto es
recomendable solicitarle a uno de los stakeholders que realice esta actividad, con
el fin de que sea más efectivo. Se pueden crear grupos de ideas con rótulos, por
ejemplo, “nuevas funciones”, “mejoras de rendimiento”, “mejoras de caracterís-
ticas actuales”, entre otras [15].
3. Definir: para esto es necesario que el stakeholder que propuso cada idea la defi-
na brevemente, con el fin de generar entendimiento entre los participantes del
proceso [15].
4. Priorizar las ideas: cada stakeholder le da una valoración a cada una de las ideas,
de tal manera que se puedan clasificar; esto con el fin de ordenarlas desde la más
importante a la menos relevante [37].
El resultado de este proceso es una lista de requerimientos de usuario, ordenados

de acuerdo con la prioridad que estos le conceden a cada requerimiento, como la
que se muestra en la tabla 2.5.
Tabla 2.5. Resultado del proceso de lluvia de ideas
Reporte de posiciones
ID Descripción Votos
Rep1 El reporte debe mostrar las posiciones activas hasta la fecha 120
Rep2 El reporte debe mostrar el número de personas activas en dicha posición 110
El reporte debe mostrar el número máximo de personas permitidas para
Rep3 100
dicha posición
… … …
Al revisar cada una de las técnicas mencionadas, se puede observar que existen si-
militudes entre ellas. En la tabla 2.6 se encuentran las características más relevantes.
Tabla 2.6. Comparativo de técnicas de grupos
Criterio/
Talleres Grupos focales jad Lluvia de ideas
técnica
Depende de los objetivos de- Generalmente planean temas Dado que se inicia desde las Debido a que el tema son
finidos. Si se planea una se- específicos, donde su discu- reglas de negocio, puede lle- requerimientos de usuario,
sión larga, al igual que los sión toma más de 2 horas. gar a ser extenso. los ítems pueden ser diversos
Temas
jad , comenzarán desde las y largos; sin embargo, com-
(extensos)
reglas de negocio. parado con los talleres, los
temas no suelen ser tan ex-
tensos.
Todas las técnicas manejan roles, cada participante tiene unas tareas que debe cumplir dentro del tiempo establecido. De esta
forma se facilita la asignación de tareas y el cumplimiento de los objetivos. Algunos de los roles comunes para las técnicas son:
Participantes • Facilitador/moderador.
• Participantes (usuarios, clientes).
• Analista/documentador.
Costoso. El tiempo inverti- Comparado con jad o con los Técnica costosa. El tiempo Comparado con las demás
do y el perfil de las personas talleres, el tiempo de ejecu- invertido y el perfil de las técnicas, no se invierte tanto
necesarias pueden dificultar ción es menor; esto se debe personas necesarias pueden tiempo en su preparación y
Recursos
aplicar los talleres con éxito. a que el tema en una sesión dificultar tener una sesión jad ejecución, dado que suele ser
(tiempo y
suele ser específico y no son exitosa. un poco más flexible que las
participantes)
necesarios diferentes tipos de demás.
perfiles. De hecho, pueden
ser de la misma área.
Criterio/
Talleres Grupos focales jad Lluvia de ideas
técnica
Estas cuatro técnicas, comparten fases similares, las cuales son:
• Fase de preparación.
• Fase de ejecución.
• Fase de recapitulación.
Sin embargo, cada una difiere en la fase de ejecución. A continuación, se muestran características propias de cada una.
Debido a la diversidad de los La agenda de los grupos foca- Generalmente la agenda de El curso de la sesión se guía
temas que se van a tratar en les suele estar guiada por los una sesión jad es: por estos pasos:
Fases los talleres, suelen hacer ite- siguientes pasos: • Introducción. • Generación de ideas.
raciones entre ellos. A conti- • Introducción al tema. • Definición de requerimien- • Agrupación.
nuación, se muestra los pasos • Discusión. tos de negocio. • Priorización.
de la iteración: • Revisión de respuestas por • Definición del alcance del • Definición.
• Proposición. parte del moderador. sistema.
• Acción. • Conclusión a partir de las • Planeación del jad/design.
• Reacción. respuestas y comentarios • Documentación de pre-
• Reflexión. obtenidos. guntas y consideraciones.
• Conclusión.
Fuente: [11], [13], [15], [17], [24], [36]-[38].

Una vez analizados los stakeholders, realizadas las entrevistas, el brainstorming y

los talleres se pueden buscar otras fuentes que revelen requerimientos que no fueron
identificados previamente. Esas nuevas fuentes de requerimientos son:
• Experimentar la vida como los usuarios: una persona debería experimentar el traba-
jo que deben hacer los usuarios con un entrenamiento mínimo, cuando no son
trabajos de alto riesgo [24]. Puede ser útil para conocer el proceso general de la
organización y los flujos de información relacionados; pero no puede identificar
casos excepcionales o comportamientos extraños.
• Observaciones de los usuarios haciendo su trabajo: les permite a los analistas validar
la información ya recolectada, ya sea por los talleres, las entrevistas o los otros
métodos de colecta de requerimientos. También permiten identificar más temas
para nuevas entrevistas, “para ver problemas con el sistema actual e identificar
nuevas formas en las que el sistema puede soportar mejor el flujo de trabajo” [1].
• Prototipos: según Ian Alexander [24], tan pronto como se ve un modelo funcio-
nando, se pueden identificar características y funciones por mejorar. Por esto,
un simple prototipo puede ayudar a los clientes a aprobar los requerimientos o a
cambiar algunos de estos. Se debe recalcar que el prototipo es solo eso y no una
versión final, para que no existan malentendidos con los usuarios.
• Reportes de problemas y equipos de apoyo: estas son fuentes de los requerimientos, ya
que los equipos de apoyo y los reportes de problemas muestran las dificultades
a las que se han enfrentado o descubierto los usuarios del sistema actual [1].
• Instructores y consultores: ya que estas personas mantienen un contacto frecuente
con los usuarios y saben qué consideran los usuarios difícil de hacer [24].
• Documentos que describen el sistema actual o productos comparables y rivales: estos do-
cumentos pueden identificar posibles requerimientos que deben ser incluidos en
la solución, así como identificar posibles normas o legislación que sea aplicable
al producto [1], [8].
• Diseños y especificaciones existentes: esta fuente sirve para recolectar requerimientos
que se hayan pasado por alto o corregir aquellos que estén inconsistentes con
los documentos; en ese sentido, es importante recalcar que no necesariamente lo
especificado en un documento corresponde a la realidad de la organización [8].
• Sugerencias y críticas de los usuarios: una lista de sugerencias y críticas de los usua-
rios se debe utilizar para hacerle preguntas a estos y así identificar otros reque-
rimientos que no se hayan contemplado antes o llegar a la identificación de casos
de mal uso del producto [8], [24].
• Introspección: este método consiste en tratar de entender cuáles son las propie-
dades que los usuarios desean en el sistema, es decir, se debe imaginar cuál es
el tipo de sistema que quieren las personas que llevan a cabo ese trabajo con los
recursos facilitados [43].
Después de ejecutar las técnicas de recolección de requerimientos, se deberían

tener como resultado los siguientes artefactos o entregables:
• Lista con los requerimientos de negocio (véase sección “1.5.1. Requerimientos
de negocio”).
• Visión y alcance del proyecto.
• Identificación y análisis de stakeholders (véase sección “2.1.2. Análisis de stake-
holders”).
• Glosario con los términos utilizados por los stakeholders.
• Lista con los requerimientos de usuario (véase sección “1.5.2. Requerimientos
de usuario”).
2.1.7. Métodos participativos
Desde los inicios de la era informática se ha detectado un problema fundamental, al

entender la relación que existe entre la tecnología y las personas (usuarios, diseñado-
res, administradores, dueños, otros afectados): si el sistema falla, ¿es un problema de
la herramienta o del usuario? A lo largo de los años se han venido dando respuestas
cada vez más sofisticadas a esta pregunta que originaron el enfoque sociotécnico,
que no es exclusivo de los sistemas de software. Desde una perspectiva sociotécnica,
el problema no está en los aspectos humano-sociales ni en la tecnología, sino en la
relación (dinámica y evolutiva) entre los dos.
Este enfoque ha dado lugar a un imperativo a la hora de hacer ingeniería de
requerimientos: la participación. Si bien las herramientas y técnicas que hemos dis-
cutido en esta sección involucran otros actores de manera explícita (e. g., análisis de
stakeholders y técnicas para grupos), el imperativo participativo puede ir mucho más
allá hasta considerar a los usuarios (u otros stakeholders) codiseñadores del sistema,
no solo insumos de información para levantar requerimientos.
Desde esta tradición, se han propuesto diversos métodos que pueden acompañar el
ejercicio de la ingeniería de requerimientos o, incluso, todo el ciclo de vida del sistema.
Entre estas, tenemos la investigación-acción (participativa), la metodología blanda (o
suave) de sistemas y ethics. Quizá, justamente, la investigación-acción ha desatado
esta corriente de métodos: se pretende que haya un cambio o mejoramiento de un
sistema social, al tiempo que se construye teoría de manera cíclica [44]. Dado que se
trata de un proceso de inmersión en un contexto real, es inevitable y necesario que
se den espacios de diálogo y participación, donde tanto las acciones como las teorías
resultantes obedezcan a un proceso de construcción participativo.
Bajo esta filosofía, aparece ethics [45] como una de las contribuciones más influ-
yentes en el diseño participativo de los sistemas de información. Aquí la participación
se da con distintas intensidades y propósitos, dependiendo de la fase del proyecto.
En fases de ingeniería de requerimientos tiende a ser consultiva o representativa;
pero requiere consenso a la hora de llegar a acuerdos. Su diferencia fundamental
con otros enfoques está en que las necesidades se concentran en aspectos sociales
(satisfacción y calidad de vida), en lugar de solo técnicos (eficiencia de la solución).
Por su parte, Checkland y Scholes [46] definen la metodología suave de sistemas
como una que busca mejorar áreas de interés social, activando un ciclo de aprendi-
zaje para la gente involucrada en la situación; ciclo que idealmente no tiene fin. El
aprendizaje se lleva a cabo mediante un proceso iterativo de uso reflexivo de con-
ceptos de sistemas y debate en torno a las percepciones sobre el mundo real. Las
ideas de sistemas se usan para organizar el pensamiento respecto de una situación
problemática, lo cual le permite al analista enfocarse en la formulación de problemas
y en qué se debe hacer, en vez de en la solución misma del problema. El proceso
de la metodología suave de sistemas se divide en dos corrientes principales: la in-
vestigación lógica y el análisis cultural. La primera consiste en seleccionar sistemas
relevantes, nombrar los sistemas relevantes escogidos, construir los modelos de los
sistemas escogidos y comparar estos modelos con la realidad percibida. La segunda,
entre tanto, se enfoca en el análisis de la intervención, el análisis del sistema social y
el análisis del sistema político. Para obtener una visión general del weltanschauungen
(concepción o visión del mundo, en alemán), la situación es percibida mediante el
contraste de diferentes puntos de vista, a fin de alertar a los analistas para que cues-
tionen el análisis en busca de señales de regularidad y permanencia en los datos y
actividades asociadas; pero también está abierto a cualquier área de la organización.
La expresión del entendimiento de la situación promueve el uso de cualquier técnica
o modelo; por ejemplo, el uso de un diagrama ilustrativo (rich picture), que facilite
un mejor proceso de comunicación entre los profesionales de la información y los
clientes del sistema que se va a mejorar.
2.2. Análisis
Esta etapa de la ingeniería de requerimientos tiene como fin entender las necesida-
des globales de los usuarios, las cuales son identificadas en la etapa de recolección
(véase sección “2.1. Recolección”) y se ven reflejadas en los artefactos o entregables
que surgen de este proceso, para hacer una descomposición que especifique dichas
necesidades globales en sentencias más simples que proporcionen las bases para
determinar los requerimientos del sistema [6].
El análisis de los requerimientos puede tornarse complicado, debido a que las
necesidades de todos los usuarios deben incluirse, lo cual puede generar conflictos
si alguno de estos origina ambigüedades con uno o más de los requerimientos espe-
cificados. Además de esto, es preciso tener en cuenta que el análisis es la base de la
calidad del producto final, ya que es fundamental para un diseño exitoso [47]. Por
esto, el análisis de requerimientos tiene los siguientes objetivos:
1. Llegar a un entendimiento entre los stakeholders del proyecto.
2. Identificar objetivos y metas del proyecto y del producto.
3. Detectar y resolver los conflictos entre los requerimientos.
4. Definir los límites del software y cómo este va a interactuar con su entorno.
5. Especificar los requerimientos del sistema (véase sección “3.1. Especificación de
requerimientos”).
6. Proveer las bases para la verificación y validación del sistema (véase sección “3.2.
Validación y verificación”).
El análisis también es útil para representar algunos de los requerimientos de

múltiples maneras, un ejemplo de ello es la representación gráfica. Estos puntos de
vista diferentes pueden revelar ideas y problemas que no puede proporcionar una
sola vista o modelo [1]. Para cumplir con los objetivos anteriores, es necesario de-
sarrollar las siguientes prácticas:
1. Definir cuáles son los pasos que se deben cumplir para que los miembros del
proyecto acopien los requerimientos [48].
2. Establecer los requerimientos teniendo en cuenta los diferentes tipos existentes
[5] (véase sección “1.5. Tipos de requerimientos”).
3. Reconocer las entradas [47]: se deben tener como entradas para el proceso de
análisis los artefactos que resultan de la recolección de requerimientos (véase
sección “2.1. Recolección”).
4. Proyectar el diagrama de contexto. Es un modelo de análisis sencillo que per-

mite definir límites e interfaces entre el sistema que se está desarrollando y las
entidades externas [1]. Para hacer este diagrama la herramienta más utilizada
son los casos de uso.
5. Analizar la viabilidad de los requerimientos, evaluando la factibilidad de imple-
mentar cada requerimiento, teniendo en cuenta el costo y el rendimiento en el
sistema.
6. Comprender los riesgos asociados con la implementación e implantación de cada
requerimiento.
7. Dar prioridad a los requerimientos (véase sección “4.2.1.2. Priorización”).
8. Modelar los requerimientos. Un modelo de análisis gráfico muestra los reque-
rimientos a un alto nivel alto de abstracción, en contraste con el detalle que
se espera encontrar en un Software Requirements Specification (srs) [1]. Gracias a
estos modelos se pueden descubrir requerimientos incorrectos e inconsistencias
entre ellos.
9. Crear un diccionario de datos o modelo del dominio. Esto permite a los stakehol-
ders manejar el mismo vocabulario y facilitar así la comunicación, además de la
consistencia en los diferentes modelos [17].
10. Asignar requerimientos a los subsistemas. Véase sección “4.2.2.1. Localización”.
11. Resolver las siguientes preguntas [47]:
• ¿Cuáles son las razones por la cuales se debe desarrollar el sistema?
• ¿Quiénes son los clientes y cuáles son las expectativas que tienen respecto al
sistema?
• ¿Qué experiencia tienen los clientes con sistemas similares?
• ¿Cuáles son las características del ambiente donde debe funcionar el sistema?
• ¿Cuáles son las funcionalidades del sistema, en términos del cliente?
• ¿Cuáles son las restricciones de hardware, software y económicas que se tienen
para desarrollar el sistema?
En esta fase pueden usarse diferentes herramientas que apoyan las buenas prác-
ticas mencionadas, por ejemplo: Data Flow Diagrams (dfd) [17]; modelos entidad-
relación; diagramas de uml, como son los diagramas de estado, de actividad, de
secuencia, de colaboración, de clases, etc., e incluso uso de modelos de procesos en
notación del tipo Business Process Management Notation (bpmn), con el fin de ilustrar
los procesos realizados por los actores y el sistema en contexto de un objetivo de
negocio. A continuación, se describen brevemente algunas de estas herramientas.
2.2.1. Casos de uso
Para entender las necesidades que debe suplir el sistema, se encuentran las historias
de usuario (user stories) y los casos de uso. La primera tiene su origen en las metodo-
logías ágiles como el caso de Extreme Programming, en particular en el llamado
juego de la planeación, donde por medio de historias de uso de la aplicación y apo-
yados por un prototipo (véase sección “2.1.5. Prototipos”) se recolectan y analizan
los requerimientos [17].
Los casos de uso son “ampliamente aceptado(s) para la captura de requerimientos
para desarrollo de software orientado a objetos” [49], ya que permiten enfocarse
en qué hace el sistema; además, permiten a los miembros del equipo de desarrollo
entender cómo debe funcionar el sistema, al construir y documentar un modelo que
describe todas las formas en las que los stakeholders lo utilizaran [50]. Esta descrip-
ción es realizada en un lenguaje natural y muestra toda la funcionalidad del sistema.
El diagrama de los casos de uso muestra la relación existente entre los actores
y los casos de uso del sistema. Para definir estos casos es necesario identificar los
siguientes elementos [51]:
• Actores: se pueden extraer del análisis de stakeholders, ya que son las personas, las
organizaciones o los sistemas externos que interactúan con el sistema.
• Límites del sistema: se pueden extraer de los artefactos que surgen de la recolec-
ción de requerimientos, ya que se debe identificar cuál es el alcance y los límites
que separan al sistema de su ambiente.
• Casos de uso: es una descripción de la secuencia de interacciones que se produce
cuando un actor ejecuta una funcionalidad del sistema. Para hacer describir cada
caso de uso se deben utilizar los requerimientos de usuario (véase sección “1.5.2.
Requerimientos de usuario”) obtenidos en el proceso de recolección.
• Relaciones: estas permiten identificar qué casos de uso necesitan de otros casos
de uso para cumplir sus funciones.
Una vez terminado el modelado de casos de uso, se genera uno de los entregables
de esta etapa de análisis de requerimientos: el documento de casos de uso, por medio
del cual los analistas identifican los requerimientos del sistema, que se expresan en
tres diferentes vistas que se describen a continuación:
• Vista operacional [50]: hace referencia a cómo debe funcionar el sistema, donde
se deben tener en cuenta condiciones como: “qué tan bien” o “bajo qué circuns-
tancias”. Esta vista identifica las necesidades operacionales, las condiciones y
eventos a los que debe responder el sistema, las restricciones operacionales y las
condiciones desde las cuales este interactúa con otros. Esta vista representa los
requerimientos no funcionales del sistema (véase sección “1.5.5. Requerimientos
no funcionales”).
• Vista física: hace referencia a cómo debe ser construido el sistema.
• Vista funcional: pone el relieve en qué debe hacer el sistema para satisfacer el
comportamiento operacional descrito. Esta vista muestra las funciones del sis-
tema, las restricciones de desempeño, las tareas o acciones que se deben realizar,
es decir, la vista representa los requerimientos funcionales (véase sección “1.5.4.
Requerimientos funcionales”).
Para finalizar el proceso de análisis de requerimientos, el documento debe incluir

los insumos necesarios para especificar requerimientos (véase sección “3.1. Especi-
ficación de requerimientos”), teniendo en cuenta que los requerimientos durante el
análisis ya fueron priorizados y localizados:
• Lista de requerimientos de negocio.
• Lista de requerimientos de usuario.
• Diagrama de casos de uso.
• Lista de requerimientos del sistema.
2.2.2. Data Flow Diagrams
Los dfd son una técnica que apareció en los años setenta, inspirada en el paradigma
transaccional y procedimental, creada por Edward Yourdon [17]. Esta técnica per-
mite construir modelos de los procesos de una organización con diferentes niveles
de detalle y son particularmente útiles para identificar los flujos de información que
es usada, transmitida o manipulada por el sistema [38].
Los modelos dfd se caracterizan por incluir los siguientes elementos [17], [39]:
• Procesos: que representan el trabajo que se realizará (con diferentes niveles de gra-
nularidad) y que, a su vez, transforma o procesa información (datos) (figura 2.11).
Figura 2.11. Representación de un proceso
Proceso
Fuente: [17].
• Almacenes de datos: corresponden a grupos consistentes de datos que son al-

macenados para uso de los procesos (entiéndase como archivos, bases de datos,
etc.) (figura 2.12).
Figura 2.12. Representación de un almacén de datos
Almacén de datos
Fuente: [17].
• Entidades externas: son personas o entidades organizacionales u otros sistemas

externos al sistema que se está modelando (figura 2.13).
Figura 2.13. Representación de una entidad externa
Entidad externa
Fuente: [17].
• Flujos de información: corresponden a enlaces dirigidos que indican flujo de in-

formación entre los elementos mencionados anteriormente (figura 2.14).
Figura 2.14. Un dfd completo
Entidad externa 1 Almacén de datos 2

Proceso 1
Proceso 2 Proceso 4 Proceso 5
Almacén de datos 1
Entidad externa 2
Proceso 3
Fuente: [17].
La construcción de este modelo incluye la creación de diferentes dfd que in-

dican los distintos niveles de granularidad esperados de los procesos desde que se
ve un único proceso que representa el sistema (figura 2.15) que se está modelando
hasta múltiples modelos que representan actividades y tareas más refinadas que son
realizadas por el sistema. La figura 2.16 muestra un diagrama de nivel 1 donde se
observan los procesos más relevantes del sistema que se va a modelar.
Figura 2.15. Diagrama de contexto o cero
Entidad externa 1 Entidad externa 2
Proceso 1
Entidad externa 2 Entidad externa 2
Fuente: [17].
Figura 2.16. Diagrama de nivel 1
Cliente
Crear orden
Verificar
tarjeta de
crédito
Cambiar
información Orden Información
de cuenta aprobada financiera
Proveer
información
Entidad financiera
Mantener Procesar
información orden
de cliente
Información de clientes
Fuente: [17].
Adicionalmente, los modelos dfd pueden representar procesos lógicos. Se en-

tiende con esto lo que hacen las personas y la información que es manipulada, hasta
llegar al detalle físico que indica detalladamente qué hace el sistema analizado en
contexto del negocio [17], [39].
Los dfd, dada su naturaleza y origen en el paradigma de la programación es-
tructurada, están enfocados en identificar las estructuras de información y los pro-
cesos que las transforman; por esto, además de la documentación de los modelos,
es importante construir un diccionario de datos, que finalmente será el precursor
de un modelo entidad-relación que modele los datos del sistema propuesto (véase
sección “2.2.4. Entidad-relación”).
2.2.3. Modelos estáticos
Un modelo estático es aquel donde la variable del tiempo no se tiene en cuenta.

Como lo menciona Larman, “es como una fotografía instantánea del sistema en un
punto fijo del tiempo” [50], donde el objetivo es mostrar los elementos involucrados
en el sistema y sus relaciones; mientras que el flujo de información o la generación
de eventos son representados por modelos dinámicos (véase sección “2.2.6. Otros
modelos”).
Un modelo estático útil es el diccionario de datos, que “es una obra de consul-
ta con información acerca de los datos” [17], también llamados metadatos. Los usa
el grupo de trabajo para el conocimiento de los diferentes conceptos utilizados en el
negocio, durante el desarrollo del proyecto. Los diccionarios de datos pueden incluir
información sobre [17]:
• Almacenes de datos
• Flujos de datos
• Estructuras de datos
• Elementos de datos
Los diccionarios de datos son útiles principalmente para validar la integridad de los
flujos de datos, dado que una de las principales fuentes de los diccionarios de datos son
los diagramas de flujos de datos. También es utilizado para la elaboración de formatos
de pantalla o reportes y puede ayudar a la definición de los datos almacenados [52].
Los diccionarios de datos describen los contenidos de los flujos de datos y alma-
cenes de datos. En la figura 2.17 se muestra la relación que tienen los elementos de
un diccionario de datos y de dónde pueden provenir.
Figura 2.17. Relación de los diccionarios de datos con flujos de procesos y almacenes de datos
Flujo de datos Forma de

descripción de Estructura Elemento
flujo o almacén de datos de datos
Almacén de datos de datos
Fuente: [17].
A continuación, se presenta una breve descripción de cada una de las fuentes

del diccionario de datos [17]:
• Almacenes de datos: como su nombre lo indica, contiene información de los
datos que van a ser almacenados. Estos provienen, en su mayoría, del diagrama
de flujo de datos.
• Flujos de datos: es una de las principales fuentes para el diccionario de datos [17],
pues a través de estos se pueden determinar los elementos de entrada y de salida
de información al sistema. Esta información es obtenida a través de documen-
tos, formularios, entrevistas y observación de los usuarios. Como la figura 2.17
muestra, puede estar compuesta de estructuras de datos.
• Estructuras de datos: son un conjunto de elementos de datos organizados de tal
forma que el analista puede ver la información referente a cada elemento que
los compone. Para esto existe una notación para describir las estructuras de da-
tos. (Para mayor información sobre la notación véase el libro Análisis y diseño de
sistemas, de Kendall y Kendall [17])
• Elementos de datos: presentan las características propias de los elementos de
datos. Pueden ser utilizados en más de una estructura, que a su vez puede usarse
en un flujo o almacén de datos (figura 2.17). Las características pueden ser físicas
o lógicas, unos ejemplos de las características son:
* Físicas: tipo de dato, longitud, rango.
* Lógicas: nivel de acceso, relaciones.
Actualmente, con ayuda de las herramientas de ingeniería de software asistida

por computador (case, por su sigla en inglés) el desarrollo de un diccionario de datos
es más rápido, además que los problemas de integridad y consistencia disminuyen,
ya que se tiene centralizada la información y su búsqueda es más fácil.
2.2.4. Entidad-relación
Un diagrama entidad-relación presenta los datos de un sistema u organización [39],

el cual se compone de entidades y las relaciones existentes entre ellos. La entidad “es
un objeto de mundo real que es distinguible de todos los demás” [53], por ejemplo,
un cliente o un producto. Cada entidad tiene atributos que representan las propie-
dades, como un nombre o un identificador. Existen tres conjuntos de atributos: los
simples y compuestos, los monovalorados y multivalorados y los derivados. Ade-
más, una entidad puede estar relacionada con otras entidades (existen tres tipos de
relaciones: uno a uno, uno a muchos, muchos a muchos) [54].
En la figura 2.18 se presentan los pasos propuestos para realizar un diagrama
entidad relación [53], [54]:
Figura 2.18. Pasos para el diseño de un diagrama entidad-relación
Valores
Mundo real
Análisis de
requerimientos
Modelado conceptual
Esquema Modelo
conceptual conceptual
Sistema de gestión
de bases de datos
Diseño lógico
Esquema Modelo
lógico representación
Diseño físico
Esquema Modelo físico

interno

1. Análisis de requerimientos: el objetivo de este análisis es identificar qué entidades

deberían ir dentro del diagrama entidad-relación; además de los atributos de ca-
da entidad. Para esto se aplican diferentes técnicas de recolección (véase sección
“2.1. Recolección”) para así saber qué información se requiere, cada cuánto se
necesita y su relación con otros conceptos.
2. Diseño conceptual: con la información recolectada se diseña el modelo entidad-
relación, que es la representación conceptual de la base de datos. Este diseño es
de alto nivel, lo cual permite tener claridad en la información del negocio.
3. Diseño lógico: se debe escoger un sistema de gestión de bases de datos y a partir
del diseño conceptual realizado en el paso anterior se obtiene un esquema de la
base de datos.
4. Diseño físico: en este paso se puede refinar el diseño lógico de la base de datos,
que se obtuvo del paso anterior con ayuda de las normalizaciones que existen
(1nf, 2nf, 3nf). Para eso, “se debe tener en consideración las cargas a soportar”
por la base de datos, de modo que cumpla con los requerimientos de desempe-
ño. Además, el ingreso de “índices puede implicar un rediseño importante del
esquema obtenido de los pasos anteriores”.
5. Revisión: se debe llevar a cabo la respectiva revisión con los stakeholders, y si es
necesario, refinarlo hasta que todos estén satisfechos con el diseño y este cumpla
con los requerimientos definidos en el proyecto.
2.2.4.1. Modelo del dominio
El modelo de dominio se usa en el análisis y diseño orientado por objetos, y en este se

relacionan los objetos en el dominio del sistema entre sí; además, se definen los con-
ceptos y términos que va a manejar en el sistema. Los objetos en el modelo pueden
ser abstractos (conceptos) y físicos (objetos) [50].
Para realizar un modelo del dominio hay que tener en cuenta diferentes concep-
tos del sistema, como son [48]:
• Actores
• Eventos
• Transacciones
• Objetos (físicos):
* Contenedores
* Otros sistemas
* Organizaciones
• Especificación de conceptos
En la figura 2.19 se muestran los diferentes elementos del modelo del dominio,
los cuales pueden representar los conceptos del sistema mencionados.
Figura 2.19. Elementos del modelo del dominio
Relación y dirección de lectura
Rol Tiene 1
Clase 1 Clase 2
n
+ Responsabilidad 1 ()
Herencia
(Es-Un)
Cardinalidades
Clase 3
Para la elaboración del modelo del dominio, hay que tener en cuenta diferentes
aspectos. A continuación, se mencionan los ítems más relevantes dentro de este
diagrama [50]:
• Abstracciones: son un concepto. Serán modeladas como una entidad dentro del
dominio del sistema. Se debe tener en cuenta que esta entidad tiene unas respon-
sabilidades que serán asignadas para determinar su comportamiento.
• Responsabilidades (conocimiento, comportamiento): como se mencionaba, las
abstracciones tienen unas responsabilidades que pueden ser del tipo conocimien-
to o comportamiento, donde se determina si la abstracción o entidad mantiene
información sobre algo en específico o deben realizar algunas funcionalidades.
• Relaciones: las abstracciones o entidades tienen relaciones entre ellas para poder
ejecutar cualquier escenario del sistema. En el modelo del dominio se manejan
dos tipos de relaciones: asociaciones y generalización.
2.2.5. Modelos de decisión
2.2.5.1. Árboles de decisión
Los árboles de decisión son una técnica que permite considerar diferentes condiciones
o acciones y la manera en la que las decisiones deben tomarse, así como las conse-
cuencias que estas conllevan. También permiten generar una estructura con la cual
los analistas de requerimientos investigan posibles resultados y visualizan los riesgos

y beneficios que se obtienen de las decisiones tomadas sobre los requerimientos [56].
Las partes que componen un árbol de decisión son:
• Raíz: es el nodo principal del árbol; de este se despliegan todas las posibles ac-
ciones que se van a realizar.
• Nodos: son los puntos en los cuales se debe tomar la decisión.
• Ramas: representan las posibles acciones que se pueden tomar.
Para construir un árbol de decisión (figura 2.20) se puede utilizar el siguiente

proceso [17]:
1. Definir el nodo raíz.
2. Dibujar un círculo que representa la decisión que se va a tomar; estos represen-
tan los nodos del árbol.
3. A partir del círculo, dibujar las líneas que representan todas y cada una de las
acciones que se pueden llevar a cabo; estas líneas son las ramas del árbol.
4. Escribir las opciones; una en cada línea.
Si de la opción resulta una nueva decisión, se repite el proceso; si no, se describe

la respuesta final.
Figura 2.20. Árbol de decisión
Acción 1
Nodo de decisión
Acción 2
Alternativa 1
Acción 3
Nodo raíz
Alternativas de decisión
Alternativa 2
Fuente: [58].
Las ventajas de realizar un árbol de decisión son las siguientes:

• Se comprenden cuáles son las consecuencias de una decisión tomada.
• Explica cuál es el procedimiento respecto a una decisión tomada.
Al finalizar la construcción del árbol de decisiones, se evalúa. Para esto, es nece-

sario asignarle un costo a cada una de las opciones de una decisión. Se pueden utilizar
porcentajes o fracciones, lo importante es que si se utilizan los porcentajes, la suma
total de las opciones de cada decisión llegue al ciento por ciento, y si son fracciones,
que esta suma total sea uno [57]. En la figura 2.21 se muestra un ejemplo de un
árbol de decisión sobre la compra de un libro.
Figura 2.21. Evaluar un árbol de decisión
Novedades
0,5
Géneros Ficción
0,2
0,3
Librería Terror
¿Dónde? Clásicos
0,6
Feria
Sí 0,4 Usados
¿Hay dinero suficiente?
Romance
0,3
No Géneros Ficción
0,3
Sí 0,4
Ir a la biblioteca Terror
No

2.2.5.2. Tablas de decisión
Una tabla de decisión es una herramienta que evalúa un conjunto de condiciones y

acciones que se deben tomar de acuerdo con el valor que adquiere cada una de estas
condiciones. La tabla de decisión cuenta con una matriz de condiciones, en la cual se
describen todas las situaciones que se pueden presentar; una matriz de reglas, la cual
se refieren a los posibles valores que pueden adoptar las condiciones, y una matriz de
acciones, que reúne el proceso o los pasos que se deben seguir, si se presenta alguna
de las condiciones. La figura 2.22 muestra cómo se distribuyen las matrices en la
tabla de decisiones.
Figura 2.22. Componentes de las tablas de decisión
Condiciones Entrada de
condiciones
Acciones Entrada de
acciones
Fuente: adaptada de [58].
Para llenar la tabla de decisión se sugiere la siguiente secuencia de pasos [57], [58]:
1. Identificar cuáles son las condiciones que afectaran las decisiones. Las condiciones
son aquellos acontecimientos que pueden llegar a suceder o no.
2. Determinar cuáles son las posibles acciones para llevar a cabo. Las acciones son las
actividades que se derivan de las condiciones que se identifican en el primer paso.
3. Ubicar las condiciones y acciones en los respectivos cuadrantes de la matriz. Se re-
comienda seguir las siguientes consideraciones en el momento de llenar la matriz:
a. Tener en cuenta las condiciones y acciones que, descritas de diferentes mane-
ras, tengan el mismo significado. Estas deberían expresarse como una sola
condición o acción.
b. Si existen dentro de la lista de condiciones, sentencias que representen lo
opuesto, por ejemplo, mayor y menor. Solo debe tenerse en cuenta una de
ellas, puesto que, al negarla, se obtendrá automáticamente la otra.
4. Una vez se obtiene la lista de condiciones y la lista de acciones, construir las re-
glas. Estas se obtienen de la fuente sobre la cual se obtuvieron las condiciones y
las acciones. Las reglas pueden tener tres valores: S = la condición se cumple;
N = define que la condición no debe o no se cumple e I = indiferencia, es decir,
no afecta el proyecto si esa condición se cumple o no.
Al finalizar el proceso, la tabla de decisión debe quedar de la siguiente manera

(tabla 2.7):
Tabla 2.7. Decisión final
1 2 3
Dinero suficiente S S N
Ir a la librería S N N
Ir a la feria N S N
Ir a la biblioteca N N S
Comprar novedades X - -
Leer terror X X X
Comprar usados - X -
Comprar clásicos X X -
2.2.6. Otros modelos
La notación uml propuesta por el Object Management Group [59] presenta una
serie de modelos que comunican, diseñan y apoyan el proceso de análisis desde el
punto de vista dinámico. En particular, podemos mencionar los diagramas de acti-
vidad, de secuencia, de colaboración y de estado.
2.2.6.1. Diagramas de actividad
Los diagramas de actividad describen secuencias de actividades, bien sea de un

proceso de negocio o de un sistema; al igual que permiten mostrar actividades en
paralelo y formalizar casos de uso [60]. Los componentes de estos diagramas son:
• Acciones: representadas por rectángulos con esquinas redondeadas. Dentro de

estos se encuentra una expresión que indica la acción que se realiza (figura 2.23).
Figura 2.23. Actividad
Pagar orden
• Decisiones: representa rutas alternativas (dos o más) que puede tomar un proceso,
representada por condiciones que son cumplidas por una u otra ruta (figura 2.24).
• Sincronización (paralelismo): indica cuando más de dos acciones o flujos de ac-
ciones deben iniciar o terminar al mismo tiempo (figura 2.25).
Figura 2.24. Decisión Figura 2.25. Sincronización
[Condición 1]
Generar orden
Pagar orden
Pagar Procesar
[Condición 2] orden bodega
Entregar orden

• Swimlanes (calles): usadas para indicar quién o qué entidad realiza las acciones.
Esto ayuda a comprender mejor los procesos de negocio o flujos de trabajo en
una organización. La figura 2.26 presenta un flujo de trabajo que es realizado
por tres entidades: cliente, ventas e inventario; también se pueden observar rec-
tángulos que indican artefactos creados o generados durante la ejecución de una
actividad, que a su vez son usados por otra (order).
Figura 2.26. Flujo de trabajo
Cliente
Paga el pedido Recoge el pedido
Solicita un
pedido
Pedido Pedido
(Realizado) (Entregado)
Ventas
Entregar el pedido
Toma el pedido
Pedido Pedido
(Ingresa) (Completo)
Inventario
Completar pedido
Fuente: adaptado de ejemplos JDeveloper [61].
2.2.6.2. Diagramas de estado
Representan gráficamente los comportamientos o los cambios en el estado y ciclo

de vida (creación, ejecución y destrucción) de un objeto (en el contexto de la pro-
gramación orientada a objetos). En sí mismo es una representación de un autómata
finito, en el cual los nodos corresponden a estados y los arcos que unen los nodos
representan las transiciones entre estados, que son a su vez “disparados” por un
evento (figura 2.27) [60].
Figura 2.27. Ejemplos de un diagrama de estados
Inicio Fin
Evento
En la estantería
Verificar () [Buen Estado]

Transición
Estado
Tomar prestado ()
En préstamo En préstamo
Verificar () [Mal estado]
2.2.6.3. Diagramas bpmn
Los modelos bpmn son similares en notación a los diagramas de actividad, pero su
principal objetivo es describir los procesos de negocio, caracterizados por actividades
(elementos activos, consumen tiempo y cambian de estado), eventos (representan
condiciones y no consumen tiempo), objetos (representan información u objetos
físicos), actores (quienes ejecutan las acciones o quienes consumen el resultado del
proceso) [62]. Este modelo tiene como principal objetivo describir cómo funciona
la organización de cara al cliente, lo que permite, además, refinar descripciones de
los stakeholders, sus responsabilidades y su conocimiento. Su uso se ha extendido es-
pecialmente en la descripción y definición de requerimientos de negocio.
Referencias
Press, 2013.
[2] K. Wiegers, More about Software Requirements: Thorny Issues and Practical Advice,
[4] Real Academia Española, Diccionario de la lengua española. [Online]. Disponible:
http://dle.rae.es/?w=diccionario. [Consultado: 29-mar-2017].
[5] S. Lauesen, Software Requirements: Styles & Techniques, 1.a ed. Harlow: Addison-
[6] R. R. Wright, “Guidelines for Successful Acquisition and Management of
Software-Intensive Systems: Weapon Systems”. [Online]. Disponible: https://
acc.dau.mil/CommunityBrowser.aspx?id=18602. [Consultado: 05-abr-2017].
[7] B. Nuseibeh y S. Easterbrook, “Requirements engineering: A roadmap”, en
Proceedings of the Conference on the Future of Software Engineering, 2000, pp. 35-46.
[8] I. Alexander y L. Beus-Dukic, Discovering Requirements: How to Specify Products
and Services. West Susex, Inglaterra: John Wiley & Sons, 2009.
[9] World Wild Foundation, “Cross-Cutting Tool, Stakeholder Analysis”. Oct.
2005. [Online]. Disponible: https://www.google.com.co/url?sa=t&rct=j&q
=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiO4N
W16e3VAhVCSiYKHTYqDhcQFggrMAA&url=http%3A%2F%2Fwww.
panda.org%2Fstandards%2F1_4_stakeholder_analysis&usg=AFQjCNFuC
vkaDhQKxynpEHznM9yJj8MKYA
[10] N. Rozanski y E. Woods, Software Systems Architecture: Working with Stakeholders
Using Viewpoints and Perspectives, 1.a ed. Upper Saddle River, NJ: Addison-
[11] H. Sharp, A. Finkelstein y G. Galal, “Stakeholder identification in the
requirements engineering process”, Proceedings of 10th International Workshop on
Database & Expert Systems Applications (dexa), set. 1999. [Online]. doi: http://
doi.ieeecomputersociety.org/10.1109/DEXA.1999.795198
[12] R. F. Goldsmith, Discovering Real Business Requirements for Software Project Success.
Norwood, MA: Artech House, 2004.
[13] K. Baxter y C. Courage, Understanding Your Users: A Practical Guide to User
Requirements Methods, Tools, and Techniques, 1.a ed. San Francisco, CA: Morgan
Kaufmann, 2005.
[14] O. Schibi, Managing Stakeholder Expectations for Project Success: A Knowledge

Integration Framework and Value Focused Approach. Plantation, FL: J. Ross
Publishing, 2013.
[15] S. Raghavan, G. Zelesnik y G. Ford, “Lecture notes on requirements
elicitation”. [Online]. Disponible: http://resources.sei.cmu.edu/library/asset-
view.cfm?assetID=12015. [Consultado: 29-mar-2017].
[16] P. M. Ginter, W. J. Duncan y L. E. Swayne, Strategic Management of Health Care
Organizations, 7.a ed. Chichester, UK: John Wiley & Sons, 2013.
[17] K. E. Kendall y J. E. Kendall, Análisis y diseño de sistemas. Madrid: Pearson
Educación, 2005.
[18] M. G. Christel y K. C. Kang, “Issues in requirements elicitation”, dtic
Document, 1992.
Chichester, UK: John Wiley & Sons, Inc., 1997.
Springer, 2010.
[21] Ludwig Consulting Services, “Interviewing User-Tips”. 2009. [Online].
Disponible: http://www.jiludwig.com/Interviews.html. [Consultado:
29-mar-2017].
[22] E. Derby, “Building a Requirements Foundation with Customer Interviews”.
7 de junio de 2010. [Online]. Disponible: http://www.estherderby.
com/2010/06/building-a-requirements-foundation-with-customer-
interviews.html. [Consultado: 29-mar-2017].
[23] Changing Minds, “Open and Closed Questions”. [Online]. Disponible: http://
changingminds.org/techniques/questioning/open_closed_questions.htm.
[Consultado: 29-mar-2017].
[25] Construx, “Software Development Resources”. [Online]. Disponible: http://
www.construx.com/ResourceLandingPage/. [Consultado: 29-abr-2017].
[26] Explorable, “Analysis and Handling Survey Data”. [Online]. Disponible:
https://explorable.com/handling-survey-data. [Consultado: 17-may-2017].
[27] H. Jonasson, Determining Project Requirements: Mastering the babok® and the
cbap® Exam, 2.a ed. Boca Ratón: Auerbach Publications, 2012.
[28] University of Texas, “Analyzing Survey Data”, Faculty Innovation Center,
2017.
[29] C. Peters, “How to Design and Analyze a Survey”. [Online]. Disponible:

https://zapier.com/learn/forms-surveys/design-analyze-survey/. [Consultado:
17-may-2017].
[30] International Institute of Business Analysis, “babok Guide” [Online]. Disponible:
https://www.iiba.org/babok-guide.aspx. [Consultado: 20-feb-2017].
pp. 44-48, 1999.
[32] N. R. Mead. “Requirements Elicitation Introduction”. [Online]. Disponible:
http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=297238.
[Consultado: 05-abr-2017].
[33] A. Chen y J. Beatty, Visual Models for Software Requirements, 1.a ed. Redmond,
WA: Microsoft Press, 2012.
[34] Rational Software Corporation, “Work Guidelines: Requirement Workshop”.
[Online]. Disponible: http://sce.uhcl.edu/helm/rationalunifiedprocess/process/
workguid/wg_rqwsh.htm. [Consultado: 29-mar-2017].
[35] E. Gottesdiener, “Requirements Workshops: Collaborating to Explore User
Requirements”, StickyMinds, 8 de marzo de 2012. [Online]. Disponible:
https://www.stickyminds.com/article/requirements-workshops-collaborating-
explore-user-requirements. [Consultado: 29-mar-2017].
[36] ebg, “More Info on Workshops”. [Online]. Disponible: https://www.
ebgconsulting.com/about/
[37] T. C. Corner, “Six Steps for Executing Successful erp Requirements Workshops”,
Panorama Consulting Solutions, 9 de junio de 2010. [Online]. Disponible:
https://www.panorama-consulting.com/six-steps-for-executing-successful-
erp-requirements-workshops/
[38] E. Gottesdiener, “Requirements by Collaboration”. 2003. Disponible: https://
www.ebgconsulting.com/Pubs/Articles/ReqtsByCollab-Gottesdiener.pdf
[39] J. Whitten y L. Bentley, Systems Analysis and Design Methods, 7.a ed. Boston:
McGraw-Hill/Irwin, 2005.
[40] FreeMind, “Main Page”. [Online]. Disponible: http://freemind.sourceforge.
net/wiki/index.php/Main_Page. [Consultado: 29-mar-2017].
[41] mindjet. “Mind Mapping Software for Visualizing Ideas”, 01-abr-2015.
[Online]. Disponible: https://www.mindjet.com/. [Consultado: 29-mar-2017].
Piscataway, NJ: ieee Computer Society, 2014.
[43] J. A. Goguen y C. Linde, “Techniques for requirements elicitation”, en

Requirements Engineering, 1993, Proceedings of ieee International Symposium on,
1993, pp. 152-164.
[44] E. Mumford, “Advice for an action researcher”, Inf. Technol. People, vol. 14, no. 1,
pp. 12-27, mar. 2001.
[45] E. Mumford, Designing Human Systems for New Technology: The ethics Method.
Manchester: Manchester Business School, 1983.
[46] P. Checkland y J. Scholes, Soft Systems Methodology in Action. Nueva York:
Wiley, 1999.
[47] Department of Defense Systems Management College, Systems Engineering
Fundamentals, 2001.
[48] New York State, New York State Project Management Guidebook: Release 2. Albany,
NY: New York State Office for Technology, 2003.
[49] R. Biddle, J. Noble y E. Tempero, “Essential Use Cases and Responsibility in
Object-oriented Development”, en Proceedings of the Twenty-fifth Australasian
Conference on Computer Science-Volume 4, Darlinghurst, Australia, Australia,
2002, pp. 7-16.
[50] C. Larman, Applying uml and Patterns: An Introduction to Object-Oriented Analysis
and Design and Iterative Development, 3.a ed. Upper Saddle River, NJ: Prentice
Hall, 2004.
[51] A. Cockburn, Writing Effective Use Cases, 1.a ed. Boston: Addison-Wesley
Professional, 2000.
[52] A. Peña Ayala, Ingeniería de software: Una guía para crear sistemas de información.
México D. F.: Instituto Politécnico Nacional, 2006.
[53] C. J. Date, An Introduction to Database Systems, 8.a ed. Boston: Pearson, 2003.
[54] A. Silberschatz, H. Korth, y S. Sudarshan, Fundamentos de bases de datos, 6.ª ed.
Madrid: McGraw-Hill, 2014.
[55] P. Oldfield, “Domain Modelling” [Online]. Appropiate Process
Movement, 2002. Disponible: http://www.aptprocess.com/whitepapers/
DomainModelling.pdf
[56] “Toma de decisión con certidumbre”. [Online]. Disponible: http://www.ehu.eus/
asignaturasKO/Metodologia/montecarloyarboles. [Consultado: 29-mar-2017].
[57] Centro de Estudios y Diseño de Sistemas, “Tablas de decisión: ejemplo”.
[Online]. Disponible: http://www.ceds.es/cursoad/ejemplos/ejemplotd.htm.
[Consultado: 29-Mar-2017].
[58] M. J. Castilla, “Tabla de Decisión” [online], en Sistemas de Información ii. Cátedra,

Facultad de Ciencias Social, Universidad Nacional de San Juan, Argentina.
Disponible: http://www.facso.unsj.edu.ar/catedras/ciencias-economicas/
sistemas-de-informacion-II/documentos/tabla.pdf
[59] Unified Modeling Language (uml), “Welcome to uml Web Site!”. [Online].
Disponible: http://www.uml.org/. [Consultado: 19-may-2017].
[60] B. Bruegge y A. H. Dutoit, Object-Oriented Software Engineering Using uml,
Patterns, and Java, 3.a ed. Boston: Pearson, 2009.
[61] Oracle, “Oracle JDeveloper”. [Online]. Disponible: http://www.oracle.com/
technetwork/developer-tools/jdev/overview/index-094652.html. [Consultado:
19-may-2017].
[62] M. Dumas, M. L. Rosa, J. Mendling y H. Reijers, Fundamentals of Business
Process Management. Nueva York: Springer, 2013.
Capítulo 3
Especificación, verificación y validación
3.1. Especificación de requerimientos
La especificación de requerimientos se encarga de documentar detalladamente las

funcionalidades, las capacidades y las restricciones del sistema [1], identificadas en
la recolección y en el análisis. Esta especificación se conoce con el nombre de srs.
Este documento debe describir por completo el comportamiento del sistema, pero
no debe contener condiciones de diseño, planeación, implementación y pruebas [2].
Para esto es necesario especificar los requerimientos, tanto de negocio y usuario como
los requerimientos del sistema, teniendo en cuenta que para que los requerimientos
sean adecuados y estén debidamente documentados deben contar con cierto tipo de
atributos, por ejemplo, la fecha de creación, el autor, la versión y la prioridad, entre
otros, los cuales se encuentran mejor detallados en la sección “4.2.1.1. Definir los
atributos de los requerimientos”.
La especificación de requerimientos es la base para el diseño y la implementación
del sistema, así como la fuente primaria de las pruebas y la documentación. Se dice
que es la base, ya que [2]-[4]:
• Los clientes necesitan saber cuál es producto que va a ser entregado.
• Ya que provee la descripción del sistema, el gerente del proyecto puede basarse
en este para hacer los estimados de la calendarización, esfuerzo y recursos.
• Los desarrolladores del sistema pueden conocer a cabalidad el sistema que se
debe implementar.
• El equipo encargado de realizar las pruebas puede saber qué parte o partes del
producto se encargan de cada funcionalidad.
_103
Los objetivos de realizar la especificación de los requerimientos son:

1. Asegurar que todos los stakeholders entienden de la misma manera el sistema
que se va a construir.
2. Garantizar que las pruebas que se definen y construyen sean las adecuadas para
el sistema que se está construyendo.
Para asegurar que los objetivos de la especificación de requerimientos se cumplen,

es necesario tener en cuenta las siguientes características de calidad [1], [2], [5], [6]:
• Correcto: significa que cada requerimiento describe de forma correcta las nece-
sidades o las expectativas de los clientes. Cuando el requerimiento no describe
la necesidad de manera correcta o cuando este describe algo diferente a lo que
el cliente necesita, el requerimiento es incorrecto.
• Completo: es decir, todas las necesidades del cliente están descritas dentro de la
especificación. Además, debe describir los requerimientos asociados con el ren-
dimiento, las restricciones de diseño y las interfaces externas del sistema.
• Factible: significa que todos los requerimientos descritos en la especificación se
pueden implementar, teniendo en cuenta las capacidades y las limitantes del
sistema, los desarrolladores y el entorno.
• No ambiguo: hace referencia a que cada uno de los requerimientos se debe en-
tender de una sola forma, lo cual implica que, sin importar qué stakeholder del
proyecto lea el documento de especificación de requerimientos, este entenderá
el significado de cada requerimiento de una sola forma.
• Necesario: quiere decir que cada uno de los requerimientos, en efecto, describe
una funcionalidad que es requerida por los clientes.
• Consistente: significa que cada requerimiento no entra en conflicto con ninguno
de los otros requerimientos. Para evitar que la especificación de requerimientos
sea inconsistente, se debe evitar utilizar sinónimos para referirse al mismo objeto,
ya que puede generar confusiones.
• Priorizado: quiere decir si se puede asignar una prioridad a cada requerimiento
para indicar la importancia de este durante una versión del producto en particu-
lar. Véase sección “4.2.1.2. Priorización”.
• Entendible: es decir si es comprensible el significado de cada uno de los reque-
rimientos con una mínima explicación.
• Verificable: existen métodos finitos que permiten verificar si el requerimiento
cumple con lo estipulado o no. Es recomendable que estos métodos sean únicos
para cada requerimiento, es decir, que no existan diferentes formas de verificar
un requerimiento.
Especificación, verificación y validación _105
• Modificable: cada requerimiento debe ser modificable, lo cual implica que cada
requerimiento debe ser especificado por separado. Esto permite evitar la ambi-
güedad y que se tenga un registro de los cambios realizados sobre los requeri-
mientos.
• Trazable: cada uno de los requerimientos se debe poder relacionar con su fuente,
caso de uso relacionado o el cliente al cual está ligado. Además de esto, se debe
poder relacionar con los elementos de diseño, la implementación y los casos de
prueba.
• Independiente del diseño: significa que es posible realizar el mismo objetivo,
pero de diferentes formas, diseño e implementación.
• No redundante: como su nombre lo indica, el requerimiento no debe estar re-
petido en todo el documento srs, pues facilita caer en la inconsistencia, además
de entorpecer el manejo de cambios.
Para realizar la especificación de requerimientos es necesario: estructurar el do-

cumento, definir atributos y verificar el lenguaje.
3.1.1. Estructurar el documento
La especificación de requerimientos puede convertirse en un documento extenso,

dependiendo del tamaño del sistema que se va a desarrollar. Por esto es necesario
definir de manera clara cómo se va a estructurar el documento, ya que, al hacerlo,
se asegura:
• Minimizar el número de requerimientos.
• Entender grandes cantidades de información.
• Organizar los requerimientos en grupos dependiendo del tema al que hagan
referencia.
• Detectar requerimientos repetidos.
• Detectar requerimientos faltantes.
• Eliminar inconsistencias en los requerimientos, es decir, eliminar los conflictos
que se presenten entre estos.
• Rechazar requerimientos en caso de ser necesario.
• Gestionar las iteraciones de desarrollo de los requerimientos, así como asegurar
un adecuado control de cambios sobre estos.
El estándar iso/iec/ieee 29148 [1] establece los contenidos mínimos con los que
debe contar una especificación de requerimientos:
• Introducción: en esta sección se resume el documento. De manera que el lector

tenga una breve idea de los temas que se tratan, se debe incluir el propósito del
documento, el alcance, las definiciones y acrónimos y las referencias.
• Descripción general: en esta sección se debe dar una perspectiva del proyecto,
entorno de la organización cliente, las funciones del producto, las características
de usuario, las restricciones, las suposiciones y las dependencias.
• Requerimientos específicos: se deben describir todos los requerimientos del siste-
ma. En particular, esta sección es la que mayor detalle debe tener en el momento
de estructurar los requerimientos.
Al estructurar esta última sección es importante tener presente que aun cuando
bien podrían agruparse los requerimientos por su tipo (negocio funcional, no fun-
cional, etc.), pueden agruparse por tipos de usuario (basado en el modelo de casos
de uso), subsistemas o módulos (inferidos a partir de uso común de información o de
procesos de negocio relacionados). Por ejemplo: imagine que está usted diseñando
un avión y tiene diferentes requerimientos originados de sus funcionalidades básicas,
así como de los stakeholders del producto (empresa de aviación, pilotos, personal de
mantenimiento, azafatas, pasajeros, etc.) [7].
Una primera aproximación a estructurar los requerimientos puede ser por actores:
• Requerimientos de negocio (de la empresa dueña o administradora del aparato)
• Personal de mantenimiento
• Piloto
• Azafata
• Pasajeros
Cada uno de estos grupos puede internamente agrupar los requerimientos por
tipos de acuerdo con el usuario.
Otra forma de agruparlos podría ser a partir de grupos de comportamientos
relacionados:
• Preparación para el vuelo
• En vuelo
• Preparación al aterrizaje
• Aterrizaje
• Mantenimiento
• Desempeño
• Safety (integridad física de los usuarios)
En el caso anterior se tiene una sección para requerimientos de desempeño que

pueden ser referenciados o relacionados con las respectivas secciones a las que afecten.
3.1.2. Definir atributos
Para establecer un requerimiento, se deben definir una serie de atributos que ase-
guren que el requerimiento será definido de manera completa, asegurando así que
todos los detalles del requerimiento son tenidos en cuenta [8] (véase sección “1.2.
Atributos de calidad del requerimiento”).
3.1.3. Verificar el lenguaje
Se deben definir cuáles son los términos con los cuales se va a hacer la especifica-
ción; por ejemplo, si se quiere hacer referencia al usuario final, se puede definir que
el término para identificarlo será usuario [2]. Es útil en este contexto el uso de un
diccionario de datos que permita identificar de una manera unívoca los elementos
del negocio que serán expresados en los requerimientos.
3.2. Validación y verificación
El proceso de verificación consiste en evaluar la exactitud, la completitud y la con-

sistencia [9] de cada uno de los requerimientos especificados, para asegurar que el
sistema que se va a construir satisfará las necesidades y expectativas de los usuarios
en términos de funcionalidad y calidad [10], [11]. Además de esto, se debe generar
un criterio de verificación para la arquitectura del sistema, el cual asegure que los
costos, el cronograma y los requerimientos de rendimiento se cumplen [12].
Con lo anterior, los objetivos de la verificación de requerimientos son [13]:
• Asegurar que la especificación de requerimientos es una clara y correcta descrip-
ción del sistema que debe ser implementado.
• Aseverar la consistencia, la exactitud y la completitud del documento de espe-
cificación de requerimientos.
• Confirmar que la especificación sigue un estándar.
• Garantizar la trazabilidad de los requerimientos entre sí (su estructura y organi-
zación), así como con casos de prueba, resultados y roles asociados [10].
Teniendo en cuenta que la verificación es un proceso, se deben tener las siguien-

tes entradas:
• El documento de especificación de requerimientos (véase sección “3.1. Especifi-

cación de requerimientos”).
• Estándares organizacionales: al igual que los conocimientos de la organización,
permitirán verificar los requerimientos. Dentro de estos documentos se pueden
encontrar estándares, políticas y reglas de la organización.
En las siguientes secciones se presentan las diferentes actividades que componen

el proceso de verificación. El objetivo es asegurar que los requerimientos sirvan de
base para el diseño, construcción, pruebas y gestión de proyectos. Los artefactos
resultantes son: la planificación de aceptación de pruebas, las revisiones informales,
las listas de chequeo de las inspecciones realizadas al srs y las pruebas técnicas.
3.2.1. Proceso de inspección
Inspección formal de los requerimientos “es una de las prácticas de calidad de más
alto valor” [2]. En este tipo de revisiones es recomendable que participen personas de
diferentes perspectivas. Estas se encuentran clasificadas de la siguiente manera [2]:
• “El autor del producto de trabajo y tal vez los colegas del autor”, es decir, la
persona que cumple con el rol de analista de requerimientos.
• El autor de algún artefacto anterior al srs puede ser un arquitecto que asegura
que el srs cumple con las especificaciones del sistema de manera detallada o
pueden ser también los representantes de los clientes para asegurarse de que el
srs describe sus necesidades correcta y completamente.
• Personas que van a realizar su trabajo basados en el producto que van a ins-
peccionar. Pueden ser los desarrolladores, probadores, director de proyecto y
documentador.
• Las personas que son responsables de artefactos que se interconectan con el pro-
ducto que se va a inspeccionar, es decir, las interfaces externas, para evitar que
existan problemas con sistemas externos.
Dentro de la inspección se deben representar unos roles que cumplen con unas
funcionalidades específicas para poder llevar a cabo la inspección de una manera
concreta [2], [3], [14]:
• Autor: es la persona que ha desarrollado el srs. Su función dentro de la especifi-
cación es explicar el srs a otros miembros del equipo de inspección.
• Moderador: asegura que el equipo de inspección se selecciona adecuadamente,
ya que el equipo de inspección debe estar capacitado para llevar a cabo el proceso
regido por unas reglas predefinidas.
• Lector: su funcionalidad, como su nombre lo indica, es leer el srs, donde los otros
participantes señalan posibles defectos y problemas. El lector puede ofrecer una
interpretación propia del requerimiento, donde pueden surgir diferencias entre
los inspectores. “Es una buena manera de revelar una ambigüedad, un posible
defecto o una suposición” [2]. Es recomendable que el lector no sea uno de los
autores del srs.
• Registrador (recorder): ayuda a reducir la carga al moderador. Se encarga de man-
tener anotadas todas las objeciones y cuestiones planteadas durante la reunión.
Es recomendable que el registrador lea lo que haya escrito, para informar al resto
lo que se ha plasmado y no dar espacio a malentendidos.
El proceso para llevar a cabo la inspección se presenta en la figura 3.1.
Figura 3.1. Proceso de verificación de requerimientos
Producto Visión general

Planeación de la reunión
Inicial
Inspección Preparación
Validación
Línea
Rehacer Seguimiento base del
producto
• Planeación: “El principal objetivo de la fase de planificación consiste en organizar

una reunión de inspección, cuando los materiales para las inspecciones se deter-
minan” [14]. Para evaluar si es prudente realizar o no la reunión de inspección
se tienen en cuenta los siguientes criterios de entrada, que según Wiegers [2] el
documento debe cumplir como son: cumplimiento con algún estándar, ortografía,
que visualmente no tenga errores, que los antecedentes o documento de referen-
cias del srs estén disponibles y, por último, si el moderador revisa el documento
y encuentra más de tres defectos importantes en un examen de diez minutos de
una muestra representativa, se pueda regresar el documento para su corrección.
• Visión general de la reunión: en esta fase el autor describe los antecedentes de la

inspección, las suposiciones que hizo y sus objetivos. Puede omitir esta etapa si
todos los inspectores ya están familiarizados con los temas objeto de la inspección.
• Preparación: antes de la reunión de inspección, cada inspector examina el producto
para identificar posibles defectos y cuestiones que han planteado, utilizando las
listas de verificación. Según Humphrey [2], el 75 % de los defectos encontrados
se detectan en esta fase; por lo tanto, es importante ejecutar esta fase del proceso.
• Inspección: el lector lleva a los demás inspectores a través de la srs, que describe
cada uno de los requerimientos con sus propias palabras. Cada defecto o cues-
tión, el registrador los anota en un formulario que se convierte en el elemento
de acción para el autor. El propósito de la reunión es identificar tantos defectos
importantes en el documento de requerimientos como sea posible.
• Rehacer: el autor debe llevar a cabo la corrección de los defectos, resolver las am-
bigüedades, eliminar la falta de claridad, entre otros aspectos mencionados en
la reunión por los demás evaluadores.
• Seguimiento: el objetivo es garantizar que el autor de los srs ha resuelto todos los
reportados incompleta o inconsistente requisitos.
Para el proceso de inspección se tienen en cuenta unas listas de chequeo pro-

puestas por Wiegers [2], para evaluar los casos de uso y la especificación de reque-
rimientos de software. Estas listas se encuentran en la tabla 3.1.
Tabla 3.1. Lista de chequeo para el proceso de verificación
srs Casos de uso

Organización y completitud: • Es el caso de uso stand
• ¿Son correctas todas referencias cruzadas internas a otros re- alone, ¿la tarea es discreta?
querimientos? • ¿El objetivo o el valor me-
• ¿Están todos los requerimientos descritos coherentemente y con dible del caso de uso es
un nivel adecuado de detalle? claro?
• ¿Los requerimientos proporcionan una base adecuada para el • ¿Está claro que actor o ac-
diseño? tores se benefician de un
• ¿La prioridad de implementación de cada requerimiento es caso de uso?
incluido? • ¿Está el caso de uso es-
• ¿Están todas las interfaces externas definidas (hardware, software crito en el nivel esencial,
y comunicación)? libre de detalles de diseño
• ¿Están los algoritmos intrínsecos definidos para los requerimien- e implementación?
tos funcionales definidos?
srs Casos de uso

• ¿El srs incluye todas las necesidades del sistema? • ¿Están todos los cursos al-
• ¿Hay alguna información que falte en un requerimiento? Si es ternativos previstos, docu-
así, ¿se ha identificado como un pendiente? mentados?
• ¿El comportamiento esperado está documentado para todas las • ¿Están todas las condicio-
condiciones de error esperadas? nes de excepción docu-
Exactitud: mentadas?
• ¿Existe algún conflicto entre los requerimientos o existen reque- • ¿Hay secuencias de acción
rimientos duplicados? común que puedan divi-
• ¿Cada requerimiento está redactado de forma clara, concisa y dirse en dos casos de uso?
sin ambigüedades del lenguaje? • ¿Están los pasos para cada
• ¿Cada requerimiento es verificable mediante pruebas, demos- curso escritos claramente,
tración, revisión o análisis? sin ambigüedades y com-
• ¿Cada requerimiento está dentro del alcance del proyecto? pletos?
• ¿Es cada requerimiento libre de contenido y errores gramati- • ¿Es adecuado cada actor
cales? y proceso del caso de uso
• ¿Todos los requerimientos pueden ser implementados dentro las para desempeñar esa ta-
restricciones conocidas? rea?
• ¿Están todos los mensajes de error especificados de manera única • ¿Es cada curso se define
y significativa? una alternativa posible y
Atributos de calidad: verificable?
• ¿Están todos los objetivos de desempeño especificados adecua- • ¿Las condiciones precon-
damente? diciones y poscondiciones
• ¿Están todas las consideraciones de seguridad (security and safety) están adecuadas dentro
especificadas adecuadamente? del marco del caso de uso?
• ¿Hay otros atributos de calidad pertinentes explícitamente
documentados y cuantificados, con la aceptación del acuerdo
especificado?
Trazabilidad:
• ¿Cada requerimiento es único y es identificado correctamente?
• ¿Cada requerimiento funcional de software está trazado hacia
un requerimiento de alto nivel (por ejemplo, requerimientos del
sistema o caso de uso)?
Temas especiales:
• ¿Son todos los requerimientos soluciones de diseño o imple-
mentación?
• ¿Están identificada las funcionalidades de tiempo crítico y sus
criterios de planeación está especificado?
• ¿Ha abordado de manera adecuada los problemas de interna-
cionalización?
3.2.2. Evolución de requerimientos
En esta etapa entran a participar los casos de prueba de los requerimientos de usua-
rio (véase sección “1.5.2. Requerimientos de usuario”), con el fin de documentar el
comportamiento esperado del producto en determinadas condiciones. Trace los casos
de prueba a los requerimientos funcionales para asegurarse de que ningún reque-
rimiento se ha pasado por alto [2]. Estos casos de prueba se utilizan para verificar
la exactitud de los modelos de análisis y prototipos, y es una manera económica de
corregir defectos de los requerimientos antes de haber empezado a implementar.
En la figura 3.2 se muestra cómo las pruebas derivan de los requerimientos de
usuario, además de presentar qué pruebas se pueden realizar para cada artefacto. Los
casos de prueba sirven para evaluar las necesidades textuales, los modelos de análisis
y los prototipos [3]. Se tienen los casos de prueba para evaluar el curso normal, al-
ternativo y excepciones existentes en los casos de uso [15]. Y se tienen los prototipos
para determinar el procedimiento que el usuario final desea en cada caso de uso.
Figura 3.2. Desarrollo y prueba productos de trabajo
Requerimientos
de usuarios
Analista Probador
Requerimientos Comparar
funcionales y Casos de prueba
modelos de análisis y escenarios
Comparar
Técnicas y Procedimientos de
diseños GUI pruebas y scripts

3.2.3. Modelos y criterios de aceptación
Es necesario saber cómo los usuarios van a determinar si el producto satisface sus
necesidades y es apto para su uso. Por lo tanto, “los criterios y pruebas de aceptación,
deben analizar si el producto cumple sus requerimientos documentados y si es apto
para su uso” [2]. Los principales usuarios deben considerar el uso más común y casos
de uso más importantes al decidir la forma de evaluar la aceptabilidad del software.
Es deseable que al inicio del proyecto se determinen conjuntamente los criterios de
aceptación, junto con sus pruebas asociadas y escenarios; de igual manera, se debe
diferenciar la aceptación de los prototipos por parte de los gerentes o dueños del pro-
ducto, de aquella realizada por clientes o usuarios finales (reales o potenciales) [10].
En cualquier caso, existen modelos e instrumentos genéricos que contribuyen a de-
terminar la utilidad o valor del producto, como pruebas de compromiso (engagement),
usabilidad [16], satisfacción [17], entre otros [18].
Tal vez el modelo más generalizado para realizar pruebas de aceptación es el
modelo de aceptación tecnológica (tam, por su sigla en inglés), cuya contribución funda-
mental es establecer, con un alto poder predictivo, si el artefacto tecnológico será
aceptado o no. Es decir, se trata de una medición ex ante para determinar la utilidad
potencial del artefacto antes de implantarlo en un contexto de producción. En ese
sentido, tam es un modelo para evaluar la aceptación potencial de un sistema por
parte de un grupo de usuarios [19]. En su versión original (1989), los criterios o
variables de aceptación se asocian con dos constructos: utilidad percibida y facili-
dad de uso percibida. Más recientemente, tras años de aplicación y refinamiento
del modelo, los factores han sido revisados para considerar más explícitamente los
condicionantes de la aceptación (o no) del artefacto: experiencia, volición (libertad
en elegir o no el artefacto), normas subjetivas, imagen, relevancia para el trabajo,
calidad de las salidas del sistema y la demostración de los resultados [20].
Dado que muchas personas han usado y generado variantes de tam, se ha in-
tentado llegar a un modelo unificado [20], [21]. Se ha podido lograr una capacidad
predictiva del 70 % con un modelo cuyas variables independientes son:
• Expectativa de mejora en el desempeño
• Expectativa de esfuerzo requerido
• Influencia social
• Condiciones facilitadoras
Estos anteriores son los factores que conducen inicialmente una intención de
uso del artefacto y esta intención es la que conduce eventualmente al uso real. No
obstante, también se han determinado variables moderadoras que es importante
tener en cuenta como influencia en la aceptación:
• Género
• Edad
• Experiencia previa
• Volición (libertad de elegir)
En cualquier caso, estos constructos se deben operacionalizar mediante instru-

mentos que usualmente incluyen afirmaciones que son calificadas por una población
de usuarios potenciales, mediante escalas tipo Likert (de muy en desacuerdo a muy de
acuerdo). Así, por ejemplo, para el constructo de utilidad percibida se incluyen los
siguientes ítems en la encuesta de aceptación de usuarios:
• Usar el sistema en mi trabajo me permitiría acabar mis tareas más rápidamente.
• Usar el sistema mejoraría mi desempeño laboral.
• Usar el sistema incrementaría mi productividad laboral.
• Usar el sistema potenciaría mi efectividad laboral.
• Usar el sistema me facilitaría el trabajo.
• Encontraría el sistema útil para mi trabajo.
Cabe subrayar que este instrumento predice aceptación, con lo cual se puede
evaluar a partir de prototipos o demostraciones, no necesariamente de uso real en
producción.
3.2.4. Ejemplo de verificación y validación
Como lo indica Wiegers [2], aparte de las listas de verificación y validación, la es-
pecificación de requerimientos también se puede evaluar por la consistencia de sus
componentes. En este ejemplo, vamos a comparar un requerimiento con un caso de
prueba1 definido para verificar el requerimiento. Supongamos que es una empresa
que manufactura diferentes productos.
1
Dícese del conjunto de entradas de prueba para el sistema y su respectivo conjunto de salidas esperadas, así
como una descripción de lo que será probado [22].
Tabla 3.2. Ejemplo de V&V: parte 1
Requerimiento
El sistema debe validar los atributos del producto para que el usuario pueda enviar la solicitud.
Caso de prueba
Para aprobar la solicitud, debe revisar los atributos del producto si existen para reportarlos en la
solicitud.
En la tabla 3.2 se muestra un requerimiento con el caso de prueba, donde se

muestra que el caso de prueba no está tan detallado para una persona que no tenga
conocimiento del desarrollo. Esto se debe a que el requerimiento no tiene especifi-
cado lo que quiere validar del producto. Como falta información, el caso de prueba
no tiene las suficientes herramientas para crear, al menos, un escenario detallado.
Entonces, se debe redefinir el requerimiento y el caso de prueba. Para este ejemplo,
la corrección sería la siguiente (tabla 3.3):
Tabla 3.3. Ejemplo de V&V: parte 2
Requerimiento
El sistema debe validar que cada uno de los atributos característicos del producto tenga al menos
un valor diligenciado en la solicitud para que el usuario pueda enviar la solicitud.
Caso de prueba
Para enviar la solicitud, el usuario debe probar los siguientes escenarios:
• Cuando todos los atributos del producto estén diligenciados, el resultado debe ser el envío de
la solicitud sin ningún problema.
• Cuando uno de los atributos del producto no tenga un valor asignado, al enviar la solicitud, el
sistema debería mostrar un mensaje de error e impedir que se envíe la solicitud.
Ahora, se detalla un poco más el caso de prueba, incluso tiene dos escenarios,
gracias a la información adicional que ahora tiene el requerimiento.
Con este tipo de revisiones se pueden evitar posibles errores al descubrir am-
bigüedad en el requerimiento, orientar mejor la prueba para el requerimiento o
redefinir el requerimiento hacia lo que en realidad quiere el cliente.
Referencias
[1] International Organization for Stardization, “iso/iec/ieee 26531:2015.

Systems and software engineering”. [Online], dic. 2011. Disponible: https://
www.iso.org/standard/43090.html
Press, 2013.
Piscataway, NJ: ieee Computer Society, 2014.
[5] S. Lauesen, Software Requirements: Styles & Techniques, 1.a ed. Harlow: Addison-
pp. 44-48, 1999.
Springer, 2010.
[9] A. Chen y J. Beatty, Visual Models for Software Requirements, 1.a ed. Redmond,
WA: Microsoft Press, 2012.
[10] E. Bjarnason et ál., “Challenges and practices in aligning requirements with
verification and validation: a case study of six companies”, Empir. Softw. Eng.,
vol. 19, no. 6, pp. 1809-1855, jul. 2013.
[11] K. E. Wiegers, “When telepathy won’t do: Requirements engineering
key practices”, Process Impact, 2000. [Online]. Disponible: http://www.
processimpact.com/articles/telepathy.html
[12] Department of Defense Systems Management College, Systems Engineering
Fundamentals, 2001.
Chichester, UK: John Wiley & Sons, Inc., 1997.
[14] U. A. Raja, “Empirical studies of requirements validation techniques”, en
Control and Communication 2009: 2nd International Conference on Computer, 2009,
pp. 1-9.
[15] M. J. Castilla, “Tabla de decisión” [online], en Sistemas de Información ii. Cátedra,

Facultad de Ciencias Social, Universidad Nacional de San Juan, Argentina.
Disponible: http://www.facso.unsj.edu.ar/catedras/ciencias-economicas/
sistemas-de-informacion-II/documentos/tabla.pdf
[16] J. W. Palmer, “Web site usability, design, and performance metrics”, Info. Sys.
Res., vol. 13, no. 2, pp. 151-167, jun. 2002.
[17] R. O. Briggs, B. A. Reinig y G.-J. de Vreede, “The yield shift theory of
satisfaction and its application to the is/it domain”, en Information Systems
Theory, Y. K. Dwivedi, M. R. Wade y S. L. Schneberger, eds. Nueva York:
Springer, 2012, pp. 185-217.
[18] H. L. O’Brien y E. G. Toms, “The development and evaluation of a survey
to measure user engagement”, J. Am. Soc. Inf. Sci. Technol., vol. 61, no. 1,
pp. 50-69, en. 2010.
[19] P. Legris, J. Ingham y P. Collerette, “Why do people use information
technology?: A critical review of the technology acceptance model”, Inf.
Manage., vol. 40, no. 3, pp. 191-204, en. 2003.
[20] V. Venkatesh y H. Bala, “Technology Acceptance model 3 and a research
agenda on interventions”, Decis. Sci., vol. 39, no. 2, pp. 273-315, may 2008.
[21] V. Venkatesh, M. G. Morris, G. B. Davis y F. D. Davis, “User acceptance of
information technology: Toward a unified view”, MIS Q., pp. 425-478, 2003.
Capítulo 4
Administración de requerimientos
4.1. ¿Qué es la administración de requerimientos?
Como se muestra en la figura 4.1, la administración de requerimientos es una de las

actividades de la ingeniería de requerimientos cuyo objetivo principal es administrar
los cambios que pueden surgir en los requerimientos durante su implementación
o luego de ella y en todos los lanzamientos del producto, ya que, en ciertos casos,
cuando se hace el lanzamiento de alguna versión del sistema, puede que algunos
requerimientos ya no sean necesarios o hayan cambiado por alguna disposición del
cliente u otra razón [1].
Además del control de cambios, la administración de requerimientos debe en-
cargarse del control de versiones, hacer seguimiento del estado de los requerimientos
y realizar la trazabilidad que permita ubicar el origen y lugar donde se encuentra
el requerimiento en cualquier artefacto producto del proceso de desarrollo. Estas
responsabilidades del proceso permiten asegurar la precisión, la integridad y que
los requerimientos se encuentren siempre actualizados [2].
Una vez realizadas la recolección, el análisis y la especificación de los requerimien-
tos, es necesario empezar a realizar las tareas de administración de requerimientos
para, así, aumentar las posibilidades de éxito, ya que dentro de las causas por las
cuales fracasan los proyectos de software, según el estudio chaos [3], realizado por
el Standish Group, se encuentran, entre otras, la incapacidad de manejar el cambio,
la inexactitud e incomprensión de los requerimientos y la planeación inapropiada, las
cuales están estrechamente relacionadas con la administración de los requerimientos.
_119
4.2. Proceso de administración de requerimientos
Para alcanzar una gestión de requerimientos exitosa se deben realizar las actividades
registradas en la figura 4.1.
Figura 4.1. Proceso de administración de requerimientos
Proceso Actividad
Identificar
requerimientos
Definir otros atributos

Capturar de los requerimientos
Priorizar requerimientos
Localización
Administración
de Trazar
requerimientos
Trazabilidad
Definir políticas de
administración
Monitoreo y
reporte
Almacenar los
requerimientos rechazados
Administrar
el cambio Control de cambios

Administración de requerimientos _121
4.2.1. Capturar
4.2.1.1. Definir los atributos de requerimientos
“Los requerimientos son objetos de ingeniería y deben ser organizados y rastreados

como tal” [5], es decir, los requerimientos son parte fundamental del proyecto y son
herramientas poderosas, las cuales permiten definir cuál debe ser el comportamiento
del sistema. Por lo tanto, además de la descripción textual de los requerimientos,
cada uno de estos debería contar con ciertos atributos que permiten la contextuali-
zación del requerimiento dentro del sistema, pues los requerimientos, al igual que
otros artefactos, cambian su estado y es necesario saber qué cambia, cómo cambia,
por qué cambia, quién lo cambia, entre otras cuestiones.
Los atributos de los requerimientos, como bien lo dicen Alexander y Stevens
[5], sirven para rastrear el estado de los requerimientos en cualquier etapa del pro-
yecto; sin embargo, no todos los requerimientos tienen la misma necesidad de ser
monitoreados todo el tiempo, por su simplicidad, bajo riesgo respecto al cambio o
baja prioridad; pero existen atributos que aplican a todos los requerimientos en ge-
neral. Por lo tanto, debe de haber un conjunto de atributos para utilizar de manera
general en los proyectos y para realizar un proceso de administración que cumpla
con las características mínimas [6].
Con este propósito, se presenta una clasificación de los atributos de los reque-
rimientos (tabla 4.1). En primera instancia, están los atributos que describen la in-
formación del requerimiento. En segunda, se hallan los atributos que se desarrollan
durante el proyecto, ya sea porque dependen de otros requerimientos para obtener
su valor o porque existen otros artefactos que pertenecen a otras fases que influyen
en este (por ejemplo, localización o trazabilidad). Por último, se encuentran los atri-
butos opcionales, que pueden albergar una gama amplia dependiendo de lo que el
proyecto requiera [6].
Tabla 4.1. Distribución de los atributos de los requerimientos
Atributo Descripción
Atributos propios del requerimiento
Fecha Día, mes y año en el cual fue creado el requerimiento.
Descripción Describe el requerimiento identificado en la fase de recolección.
Versión Versión actual del requerimiento.
Autor Nombre de la persona que creó el requerimiento.
Responsable Persona que debe asegurar que el requerimiento se cumple.
Persona a la que pertenece el requerimiento o una lista de
Dueño
stakeholders.
Fase en que se encuentra el requerimiento, es decir, el reque-
Estado rimiento puede estar propuesto, rechazado, implementado o
verificado, dependiendo de los criterios que cada grupo tenga.
Número de la versión del requerimiento, el cual pertenece a la
Versión línea base
línea base actual.
Describe las fuentes del requerimiento (véase sección “2.1.4.
Origen
Entrevistas y cuestionarios”)
Razón Se utiliza para saber el motivo de la última revisión.
Cambios realizados Lista de los cambios realizados al requerimiento.
Indica el responsable de los cambios realizados en los requeri-
Responsable del cambio
mientos.
Fecha del último cambio Fecha en la cual fue modificado por última vez el requerimiento.
Atributos para el proyecto
Prioridad Importancia del requerimiento.
Requerimientos que se relacionan, ya sea porque pertenecen al
Requerimientos asociados
mismo módulo.
Subsistemas Lista de subsistemas en los que se encuentra el requerimiento.
Casos de uso que cumplen con el requerimiento. Este atributo
Casos de uso asociados
está relacionado con los que tratan sobre la trazabilidad vertical.
Según la clasificación que se maneje en el grupo, a qué grupo de
Tipo de requerimiento
requerimientos pertenece.
Volatilidad Este campo indica qué tan volátil es el requerimiento.
Especifica el componente o subsistema donde se encuentra asig-
Localización
nado el requerimiento.
Indica el nivel de riesgo que puede tener un requerimiento, debi-
do a diferentes factores como la limitación de la herramienta de
software que se utilice, la falta de conocimiento de la herramienta,
Riesgo
la dificultad de la interfaz, el conjunto de habilidades en el equipo
de desarrollo y la criticidad con el incumplimiento de una obli-
gación se propagará el riesgo.
Indica la dificultad para los desarrolladores para implementar el
Dificultad
requerimiento.
Indica el nivel de beneficio para el proyecto en general, puede ser
Beneficio distribuido según diferentes criterios. Para mayor ampliación del
tema véase la sección “4.2.1.2. Priorización”.
Muestra los artefactos que permiten seguir la vida del requeri-
Trazabilidad
miento (véase sección “4.2.2.2. Trazabilidad”).
Atributos adicionales
Indica el caso de prueba asignado para validar el requerimiento
Casos de prueba asignados
en cada una de las fases de desarrollo.
No siempre el responsable en la fase de requerimientos es el mis-
Responsables en cada una de mo en la fase de diseño, implementación o pruebas; por lo tanto,
las fases es necesario saber quién está a cargo del requerimiento en cada
una de las fases.
El método que se utilizará en pruebas de aceptación para demos-
Método de calificación
trar la conformidad del producto con el requisito.
Resultados obtenidos de las métricas asociadas al método de ca-
Métricas asociadas
lificación, si lo van a aplicar.
Porcentaje del resultado que indica si cumple con los estándares
Aprobación (según estándar
de calidad definidos en el proyecto, según las listas de chequeo
que se maneje)
aplicadas.
Fuente: [2], [6], [7].
Sin embargo, como menciona Heumann en su artículo “The Five Levels of Re-
quirement Management Maturity” [7], no todos los requerimientos son iguales;
existen requerimientos más estables que otros, existen requerimientos que son más
importantes que otros, razón por la cual se les presta mayor atención. Por lo tan-
to, no es necesario aplicar dentro de la especificación de los requerimientos (véase
sección “3.1. Especificación de requerimientos”) todos los atributos descritos en la
tabla 4.2, simplemente se pueden tomar algunos como base para modificar y agre-
gar nuevos atributos que sean necesarios, a fin de que se pueda considerar que un
requerimiento es completo y apropiado para el proyecto.
Los requerimientos se pueden considerar volátiles por dos razones: la primera es
que puede que uno o más clientes no estén de acuerdo con la funcionalidad o carac-
terística que describe el requerimiento y la segunda razón es que existen ciertos tipos
de eventos externos al proyecto que no pueden ser controlados y pueden generar
algunos cambios sobre los requerimientos [8]. Un ejemplo clave de requerimientos
volátiles son las interfaces externas.
Los requerimientos volátiles pueden ser de diferentes tipos, por ejemplo:
• Requerimientos cambiantes: son los que cambian debido al ambiente donde se
encuentra o se encontrará el sistema.
• Requerimientos emergentes: estos surgen cuando el sistema ya está en fases de
diseño y de implementación, ya que no es común verlos cuando el sistema se
especifica.
• Requerimientos “consecuentes”: surgen de las especulaciones hechas en el mo-
mento de realizar la especificación, sobre la manera en la que va a ser usado por
los clientes del sistema.
• Requerimientos de compatibilidad: son requerimientos sobre la compatibilidad
que debe tener el sistema en caso de que surjan nuevas actualizaciones sobre el
ambiente en el que va a funcionar el sistema.
Se debe considerar realizar el análisis de la volatilidad del requerimiento dentro

del proceso, ya que uno de los beneficios es la facilidad para los desarrolladores en
el momento hacer un cambio en los componentes del sistema que no se encuentran
fuertemente acoplados. Por esto, teniendo la lista de requerimientos volátiles, estos
se pueden ubicar en los componentes más desacoplados, para así facilitar la modi-
ficación del sistema.
4.2.1.2. Priorización
La priorización es un proceso necesario dentro de la ingeniería de requerimientos,

ya que un proyecto depende de diferentes recursos como el tiempo, el personal y el
dinero. Por esto, es preciso entregar un producto que contenga lo esencial (funcio-
nalidades importantes) [9].
Para saber lo “esencial”, es preciso organizar los requerimientos de tal forma que
se tenga un conjunto de requerimientos indispensables dentro del producto [10].
Según Berander y Andrews, el proceso de priorización de requerimientos apoya
diferentes actividades como [10]:
• Negociar el alcance del proyecto, pues a veces se generan conflictos con algunas
restricciones, como programa, presupuesto, recursos, tiempo en el mercado y
calidad.
• Que los stakeholders puedan decidir cuáles son los requerimientos básicos del
sistema.
• Hacer frente a exigencias contradictorias para enfocarse en el proceso de nego-
ciación y resolver los desacuerdos entre los stakeholders.
• Equilibrar las repercusiones de los requerimientos en la arquitectura de software
y la evolución futura del producto y sus costos asociados.
• Seleccionar solo un subconjunto de los requerimientos y aún producir un sistema que
satisfacer al cliente(s).
• Estimar las expectativas del cliente.
• Conseguir una ventaja técnica y optimizar las oportunidades de mercado.
• Minimizar la repetición de trabajos y atrasos en el calendario (estabilidad del
plan).
• Establecer la importancia relativa de cada requerimiento con el objetivo propor-
cionar el mayor valor al menor costo.
4.2.1.2.1. Criterios
Existen diferentes factores que pueden intervenir en la priorización, ya que se debe
tomar en cuenta la opinión de los stakeholders del proyecto; por lo tanto, los factores
que existen son muchos dependiendo de los objetivos y prioridades de cada stake-
holder. Para esto, diferentes autores como Berander y Andrews [10] o Botta y Bahill
[11] han agrupado diversos criterios útiles para establecer prioridades que pueden
tomarse en cuenta para realizar el proceso de priorización de requerimientos. En la
tabla 4.2 se presenta un conjunto de los criterios que pueden ser usados.
Tabla 4.2. Criterios de priorización de requerimientos
Criterio Justificación
“Características que pueden incrementar la satisfac-
Satisfacción ción del cliente deben ser de prioridad alta”, pues el
de cliente producto es desarrollado a petición del cliente. Su
opinión es una de las más importantes en esta etapa.
Importancia Si se ha llegado a tener un acuerdo de lo que tiene
Los stakeholders deben de- Compromiso o debería hacer el sistema, esto se debe cumplir,
cidir qué requerimiento dado que ha existido un previo trato con el cliente.
es más importante para
el sistema. Dado que cada Es importante dar prioridad a las características que
Prioridad de
uno va a seguir su propio participan en los escenarios (casos de uso), ya que
escenarios
criterio, este ítem puede pueden ser importantes para los objetivos del negocio.
llegar a ser multifacético. Este beneficio se refiere a características relaciona-
Por lo tanto, es necesario Beneficio das con requerimientos no funcionales del sistema,
especificar el área de im- como desempeño, tiempo entre fallas, entre otros.
portancia que se quiere
manejar para asegurar, Las características críticas de seguridad deben ser
Seguridad
por lo menos, que se está de alta prioridad, ya que se está involucrando la
(safety)
calificando con las mismas seguridad de los seres humanos.
reglas. En algunas ocasiones, existen características que
deben ser planeadas de manera temprana, debido
Cuando es
al deseo o a restricciones por parte del cliente; por
necesario
lo tanto, el tiempo es algo que también se debe
tomar en cuenta.
Dar alta prioridad a las características que tendrán
un gran impacto en la arquitectura del sistema.
Impacto negativo
Esto se debe a que los cambios que se realicen so-
(penalización) Arquitectura
bre ellas posteriormente pueden afectar diferentes
Es el valor que tiene el
entidades y causar así más cambios en diferentes ar-
requerimiento para el
tefactos, lo cual llega a ser costoso para el proyecto.
stakeholder, pero se aplica
al contrario, es decir, qué Este tipo de relaciones entre los requerimientos
tanto se perjudica el siste- Dependencias pueden indicar el grado de impacto que puede
ma si se realiza o no un re- causar si existe cambio sobre algún requerimiento.
querimiento. Al igual que
Objetos que pueden ser usados muchas veces du-
el anterior grupo de crite-
rante el desarrollo del proyecto deben ser de alta
rios, se necesita especificar Frecuencia de
prioridad. Por ejemplo, un fragmento de código
el área que se va a evaluar. uso
que realiza una funcionalidad específica repetidas
veces, debe ser elaborado y optimizado.
El costo es el valor numérico que se le asigna a cada
requerimiento, cuantificando los recursos invertidos
(tiempo, personas, viajes).
Depende de los stakeholders analizar su costo y si
Costo el retorno de la inversión es satisfactorio para el
cliente, el cual se puede obtener revisando el be-
neficio del requerimiento. Si el beneficio que trae
desarrollar el requerimiento es alto para el cliente,
entonces se puede considerar incluirlo.
Proporción Como su nombre lo indica es la combinación del
costo- costo-beneficio, obteniendo así características que
beneficio ofrecen mayor beneficio con menor costo.
Las características que son complejas de desarrollar
Costo Complejidad deben ser de alta prioridad, pues se debe asignar a
Como su nombre lo indi- los mejores miembros para llevarlas a cabo.
ca, es el esfuerzo en el que Si es un ítem altamente reusable, debe tener una
incurre el stakeholder para Potencial de
prioridad alta, pues puede influir en el tiempo de
llevar a cabo el requeri- reúso
desarrollo.
miento. Según el stakehol-
der, el recurso a tener en Los requerimientos que cuentan con un grado de
cuenta difiere. dificultad alto en el momento de poner en prácti-
ca deberían tener alta prioridad; por ejemplo, los
atributos que pueden hacer difícil la aplicación
Dificultad de incluyen gran tamaño, la incertidumbre, la no-
implementa- vedad, el número de personas involucradas y las
ción restricciones organizacionales. La complejidad y la
dificultad de implementación son diferentes, pues
la segunda se refiere más a la dificultad en aplicar la
solución, mientras que la primera se refiere al costo
que puede incurrir para el sistema.
Como su nombre lo indica, es el tiempo que puede
Tiempo de necesitar un requerimiento para ser aceptado; por
implementa- lo tanto, los que necesiten más tiempo deben ser
ción planeados con anterioridad y tener prioridad, para
no crear posibles caminos críticos en el proyecto.
“Trabajar sobre los requerimientos de alto riesgo
en primer lugar para reducir el riesgo y, además
porque son más propensos a cambiar, produciendo
Riesgo
así cambios en otras características”. Con esto se
evita el gasto de dinero en la aparición de cambios
no planeados.
“La volatilidad de los requerimientos se considera
un factor de riesgo y en ocasiones se manejan como
parte del aspecto de riesgo. Otros piensan que la
volatilidad se debe analizar por separado”. Existen
Riesgo diferentes razones, por las cuales la volatilidad
Es la probabilidad de fallo puede variar como cambios en el mercado, en los
que tiene el requerimiento Volatilidad requerimientos de negocio, cambios legislativos,
de no ser implementado etc. Sin embargo, independiente de la razón, estos
o aplicado dentro del sis- cambios causan atrasos en el cronograma lo que
tema. lleva al gasto de dinero adicional en el proyecto.
Por lo tanto, hay que definir estos requerimientos
con alta prioridad y así evitar problemas en el de-
sarrollo del proyecto.
“Desarrollar requerimientos estables en primer
lugar” ayuda a mantener una base casi intacta
sobre la que se puede trabajar el resto de los reque-
Estabilidad rimientos. Además, permite visualizar los cambios
de otros requerimientos con antelación [52] y evi-
tar así el gasto de dinero en cambios que pudieron
ser evitados.
Fuente: [10], [11].
4.2.1.2.2. Proceso
Existe un proceso para priorizar requerimientos que recomienda el autor Firesmith
para integrarlo a la administración de requerimientos [12]:
• Convencer a los stakeholders: es necesario dar a conocer la importancia de la prio-
rización de requerimientos a los stakeholders; de esta forma se pueden obtener
mejores resultados.
• Entrenar a los stakeholders: el entrenamiento a los stakeholders de requerimientos
es necesario, ya que así se asegura que todos los involucrados en el proceso de
priorización de requerimientos están tomando el mismo concepto y criterio a la
hora de evaluar.
• Escoger técnica: se debe escoger una técnica de priorización para saber los cri-
terios a tener en cuenta para evaluar la importancia de cada uno de los requeri-
mientos. La selección de la técnica depende de la organización, del cliente, de la
complejidad del proyecto y de sus stakeholders [10].
• Priorizar los requerimientos actuales: “Durante el análisis de requerimientos,
el equipo debe trabajar con el representante de los stakeholders para priorizar
los requerimientos actuales” [12]. Dentro de esta fase se incluyen actividades
como la negociación con los stakeholders sobre los requerimientos que se van a
desarrollar y su validación.
• Publicar las prioridades: durante la especificación de requerimientos, el equipo
debe publicar las prioridades resultantes después del análisis, con el fin de que
todas las partes interesadas estén informadas y puedan utilizar este informe de
prioridades.
• Estimación el esfuerzo: con el equipo de arquitectura y el de desarrollo se regis-
tran estimaciones realistas sobre los esfuerzos a incurrir en los requerimientos
seleccionados.
• Desarrollar un cronograma: con los resultados obtenidos en la fase anterior se
desarrolla un cronograma para las etapas posteriores del desarrollo del producto.
Este cronograma no es permanente, ya que puede cambiar dependiendo de las
posibles modificaciones de los requerimientos en el futuro.
• Mantenga las prioridades: “Durante la administración de requerimientos, el
equipo debe trabajar con los stakeholders para mantener los parámetros de exi-
gencia a medida que cambian” [12]. Generalmente, este campo suele ser como
un atributo del requerimiento al final de todo el análisis.
4.2.1.2.3. Técnicas
En el momento de priorizar los requerimientos, los stakeholders asignan un valor de
importancia al requerimiento según el criterio; sin embargo, en proyectos donde la
complejidad es alta, el asignar un valor no soluciona el problema, pues el resultado
no logrará satisfacer los objetivos propuestos en principio, es decir, el conjunto de
requerimientos estará vagamente delimitado y no se tendrá la certeza de que esos re-
querimientos merecen estar dentro de ese conjunto. Además, el hecho de que influyan
diferentes stakeholders lo hace aún más complicado, ya que podría encontrarse con re-
sultados contradictorios, donde no se tiene un criterio de decisión más que escoger los
de mayor puntuación. Para evitar este tipo de problemas se han presentado diferentes
técnicas de priorización de requerimientos desde hace varios años. A continuación, se
presentarán las más comunes.
Para empezar, se debe mencionar que existen diferentes escalas para evaluar un
requerimiento, ya que dependiendo de la granularidad que se esté manejando, esta
puede variar [9]. Las más comunes son:
• Bajo, medio y alto
• Esencial, condicional y opcional
• Bueno tenerlo, objetivo, altamente deseada y se debe lograr
• Numérica (por ejemplo, 1-5 o 1-10)
Dependiendo de la técnica, se escoge la que mejor se adecue, pues según la escala

se puede elegir qué tan detallado resulta el análisis.
4.2.1.2.4. Asignación numérica

La asignación numérica es una de las técnicas más sencillas y comunes [10]. Con-
siste en agrupar los requerimientos en diferentes niveles (véase sección “4.2.1.2.3.
Técnicas”), donde cada uno de los stakeholders tiene que agruparlos según su criterio.
Para evitar inconvenientes, como el considerar todos los requerimientos importantes,
se debe limitar el número de requerimientos por grupo. De esta forma se tiene un
conjunto de requerimientos semiordenados.
4.2.1.2.5. Priorización basada en valor, costo y riesgo

Esta técnica la propone Wiegers en su artículo “First Things First: Prioritizing
Requirements” [9], el cual menciona que se deben tener en cuenta las diferentes
perspectivas de los stakeholders para estimar las prioridades relativas de un conjunto
de requerimientos. Esta consiste en evaluar cuatro criterios:
• Beneficio
• Impacto negativo (penalty)
• Costo
• Riesgo
Los stakeholders asociados a esta técnica suelen ser el director del proyecto, para me-
diar entre las partes implicadas; los representantes del área de desarrollo, para estimar
los riesgos y costos que se van a afrontar, y los representantes de los clientes “clave”,
para que indiquen qué beneficios e impactos negativos podrían tener si el requerimiento
está o no dentro del producto.
Luego de evaluar cada requerimiento se deben asignar unos pesos a cada crite-
rio, es decir, un valor de importancia a cada ítem; por ejemplo, si se considera que
el proyecto es de alto riesgo (variedad de caminos críticos, presupuesto o tiempo),
se le proporciona más valor al criterio riesgo. Por último, se les aplica una fórmula a
los valores asignados sobre los requerimientos respecto a cada criterio [2]:
porcentaje del valor

Prioridad =
porcentaje del costo + porcentaje del riesgo
Así se logra un valor específico de cada requerimiento, se organiza la tabla de

mayor a menor y se obtiene un conjunto priorizado de requerimientos.
4.2.1.2.6. Analytical Hierarchy Process

Es un método para la toma de decisiones adaptado a la priorización de requerimien-
tos de software [10], [13]. Se utiliza “por pares”, ya que se usa una matriz de com-
paración para calcular el valor relativo y los costos de los requerimientos entre sí.
Mediante el uso del Analytical Hierarchy Process (ahp), el analista de requerimientos
puede confirmar la coherencia del resultado, pues los errores pueden identificarse
durante las comparaciones redundantes que se realizan. El ahp posee diferentes
ventajas, como el evitar errores subjetivos, además de aumentar la probabilidad de
que los resultados sean confiables. El método de esta técnica se distribuye en cuatro
puntos generales [13]:
1. Revisar los requerimientos asociados al requerimiento candidato.
2. Aplicar el método de comparación por pares para evaluar el valor relativo de
cada uno de los requerimientos candidatos.
3. Aplicar el método de comparación por pares para evaluar el costo relativo de los
requerimientos candidatos.
4. Calcular el valor relativo de cada requerimiento candidato y costo de implemen-
tación, para luego realizar un diagrama de costo-valor.
Utilice el diagrama de costo-valor como un mapa para analizar los requerimien-

tos candidatos.
4.2.1.2.7. Valor acumulativo: la prueba de 100 dólares

La prueba de 100 dólares es una técnica muy sencilla de priorización en la cual a
los interesados se les da 100 unidades imaginarias para distribuir entre los requeri-
mientos [13]. El resultado de la priorización se presenta en una escala de razón [10].
Un problema con esta técnica se presenta cuando hay demasiados requerimientos;
sin embargo, un estudio al respecto mostró resultados positivos en cuanto al uso de
otros valores, aparte de 100 (por ejemplo, 1000, 10 000 o 1 000 000) [10].
4.2.1.2.8. Árbol de búsqueda binario

El árbol binario de búsqueda es un algoritmo que suele utilizarse en la búsqueda
de información y puede emplearse en la priorización de los requerimientos [13]. La
clasificación que usa esta técnica se basa es una escala ordinal, donde el requerimien-
to más importante ocupa la posición número 1, y el menos importante, la posición
número n (de n requerimientos) [10]. El proceso que se utiliza es:
1. Ubicar los requerimientos en una lista (no importa el orden).
2. Tomar el primer requerimiento y posicionarlo como raíz.
3. Tomar otro requerimiento y realizar la comparación con el nodo raíz.
4. Si el requerimiento es menos importante que el nodo raíz, debe compararlo con
el nodo hijo izquierdo. Si el requerimiento es más importante que el nodo raíz,
debe compararlo con el nodo hijo derecho. En el caso de que el nodo no ten-
ga nodos secundarios, introducir el nuevo requerimiento como el nuevo nodo
secundario hacia la derecha o izquierda, dependiendo de si el requerimiento es
más o menos importante.
5. El grupo que realiza el análisis debe repetir los pasos 3 y 4 hasta que todos los re-
querimientos se hayan comparado e insertado en el árbol de búsqueda binario (bst).
Cuando se requiera ver una presentación más común, se debe recorrer todo el bst
en orden. Con esto se obtienen los requerimientos en una lista ordenada de mayor
a menor importancia, para llegar así a lo que Berander y Andrews llaman técnica de
priorización ranking [10].
4.2.1.2.9. Ejemplo de priorización

Para tener una mejor comprensión de este tema, se expone un ejemplo utilizando
una de las técnicas descritas en las secciones anteriores. Para este caso se utilizará la
técnica de costo-beneficio, propuesta por Wiegers [9].
Se tiene un conjunto de 12 requerimientos, el cual debe priorizarse. Se tienen
recursos limitados para la primera entrega del proyecto y el objetivo es cumplir con
un alcance definido por el cliente. Para ello se ha propuesto a algunos stakeholders
que evalúen los requerimientos dependiendo de 4 variables, como las que expone
Wiegers: costo, beneficio, riesgo y penalidad. El costo es el valor numérico de los
recursos invertidos (tiempo, personas, materiales o viajes) que se necesitan para
realizar un requerimiento. El beneficio, como su nombre lo indica, es qué tan bueno
para el cliente o para el proyecto sería realizar este requerimiento en este momento.
La penalidad es todo lo contrario: se evalúa qué tan malo sería para el cliente o para
el proyecto no realizar este requerimiento. Por último, está el riesgo, que indica la
probabilidad de fallo o grandes cambios durante el desarrollo del requerimiento, lo

cual es considerado un riesgo para el proyecto. En la tabla 4.3 se muestran los datos
recolectados y totalizados para cada requerimiento.
Tabla 4.3. Ejemplo de datos para la priorización del requerimiento
Pesos 40 % 20 % 10 % 30 %

Total
id req Beneficio Penalidad Riesgo Costo
R1 6,4 4,8 1,6 6,3 1,7
R2 4,1 7,0 2,8 7,3 1,2
R3 6,8 7,8 3,1 2,8 3,7
R4 6,1 5,8 2,5 6,1 1,7
R5 5,3 6,0 3,6 2,1 3,3
R6 5,9 6,3 2,8 5,5 1,8
R7 3,1 3,6 1,6 3,8 1,5
R8 6,6 7,0 3,3 5,6 2,0
R9 7,0 3,6 2,5 4,1 2,3
R10 7,6 7,8 3,8 3,6 3,1
R11 7,5 7,5 3,8 3,5 3,1
R12 5,8 6,5 3,3 5,8 1,7
En la tabla 4.3 se muestran los cuatros criterios de evaluación que se tuvieron

en cuenta para el proyecto. Para este se acordó utilizar una escala de 1 a 10, donde
es posible utilizar cifras decimales.
Como lo indica Wiegers [9], es recomendable poner un peso a cada uno de los
criterios, si es necesario en el proyecto. Esto con el fin de priorizar también los cri-
terios en la especificación —por ejemplo, en este proyecto se define, por el grupo
de proyecto, que el riesgo que se presenta en cada requerimiento no es significativo;
por lo tanto, el porcentaje es el menor de todos los criterios (10 %)—. Esta opción
también puede aplicarse a los stakeholders, donde el porcentaje de decisión por per-
sona es diferente y los datos no son promediados. Esto es permitido mientras todo
el grupo de proyecto esté de acuerdo [10].
Siguiendo con el ejemplo, se puede observar que el criterio de mayor peso es

el beneficio (40 %); por lo tanto, se deduce que la apreciación del cliente para esta
primera entrega es mayor, así el costo que implique realizarlo no sea significativo.
Por ejemplo, el requerimiento R2 tiene un costo alto (implica tiempo de desarrollo,
análisis y diseño, personal); sin embargo, para esta entrega no queda dentro de los
requerimientos seleccionados para implementar (resaltados en verde), dado que para
el cliente el beneficio que alcanza a percibir no es tan alto como el de otros requeri-
mientos, en este tipo de situaciones es donde se valora una priorización a conciencia,
porque genera resultados bien argumentados.
También se puede ver el caso contrario: que son los requerimientos con bajo cos-
to, pero con un alto impacto para el cliente, en este caso el requerimiento R3, que
tiene el valor de prioridad más alto de los 12 requerimientos evaluados. Si en esta
evaluación solo se hubiera tenido en cuenta la opinión del grupo de desarrollo, muy
seguramente este requerimiento no se implementaría para la primera entrega, dado
su bajo costo para el desarrollador; sin embargo, para el cliente ver esta funcionalidad
en ejecución sí es importante, lo cual demuestra que en el proceso de priorización es
recomendable tener stakeholders con diferentes perspectivas (en este caso, el cliente).
A partir del ejemplo anterior, se concluye que la priorización es importante den-
tro del desarrollo del proyecto, pues permite planear de mejor manera el desarrollo
de requerimientos y obtener una mejor apreciación del cliente, que al final de todo
el proceso es uno de los objetivos.
4.2.2. Trazar
4.2.2.1. Localización
La localización es un procedimiento que consiste en asignar requerimientos de alto

nivel (véase sección “1.5.3. Requerimientos de sistema”) a los subsistemas específicos.
Es necesario que durante el desarrollo se incluyan tanto componentes de hardware
y software como productos complejos que contienen múltiples subsistemas de soft-
ware [2]. La asignación se realiza después de que los requerimientos de sistema se
especifican y la arquitectura del sistema se ha definido.
La localización es necesaria para asegurar que todos los requerimientos del sis-
tema son cumplidos por un subsistema o componente o por un conjunto de ellos
colaborando juntos, pues no es seguro que un requerimiento se cumpla con solo
un subsistema o componente. Daneva y Herrmann [14] presentan una forma de

distribuir los diferentes grupos donde pueden ser asignados los requerimientos:
• Subsistemas: grupo de funcionalidades lógicas.
• Componentes del sistema: hardware, software, entrenamiento y documentación.
La fase de diseño de la arquitectura es especialmente crítica para los sistemas

que incluyen componentes de software y hardware [2]. Una etapa importante para
el análisis es asignar requerimientos de sistema a los distintos subsistemas y com-
ponentes. Los requerimientos de sistema se deben descomponer en requerimientos
funcionales y no funcionales para los diferentes subsistemas y componentes [9].
Adicional a lo anterior, la información sobre la trazabilidad permite al equipo de
desarrollo abordar cada requerimiento en el diseño.
El proceso de localización ayuda a retroalimentar el proceso de análisis de re-
querimientos, de igual forma que el proceso de localización es retroalimentado por
el proceso de diseño [15], tal y como se muestra en la figura 4.2.
Figura 4.2. Localización dentro del proceso de ingeniería
Análisis de
requerimientos
Ciclo de
requerimientos
Análisis y
localización
Ciclo de diseño
Verificación Diseño
Fuente: tomado de [16].

“La localización es importante para permitir el análisis detallado de las necesi-

dades” [15], ya que una vez un conjunto de requerimientos es asignado a un com-
ponente, las necesidades individuales pueden surgir y ser analizadas para descubrir
más necesidades que pueden ser cubiertas por el mismo u otros componentes. Como
se muestra en la figura 4.2, en grandes proyectos la asignación estimula una nueva
ronda de análisis de cada subsistema [15].
Para llevar a cabo este proceso, Wiegers y Beatty [2] recomiendan empezar
siempre desde la parte general del sistema, ya que esto permite el surgimiento de
nuevos requerimientos durante el proceso [1], [15], es decir, desde los requerimien-
tos de negocio hasta los requerimientos del sistema, los cuales se encargan de describir la
arquitectura y la funcionalidad del sistema distribuida en diferentes componentes.
Como se muestra en la figura 4.2, para obtener un buen diseño, se debe iterar
con ayuda del análisis de requerimientos, porque una de las ventajas es que se pue-
den encontrar puntos de ambigüedad y confusión [2]. Si se encuentran muchos de
esos problemas, los requerimientos no eran lo suficientemente claros o no estaban
detallados de modo adecuado.
Adicional a lo mencionado, otra de las ventajas de realizar el proceso de loca-
lización es asegurar que el proceso de verificación (véase sección “3.2. Validación
y verificación”) pueda realizarse de la mejor manera, a fin de asegurar que los re-
querimientos, en su mayoría, han sido comprendidos, aceptados por el cliente y se
encuentran dentro del sistema.
Por último, la localización también está relacionada con el proceso de pruebas,
pues como mencionan Wiegers y Beatty [2], los requerimientos proveen la base para
el análisis de pruebas del sistema, pues estas deben ser verificadas contra lo que se
especifica en el Software Requirements Specification (srs); por lo tanto, los requerimien-
tos deben ser trazados y localizados (véase sección “4.2.2.2. Trazabilidad”). Esto se
debe a que sería posible que el producto muestre correctamente todas las conductas
descritas en los casos de prueba basados en el código, pero eso no quiere decir que
implemente correctamente las exigencias funcionales [2].
4.2.2.2. Trazabilidad
La trazabilidad de requerimientos es la habilidad de definir, capturar y seguir [17] la

vida del requerimiento hacia atrás y hacia adelante [18], es decir, es el grado como se
puede establecer una relación entre el requerimiento y su origen y el requerimiento y
los productos que se generan al implementarse [19]. Esto hace referencia al código,
a las pruebas y a la documentación [16]. Existen dos tipos de trazabilidad:
• Trazabilidad prerrequerimientos: se refiere a la habilidad de describir y seguir

la vida del requerimiento antes de que este sea incluido en la especificación de
requerimientos [16], es decir, seguir el rastro del requerimiento desde que este
es recolectado (véase sección “2.1. Recolección”) hasta el proceso de análisis de
requerimientos (véase sección “2.2. Análisis”).
• Trazabilidad posrequerimientos: hace referencia a la habilidad de describir y se-
guir la vida del requerimiento después de que este ha sido incluido en la especifi-
cación de requerimientos [16]. Es decir, se debe seguir el rastro del requerimiento
durante la especificación (véase sección “3.1. Especificación de requerimientos”)
hasta los elementos de la implementación, por ejemplo, un método que haya
sido incluido dentro del código para satisfacer el requerimiento. La figura 4.3
muestra a qué se refiere esta clasificación de la trazabilidad de los requerimientos.
Figura 4.3. Trazabilidad prerrequerimientos y trazabilidad posrequerimientos
Trazabilidad prerrequerimientos Trazabilidad posrequerimientos
Especificación de
Fuentes requerimientos Diseño Implementación
R1
D1 DC1
R2
R3 D2 DC2
R4 D3 DC3
R5
Además de los dos tipos anteriores, también existen los siguientes:

• Trazabilidad hacia atrás: puede ser vertical u horizontal. Si es vertical, se refie-
re a la habilidad de describir las relaciones del requerimiento desde las fuentes
(véase sección “2.1. Recolección”) hasta su especificación [18]. Si es horizontal,
se refiere a la relación existente entre las versiones que se desarrollan a lo largo

de la vida del requerimiento [17].
• Trazabilidad hacia adelante: al igual que la trazabilidad hacia atrás, esta puede ser
vertical u horizontal. Si es vertical, describe la relación entre los requerimientos
hasta las fases posteriores del ciclo de vida del desarrollo del sistema, es decir, los
requerimientos se pueden ubicar dentro de la implementación del sistema, en
documentos como manuales de usuario, en secciones del código. Si es horizontal,
esta trazabilidad hace referencia a las versiones posteriores del requerimiento.
En la figura 4.4 se muestra la diferencia entre estos cuatro tipos de trazabilidad,
para aclarar posibles confusiones.
Figura 4.4. Tipos de trazabilidad hacia adelante y hacia atrás
Hacia atrás Origen del

requerimiento
(Versión 2) (Versión 3) (Versión n)
Hacia atrás Hacia adelante

Horizontal
Vertical Otros artefactos intermedios

en los cuales se encuentran
los requerimientos.
Por ejemplo, en la especificación
de requerimientos,
el documento de diseño.
Realización de requerimiento.
Hacia adelante Ejemplo: en un módulo de
software de la implementación.
Fuente: tomado y adaptado de [16].

4.2.2.2.1. Beneficios de realizar la trazabilidad

Dentro de los beneficios identificados por Wiegers y Beatty [2] se encuentran:
• Utilizar la trazabilidad para verificar, validar (véase sección “3.2. Validación y
verificación”) y demostrar que se han implementado todos los requerimientos.
• Realizar cambios de manera correcta durante el mantenimiento, ya que teniendo
una matriz de trazabilidad (tabla 4.4), esta permite saber cuáles son los cambios
que se deben llevar a cabo en caso de que, por ejemplo, cambie un requerimiento
de negocio.
• Afirmar con seguridad cuál es el estado de implementación del sistema y cuáles
son los requerimientos que no se han implementado.
• Facilitar la reutilización de componentes del sistema, ya que la trazabilidad iden-
tifica los paquetes u otras unidades de código que están relacionadas tanto con
los requerimientos como con el diseño, las pruebas y otros paquetes.
Cuando se presentan un resultado inesperado después de ejecutar alguna de las

pruebas, se puede ir a la matriz de trazabilidad (tabla 4.4) para identificar cuáles
son los componentes o unidades de código que deben revisarse.
Tabla 4.4. Tabla de trazabilidad
Fuentes del Elementos Unidad de Casos de

Requerimiento Manuales
requerimiento de diseño código prueba
Fuente: adaptado de Westfall [18].
4.2.2.2.2. Información necesaria para realizar trazabilidad

Para realizar cualquier tipo de trazabilidad se necesita información que permita
establecer las relaciones entre los requerimientos y las demás etapas del proceso de
ingeniería de software. Algunos ítems para tener en cuenta son [16], [19]:
• Fuente del requerimiento: consiste en identificar cuál es el origen del requerimien-
to. Las fuentes se ven reflejadas en la recolección de los requerimientos en procesos
como las entrevistas con los stakeholders. Por esto es necesario tener en cuenta los
documentos que surgen de la especificación de requerimientos.
• Razón de ser del requerimiento: muestra la descripción del porqué el reque-
rimiento fue especificado.
• Personas involucradas con el requerimiento: relaciona el requerimiento con su

autor y con las personas encargadas.
• Requerimientos asociados: permite relacionar el requerimiento con otros reque-
rimientos que de alguna manera dependen de él.
• Diseño del sistema: relaciona por medio de la localización los componentes del
diseño del sistema con los requerimientos, así asegura que cada uno de estos es
implementado en el sistema.
• Arquitectura del sistema: relaciona el requerimiento con el módulo en el que se
encuentra implementado; pero no solo el módulo, también se debe relacionar el
requerimiento con la sección de código (ya sea un paquete, un objeto, una clase
o un método) que realmente implemente dicho requerimiento [4].
• Pruebas: permite relacionar los requerimientos con las pruebas que son diseñadas
para comprobarlo. Los requerimientos de usuario, por ejemplo, se relacionan con
pruebas de aceptación; mientras que los requerimientos de sistema se relacionan
con las pruebas de sistema e integración.
Antes de detallar cuáles son las técnicas que se usan para realizar la trazabilidad,
cabe notar que es necesario que tanto los requerimientos como los demás productos
que surgen durante el desarrollo del sistema, cuenten con un identificador único
(véase sección “4.2.1.1. Definir los atributos de los requerimientos”).
4.2.2.2.3. Técnicas utilizadas para realizar la trazabilidad

Matriz de trazabilidad: es una matriz de referencia cruzada [16], es decir, la matriz
muestra las relaciones entre los elementos ubicados en las filas con los elementos
ubicados en las columnas [4]. Esta matriz se utiliza con el fin de relacionar los re-
querimientos con los productos que se generan para satisfacerlos [20].
La anterior tabla 4.4 muestra un ejemplo de una tabla de trazabilidad, en la cual
se puede tener los dos tipos de trazabilidad vertical, tanto hacia adelante como hacia
atrás, ya que se describe desde la fuente del requerimiento, pasando por los elemen-
tos de diseño y las unidades de código, hasta los casos de prueba y los manuales.
Pero no solo se pueden realizar matrices de trazabilidad como la que se muestra
en la tabla 4.4, también se es posible hacer matrices que muestren la relación solo
entre dos elementos, por ejemplo, requerimientos y casos de uso, como la tabla 4.5.
Tabla 4.5. Matriz de trazabilidad
Requerimiento
uc-1 uc-2 uc-3 uc-4
funcional
rf-1 X
rf-2 X
rf-3 X
rf-4 X
rf-5 X X
Fuente: tomado de [16].
Lista de trazabilidad: es una técnica más simple y más compacta que la matriz,
donde cada requerimiento tiene una lista que muestra la información de trazabili-
dad. Estas listas, en general, como se muestra en la tabla 4.6, consisten en ubicar
en la primera columna los requerimientos y en la segunda poner los requerimientos
que están asociados o de los cuales depende el requerimiento de la primera columna
[16], lo cual más adelante permite crear una visualización gráfica más clara de los
requerimientos, como son los grafos de dependencias, que se utilizan para identificar
rutas críticas y ayudar con la priorización de requerimientos (véase sección “4.2.1.2.
Priorización”). La desventaja de utilizar las listas a cambio de la matriz de trazabili-
dad es que no se puede evaluar de manera inversa la relación [16].
Tabla 4.6. Lista de trazabilidad
Requerimiento Dependencia
rf-1 -
rf-2 rf-1
rf-3 rf-2, rf-1
rf-4 rf-1, rf-3
rf-5 rf-2

4.2.2.2.4. Ejemplo de localización y trazabilidad

El siguiente ejercicio tiene como objetivo principal aclarar las posibles dudas que
surjan al estudiar los conceptos de localización y trazabilidad. Para esto se listan a
continuación ciertos elementos que hacen parte de un proyecto realizado para la ma-
teria Ingeniería de Software de la Pontificia Universidad Javeriana, llamado Demented
Movie Game, el cual pretendía simular el juego Super Triumph.1 No se incluyen los
componentes registrados en el documento de diseño, debido a que el diseño de la
aplicación no puede ser resumido.
El ejercicio consiste en relacionar los requerimientos con su origen y los objetos
derivados. Para esto, al final del ejercicio se encuentran las tablas en las cuales se
debe registrar la trazabilidad tanto horizontal como vertical.
Reglas:
Tabla 4.7. Reglas del ejercicio de localización y trazabilidad
id regla Descripción
reg1 Super Triumph permite jugar en dos diferentes modalidades.
El jugador debe elegir con cuál característica apuesta. Puede elegir si la apuesta
a la mayor o a la menor. Eso quiere decir que dentro de las cartas que se ponen
reg2
en juego gana el que tenga el mayor o el menor puntaje, dependiendo si está a
la mayor o a la menor. Quien gana se lleva todas las cartas que están en la mesa.
El turno de un jugador termina cuando le pide a un contrincante una carta y el
reg3
contrincante no la tiene.
reg4 Los cuartetos se forman con la letra del identificador de la carta.
1
Super Triumph es la versión latina del juego Ace Trump, véase: https://en.wikipedia.org/wiki/Ace_Trumps
Casos de uso:
Tabla 4.8. Casos de uso del ejercicio de localización y trazabilidad
id caso de uso Nombre Descripción

Pedir carta a otro
imcu-023 El jugador puede pedir cartas a otro jugador.
usuario
imcu-024 Escoger modalidad Escoger la segunda modalidad que permite el juego.
Repartición equitativa de las cartas a todos los usuarios
presentes en la partida. En caso de que el número no
imcu-026 Repartir cartas permita una repartición equitativa de cartas, las cartas
se repartirán hasta que se terminen, en el orden de ins-
cripción de juego por parte de los usuarios.
El jugador, después de escoger la modalidad que desea
jugar, cuando tiene su turno de juego, toma la decisión
de jugar a la mayor de alguna de las características que
imcu-040 Apostar a la mayor
tiene la primera carta de su baraja. Consiste en apostar
su carta a que los demás jugadores tienen menor puntaje
que él en la característica que escoge.
El jugador, después de escoger la modalidad que desea
jugar, cuando tiene su turno de juego, toma la decisión
de jugar a la menor de alguna de las características que
imcu-041 Apostar a la menor
tiene la primera carta de su baraja. Consiste en apostar
su carta a que los demás jugadores tienen mayor puntaje
que él en la característica que escoge.
Componentes definidos:
Tabla 4.9. Componentes del ejercicio de localización y trazabilidad
Componente Descripción
Componente definido para reunir los requerimientos relacionados con la
Jugar
manera en la cual se desarrolla el juego.
Componente definido para contener los requerimientos relacionados con
Consultas
la base de datos.
Son los requerimientos asociados a la gestión de la información de los par-
Administración
ticipantes del juego.
Requerimientos:
Tabla 4.10. Requerimientos del ejercicio de localización y trazabilidad
id
Descripción Versión
requerimiento
El sistema debe validar que el usuario y la contraseña dados existan
imr002 2.0
en la base de datos.
imr002 El sistema debe validar los datos para acceder al sistema. 1.0
El sistema debe permitir que el anfitrión escoja la modalidad con
imr016 1.0
la cual se va a jugar la partida.
El sistema debe permitir al jugador en turno apostar al mayor
imr027 1.0
valor o al menor valor, en la segunda modalidad.
El sistema debe poder terminar el turno de un jugador si sus po-
imr039 1.0
sibilidades de juego son nulas en la primera modalidad.
El sistema debe validar cuál es la carta que tiene la mejor caracte-
imr024 2.0
rística elegida por el jugador en turno en la segunda modalidad.
El sistema debe permitir al jugador en turno apostar al mayor
imr027 2.0
valor en la segunda modalidad.
El sistema debe permitir al jugador en turno apostar al menor
imr028 2.0
valor en la segunda modalidad.
El sistema debe validar cuál carta es la mejor para la segunda
imr039 1.0
modalidad.
Pruebas:
Tabla 4.11. Pruebas del ejercicio de localización y trazabilidad
id prueba Qué se prueba Resultados

P1 Registro de usuario. Aprobado
P2 La carta seleccionada es la que tiene la mejor característica. Aprobado
El sistema asignó el turno al siguiente jugador, debido a que el
P3 Aprobado
jugador actual no puede realizar ninguna jugada.
El jugador puede seleccionar la modalidad con la cual quiere
P4 Aprobado
jugar una partida.
P5 El jugador apuesta “A la mayor”. Aprobar
P6 El jugador apuesta “A la menor”. Aprobado
Solución: la tabla 4.12 se debe utilizar para definir la localización de los requeri-
mientos. Para esto marque con una X la casilla correspondiente al componente en
el cual usted cree que se encuentra el requerimiento.
Tabla 4.12. Plantilla de requerimientos: ejercicio de localización y trazabilidad
Requerimiento Jugar Consultas Administración

imr002
imr016
imr027
imr039
imr024
En la tabla 4.13 registre las fuentes relacionadas con el requerimiento, a fin de

definir la trazabilidad vertical hacia atrás. Para la trazabilidad vertical hacia adelante,
ubique los casos de prueba relacionados con el requerimiento.
Tabla 4.13. Plantilla de requerimientos 2: ejercicio de localización y trazabilidad
Fuente 1 Fuente 2 Requerimiento Casos de prueba

imr002
imr016
imr027
imr039
imr024
En cuanto a la trazabilidad horizontal, utilice las tablas a continuación para ubi-

car las versiones de los requerimientos listados anteriormente (figura 4.5).
Figura 4.5. Plantilla de requerimientos 3: ejercicio de localización y trazabilidad
id requerimiento Versión id requerimiento Versión

4.2.3. Monitoreo y reporte
4.2.3.1. Definir políticas de administración
Definir las políticas de administración no es más que establecer el plan de adminis-

tración de requerimientos, en el cual se describen los procedimientos y los estándares
que deberían seguirse durante la administración de los requerimientos. Ya que se
define como el plan de administración de requerimientos, debe incluir a las personas
responsables de llevar a cabo las actividades del plan [21].
Para definir las políticas de administración de requerimientos, es preciso empezar
por una lista general que contenga los siguientes lineamientos [4]:
• Cuáles son los estándares que se deben seguir durante el proceso.
• Cómo se deben recolectar los requerimientos y cuáles son las personas involu-
cradas en este procedimiento.
• Cómo se van a identificar cada uno de los elementos contenidos en la especifi-
cación.
• Qué tipo de atributos se considerarán al momento de especificar cada requeri-
miento (véase sección “4.2.1.1. Definir los atributos de los requerimientos”).
• Qué tipo de atributos debe contener la especificación de requerimientos.
• Quiénes son los encargados de realizar la especificación de requerimientos.
• Teniendo en cuenta las políticas organizacionales, cómo se realizará el análisis
de los requerimientos.
• Especificar las políticas de administración de cambio de requerimientos (véase
sección “4.2.4. Administración del cambio”).
• Especificar quiénes serán los encargados, qué tipo y qué técnica de trazabilidad
será utilizada en el desarrollo del sistema (véase sección “4.2.2.2. Trazabilidad”).
• Definir cuál es la forma correcta de almacenar los requerimientos rechazados [22].
Una vez definida la lista de políticas (o si ya se tiene una lista general), se deben
seleccionar las políticas más adecuadas para el proceso de administración del pro-
yecto específico.
El plan de administración de requerimientos debe incluir secciones que se en-
carguen de definir:
• Los objetivos que se van a cumplir en el proceso de administración de reque-
rimientos. Se debe especificar todo, por ejemplo, los objetivos que se quieren
cumplir en determinado lapso, el alcance que tendrá el documento [21] y las
reglas aplicables en cualquier situación (ya sea una entrevista con el cliente o el
proceso que se realizará para solicitar algún cambio). Además, caben mencionar
las herramientas y capacitaciones sobre ellas para tener un mejor desempeño en

el proceso de administración [22].
• El proceso de recolección de requerimientos que se va a seguir [23] (véase sección
“2.1. Recolección”).
• Los estándares que se deben seguir para hacer la descripción de los requerimientos
y el srs, por ejemplo el estándar ieee 29148 [24].
• Cómo realizar el control de cambios [23] (véase sección “4.2.4. Administración
del cambio”). Dada la situación general de casi todos los proyectos, donde el
cambio en los requerimientos es más que inevitable, es necesario definir estra-
tegias que permitan administrar el cambio de los requerimientos, por ejemplo,
mantener un historial de cambios o establecer un canal único para el cambio
[21]; también se pueden usar herramientas que complementen esta actividad.
Una que menciona Ralph Young es Change Control Boards (ccb) [22].
• Cómo realizar las revisiones y la validación de los requerimientos: las revisiones no
requieren mucho trabajo y se obtiene un beneficio [22], que es el aseguramiento
de la calidad de los documentos e informes de la especificación.
• Cuál es la técnica (ya sea la matriz o la lista) y qué información [25] se utilizará
para llevar a cabo la trazabilidad (véase sección “4.2.2.2. Trazabilidad”).
• Las métricas de la administración de requerimientos: esto con el fin de conocer
en qué medida está avanzando el proyecto, por ejemplo, el estado de cada re-
querimiento, el número de cambios acumulado [21], etc.
• Qué excepciones en cuanto al plan se pueden realizar, en qué casos y con la au-
torización de quién.
Los beneficios que trae realizar un plan de administración de requerimientos son:

• Tener las políticas por escrito permite que las personas involucradas en el desa-
rrollo del proyecto tengan el conocimiento de cómo se debe hacer el proceso de
administración de requerimientos, lo cual permite que se ahorre tiempo durante
este proceso.
• De alguna manera, permite que el grupo de desarrollo sea proactivo a cualquier
eventualidad, lo cual es una gran ventaja, pues todos saben qué se debe hacer en
caso de que se presente un problema o retraso en el proceso.
En cuanto a los problemas que se pueden presentar, está el hecho de que se debe
consultar a las personas que están involucradas en el proceso de ingeniería de reque-
rimientos para modificar, proponer y revisar las políticas, con el fin de generar un
entrenamiento que asegure que las personas involucradas en el proceso conozcan y
apliquen dichas políticas, lo cual puede tomar mucho tiempo.
4.2.3.2. Almacenar requerimientos rechazados
Ya que los requerimientos rechazados pueden llegar a surgir durante alguna de las
etapas posteriores a la especificación de requerimientos (véase sección “3.1. Especifi-
cación de requerimientos”), es indispensable contar con un registro que los almacene
y las razones por las cuales se decidió que estos no deberían ser implementados, con
el fin de evitar un proceso de análisis de requerimientos (véase sección “2.2. Aná-
lisis”), a efectos de verificar por qué no se tuvieron en cuenta en el análisis anterior
[8]. Para almacenar estos requerimientos Sommerville y Sawyer [4] recomiendan
utilizar una base de datos.
4.2.4. Administración del cambio
4.2.4.1. Control de cambios
Varios autores, como Lam o Wiedemann, indican que “los cambios siempre ocurren
en un proyecto y en cualquier fase” [26]. Para esto se es preciso contar con un proceso
de control de cambios que le permita al equipo de trabajo manejar el cambio en los
requerimientos de la mejor manera, a fin de evitar cualquier incoherencia o atraso
dentro del proceso [27]. A estos efectos, se deben definir los lineamientos o las po-
líticas que se van a seguir cuando se va a efectuar un cambio en los requerimientos.
4.2.4.1.1. Proceso de control de cambios

El objetivo de definir un proceso de control de cambios es establecer cuáles deben
ser los pasos formales cuando se desea hacer un cambio en algún requerimiento.
Tener en cuenta los siguientes pasos permite ese control de cambios:
1. Cuál debe ser el proceso para realizar la solicitud del cambio en los requerimien-
tos: el definir un proceso de control del cambio permite asegurar que los cam-
bios propuestos son evaluados o aplicados de manera consistente [4]. Para una
solicitud de cambio se realizan las siguientes actividades:
• Llenar la plantilla de solicitud de cambios. Esta debe contener atributos como:
el número de la solicitud, la fecha en la cual se hace, el nombre de la persona
que solicita el cambio, la descripción del problema, la descripción del cam-
bio, el costo del cambio, y campos en los cuales posteriormente se aceptará
o se registrarán las razones por las cuales no se acepta el cambio [28]. En la
tabla 4.14 se muestra un ejemplo de cuáles son los atributos en la solicitud
del cambio.
Tabla 4.14. Posibles atributos para el control de cambios
Solicitud de cambio
Dueño Identificador único
Resultados del análisis Fecha de registro
Referencia Prioridad
Fecha de decisión Persona que propone
Estado Descripción
Justificación Explicación
• Analizar la solicitud de cambio [28] y cálculo de costos [26]: después de que es

realizada la solicitud del cambio, esta se analiza para verificar si es válido. Es
obligatorio evaluar si es o no factible, cuál es el efecto que tendrá y cuáles
son los costos en los que se incurrirá en caso de hacer la modificación en el
sistema. Existen tres factores principales que pueden influir o no en el cambio
de un requerimiento [26]:
* Los resultados del análisis (en particular la incidencia en los costos y el
calendario).
* La estructura técnica del sistema que se va a desarrollar.
* Las estructuras organizativas del cliente y el proveedor.
• Implementación del cambio: una vez aprobada la solicitud de cambio, puede
aplicarse al sistema, es decir, se debe modificar el srs, y si es necesario tam-
bién el diseño, la implementación, las pruebas y los manuales [29]. También
es preciso que se registre el cambio realizado, para informar a todo el grupo
de trabajo cuál fue el cambio de la especificación y qué debe modificarse en
adelante [26].
• Mantener el historial de cambios: cuando se efectúa el cambio es importante
almacenar toda la información pertinente a este.
2. Establecer un comité de control de cambios [4]: esto con el fin de asegurar que
todas las solicitudes de cambio serán evaluadas. Para establecer este comité se
siguen los siguientes pasos:
• Seleccionar a los miembros: el objetivo de este paso es seleccionar a las personas
correctas que se encarguen de evaluar todos los cambios. Todos los stakeholders
pueden ser parte del comité [28].
• Reuniones para evaluar los cambios: los miembros del comité deben reunirse de
manera constante para asegurarse de que las solicitudes de cambios se eva-
lúan y que son contestadas en un tiempo determinado [28].
3. Definir cómo notificar el cambio a los stakeholders afectados [4]: se debe informar
a los stakeholders afectados los cambios que fueron aceptados e implementados.
La ventaja de definir un proceso de control de cambios es que los cambios se

llevarán a cabo de manera controlada; entonces, cada vez que se realice uno, se ana-
lizará el impacto que generará en el proyecto, y al finalizar, los stakeholders podrán
conocer cuáles fueron las modificaciones hechas.
4.2.4.1.2. Usar una base de datos de requerimientos

Para mantener un mejor control sobre los cambios del sistema, se recomienda con-
tar con una base de datos de requerimientos que almacene todos los atributos, los
estados y los cambios realizados. Esta práctica trae beneficios como:
• Realizar búsquedas de grupos de requerimientos y mantener los enlaces de cada
requerimiento hacia otros requerimientos.
• Tener una base de datos que funciona como un repositorio en el cual se puede tra-
bajar de manera concurrente sin la posibilidad de que se presenten conflictos [4].
• Publicar al grupo el estado de la solicitud del cambio si fue aceptado, rechazado
o está pendiente para ser evaluado [30].
4.2.4.1.3. Ejercicio control de cambios

De acuerdo con el proceso mencionado para el control de cambios, defina qué atri-
butos debe contener la plantilla de solicitud de un cambio, a fin de que se acomode
al proceso de administración de requerimientos dentro su proyecto. Para esto utilice
la tabla 4.15.
Tabla 4.15. Ejercicio de control de cambios

Después de definir los atributos mínimos que se diligencian para solicitar un

cambio en los requerimientos, establezca el proceso para informar a los stakeholders
del proyecto que se ven afectados por los cambios realizados.
4.3. Beneficios de la administración de requerimientos
Dentro de los beneficios de hacer una buena administración de requerimientos se

encuentran:
• Permite verificar que el sistema que se está construyendo es el mismo durante
toda la fase de construcción [31].
• Reusabilidad, ya que la información que se registra durante la especificación del
proyecto puede ser reutilizada en la construcción de otros [26].
• Seguridad legal: ya que los requerimientos son prácticamente el único medio
escrito mediante el cual el cliente y el gerente del proyecto pueden comprobar
que el sistema que se entrega es el mismo sistema que se solicitó.
• Da seguridad para todos los stakeholders del proyecto, ya que se puede tener una
imagen clara de qué se está desarrollando, cómo y con qué [26].
• La administración de requerimientos permite tener una especificación de re-
querimientos clara que no se preste para malos entendidos ni confusiones [32].
• Como la administración de requerimientos tiene que agregar los atributos des-
critos en la sección “4.2.1.1. Definir los atributos de los requerimientos”, es muy
fácil generar un reporte de avance del proyecto de acuerdo con la información
registrada en el campo de estado del requerimiento, ya que indica el estado de
implementación de cada uno [26].
• Permite mantener los acuerdos sobre el alcance del proyecto entre los desarrolla-
dores, usuarios y los demás stakeholders del proyecto [32], esto además conlleva
que se genere un sistema de alta calidad [33].
• Se establecen los criterios de aceptación del sistema que será entregado [32].
• Permite generar las pruebas adecuadas que verifiquen que el proyecto tiene las
funcionalidades que el cliente solicitó [26].
• Se reducen las posibilidades de realizar la entrega del proyecto por fuera de la
fecha límite y se reducen los costos, debido a que la administración de requeri-
mientos disminuye el número de errores [33].
• Además de los beneficios ya mencionados, también se pueden obtener los bene-
ficios descritos en la sección “4.2.2.2. Trazabilidad”.
4.4. Beneficios de usar una herramienta de administración de requerimientos
Gracias al avance de la tecnología, se han desarrollado diferentes opciones para apoyar

los procesos de construcción de productos de todo tipo, y la construcción de software
no se queda atrás. Por esto existen en el mercado herramientas hechas con el propósi-
to de apoyar los procesos de administración de requerimientos dentro del desarrollo
de software. Cuando se utilizan este tipo de herramientas, son muchos los beneficios
con los que se pueden encontrar los grupos de desarrollo, dentro de los cuales se en-
cuentran los beneficios de negocio y los beneficios de proyecto.
4.4.1. Beneficios de negocio
Los beneficios que se pueden obtener son los siguientes:

• Ahorro de tiempo, ya que se automatizan muchos de los procesos de la adminis-
tración de requerimientos [34].
• Disminución en el estrés del equipo de desarrollo, debido a la automatización
de los procesos de trazabilidad y control de cambios [34].
• Algunas herramientas proporcionan permisos de acceso para los stakeholders, lo
cual asegura que los requerimientos del proyecto solo están disponibles para los
stakeholders involucrados [2].
4.4.2. Beneficios de proyecto
Los beneficios que se pueden obtener son los siguientes:

• Permiten que el proceso de control de cambios se realice de manera sencilla [35],
ya que estas herramientas pueden mantener un historial de cambios para cada
requerimiento. Ello posibilita la comunicación del cambio a los stakeholders y,
además, si se quiere restaurar algún estado anterior de algún requerimiento, se
puede hacer con facilidad [2].
• Es más eficiente el análisis de impacto de un cambio (véase sección “4.2.4. Ad-
ministración del cambio”), debido a que la información que se utiliza para llevar
a cabo este análisis se encuentra reunida en el mismo lugar [35].
• Se pueden guardar con mayor eficiencia los atributos del requerimiento, debi-
do a que los campos de los atributos de cada requerimiento ya están listos para
recibir la información [35].
• Algunas herramientas les permiten a los equipos estructurar sus requerimientos,

es decir, el equipo de desarrollo decide cuáles son los atributos con lo que se va
a especificar el requerimiento [34].
• Facilitan la implementación del proceso de trazabilidad [2]. En algunos casos se
pueden implementar la trazabilidad hacia adelante y hacia atrás (véase sección
“4.2.2.2. Trazabilidad”), ya que muchas de estas herramientas permiten la defi-
nición de casos de uso y componentes de diseño [35].
• Muchas de estas herramientas permiten saber casi de manera instantánea cuál
es el estado del proyecto en cuanto a implementación de requerimientos [2].
• Permiten mejorar la colaboración entre los stakeholders del proyecto [34].
• Aseguran que el producto que se está realizando es el producto que el cliente
está esperando [35].
Referencias
[1] K. Wiegers, More About Software Requirements: Thorny Issues and Practical Advice,
Press, 2013.
[3] “The Standish Group Report: chaos”. 2014. [Online]. Disponible: https://
www.projectsmart.co.uk/white-papers/chaos-report.pdf
Londres: John Wiley & Sons, 1997.
[6] The Land Software Engineering Centre, “Requirements Attributes”, 2010.
[Online]. Disponible: http://www.lsec.dnd.ca/qsd_current_version/sw_eng/
di/reqpro_attributes.htm
[7] J. Heumann, “The Five levels of requirements management maturity”, The
Rational Edge, 2003. [Online]. Disponible: http://vincentvanrooijen.com/
container%5CRequirements%20Management%5CThe%205%20levels%20
of%20ManagementMaturity_TheRationalEdge_Feb2003.pdf
[8] I. F. Hooks y K. A. Farry, Customer Centered Products: Creating Successful Products
Through Smart Requirements Management, 1.a ed. Nueva York: Amacom/
American Management Association, 2000.
[10] P. Berander y A. Andrews, “Requirements prioritization”, en Engineering

and Managing Software Requirements, A. Aurum y C. Wohlin, eds. Berlín,
Heidelberg: Springer, 2005, pp. 69-94.
[11] R. Botta y A. T. Bahill, “A prioritization process”, Eng. Manag. J., vol. 19, no. 4,
pp. 20-27, dic. 2007.
[12] D. Firesmith, “Prioritizing requirements”, J. Object Technol., vol. 3, no. 8,
pp. 35-48, 2004.
[13] N. Mead, “Requirements prioritization introduction”, United Stares Computer
Emergency Readiness Team (us-cert), set. 26, 2006. [Online]. Disponible:
https://www.us-cert.gov/bsi/articles/best-practices/requirements-engineering/
requirements-prioritization-introduction. [Citado: 29-mar-2017].
[14] M. Daneva y A. Herrmann, “Requirements prioritization based on benefit and
cost prediction: a method classification framework”, en 2008 34th Euromicro
Conference Software Engineering and Advanced Applications, 2008, pp. 240-247.
[15] M. Eriksson, K. Borg y J. Börstler, “7.2.1 The FAR Approach-Functional
Analysis/Allocation and Requirements Flowdown Using Use Case
Realizations”, incose Int. Symp., vol. 16, no. 1, pp. 950-964, jul. 2006.
[16] M. Hokkanen, “Requirements traceability”, tesis de maestría, Lappeenranta
University of Technology, Finlandia, 2001. [Online]. Disponible: https://core.
ac.uk/download/pdf/39921616.pdf
[17] F. A. C. Pinheiro, “Chapter 5”, en Requirements Traceability, s. d.
[18] L. Westfall, “Bidirectional requirements traceability”, The WestFallTeam,
2006. [Online]. Disponible: http://www.compaid.com/caiinternet/ezine/
westfall-bidirectional.pdf
[19] L. Antonelli y A. Oliveros, “Traceability en la etapa de elicitación de
requerimientos”, en Anais do WER01-Workshop em Engenharia de Requisitos,
Buenos Aires, Argentina, Novembro 22-23, 2001, pp. 1–19.
[20] Ludwig Consulting Services, “Interviewing User-Tips”. 2009. [Online].
Disponible: http://www.jiludwig.com/Interviews.html. [Consultado:
29-mar-2017] .
[21] Ludwig Consulting Services, “Requirements management”, en Introduction
to Requirements Management. [Online]. Disponible: http://www.jiludwig.com/
Requirements_Management.html. [Consultado: 29-mar-2017].
[22] R. R. Young, “Twelve requirements basics for project success”, CrossTalk. The
Journal of Defense Software Engineering, dic. 2006. [Online]. Disponible: http://
www.compensationanalytics.com/_resources/RequirementsBasics.pdf
[23] Construction Management Guide, “Create requirements management plan”,

2009. [Online]. Disponible: http://www.cmguide.org/archives/1420
[24] International Organization for Stardization, “iso/iec/ieee 26531:2015.
Systems and software engineering”. [Online], dic. 2011. Disponible: https://
www.iso.org/standard/43090.html
[25] “Guidelines: Requirements Management Plan”. [Online]. Disponible: http://
sce.uhcl.edu/helm/rationalunifiedprocess/process/modguide/md_rmp.htm.
[Cosultado: 29-mar-2017].
[26] C. Hood, S. Wiedemann, S. Fichtinger y U. Pautz, Requirements Management:
The Interface Between Requirements. Berlín: Springer, 2008.
[27] A. Kobayashi y M. Maekawa, “Need-based requirements change management”,
en Proceedings. Eighth Annual ieee International Conference and Workshop On the
Engineering of Computer-Based Systems-ecbs 2001, 2001, pp. 171-178.
[28] “Activity: Establish Change Control Process”. [Online]. Disponible: http://
sce.uhcl.edu/helm/rationalunifiedprocess/process/activity/ac_epcmp.htm.
[Consultado: 29-mar-2017].
[30] M. Hoffmann, N. Kuhn, M. Weber y M. Bittner, “Requirements for
requirements management tools”, en Requirements Engineering Conference,
2004. Proceedings. 12th ieee International, 2004, pp. 301-308.
Springer, 2010.
[32] Oakleigh Consulting, “When is Projects go Bad”. [Online]. Disponible:
http://www.oakleigh.co.uk/page/1388/White-Papers/Whitepaper-Articles/
When-IS-Projects-Go-Bad. [Consultado: 29-mar-2017].
[33] A. Davis y D. Leffingwell, “Using requirements management to speed delivery
of higher quality applications”, 1995. [Online]. Disponible: http://citeseerx.
ist.psu.edu/viewdoc/download?doi=10.1.1.194.7124&rep=rep1&type=pdf
[34] “Requirements Management Tools - Overview”. [Online]. Disponible:
http://pmblog.accompa.com/2009/07/30/requirements-management-tools-
overview/. [Consultado: 29-mar-2017].
[35] “Benefits of Requirements Management Tool - Product Management School”.
[Online]. Disponible: http://www.productmanagementschool.com/w1/
Benefits_of_Requirements_Management_Tool. [Consultado: 29-mar-2017].
Capítulo 5
Herramientas
El proceso de administración de requerimientos, como se puede observar en la sección

“4.2. Proceso de administración de requerimientos” está compuesto por diferentes
actividades que si se realizan manualmente, requieren tiempo; mientras que el uso
de alguna herramienta que apoye el proceso de administración puede agilizarlas y
asegurar la consistencia de los requerimientos dentro de todas las fases de desarrollo
de software [1].
5.1. Características
En el mercado se encuentra gran variedad de herramientas exclusivas para la admi-

nistración de requerimientos, que cumplen con diferentes actividades del proceso.
Según Hoffmann et ál. [2], existen diferentes características para construir una
herramienta de este tipo, dentro de los cuales se encuentran:
• Clasificación de requerimientos:
* A la hora de recolectar e identificar requerimientos, es importante tener en
cuenta qué tipo de requerimientos se están manejando, para así evitar con-
fusiones dentro del proyecto, más adelante.
* El factor que se debe evaluar a la hora de escoger una herramienta es si la forma
en la que se realiza la clasificación es estricta o flexible, es decir, si la herramienta
permite una clasificación predeterminada o personalizada.
• Atributos de los requerimientos: para el proceso de especificación (véase ca-

pítulo 2, “Recolección y análisis”), es importante definir la documentación de
_157
los requerimientos al inicio del proceso, pues de esto depende la continuidad

durante las siguientes fases. Existen, como se menciona en la sección “4.2.1.1.
Definir los atributos de los requerimientos”, atributos que no son de utilidad y
que pueden llegar a ser innecesarios hasta el punto de ser un obstáculo dentro
de la especificación. Por esta razón, es primordial identificar qué atributos se van
a usar dentro del proyecto. Al igual que el ítem anterior, lo que se debe evaluar
es qué tanta flexibilidad tiene la herramienta respecto al manejo de los atributos
dentro de la herramienta.
• Trazabilidad: es un componente importante para integrar el proceso de reque-
rimientos al proyecto [3], pues permite hacerle seguimiento durante todo el
proceso de desarrollo del sistema. El factor que se va a evaluar es qué tipo de
trazabilidad realiza y cómo la muestra al usuario.
• Control de cambios: como se menciona en la sección “4.2.4. Administración del
cambio”, dentro de un proyecto los cambios son inevitables, y más cuando se
trata de requerimientos; por lo tanto, se deben manejar los cambios de la mejor
forma posible para disminuir el impacto en el proyecto. Se debería evaluar si la
herramienta cuenta con un historial donde se registren los diferentes cambios que
sufre un requerimiento, quién realizó los cambios y cuáles fueron los artefactos
que se vieron afectados.
• Visualización de los requerimientos: esta característica está enfocada en el usuario
y no hace parte del proceso de administración de requerimientos; sin embargo,
se considera un criterio de evaluación, porque de alguna forma facilita el uso de
la herramienta, pues es más sencillo ver un gráfico sobre las dependencias, las
relaciones o las clasificaciones que tienen los requerimientos, que una gran lista
de requerimientos sin clasificar.
• Factor plus: como es de suponer, no todas las herramientas son iguales; existen
factores adicionales que la hacen única. Aquí se debe considerar aquel factor
plus que sea de mayor utilidad para facilitar el proceso de administración de
requerimientos.
5.2. Beneficios
Además de las ventajas de aplicar un proceso de administración de requerimientos

(véase sección “4.4. Beneficios de usar una herramienta de administración de re-
querimientos”), existen otros beneficios que se pueden obtener dentro del proyecto
y la administración de requerimientos si se utiliza una herramienta que agilice este
proceso. Estas ventajas son [2]:
Herramientas _159
• El apoyo a la adquisición, la especificación, la agrupación y la atribución de los

requerimientos.
• El apoyo a su derivación a niveles más detallados, mantenimiento y ajuste de
los atributos.
• La ejecución de casos y entornos de prueba que se definan y relacionen.
• El relacionar los requerimientos con los componentes de diseño, implementación
y pruebas para realizar el seguimiento y la localización de estos.
• El desarrollo distribuido dentro de la organización.
5.3. Análisis de herramientas
Después de evaluar herramientas como Rational RequisitePro, Eterprise Architect,

TopTeam Analyst y GetherSpace, difíciles de obtener, debido a los altos costos, se
observó que el proceso de administración de requerimientos que estas respaldan
tiene falencias en algunas áreas del proceso, por ejemplo, la visualización de reque-
rimientos, ya que se presenta la lista de requerimientos; pero esta no permite ubicar
las rutas críticas.
En algunas de estas herramientas también se ve que el proceso de trazabilidad
solo se puede realizar con los casos de uso, y no con los demás productos que se ge-
neran durante el desarrollo de software.
Al igual que las herramientas anteriores, Caliberrm tiene una gran desventaja:
la licencia para la adquisición. Además de que la trazabilidad que realiza se basa solo
entre los requerimientos, a pesar de que la visualización de la tabla de trazabilidad
es clara para el usuario, igualmente no existe un gráfico que permita la visualización
de las dependencias entre los requerimientos.
Por otra parte, también fueron evaluadas herramientas gratuitas rem y osrm;1 sin
embargo, al igual que las herramientas anteriores, poseen falencias. Por ejemplo, rem
no es multiusuario y solo aplica para algunos sistemas operativos de Windows y no
maneja líneas base dentro del proceso de ingeniería de requerimientos. rem y osrmt
no generan un documento orientado al usuario; los documentos que genera son para
uso interno del grupo y no analiza el impacto con respecto al control de cambios.
No obstante, existen características que son deseables implementar, como la vi-
sualización de la trazabilidad a través de una matriz de relaciones entre las diferentes
fases y los requerimientos, la visualización de jerárquica de los requerimientos, la
1
Disponibles en http://sourceforge.net
flexibilidad para personalizar el proyecto, el manejo de la localización con los docu-

mentos y el manejo de dependencias entre los requerimientos.
5.4. Easy Requirement Management Tool: ermt 2
Un ejemplo de las herramientas para la administración de requerimientos es la apli-

cación ermt, con unas funcionalidades útiles para la administración de requerimien-
tos, descrita en las secciones anteriores. A continuación, se muestran las principales
características de esta aplicación (figura 5.1).
Figura 5.1. ermt: página principal
Fuente: [4].
En la figura 5.2 se muestra que la herramienta permite elegir atributos para el

proyecto y dar flexibilidad a los usuarios, lo cual permite al grupo de proyecto estu-
diar y elegir qué atributos se requieren manejar durante el proceso.
2
Herramienta desarrollada como un proyecto de grado del programa de Ingeniería de Sistemas de la Pontificia
Universidad Javeriana.
Herramientas _161
Figura 5.2. ermt: selección de Atributos
Fuente: [5].
Para la definición del requerimiento ermt proporciona una plantilla acorde a

los atributos que se han definido para el proyecto. Estos requerimientos podrán ser
listados para su completa visualización. Adicionalmente, existen algunos campos que
no son diligenciados directamente por el usuario, sino que son obtenidos a través de
cálculos (priorización) o relaciones hechas durante la administración.
Para la priorización de requerimientos ermt ofrece dos métodos: el de Wiegers
[6] y el de asignación numérica. El usuario puede escoger alguno de los dos, depen-
diendo de la complejidad del proyecto (figura 5.3).
Figura 5.3. ermt: priorización
Fuente: [5].
Adicional a la priorización, ermt ofrece la posibilidad de establecer relaciones

entre los requerimientos (dependencia o igualdad). Ello genera grafos de implemen-
tación que permiten tener una visualización general del estado del proyecto. En la
figura 5.4 se muestra uno de los grafos que se puede generar con esta herramienta.
Figura 5.4. ermt: grafos

Atributos y clasificación
Igualdad
Verificación y validación
52 9 10 11
Igualdad
Priorización 12
53 42 14
13
Igualdad
41 51 16 15
Administración del cambio
27 22 17 19
Localización y trazabilidad
26 28 43 20 18 21 38 35
Igualdad
Igualdad
Grafo y reportes
25 24 43 33 40 34 37 30
Igualdad
45
39 36 29
44 46 49 32 31
Igualdad
48
50
47
Fuente: [5].
Herramientas _163
ermt también tiene la funcionalidad de generación de reportes, los cuales per-

miten condensar los datos recolectados y administrados en un archivo. Estos ge-
neralmente son archivos en Excel e imágenes. En la figura 5.5 se muestra uno de
los reportes que genera la aplicación. Este reporte le permite al usuario conocer el
estado del proyecto.
Figura 5.5. ermt: reportes
Fuente: [5].
ermtpermite crear líneas base que agrupan los requerimientos en diferentes

conjuntos definidos por el usuario. Las líneas base creadas por el usuario pueden ser
consultadas y eliminadas dependiendo de la necesidad del usuario. En la figura 5.6 se
pueden observar algunas líneas base con los requerimientos que hacen parte de ellas.
Figura 5.6. ermt: línea base
Fuente: [4].
Para el seguimiento de los cambios (administración del cambio) realizados en

los requerimientos, ermt cuenta con la funcionalidad “Control de cambios” que le
facilita al usuario verificar por medio de una descripción, versión, estado y respon-
sable los cambios que se han registrado en cada requerimiento. En la figura 5.7 se
muestra el registro de los cambios.
Figura 5.7. ermt: seguimiento a cambios
Fuente: [4].
Para administrar el riesgo de los requerimientos, esta herramienta le proporcio-

na al usuario asociar, editar y consultar los riesgos. En la herramienta se definen los
riesgos en términos de volatilidad, identidad y complejidad (figura 5.8), dependiendo
del nivel de cada riesgo ingresado por el usuario. ermt provee un nivel de prioridad
para cada técnica de mitigación; de esta forma facilita la selección de acciones pre-
ventivas o correctivas para cada requerimiento.
Figura 5.8. ermt: gestión de riesgos
Fuente: [4].
Herramientas _165
En cuanto al seguimiento de problemas en los requerimientos, ermt le ofrece al

usuario esta funcionalidad, en la cual es posible asociar, editar y eliminar (figura 5.9)
uno o más problemas en cada uno de los requerimientos del proyecto.
Figura 5.9. ermt: problemas en los requerimientos
Fuente: [4].
Además, ermt genera un reporte con el historial de todos los problemas que han
sido asociados a los requerimientos (figura 5.10).
Figura 5.10. ermt: reporte, problemas de requerimientos
Fuente: [4].
Por otro lado, ermt les permite a los usuarios generar en archivo csv (comma
separated values), una matriz de trazabilidad (véase sección 4.2.2.2), la cual cuenta
con todos los requerimientos registrados bajo un proyecto en la herramienta y la
relación que estos tienen con los casos de uso (figura 5.11).
Herramientas _167
Figura 5.11. ermt: reporte de trazabilidad
Fuente: [4].
Por último, la aplicación apoya el proceso de verificación y validación de los reque-

rimientos a través de plantillas, propuestas por diferentes autores, entre ellos Wiegers
y Beatty [7]. Esta información también puede presentarse a través de los reportes que
son generados por ermt.
ermt surge debido a las necesidades identificadas durante la implementación de
proyectos en asignaturas como Ingeniería de Software o Arquitectura de Software
de la Pontificia Universidad Javeriana, ya que, al intentar utilizar algunas herramien-
tas disponibles en el mercado y acordes al ámbito educativo, estas no contaban con
los métodos y técnicas necesarias para realizar una administración de requerimientos
que se ajustara a dichas asignaturas.
Referencias
[1] J. Heumann, “The Five levels of requirements management maturity”, The

Rational Edge, 2003. [Online]. Disponible: http://vincentvanrooijen.com/
container%5CRequirements%20Management%5CThe%205%20levels%20
of%20ManagementMaturity_TheRationalEdge_Feb2003.pdf
[2] M. Hoffmann, N. Kuhn, M. Weber y M. Bittner, “Requirements for
requirements management tools”, en Requirements Engineering Conference,
2004. Proceedings. 12th ieee International, 2004, pp. 301-308.
[3] R. R. Young, “Twelve requirements basics for project success”, CrossTalk. The
Journal of Defense Software Engineering, dic. 2006. [Online]. Disponible: http://
www.compensationanalytics.com/_resources/RequirementsBasics.pdf
[4] C. Duarte, “Herramienta para la administración de requerimientos de los
proyectos de las asignaturas de Ingeniería y Arquitectura de Software de la
Pontificia Universidad Javeriana”. [Online]. http://pegasus.javeriana.edu.
co/~CIS1410IS08/index.html [Consulta: 11 de abril de 2016].
[5] L. Zorro y V. Loaiza, “Herramienta para la administración de requerimientos
de los proyectos de las asignaturas de Ingeniería y Arquitectura de Software de
la Pontificia Universidad Javeriana”. [Online]. http://pegasus.javeriana.edu.
co/~CIS1010IS05/ [Consulta: 11 de abril de 2016].
Press, 2013.
Capítulo 6
Caso de estudio 4-Med
Aplicar adecuadamente el proceso de ingeniería de requerimientos es de vital im-

portancia para obtener resultados exitosos en las actividades asociadas a la gestión,
la construcción y la producción del producto de software. Si además se aplican estos
conceptos a un área particular y compleja como lo es el área de la salud, se identifican
algunos elementos que complementan dicho proceso de ingeniería de requerimien-
tos, como la habilidad de comunicación con usuarios de diferentes áreas (no solo
personal médico, sino administrativo), el conocimiento de dominio del problema,
la comprensión del lenguaje propio del área, los aspectos legales relacionados con
el manejo de la información, etc. En este capítulo se muestra una aplicación prác-
tica del proceso de ingeniería de requerimientos en el área de salud mediante un
framework denominado 4-Med [1].
6.1. Complejidad de los sistemas de salud
Cuando un ingeniero de requerimientos aborda por primera vez la especificación de

un sistema de salud y se relaciona con stakeholders que trabajan en esta área (médicos,
enfermeras, odontólogos, administrativos, auxiliares, etc.), encuentra una brecha
entre lo comunicado por los usuarios y lo que él mismo comprende. El área de la
salud contiene terminología usual para estos profesionales; pero desconocida para
el ingeniero de requerimientos. De igual manera, los profesionales de otras áreas
no necesariamente tienen experiencia o conocen el vocabulario usado al desarrollar
sistemas de información; por lo tanto, surge la necesidad de establecer mecanismos
_169
comunes que permitan aclarar dichos términos e instaurar un vocabulario compren-

sible tanto para el área de tecnología como para el área de la salud.
Por otra parte, los sistemas de salud son altamente dinámicos, factores del con-
texto como la normatividad vigente, la evolución clínica del paciente y los registros
clínicos electrónicos [2], la interactividad de los pacientes con software que les per-
miten ayudar a monitorear su estado de salud [3], las nuevas relaciones entre los
profesionales de salud y los pacientes, gracias a sistemas e-health [4] o a la aparición
de sistemas de salud en la nube o e-health cloud [5], que hacen que la flexibilidad del
sistema sea una característica requerida.
Finalmente, los sistemas de salud son sistemas sociotécnicos que requieren gran
interacción con los usuarios e integración de los diferentes intereses de los stakehol-
ders; por eso, desde el proceso de requerimientos es necesario establecer una gran
interacción y comunicación con los usuarios que les permita sentirse parte activa
del proceso. Debido a todas estas características, es necesario adaptar el proceso de
requerimientos para la construcción de los sistemas e-health.
6.2. Características para incluir en los sistemas e-health
Como se observa en la figura 6.1, los sistemas e-health, al tener impacto en las per-
sonas, requieren un trabajo sociotécnico en la etapa de recolección y especificación
de requerimientos; también es importante involucrar a todos los stakeholders para
tener en cuenta los diferentes intereses y llegar a una negociación en un determinado
momento, establecer una terminología común [6] y evitar así que el proyecto de
software fracase. El contexto es también es un aspecto importante: incluye caracterís-
ticas políticas o sociales en el contexto externo y políticas propias de la organización
en el contexto interno [7]. En un estudio realizado por Ammenwerth et ál. [8], en
un hospital de Sudáfrica, se identificaron las principales fallas en la construcción y
uso del sistema Limpopo, que pueden ser aplicables a diferentes sistemas e-health
no exitosos. Las fallas incluyen, entre otras:
• No tomar en cuenta la cultura de las organizaciones de salud, ni capacitar a los
usuarios finales con la visión general de todo el proyecto.
• Subestimación de la complejidad de los procesos clínicos.
• Diferentes expectativas entre el patrocinador, desarrolladores y usuarios finales.
• Contexto muy cambiante para el cual no se adapta el sistema.
• No buscar ni aprender las lecciones aprendidas de proyectos similares.
Caso de estudio 4-Med _171
Figura 6.1. Características asociadas a la complejidad de sistemas e-health
Contexto Terminología
altamente común
dinámico
Interacción
con stakeholders
Ante estas fallas en la elaboración de sistemas e-health, se identifica que muchas

de ellas tienen su causa en el proceso de ingeniería de requerimientos que se aplicó.
Factores como el no identificar todos los usuarios interesados a través de un adecua-
do análisis y clasificación de stakeholders, no tomar en cuenta el contexto y cultura
organizacional mediante el análisis de documentos o entrevistas con los usuarios o
un contexto cambiante para el cual no se adapta el sistema y en el cual no se realizó
la administración correcta del cambio, hacen necesario que estas características par-
ticulares se tomen en cuenta en el proceso de ingeniería de requerimientos cuando
se trabaja con sistemas e-health.
6.3. El framework 4-Med
Teniendo en cuenta los factores mencionados, se propone un framework que tome en

cuenta las diferentes vistas del sistema y permita establecer un mecanismo común
de comunicación entre los usuarios finales y el equipo de desarrollo del sistema de
información. 4-Med [1] contempla diferentes técnicas, modelos y métodos de in-
geniería de requerimientos en cuatro fases: 1) recolección, 2) análisis y priorización,
3) especificación y 4) verificación y validación, integrando investigación-acción
participativa como el enfoque social necesario en todas las fases e incluyendo el co-
nocimiento de dominio médico.
El framework 4-Med tiene cuatro vistas transversales: social, dominio, empre-
sarial y técnica, que permiten al ingeniero de requerimientos integrar objetivos de
negocio, intereses de los stakeholders, conocimiento del dominio médico y aspectos
técnicos relevantes a su proceso de requerimientos. Gracias a estas vistas, se contem-
pla el sistema desde diferentes escenarios que se ven reflejados en diferentes tipos
de requerimientos, como requerimientos de negocio, requerimientos funcionales y
restricciones de diseño, que serán usados y usados en etapas propias de la gestión
de requerimientos.
Las anteriores vistas se integran al proceso de ingeniería de requerimientos me-
diante las fases de recolección, priorización, especificación, verificación y validación
tradicionales. Articular las vistas con las fases del proceso de requerimientos permite
al ingeniero incluir los diferentes intereses, restricciones y aspectos clave de negocio
en las diferentes etapas. Aunque el proceso de articular fases y vistas permite ges-
tionar el requerimiento desde diferentes ópticas, se detectó, sin embargo, que al no
tener claro el tipo de artefactos que se producen en las vistas, no existe una manera
tangible de comprobar el avance en el proceso de requerimientos. De igual manera,
la administración de requerimientos debe contemplarse tanto para la gestión del
cambio como para su traza y monitoreo. 4-Med incluye artefactos asociados a estas
vistas para definir que entregables permiten ver el trabajo realizado en cada una de
ellas y son usados en el componente de administración de requerimientos.
6.4. Vistas de 4-Med
El framework 4-Med [1] contempla cuatro vistas necesarias para modelar aplicaciones
e-health, como se puede ver en la figura 6.2. Estas vistas son la social, la empresarial,
la de dominio y la técnica, esto para contemplar los requerimientos y su impacto
desde diferentes ópticas.
Figura 6.2. Vistas de 4-Med
Social
Dominio Empresarial
Técnica
6.4.1. Vista social
Hace uso de la investigación-acción participativa. En este tipo de investigación se

trabaja activamente con la población objeto de la investigación, generando pro-
puestas que solucionen los problemas identificados por la misma comunidad. “La
investigación participativa busca que la población abordada sea motivada a participar
de la investigación como agente activo, produciendo conocimiento e interviniendo
en la propia realidad” [9].
Este tipo de investigación, ampliamente usada en las ciencias sociales, aplicada
mediante el framework 4-Med, permitirá al grupo de profesionales en salud identi-
ficar las problemáticas existentes en el proceso actual y cómo el futuro sistema los
apoyará para realizar sus actividades. Aquí, el acompañamiento de un ingeniero de
requerimientos es vital para concretar un trabajo con este grupo de stakeholders, al
brindarles el espacio para que ellos mismos sugieran posibles soluciones a su proble-
mática. La participación de los stakeholders de manera activa se contempla en cada
una de las fases de 4-Med, pues se necesita de su apoyo para una correcta especifi-
cación de los requerimientos.
Como artefacto de esta vista, se puede definir la elaboración de una matriz con
dos columnas, una donde todos los participantes describan la situación actual (as-is),
para delimitar así el problema que se requiere resolver, y otra columna donde se
describa la situación deseada (to-be), para identificar así aspectos clave de requeri-
mientos que se deben contemplar en el proceso. Se aclara que como la vista social
es transversal a todo el proceso de requerimientos, este documento debe estar en
continua actualización por parte del ingeniero de requerimientos.
6.4.2. Vista empresarial
Cuando se está realizando el proceso de requerimientos de un nuevo sistema y se

está trabajando con stakeholders de diferentes áreas, es importante articular el nuevo
sistema con los objetivos estratégicos de la organización, pues de alguna manera el
nuevo sistema estará apoyando actividades que respaldan las metas planteadas por
la empresa. Por esto, cuando se realice el proceso de requerimientos, es fundamen-
tal preguntarse ¿cómo el nuevo sistema impactará los objetivos estratégicos de la
organización? Desde el framework 4-Med se sugiere, mediante la vista empresarial
identificar los objetivos del negocio que se apoyarán con el nuevo sistema, modelos
de objetivos, modelos de negocio y contemplar tanto las políticas de la organización
como la normatividad vigente asociada al nuevo sistema e-health.
Es importante destacar aquí que factores como la calidad del servicio prestado
a los pacientes, la optimización de los recursos tanto administrativos como los uti-
lizados en las diferentes instituciones de salud, el cumplimiento de la normatividad
vigente en cuanto a tratamiento de datos de pacientes y otros aspectos asociados a
la administración de salud son clave y no se pueden omitir en la vista empresarial. El
apoyo del grupo de ingenieros industriales encargados de los diferentes procesos de
la organización es ideal al trabajar en la vista empresarial. Como artefacto asociado
a esta vista, se puede incluir un modelo del tipo Business Process Management Nota-
tion (bpmn), que permita identificar a todos los stakeholders como el nuevo sistema
apoyará los procesos de la organización.
6.4.3. Vista de dominio
Al realizar el proceso de requerimientos para sistemas e-health existen gran cantidad

de términos propios del área de salud que hacen parte de las funcionalidades a im-
plementar en el nuevo sistema. La comprensión de esta terminología es fundamental
en la captura de los requerimientos puesto que en los documentos que se elaboren en
la etapa de especificación debe quedar claro tanto para el grupo técnico como para
los stakeholders las funcionalidades a implementar en el nuevo sistema. El reto aquí
es cómo lograr que el conocimiento médico se tenga en cuenta en la construcción
del nuevo sistema. Mediante la vista de dominio se proponen diferentes mecanis-
mos con los cuales se facilite la comunicación entre las dos áreas y se contemple el
conocimiento del dominio médico. Como artefacto asociado a esta vista se puede
construir una ontología o un vocabulario.
6.4.4. Vista técnica
En el proceso de requerimientos es importante incluir los diferentes modelos, técnicas

y métodos que describan las características técnicas del sistema, y si bien es cierto que
en la etapa de requerimientos del proceso de software hasta ahora se está realizando
un primer acercamiento al sistema que se desea diseñar y construir, da los aspectos
clave que se contemplarán en las posteriores etapas de análisis, diseño y desarrollo.
Desde el punto de la vista técnica, se deben incluir requerimientos funcionales, no
funcionales y del sistema, teniendo en cuenta aspectos como sistemas existentes con
los cuales el nuevo sistema debe interactuar, restricciones de diseño, restricciones
de interfaz, restricciones en cuanto a plataformas, etc., que deben quedar claras en
la especificación de requerimientos. Los artefactos relacionados con esta vista son
los documentos técnicos asociados a requerimientos que permitan identificar los
requerimientos y sus restricciones.
6.5. Fases de 4-Med
Como se puede ver en la figura 6.3, el framework 4-Med [1] tiene cuatro fases que
hacen parte del proceso de requerimientos: recolección, priorización, especificación,
verificación y validación.
Figura 6.3. Fases de 4-Med
Recolección
Verificación Priorización
y validación
Especificación
6.5.1. Recolección
Para la recolección de requerimientos (fase 1 de 4-Med), el uso de diferentes técnicas

como entrevistas, encuestas u observación en sitio de los usuarios, permitirá generar
espacios de discusión donde los usuarios manifiesten sus inquietudes y necesidades
frente al nuevo sistema. En estos espacios de participación es importante contar con
mínimo un representante de cada uno de los grupos involucrados en el proyecto.
Técnicas como Peeling the Onion [10], que permite descubrir stakeholders de una ma-
nera recursiva, puede ayudar a identificar los interesados; posterior a este proceso
es importante almacenar la información de contacto de cada uno de ellos, en una
plantilla en la cual se incluya la empresa, el área, el nombre, el cargo, el teléfono y
el correo electrónico de contactos. Estos stakeholders pueden agruparse en diferentes
grupos o niveles acorde al proyecto, por ejemplo, el grupo médico, el grupo técni-
co y el grupo administrativo, para que sea más fácil la priorización, la validación
y la verificación de los requerimientos por cada uno de los grupos. En esta fase se
requiere la participación activa de los stakeholders tanto desde la vista social como
desde la vista de dominio.
Para la comprensión del entorno por parte del grupo técnico se sugieren reu-
niones en las cuales se expongan, por parte del personal médico a los ingenieros de
software, casos concretos en un lenguaje no médico de las patologías de salud que el
sistema apoyará. Es posible emplear modelos gráficos no técnicos para explicar una
situación en particular, e incluso el uso de técnicas como la actuación o storyboards,
que permitirán narrar qué se espera del sistema. Como resultado de esta actividad,
se puede construir un glosario o una ontología para tener de referencia en el pro-
yecto. Otra forma de obtener retroalimentación (y así una verificación inicial de
requerimientos) es mediante la construcción de un prototipo en el cual el personal
técnico exponga a los stakeholders lo que se plantea desde el sistema.
6.5.2. Análisis y priorización
Wiegers y Beatty [11] proponen el cálculo de la prioridad mediante la asignación

de valor a las variables valor, costo y riesgo en una escala de 1 a 9, siendo 1 lo me-
nos relevante y 9 el más importante por cada requerimiento. Esta asignación de
valores se hace por parte de cada uno de los interesados; posteriormente, mediante
la fórmula expuesta en la sección “4.2.1.2.5. Priorización basada en valor, costo y
riesgo”, se calcula la prioridad de cada requerimiento, que luego será avalada por
cada uno de los grupos identificados en la fase 1.
Los requerimientos capturados también se deben agrupar, teniendo en cuenta
que pueden ser requerimientos de negocio, requerimientos del proceso, requeri-
mientos del sistema, requerimientos del software y restricciones. Una descripción
detallada de estos tipos de requerimientos se puede consultar en el capítulo 1. Esta
agrupación permitirá ver las diferentes relaciones entre los requerimientos y revisar
que, en la priorización dada, estas relaciones se hayan contemplado (dependencia
de requerimientos, simultaneidad, etc.). En esta fase, la vista empresarial y la vista
técnica cobran gran importancia.
6.5.3. Especificación
En esta fase se producen los diferentes artefactos que pueden ser documentos tipo
Software Requirements Specification (srs), casos de uso, historias de usuario, modelos
visuales no técnicos que ayuden a una mejor comprensión del problema y prototipos
evolutivos. Estos documentos se deben revisar con los stakeholders para detectar posi-
bles inconsistencias en su redacción. En esta fase toma gran relevancia la vista técnica.
6.5.4. Verificación y validación
En esta fase se confrontará con el usuario que el sistema que se construirá es lo que
realmente se espera. Además, se verifica la consistencia en las relaciones de requeri-
mientos, su completitud y que los requerimientos apoyen la estrategia empresarial.
Durante todo el proyecto es importante la administración de requerimientos en
cada una de las vistas, así: la gestión del cambio en la vista social, manteniendo la
interacción con los stakeholders en todo el proceso de requerimientos; la vista técnica,
asociada con los artefactos que allí se construyen, y la vista de dominio y empresarial,
para incluir cambios en normatividad o políticas que no se hayan contemplado. En
cuanto a la captura y trazabilidad de los requerimientos, es importante también cons-
truir matrices de trazabilidad, tal como se mostró en la sección “4.2.2.2.3. Técnicas
utilizadas para realizar la trazabilidad”, que permitan identificar asociaciones entre:
• Requerimientos y objetivos del negocio.
• Requerimientos y casos de uso.
• Requerimientos y stakeholders.
• Requerimientos y artefactos de diseño.
El uso de estas matrices permite confrontar cómo los requerimientos se han con-
templado teniendo en cuenta la vista empresarial (requerimientos y objetivos del
negocio), cómo se ha involucrado a los stakeholders mediante la vista social y cómo
desde la vista técnica se producen casos de uso y diferentes artefactos que indican al
grupo de tecnología el trabajo que va a seguir. En la tabla 6.1 se aprecia un ejemplo
de la matriz de trazabilidad de requerimientos frente a casos de uso en la cual se
puede ver en qué casos de uso se está expresando lo solicitado en el requerimiento.
Tabla 6.1. Matrices de trazabilidad en 4-Med
Caso de uso
Requerimiento
cu-01 cu-02 cu-03 cu-04
1.1 X
1.2 X
1.3 X X
1.4 X
1.5 X
1.6 X X
Aplicar el framework 4-Med en sistemas e-health permite utilizar las diferentes

herramientas que brinda la ingeniería de requerimientos, agrupándolas en las cua-
tro fases que disminuyen la brecha entre lo técnico, el conocimiento de dominio
médico y los intereses empresariales, que mitigan el riesgo de construir sistemas de
información que no se adapten a las necesidades del usuario final.
Una aplicación práctica del framework 4-Med se llevó a cabo en la construcción
de un sistema de gestión de calidad de la atención en salud en una empresa admi-
nistradora de salud. Inicialmente, el grupo de profesionales de salud, conformado
por médicos y enfermeras, manifestó a la líder técnica de sistemas su necesidad de la
construcción de un software que les ayudara a realizar su labor. Teniendo en cuenta
la vista social, se inició el proceso de requerimientos con la participación activa de los
usuarios mediante investigación-acción participativa. Se realizaron diferentes talleres
con los profesionales de salud para aclarar el dominio de negocio y el contexto de
salud en el país, teniendo en cuenta la normatividad vigente. De ahí se construyó
un glosario usado en las fases de recolección y especificación y un documento de
restricciones de negocio para considerar en el software. Aquí se incluyeron las vistas
empresarial, de dominio y técnica.
Para seleccionar a los participantes de los talleres se seleccionaron stakeholders
mediante el método peeling the onion. En los talleres también se trabajó con prototipos,
diagramas de casos de uso y mapas de navegación para aclarar conceptos técnicos a
los usuarios. La priorización de requerimientos se realizó mediante la fórmula suge-
rida por Wiegers y Beatty [11]. Se definieron criterios de aceptación para la etapa de
verificación y validación y la gestión del cambio se realizó mediante documentos de
análisis de impacto y priorización de las nuevas necesidades. Como se puede obser-
var, mediante un trabajo interdisciplinar, se logró construir un software de utilidad
para el usuario, contemplando el dominio, el impacto empresarial, un trabajo social
con los usuarios y artefactos técnicos mediante el uso de las vistas y fases de 4-Med.
Referencias
[1] P. Amórtegui, A. P. Quimbaya y M. Torres, “4Med requirements process in

E-Health applications”, en Computing Colombian Conference (9ccc), 2014 9th,
2014, pp. 42-47.
[2] C. Pagliari, D. Detmer y P. Singleton, “Potential of electronic personal health
records”, bmj, vol. 335, no. 7615, pp. 330-333, ag. 2007.
[3] M. Chan, E. Campo, D. Estève y J.-Y. Fourniols, “Smart homes - current features
and future perspectives”, Maturitas, vol. 64, no. 2, pp. 90-97, oct. 2009.
[4] M. J. Ball y J. Lillis, “E-health: transforming the physician/patient relationship”,
Int. J. Med. Inf., vol. 61, no. 1, pp. 1-10, abr. 2001.
[5] E. AbuKhousa, N. Mohamed y J. Al-Jaroodi, “e-Health cloud: Opportunities
and challenges”, Future Internet, vol. 4, no. 3, pp. 621-645, 2012.
[6] S. A. Fricker, Requirements Engineering for Digital Health. Nueva York: Springer.
[7] D. Boddy, G. King, J. S. Clark, D. Heaney y F. Mair, “The influence of context
and process when implementing e-health”, bmc Med. Inform. Decis. Mak., vol. 9,
p. 9, 2009.
[8] E. Ammenwerth, S. Gräber, G. Herrmann, T. Bürkle y J. König, “Evaluation
of health information systems-problems and challenges”, Int. J. Med. Inf.,
vol. 71, no. 2, pp. 125-135, set. 2003.
[9] P. Demo, Investigación participante: mito y realidad. Barcelona: Lumen, 2009.
Press, 2013.
Autores
Ingeniera de sistemas de la Pontificia Universidad Javeriana. Profesionalmente, se

ha desempañado en el análisis, diseño e implementación de requerimientos para
diferentes sectores privados de la economía.
Ingeniera de sistemas de la Pontificia Universidad Javeriana. Actualmente, se desem-

peña como consultora en el diseño y la construcción de requerimientos en un sistema
dedicado al área de recursos humanos. Dentro de sus intereses se encuentran la in-
geniería de software, la ingeniería de requerimientos y los sistemas de información.
Ingeniero de sistemas de la Universidad Nacional de Colombia, magíster en cien-

cias de la computación de la Mississippi State University en Estados Unidos. Ha
sido docente de las asignaturas de Ingeniería de Software, Sistemas de Información
y Análisis y Programación Orientada a Objetos, además de los cursos de Tópicos
Avanzados en Ingeniería de Software e Ingeniería de Requerimientos en la Maestría
en Ingeniería de Sistemas y Computación de la Pontificia Universidad Javeriana.
_181
Sus áreas de interés son la ingeniería de software, enfocada a la ingeniería de reque-

rimientos, pruebas, calidad y desarrollo basado en componentes, así como en siste-
mas inteligentes.
Ingeniero de sistemas de la Universidad Javeriana, magíster en ciencias de la com-

putación y doctor (cum laude, Premio Aart Bosman) en ingeniería de sistemas de la
Universidad de Delft en Holanda. Ha sido profesor e investigador de ingeniería de
software, sistemas de información, tic y sociedad, pensamiento sistémico y gestión
del conocimiento, además de haber participado en proyectos de consultoría para el
sector público y privado. Actualmente, sus campos de acción se centran en el sector de
atención de emergencias y de la salud. Actualmente es profesor del Departamento
de Ingeniería de Sistemas de la Pontificia Universidad Javeriana.
Ingeniera de sistemas de la Universidad Distrital Francisco José de Caldas con espe-

cialización en ingeniería de software de la misma universidad. Magistra en ingeniería
de sistemas y computación de la Pontificia Universidad Javeriana. Cuenta con una
amplia experiencia en análisis y desarrollo de sistemas de información en diferentes
empresas del sector público y privado. En el sector académico, ha realizado inves-
tigaciones en temas asociados a minería de datos, minería de texto e ingeniería de
requerimientos.
Este libro fue realizado en caracteres
TwCenMTCondensed y AmeriGarmnd BT,
e impreso en bond beige de 70 gramos,
en el mes de febrero de 2018 en
Bogotá, D. C., Colombia.

Ingeniería de Requerimientos - Taco

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingeniería de Requerimientos - Taco

Cargado por

Copyright:

Formatos disponibles

Vanesa Carolina Loaiza Carvajal

Reservados todos los derechos Corrección de estilo:

Primera edición: Bogotá, D. C., febrero de 2018 Impresión:

Torres Moreno, Miguel Eduardo, autor

182 páginas : ilustraciones ; 24 cm

CDD 001.6425 edición 19

Figura 1.1. Clasificación de requerimientos 25

Tabla 1.1. Comparación requerimientos de negocio vs. sistema 28

Más recientemente, gracias a las metodologías de desarrollo ágil, se propuso

Este texto presenta, inicialmente, en el capítulo 1 una introducción y justifica-

La ingeniería de requerimientos, como área de conocimiento, ha evolucionado en la

• Asegurar que los gerentes de proyecto puedan tener información adecuada de

Para poder presentar la ingeniería de requerimientos es necesario introducir algunos

1.1. ¿Qué es un requerimiento?

A través de los años se han expuesto diferentes definiciones de la palabra reque-

1.2. Atributos de calidad del requerimiento

La mayor dificultad al usar los requerimientos como el elemento guía en la construc-

6. Priorizado: asignar una prioridad a cada requerimiento, característica o caso de uso

Cuando los requerimientos se agrupan, bien sea en una especificación de reque-

4. Delimitado: el conjunto de requerimientos se mantiene dentro de un alcance

1.3. Documentos de especificación de requerimientos

Los requerimientos son generalmente agrupados en especificaciones. Documen-

En particular, el Estándar iso/iec/ieee 29148 de 2011 [1] presenta una descrip-

1.4. Atributos de un requerimiento

Con el fin de construir, organizar, evaluar, cuantificar y gestionar los requerimientos,

3. Razón de ser: descripción que permite justificar el requerimiento en contexto del

El uso de estos atributos no es enteramente obligatorio, pero su uso en contex-

1.5. Tipos de requerimientos

1.5.1. Requerimientos de negocio

Figura 1.1. Clasificación de requerimientos

Requerimientos Requerimientos Requerimientos

Funcionalidad Requerimientos Requerimientos

Fuente: elaboración propia a partir de [3], [4], [13]-[16].

Según Karl Wiegers, este tipo de requerimientos “describen cómo mejoraría el

Se tienen las siguientes reglas de negocio:

De las anteriores reglas de negocio se derivan los siguientes requerimientos:

1.5.2. Requerimientos de usuario

Como se nota en la figura 1.1, los requerimientos de negocio permiten identificar

1.5.3. Requerimientos del sistema

Estos requerimientos son versiones ampliadas de los requerimientos de usuario,

1.5.4. Requerimientos funcionales

Tabla 1.1. Comparación requerimientos de negocio vs. sistema

Característica Requerimiento de negocio Requerimiento de sistema

Se recomienda que la especificación de este tipo de requerimientos sea completa

Koelsch [21] propone, además, diversos tipos de requerimientos funcionales que

1.5.5. Requerimientos no funcionales

Otro tipo de requerimiento de sistema son los requerimientos no funcionales, tam-

No obstante, no solo hacen referencia al sistema que se va a desarrollar, también

1.5.6. Requerimientos del producto

• Interoperabilidad (interoperability): la habilidad que debe tener el sistema para

Los requerimientos de eficiencia deben especificar cuál es el rendimiento esperado,

La portabilidad refleja la capacidad del sistema de cambiar de un ambiente a otro. El

• Adaptación (adaptability): los requerimientos que quieran reflejar la adaptación

1.5.7. Requerimientos organizacionales

Este tipo de requerimientos “son la consecuencia de políticas y procedimientos or-

Un ejemplo de un requerimiento organizacional es: “El proceso de desarrollo

1.5.8. Requerimientos externos

• Requerimientos de interoperabilidad: definen cómo el sistema debe interactuar

Ian Sommerville da un ejemplo de un requerimiento externo: “El sistema no

[1] “iso/iec/ieee International Standard - Systems and software engineering -

[9] E. Hull, K. Jackson y J. Dick, Requirements Engineering, 3.a ed. Londres:

[23] M. Barbacci, M. H. Klein, T. A. Longstaff y C. B. Weinstock, “Quality