METODOLOGA PARA LA ADQUISICIN Y GESTIN DE

REQUERIMIENTOS EN EL DESARROLLO DE SOFTWARE PARA

PEQUEAS Y MEDIANAS EMPRESAS (PYMES) DEL
DEPARTAMENTO DE RISARALDA.

CRISTIAN ANDRES DE LA CRUZ LONDOO

GUSTAVO ANDRES CASTRO GUEVARA

UNIVERSIDAD TECNOLOGICA DE PEREIRA

FACULTAD DE INGENIERIA
MAESTRIA EN INGENIERIA DE SISTEMAS Y COMPUTACIN
PEREIRA
2015

i
 METODOLOGA PARA LA ADQUISICIN Y GESTIN DE
REQUERIMIENTOS EN EL DESARROLLO DE SOFTWARE PARA
PEQUEAS Y MEDIANAS EMPRESAS (PYMES) DEL
DEPARTAMENTO DE RISARALDA.

CRISTIAN ANDRES DE LA CRUZ LONDOO

GUSTAVO ANDRES CASTRO GUEVARA

Tesis presentada como requisito parcial para optar por el ttulo de:
Magister en ingeniera de sistemas y computacin

Director:
Ing. CESAR ALBERTO COLLAZOS ORDOEZ
Phd Computer Science
Universidad del Cauca

UNIVERSIDAD TECNOLOGICA DE PEREIRA

FACULTAD DE INGENIERIA
MAESTRIA EN INGENIRIA DE SISTEMAS Y COMPUTACIN
PEREIRA
2015

ii
 Nota de aceptacin:

Firma del presidente del jurado

Firma del jurado

Firma del jurado

Pereira, 14/ 05/ 2015

3
AGRADECIMIENTOS

Primero agradecemos al Dr. Cesar Alberto Collazos Ordoez, coordinador del grupo IDIS
en la Universidad del Cauca y director de esta tesis; Su conocimiento, orientacin y
persistencia ha permitido finalizar con xito este documento.
Segundo deseamos mencionar al Magister Felipe Gallego de la Universidad Catlica de
Manizales y Magister Fernando Barraza de la Universidad San Buenaventura de Cali. Sus
habilidades y experticia han aportado en algunos aspectos a la construccin de este
documento.
Tercero agradecer profundamente al grupo de investigacin GRANDE de la Universidad
Tecnolgica de Pereira, por apoyarnos en este proceso.
Cuarto sentimos gratitud hacia las empresas del departamento de Risaralda las cuales nos
permitieron conocer su proceso de ingeniera de requerimientos y con esto iniciar la
estructuracin de la presente metodologa.
Quinto agradecer por el tiempo y la amabilidad por parte de los expertos de las
instituciones Universidad Nacional de San Juan (Argentina), BHP (Argentina) y
Universidad del Cauca (Colombia), al realizar la evaluacin de la metodologa en el juicio
de expertos.
Por ultimo agradecer finalmente a todas las personas que de una u otra forma apoyaron la
realizacin del trabajo final.
Los Autores

4
DEDICATORIA

A nuestros padres por su gran apoyo moral a lo largo de nuestros estudios y a nuestras
esposas que nos han impulsado a lograr nuestras metas.
Los Autores

5
 TABLA DE CONTENIDOS

1. RESUMEN ...................................................................................................................... 1
2. INTRODUCCION........................................................................................................... 2
3. MARCO TEORICO Y ESTADO DEL ARTE ............................................................... 4
4. OBJETIVO GENERAL Y OBJETIVOS ESPECFICOS ........................................... 11
4.1 Objetivo General .................................................................................................. 11
4.2 Objetivos especficos ........................................................................................... 11
5. METODOLOGIA REQUERIMIENTOS .................................................................... 12
5.1 Recopilacin de datos .......................................................................................... 12
5.1.1 Problemas tericos del anlisis de requerimientos ........................................ 14
5.1.2 Inconvenientes en las pequeas empresas y la academia de la regin de
Risaralda ...................................................................................................................... 16
5.2 Construccin de la metodologa para la adquisicin y gestin de requerimientos en
la industria de Risaralda .................................................................................................. 18
5.3 Validacin de la metodologa ............................................................................... 19
6. PRE-ANALISIS .......................................................................................................... 21
6.1 Entrega de procesos organizacionales .................................................................. 21
6.2 Reunin Inicial (Kick off) .................................................................................... 22
6.3 Acuerdo de nivel de servicio y confidencialidad ................................................. 23
6.4 Descripcin del problema .................................................................................... 24
6.4.1 Identificacin del problema .......................................................................... 24
6.4.2 Planteamiento de la solucin ........................................................................ 25
6.4.3 Estimacin costo inicial ................................................................................ 30
6.4.4 Presentacin propuesta solucin ................................................................... 32
6.5 Documentacin .................................................................................................... 35
7. ELICITACIN ............................................................................................................ 36
7.1 Clasificacin del proyecto .................................................................................... 36
7.1.1 Tipo de proyecto idea de negocio ................................................................. 37
7.1.2 Tipo de proyecto desarrollo a la medida. ...................................................... 37
7.2 Identificacin de stakeholders .............................................................................. 40
7.3 Tcnicas de elicitacin ......................................................................................... 43
7.3.1 Descripcin tcnicas de elicitacin ............................................................... 43
7.3.2 Tcnicas para ideas de negocio (Start Up) .................................................... 47
7.3.3 Tipo de proyecto desarrollo a la medida. ...................................................... 48

6
 7.4 Lista de requisitos. ............................................................................................... 49
7.5 Documentacin. ................................................................................................... 50
8. ANALISIS ................................................................................................................... 51
8.1 Verificacin requerimientos ................................................................................. 53
8.1.1 Matriz de trazabilidad ................................................................................... 54
8.1.2 Matriz de rastreo ........................................................................................... 54
8.1.3 Negociacin y resolucin de conflictos. ....................................................... 55
8.2 Lmites del sistema ............................................................................................... 55
8.3 Clasificacin ......................................................................................................... 56
8.3.1 Descomposicin funcional ............................................................................ 56
8.3.2 Priorizacin ................................................................................................... 56
8.4 Estimacin ............................................................................................................ 57
8.5 Documentacin .................................................................................................... 57
9. ESPECIFICACION ..................................................................................................... 58
9.1 Documentacin con historias de usuario. ............................................................. 61
9.2 Documentacin requerimientos del usuario ......................................................... 61
9.2.1 Especificacin de requerimientos del usuario ............................................... 61
9.2.2 Modelado de requerimientos del usuario ...................................................... 62
9.3 Documentacin requerimientos del sistema ......................................................... 63
9.3.1 Especificacin requerimientos del sistema ................................................... 63
9.3.2 Modelado requerimientos del sistema .......................................................... 67
9.4 Generacin de prototipos ..................................................................................... 70
9.4.1 Categoras del prototipado ............................................................................ 71
9.4.2 Tcnicas de prototipado ................................................................................ 72
9.5 Documentacin .................................................................................................... 73
10. VALIDACION ........................................................................................................ 75
10.1 Validacin con prototipos no funcionales ............................................................ 76
10.1.1 Objetivos de la evaluacin ............................................................................ 76
10.1.2 Previo al proceso de evaluacin .................................................................... 77
10.1.3 Ejecucin de la evaluacin ........................................................................... 78
10.2 Validacin y negociacin de requerimientos ....................................................... 79
10.2.1 Verificacin y validacin de requerimientos ................................................ 79
10.2.1.1 Inspecciones internas ................................................................................ 80
10.2.1.2 Validacin de requerimientos con los stakeholders ................................. 80
10.2.2 Negociacin de requerimientos .................................................................... 82

7
 10.2.2.1 Pre-Negociacin ........................................................................................ 83
10.2.2.2 Negociacin .............................................................................................. 83
10.2.2.3 Post-Negociacin: ..................................................................................... 85
10.3 Documentacin .................................................................................................... 85
11. GESTION DE CAMBIOS ....................................................................................... 86
11.1 Identificacin de las necesidades de cambio ........................................................ 88
11.2 Medir el impacto de los cambios sobre los requerimientos actuales .................... 88
11.3 Estimacin costo inicial ....................................................................................... 89
11.4 Presentacin propuesta ......................................................................................... 90
11.5 Negociacin de aplicacin de los cambios ........................................................... 90
11.6 Documentacin .................................................................................................... 91
12. LA INGENIERIA DE REQUERIMIENTOS EN LA ACADEMIA ....................... 92
13. DESARROLLO DE APLICATIVO SOPORTE A LA METODOLOGIA ............ 93
14. RESULTADOS Y DISCUSIN ............................................................................. 99
15. CONCLUSIONES Y TRABAJOS FUTUROS ..................................................... 102
16. ANEXO 1: FORMATOS, INSTRUMENTOS Y HERRAMIENTAS .................. 104
17. ANEXO 2: INFORME RESULTADOS FASE RECOLECCION DE DATOS ... 137
17.1 Introduccin: ...................................................................................................... 137
17.2 Ficha tcnica ...................................................................................................... 139
17.3 Revisin terica .................................................................................................. 139
17.4 Anlisis de resultados en las empresas ............................................................... 141
17.4.1 Anlisis general de las empresas y los encuestados .................................... 141
17.4.2 Anlisis de fiabilidad. ................................................................................. 143
17.4.3 Anlisis proceso ingeniera de requerimientos general de las empresas. .... 143
17.4.4 Anlisis del uso de tcnicas en ingeniera de requerimientos en las empresas
162
17.4.5 Anlisis agrupado de los resultados por empresas ...................................... 163
17.5 Anlisis de resultados en pregrados y egresados. ............................................... 164
17.5.1 Anlisis general de las enseanzas de la ingeniera de requerimientos en
pregrados segn personal docente y egresados .......................................................... 164
17.5.2 Anlisis de las tcnicas enseadas en ingeniera de requerimientos en los
pregrados segn personal docente y egresados .......................................................... 174
17.6 Encuesta ingeniera de requerimientos para empresas ....................................... 175
17.7 Entrevista ingeniera de requerimientos para empresas ..................................... 177
17.8 Encuesta ingeniera de requerimientos para universidades ................................ 178
17.9 Encuesta ingeniera de requerimientos para egresados ...................................... 179
8
 17.10 Conclusiones .................................................................................................. 180
18. ANEXO 3: PUBLICACIONES REALIZADAS ................................................... 181
19. ANEXO 4: GUA DE ENSEANZA DE LA INGENIERA DE
REQUERIMIENTOS
191
20. ANEXO 5: ARTEFACTOS CONSTRUCCION APLICATIVO WEB ................ 194
21. ANEXO 6: INSTRUMENTO DE VALIDEZ DE CONTENIDOS ...................... 203
22. BIBLIOGRAFA ................................................................................................... 208

9
 TABLA DE ILUSTRACIONES
Ilustracin 1: Entradas y salidas del proceso de ingeniera de requerimientos. .................... 18
Ilustracin 2: Fases de la metodologa propuesta por los autores. ........................................ 19
Ilustracin 3: Ventajas y desventajas de los prototipos de baja fidelidad ............................. 26
Ilustracin 4: Ventajas y desventajas de los prototipos de alta fidelidad .............................. 26
Ilustracin 5: Ejemplo de un boceto. .................................................................................... 27
Ilustracin 6: Ejemplo de prototipos en papel. ..................................................................... 29
Ilustracin 7: Ejemplo de mockup realizado en balsamiq mockups ..................................... 30
Ilustracin 8: Matriz bidimensional de escala de Cockburn adaptada para la presente
metodologa. ......................................................................................................................... 39
Ilustracin 9: Mapa de stakeholders ..................................................................................... 41
Ilustracin 10: Ejemplo mapa de stakeholders ..................................................................... 42
Ilustracin 11: Proceso de anlisis de requerimientos .......................................................... 51
Ilustracin 12: Mtodo en espiral para proceso requerimientos ........................................... 52
Ilustracin 13: Principales caractersticas relacionadas con trazabilidad y creacin de
asociaciones de las cuatro herramientas ms importantes de gestin de requerimientos ..... 55
Ilustracin 14: Especificacin y modelos segn tipo proyecto ............................................. 59
Ilustracin 15: Costos usando especificacin formal ............................................................ 60
Ilustracin 16: Proceso documentacin requerimientos ....................................................... 60
Ilustracin 17: Diagrama flujo de datos ................................................................................ 62
Ilustracin 18: Proceso de especificacin y modelado del software ..................................... 63
Ilustracin 19: Estructura de una especificacin algebraica para un sub sistema ................. 64
Ilustracin 20: Ejemplo de mquina de estado finito............................................................ 67
Ilustracin 21: Esquema de especificacin en Z ................................................................... 67
Ilustracin 22: Modelo contexto cajero automtico .............................................................. 68
Ilustracin 23: Ejemplo modelo de objetos .......................................................................... 68
Ilustracin 24: Ejemplo diagrama de secuencias UML ........................................................ 69
Ilustracin 25: Ejemplo red Petri. ......................................................................................... 69
Ilustracin 26: Proceso de creacin de prototipo .................................................................. 71
Ilustracin 27: Ejemplo de maquetacin presentada por Toni Granollers ............................ 72
Ilustracin 28: Ejemplo de Storyboard navegacin presentado por Toni Granollers ........... 73
Ilustracin 29: Proceso de evaluacin de requerimientos mediante el uso de prototipos ..... 76
Ilustracin 30: Proceso de evaluacin de solucin de conflictos, basado en QARCC
(Quality Attribute Risk and Conflict Consultant) ................................................................. 84
Ilustracin 31: Evolucin de los requerimientos a lo largo del tiempo a causa de cambios en
la comprensin del problema. ............................................................................................... 87
Ilustracin 32: Proceso realizado para elaborar y evaluar propuestas de cambios ............... 88
Ilustracin 33: Pantalla de inicio del aplicativo web ............................................................ 93
Ilustracin 34: Funcionalidades del aplicativo web .............................................................. 94
Ilustracin 35: Pantalla consulta marco terico .................................................................... 94
Ilustracin 36: Pantalla consulta gua acadmica ................................................................. 95
Ilustracin 37: Pantalla descarga resumen metodolgico ..................................................... 95
Ilustracin 38: Pantalla descarga resumen metodolgico ..................................................... 96

10
vii
1
0
Ilustracin 39: Pantalla formatos obligatorios diligenciados por fase .................................. 96
Ilustracin 40: Pantalla fase metodologa ............................................................................. 97

11
vii
1
1
Ilustracin 41: Pantalla advertencia de formatos sin diligenciar de fases previas .............. 98
Ilustracin 42: Resultado juicio de expertos ..................................................................... 100

12
vii
1
2
 TABLA DE TABLAS
Tabla 1: Principales ventajas y desventajas referentes tericos............................................ 10
Tabla 2: Sectores y herramientas aplicadas .......................................................................... 13
Tabla 3: Ficha tcnica herramientas...................................................................................... 13
Tabla 4: Valor segn personas por proyecto......................................................................... 39
Tabla 5: Clasificacin de los proyectos para metodologa ................................................... 40
Tabla 6: Tcnicas y enfoques ............................................................................................... 46
Tabla 7: Complementos y alternativas entre tcnicas, tcnicas complementarias
(Representadas con la letra C) y alternativas (Representadas con la letra A) 47
Tabla 8: Tcnicas vs objetivos propuestos para la metodologa ........................................... 47
Tabla 9: Stakeholders y tcnicas usadas para las ideas de negocio (startUp) ....................... 47
Tabla 10: Tcnicas segn clasificacin del proyecto ............................................................ 49
Tabla 11: Principales ventajas y desventajas referentes tericos .......................................... 54
Tabla 12: Elementos mnimos formato SRS......................................................................... 62
Tabla 13: Ventajas e inconvenientes de la evaluacin realizada en el entorno ..................... 78

xii
 1. RESUMEN

La ingeniera de requerimientos es un proceso de gran importancia del ciclo de vida de un

proyecto de software. Los desarrollos de software presentan una probabilidad a fracasar
cercana al 70% con respecto a los sobre costos del proyecto [1], adems de ser ms
costosas las correcciones de los errores en las fases posteriores que en la fase de
requerimientos. Si bien existen guas de trabajo como lo son CMMI y SWEBOK estas no
definen las herramientas que deben ser aplicadas en cada una de las etapas ni el cmo
desarrollarlas; por otra parte se evidencia la poca valoracin que se da a esta rea por parte
de la academia (pregrados universitarios).
La presente investigacin plantea la creacin de una metodologa para la adquisicin y
gestin de requerimientos en el desarrollo de software para pymes del departamento de
Risaralda. Para ello se desarrollaron tres fases:

Recopilacin de datos
Estructuracin de la metodologa
Validacin de la metodologa
La validacin us como instrumento el juicio de expertos en donde se evidenci que la
industria del software podr disminuir los errores, el costo y el tiempo de desarrollo de
sistemas de software al aplicar esta metodologa.
Por ltimo se recomienda profundizar en el campo de validacin de requerimientos, con el
fin de desarrollar modelos y aplicaciones que permitan realizar validacin automtica de
requerimientos, al igual que investigar ampliamente el cmo integrar los procesos de
ingeniera de requerimientos en las metodologas agiles.

1
 2. INTRODUCCION

La ingeniera de requisitos es en esencia la aplicacin de principios, mtodos, tcnicas y

herramientas con el propsito de descubrir los requisitos de un producto de software, al
igual que el anlisis, la documentacin de objetivos, funciones y restricciones de dichos
sistemas; sin embargo, existe una falla, es decir, no hay consenso sobre lenguajes, mtodos
o herramientas para su ejecucin [2], ms an, como lo define Ackoff: Fallamos ms a
menudo porque resolvemos el problema incorrecto que porque obtenemos una solucin
deficiente del problema correcto [3] , por ende, es necesario profundizar en la bsqueda de
estrategias que permitan mejorar y potenciar esta rea.
Para la ingeniera de requerimientos es importante ocuparse de la identificacin de
objetivos para un sistema propuesto, la operacin y la conversin de estos objetivos en los
servicios y restricciones [4]. El mantenimiento del software sostiene el producto en todo su
ciclo de vida (desde el desarrollo hasta las operaciones). Las solicitudes de modificacin se
registran y se realiza seguimiento, se determina el impacto de los cambios propuestos, tanto
el cdigo y otros artefactos de software se modifican, se lleva a cabo el proceso de pruebas
y una nueva versin del producto de software se libera [5]. All es fundamental la
trazabilidad de requerimientos por cuanto describe y sigue la vida de un requisito desde su
origen, desarrollo, especificacin, distribucin y uso [6].
Esta investigacin se enfoca en las pequeas y medianas empresas desarrolladoras de
software puesto que la mayora de estas empresas no poseen un msculo econmico fuerte
para implementar y mantener un modelo de calidad como lo es, por ejemplo, CMMI1 y, por
ende, sus procesos en ingeniera de software no estn claramente definidos. Al centrarse en
la situacin actual colombiana, es fcil inferir que las pequeas y medianas empresas son el
motor del pas. Segn un estudio del Centro de investigaciones de la Escuela de Finanzas y
Comercio Exterior de la Universidad Sergio Arboleda, stas generan ms del 50% del
empleo nacional, significa el 36% del valor agregado industrial, el 92% de los
establecimientos comerciales y el 40% de la produccin total del pas [7].
En el presente documento el lector encontrar una propuesta para realizar procesos de
ingeniera de requerimientos, la cual en los primeros captulos relaciona los problemas que
afronta la ingeniera de requerimientos, haciendo nfasis en las dificultades halladas en la
regin de Risaralda (Colombia) en este proceso. De manera posterior entre los captulos
seis al once se presentar la propuesta de metodologa de ingeniera de requerimientos para
esta regin, esta ha sido estructurada en fases las cuales permiten una mejor comprensin al
lector. En la primera etapa de pre-anlisis se mencionan las estrategias que permiten una
primera compresin del problema a resolver por medio de sistemas, en la segunda parte
durante la elicitacin2 se mencionan como clasificar el proyecto y segn esta clasificacin

1
CMMI (Capability Maturity Model Integration): Modelo de madurez de mejora de los procesos para el
desarrollo de productos y de servicios [114].
2
Elicitar: Adaptacin innecesaria del verbo ingls to elicit, que aparece a veces en textos de psicologa con el
sentido que corresponde a los verbos espaoles provocar, suscitar u obtener [115], La elicitacin de
requerimientos comprende por un lado el contexto del sistema y por otro lado el origen de los requerimientos.

2
como aplicar las tcnicas que permitan comprender los por menores del problema a
resolver, en tercera y cuarta fase se estructuran las formas que permitan comprender el
problema y documentarlo de manera formal e informal usando mtodos y especificaciones,
en la quinta etapa se realiza verificacin al proceso con las personas interesadas usando
estrategias de validacin y por ltimo la sexta fase se presenta como debe ser el proceso de
gestin de cambios del sistema. Al final del documento se exhibe una propuesta en cmo se
debe impartir la ingeniera de requerimientos en las instituciones de educacin superior.

3
 3. MARCO TEORICO Y ESTADO DEL ARTE

La ingeniera de requerimientos es un rea que se puede abordar desde diferentes

perspectivas, como lo son los mtodos que definen procesos para su adquisicin y
administracin, los lenguajes que permiten especificarlas, la innovacin que se puede
presentar frente la ingeniera de requerimientos, el software existente para la administracin
de los requerimientos, entre otros. A continuacin se mencionan diferentes perspectivas
desde la cual se puede abordar la ingeniera de requerimientos
Umber & Sarwar en el artculo Minimizing Ambiguity in Natural Language Software
Requirements Specification [8] del sexto congreso internacional de Digital Information
Management menciona que en las especificacin de requerimientos de software se
presentan inconvenientes al usar el lenguaje natural para su especificacin, es por esto que
es necesario presentar herramientas que permitan identificar las sentencias ambiguas de los
Lenguajes naturales de especificacin de requerimientos de software (NL SRS). En este
artculo se socializa la herramienta dowser para encontrar la ambigedad e inconsistencias
en NL SRS. Adems se presenta un enfoque usando la SBVR (Semntica del vocabulario
de negocios y reglas), el cual es un estndar de la OMG (Object management group). Este
define una semntica usando matemtica y lgica de alto nivel SBVR, la cual se compone
de un vocabulario de negocio, reglas del negocio y notaciones formales. SBVR trabaja bajo
el siguiente esquema: Un concepto puede ser un sustantivo o un hecho. Los conceptos que
se clasifican como sustantivos, estos pueden categorizarse como un tipo de objeto, un
concepto individual y unas caractersticas. La SBVR se seleccion como herramienta
debido a que es un estndar, es fcil de entender por los humanos y por la mquina, usa
sintaxis de lenguaje natural y es fcil de traducir a la mquina. SBVR se compone de un
vocabulario de negocio, reglas del negocio y notaciones formales.
Un enfoque basado en la retroalimentacin y evolucin de los requerimientos se puede
encontrar con Tilei et. al. El cual menciona en A Process Model of Software Evolution
Requirement Based on Feedback [9] que para realizar un seguimiento de la evolucin del
software es necesario usar mecanismos de retroalimentacin y el uso de los requerimientos
de software. Se ha usado dos enfoques, basado en CDPN (color dual Petri net) y basados en
el modelo de proceso de evolucin de requerimientos del software SERMP (software
evolution requirement process model) usan el concepto de feedback (Retroalimentacin).
El feedback es definido como la relacin entre la entrada y la salida de una misma unidad,
sin embargo entre estas fases (entrada-salida) no se encuentra una conexin directa,
primero se debe realizar una serie de pasos intermedios durante el proceso. De acuerdo al
feedback se puede definir como un positivo o negativo. Para el caso de la evolucin del
software se puede definir dos tipos, uno el cual motiva a la evolucin llamado O-TYPE
mientras el otro se encuentra enfocado al interior del proceso, llamado I-TYPE. Ambos son
usados para buscar errores y fallas en el proceso. El proceso O-TYPE maneja la evolucin
como la manera de obtener la descripcin original de los usuarios, mientras el I-TYPE es
usado para negociar la relacin entre las actividades durante el proceso de requerimientos.
Con respecto a CDPN, se define el modelo matemtico basado en petri net el cual usa
lugares, transiciones y flujo de relaciones. CDPN est definido como una estructura de 8
tuplas, que se define como:

4
N=<, P, T, Q, F, C, W, G> dnde:
es llamado conjunto de color, define el tipo de operacin y funcin.
P es llamado el conjunto de lugares.
T es llamado conjunto de transicin.
Q es llamado conjunto de retroalimentaciones transitorias.
F es llamado conjunto de relaciones.
C es llamada funcin color.
W unin entre funciones F.
G es llamada la funcin.
CDNP es usado para modelar la evolucin de los procesos de requerimientos de software,
en el cual el proceso inicial es la salida al ejecutar el sistema. El modelo CDNP clasifica los
diferentes tipos de problemas en colores diferentes. Cuando una actividad en un
requerimiento finaliza, la actividad de estas etapas puede volver a ser parte de una
retroalimentacin [9].
Con respecto a los proceso para la adquisicin y gestin de requerimientos de software,
Merchan en su artculo Definicin de una metodologa gil de ingeniera de
requerimientos para las empresas emergentes de desarrollo de software del sur occidente
Colombiano [10] socializa el trabajo desarrollado por el grupo de investigacin LIDIS de
la universidad de San Buenaventura en Santiago de Cali. Menciona que la obtencin de
requerimientos se puede definir como el contrato que se genera entre el cliente y los
desarrolladores, estos se enfocan en la visin que tiene el usuario del sistema. En esta
investigacin se evidenci que las empresas emergentes presentan problemas con respecto
a metodologas que soporten la actividad de los procesos de desarrollo de software. Con
respecto a los procesos de ingeniera de requerimientos se encontraron debilidades como:
El 58% no se establecen criterios para la aceptacin de proveedores de requerimientos, lo
cual puede traer falencias en el desarrollo; El 48.71% no establecen criterios para la
aceptacin de los requerimientos, por ende esto se puede traducir en errores en el
desarrollo, retrasos en los cronogramas de trabajo o rechazo por parte del cliente. Por
ltimo el 43.6% no realizan trazabilidad a los requerimientos; El realizar seguimiento a los
cambios de los requerimientos es importante para acciones relacionadas con la toma de
decisiones. Al identificarse esta falla se hace evidente la creacin de una metodologa gil
para la captura de requerimientos, se hace referencia a las metodologas giles debido a la
facilidad de implementacin en las pequeas empresas, dicha metodologa se encuentra
dirigida a dos tipos de empresas las cuales son: desarrolladoras de software a la medida y
start-up (ideas de innovacin). La metodologa define tres fases en la metodologa:
1.Elicitacion 2.Especificacin de requerimientos y 3.Gestin de requerimientos
Por otro lado se encuentra que no solo en Colombia se han preocupado por el estado de los
desarrollos de software en las pequeas empresas, Quispe et. Al [11] menciona como en
Chile tambin se han estudiado el comportamiento en las pequeas empresas, ciertamente
para dar el diagnstico de los requerimientos en las pequeas empresas de software. En este
caso se comienza por realizar una caracterizacin de las pequeas empresas desarrolladoras
de software tomando las siguientes caractersticas:
Tamao de los proyectos y el equipo de trabajo.

5
 Recursos.
Calidad del personal.
Proceso desarrollo.
Gestin de proyectos.
Estructura Organizacional.
Comunicacin y coordinacin.
Posterior a esto se realiz una bsqueda de estudios similares en dicho campo, en donde es
de mencionar que veinticuatro diferentes compaas participaron en el estudio, todas las
compaas se encontraban localizadas en Santiago de Chile. Se incluyeron dos
instrumentos, los cuales eran formulario de encuesta y grupo de enfoque.
Para el formulario de encuesta se us la escala de likert3 incluyendo 48 preguntas, los
encuestados tambin participaron en un grupo de enfoque, en el cual realizaban una
pequea discusin para comentar los problemas comunes que afectan el proceso de
desarrollo de software.
Con estos insumos se pudo realizar descubrimientos con respecto al desarrollo de software
para realizar las respectivas conclusiones. Quispe et. Al descubre que algunas de las
caractersticas principales de las pequeas empresas son [11]:
El equipo de trabajo es poco calificado, suelen ser grupos menores a diez
personas y sus proyectos no son de ms de medio ao.
Cuentan con escasos recursos.
El proceso de desarrollo y gestin del proyecto (planeacin, organizacin,
monitoreo) se basa en tcnicas informales.
No se encuentra una estructura organizacional clara y no se definen roles dentro
de la organizacin.
Por otro lado, en la ingeniera de requerimientos existen herramientas que apoyan el
proceso para la adquisicin y gestin de los requerimientos de software, como es el caso de
la herramienta Heler. Callejas menciona que la investigacin realizada profundiza en el
rea de ingeniera de requerimientos y especificacin de las actividades de entendimiento
de los problemas basados en el proceso unificado [7] esto para realizar la construccin de
la herramienta HELER. Como parte de su metodologa se encuentra el buscar trabajos
previos, los cuales consisten en conocer las herramientas relacionadas con la ingeniera de
requerimientos, posterior a esta actividad, se realiza un anlisis de esta con respecto a la
gestin de requerimientos, y a partir de dicho anlisis se definen las caractersticas de
funcionalidad para el desarrollo de HELER [12].
Al igual que HELER est el caso similar de la herramienta RADIX, creada en los
laboratorios de AT&T en la cual como lo menciona Weider el proceso de desarrollo de
software es un proceso complejo donde los errores cometidos en implementacin son
costosos de corregir, estos en general requieren un esfuerzo y un nmero de intervalos para
ser desarrollados, revisados e inspeccionados [13]. El proceso de trazabilidad de
requerimientos es un mtodo sistemtico, que permite: 1) extender la trazabilidad para los
3
Escala de Likert: Conjunto de tems que se presentan en forma de afirmacin para medir la reaccin del
sujeto en tres, cinco o siete categoras [18].

6
ingenieros de sistemas 2) Estandarizar trazabilidad en las herramientas, para hacer ms fcil
de integrar con desarrollos existentes. Los desarrollos de software en cascada requieren
gran esfuerzo, esto se ve reflejado a lo largo de cada una de las iteraciones. Aunque
podemos considerar este tipo de desarrollos como estables, el esfuerzo que se debe realizar
para ejecutar las pruebas es muy costoso. Las etapas de integracin e implementacin se
enfocan en revisin, inspeccin y pruebas basadas en una buena identificacin de los
requerimientos. La etapa de identificacin de requerimientos cobra gran importacin
debido a que segn el 5ESS nos muestra que el costo de reparacin luego de realizadas las
pruebas al software con respecto al tiempo son de 10 a 20 ms que si estas hubiesen sido
detectadas en la fase de requerimientos. Se menciona que para asegurar la calidad de un
producto, es necesario asegurar las caractersticas solicitadas en los requerimientos por
parte de los clientes externos e internos, esto con el fin que el desarrollo se realice de
manera correcta.
Weider describe un mtodo sistemtico, para asistir a 5EES, el cual permite tener una
trazabilidad de los requerimientos. Dicho mtodo sistemtico define dos cuestiones que son
necesarias a tener en cuenta, estas son: 1. La trazabilidad extendida a lo largo del proceso
de ingeniera, proceso desarrollo y proceso de verificacin (pruebas) 2. Herramientas
estndar de trazabilidad que puedan ser integradas con el entorno de desarrollo [13].
La ingeniera de requerimientos tambin puede ser observada desde la perspectiva para
cumplir los objetivos en la gestin de proyectos, como lo menciona McGovern [1], en el
cual muestra una perspectiva enfocada en el rol del project manager (Lder en la gestin
del proyecto), en donde se analiza como afrontar los cambios a realizar a un sistema. En
algunas ocasiones los proyectos se dividen en subsistemas y con esto se generan
dificultades para coordinar las dependencias entre estos. Es necesario realizar una
verificacin temprana de la arquitectura planteada, este paso es complejo y por ende se
suele posponer para etapas posteriores, en donde la arquitectura ya se encuentra construida
y esto genera un inconveniente debido a que en muchos casos es necesario realizar un
rediseo del sistema, algo que se ve impactado en los costos del proyecto (Por lo general
los proyectos tiene un sobre costo mayor o igual al 70% de lo estimado). Por ltimo se
menciona como los requerimientos no funcionales se cruzan con los requerimientos
funcionales, esto se traduce en una estimacin ms precisa del proyecto. Se menciona
adems que los requerimientos no funcionales se pueden asociar a objetivos del negocio.
La fase de ingeniera de requerimientos no est exenta de presentar errores, por ende cobra
importancia el cmo descubrir estos errores en fases tempranas, como lo menciona Porter
et.al [14] la especificacin de requerimientos de software en general se obtiene por medio
de una validacin manual, sin embargo en este artculo se presenta un proceso el cual
pretende encontrar errores en los requerimientos. Para esta revisin se usa una lista de
chequeo o un documento Ad hoc. Este mtodo no consiste en una tcnica sistematizada
para la deteccin de fallos. Porter menciona como la tcnica consiste en evaluar una
hiptesis usando un parcial factorial de 3x2. Se cuenta con un grupo de 48 estudiantes,
distribuidos en 16 grupos (3 personas por grupo), cuyo objetivo es que cada grupo realice la
inspeccin de 2 especificaciones de requerimientos de software. Cada equipo de inspeccin
combina tcnicas ad hoc y listas de chequeo.

7
En cada inspeccin se toma cuatro medidas:
Tasa de deteccin de fallos individual.
Tasa de deteccin por equipo.
Porcentaje identificacin en la primera etapa.
Porcentaje identificacin por individuo de fallos no detectados en etapas
posteriores.
Por otro lado, existen modelos realizados por grandes institutos como lo son el CMMI de la
universidad Carnegie Mellon, como lo menciona Justin y Yung-Sung [15] la integracin
de modelos de madurez de capacidades provee la mejor gua de gestin de requisitos; sin
embargo se identifican dos dificultades para la ingeniera del software:
1. No es fcil llevar una trazabilidad.
2. No es fcil realizar medicin de los requerimientos.
Esto se da debido a que es necesario tener una preparacin para manejar numerosa
documentacin que exige el proceso de CMMI. Las posibles situaciones con respecto a los
requerimientos, son: Alta frecuencia de revisin de cambios de los requerimientos, aumento
del nmero de requerimientos, incapacidad por parte de los desarrolladores para confirmar
la trazabilidad de un requerimiento, cambios en los requerimientos. Existen diferentes
estndares para la aplicacin de la ingeniera de requerimientos, podemos mencionar
algunos como lo son IEEE 12207, MIL-STD-490, entre otros [15].
Para el campo de la ingeniera de requerimientos la innovacin juega un papel que puede
ser relevante, as lo menciona Torres [16] en Tcnicas de Levantamiento de
Requerimientos con Innovacin en donde se considera como un factor determinante en la
aplicacin de cualquier tcnica seleccionada para la adquisicin de requerimientos, por
ende generar valores diferenciales frente a la aplicacin de una tcnica tradicional. Dentro
de la ingeniera del software una fase de gran relevancia es la ingeniera de requerimientos,
ya que esta es la base para el buen desarrollo de un sistema de software que se quiera
realizar de manera exitosa. Torres [16] presenta las diferentes tcnicas y la teora de los
colores de Ned Herrmann [17] y foment la creatividad e innovacin de otros autores,
realizando una correspondencia entre lo que debe ser la buena seleccin de una tcnica de
levantamiento de requerimientos, y la importancia de la creatividad en las actividades
ingenieriles.
En la tabla 1 se encuentran las principales ventajas y desventajas de cada uno de los
referentes tericos mencionados anteriormente, dicha tabla ha sido creada por los autores
de la presente metodologa.

Titulo Ventajas Desventajas Autores

propuesta
Minimizing Presenta una herramienta llamada Implica destreza en matemtica y Umber &
Ambiguity in dowser que permite identificar las lgica de alto nivel Sarwar [8]
Natural Language sentencias ambiguas de los
Software Lenguajes naturales de
Requirements especificacin de requerimientos de
Specification software

8
A Process Model CDNP (modelo matemtico El mtodo est ms enfocado Tilei et. a
of Software basado en petri net) es usado para hacia los cambios y evolucin del [9]
Evolution modelar la evolucin de los procesos software, ms no al proceso
Requirement Based de requerimientos de software, en el completo de construccin.
on Feedback cual el proceso inicial es la salida al El mtodo no previene errores,
ejecutar el sistema. sino que establece un mecanismo
correctivo de los errores
El modelo CDNP clasifica los encontrados.
diferentes tipos de problemas en
colores diferentes. Cuando una
actividad en un requerimiento
finaliza, la actividad de estas etapas
puede volver a ser parte de una
retroalimentacin
Definicin de una Metodologa gil y liviana para la La metodologa asume que el Luis
metodologa gil captura de requerimientos. La cual proceso previo a la elicitacin Merchan,
de ingeniera de es aplicable en pequeas empresas est claramente definido y no Alba
requerimientos desarrolladoras de software. alcance a contemplar todos los Urrea,
para las empresas aspectos del proceso de ingeneria Ruben
emergentes de de requerimientos. Rebolla
desarrollo de [10]
software del sur No es clara la aplicacin de
occidente aspectos como priorizacin de
colombiano requerimientos, solucin de
conflictos.
Requirements Metodologa ampliamente aplicable La metodologa se enfoca hacia Alcides
Engineering para empresas pequeas tipos de proyectos a la medida, lo Quispe,
Practices in Very desarrolladoras de software, incluye cual puede dificultar su Maira
Small Software 6 fases que contemplan el proceso aplicacin en otros tipos de Marques,
Enterprises: A completo de ingeniera de proyectos. Luis
Diagnostic Study requerimientos Silvestre,
Sergio
F
. Ochoa,
Romain
Robbes
Heler: Una Herramienta libre, para el soporte de La herramienta apoya la creacin [11]
Mauricio
herramienta para la la especificacin de requisitos, de nuevos proyectos de software, Callejas
ingeniera de permite gestionar proyectos, especficamente proyectos a la cuervo,
requisitos stackholders, artefactos y medida, la adaptacin de otros Luz Yadira
automatizada requerimientos tipos de proyectos a esta Castillo
Herramienta fcil de usar y aplicable herramienta puede dejar aspectos Estupian,
a pequeas empresas desarrolladoras relevantes por fuera. Ruby
de software. La herramienta no ofrece Monica
mecanismos de validacin de Fernandez
requerimientos ni gestin de Alvarez
cambios (faltan mdulos por [12]
implementar)
Verifying Software Propone un mtodo sistemtico que En desarrollo de proyectos Weider D.
Requirements: permite realizar de manera ptima la basados en metodologas agiles, Yu [13]
A trazabilidad de requerimientos. puede ser necesario realizar un
Requirement Herramientas estndar de trabajo adicional para recolectar
Tracing trazabilidad de requerimientos que la informacin faltante para
Methodology and pueden ser integradas con el entorno poder realizar aplicacin de este
Its Software Tool de desarrollo. mtodo sistemtico de
trazabilidad.

9
Managing Establece a los Project manager el Dado que la metodologa est Fergal
Software Projects cmo afrontar los cambios a realizar dirigida a los Project manager, el McGovern
with Business - a un sistema. proceso de gestin de cambios no [1]
Based es claro para los dems roles
Requirements involucrados en el proyecto.
Comparing Presenta una tcnica sistematizada Esta tcnica no apoya el proceso Adam A.
Detection Methods para la deteccin de fallos, mediante de deteccin y prevencin de Porter,
for Software una lista de chequeo o un documento errores de manera temprano, Lawrence
requirements Ad hoc solamente los detecta cuando G. Votta,
Inspections: A estos existen. Victor R.
Replicated Basili [14]
Experiment
Collaborative Al aplicar esta metodologa las Es de compleja aplicacin en Justin J.Y.
Requirement inconsistencias y riesgos del empresas pequeas, dado que es Lin, Yung-
Management proyecto se reducen al mnimo. necesario tener una preparacin Sung Lin
System Developed Dado que los documentos para manejar numerosa [15]
for CMMI- relacionados se correlacionan con documentacin que exige el
Coherent Software requisitos, los requisitos son mucho proceso de CMMI.
Engineering ms comprensibles y trazables.
Tcnicas de Presenta diferentes tcnicas, No se establece una gua o Nicols
Levantamiento de fomentando la creatividad e metodologa para la correcta Aristizbal
Requerimientos innovacin, realizando una eleccin de estas tcnicas de Meja,
con Innovacin correspondencia entre lo que debe acuerdo a los diferentes tipos de Miguel
ser la buena seleccin de una tcnica proyecto. Eduardo
de levantamiento, y la importancia Torres
de la creatividad en las actividades Moreno
ingenieriles. [16]
Tabla 1: Principales ventajas y desventajas referentes tericos.

10
 4. OBJETIVO GENERAL Y OBJETIVOS ESPECFICOS

4.1 Objetivo General

Desarrollar una metodologa para la adquisicin y gestin de requerimientos en el
desarrollo de software para pequeas y medianas empresas (pymes) del departamento de
Risaralda.

4.2 Objetivos especficos

Identificar, interpretar y comparar las tcnicas del CMMI, ITIL, IEEE (SWEBOK),
MPIU+a en la gestin de requerimientos para validar en que caso es ms apropiado
usar segn las necesidades de las PYMES en la regin de Risaralda.
Elaborar una gua para la enseanza de la ingeniera de requerimientos en las
universidades colombianas con base en los problemas identificados en la
investigacin.
Estructurar un esquema de trabajo para la adquisicin, elicitacin y clasificacin de
los requerimientos en los proyectos de desarrollo de software en el departamento de
Risaralda con el propsito de disminuir costos y/o tiempo durante la ejecucin en su
ciclo de vida del software.
Desarrollar un aplicativo en versin prototipo beta el cual permita soportar el
proceso de adquisicin y gestin de la ingeniera de requerimientos.

11
 5. METODOLOGIA REQUERIMIENTOS

El desarrollo de esta investigacin se realiz en tres fases, las cuales consistieron en la recopilacin
de datos, construccin de la metodologa para la adquisicin y gestin de requerimientos y por ltimo
realiz la validacin de dicha metodologa, a continuacin se explicar al detalle cada una de estas
fases.

5.1 Recopilacin de datos

La informacin de esta fase fue recopilada a partir de tres fuentes:

Revisin literaria: Tal como menciona Hernndez et al la metodologa de

investigacin se presenta como la posicin integradora en la cual es conveniente
revisar los trabajos previos, con el fin de adoptar una posicin en donde podamos
aportar a los conocimientos en dicha rea de investigacin. El planteamiento y
elaboracin de perspectivos tericos presentan una finalidad, en la cual podemos
conocer otros planteamientos, detectar conceptos claves y tener en cuenta errores
cometidos con anterioridad [18].
Muestra de empresas investigadas: Por tratarse de una investigacin cualitativa,
esta muestra corresponde a las PYMES del rea de la industria de los servicios
informticos del departamento de Risaralda. Martinez et. al en Metodologa de la
investigacin mencionan que la investigacin cualitativa es til cuando el
fenmeno de inters es muy difcil de medir [18], esta muestra de empresas fue
suministrada por el grupo de investigacin GRANDE (Grupo de avanzada en
desarrollo de software) de la Universidad Tecnolgica de Pereira.
Academia: Con el fin de identificar el estado actual y los aspectos abordados de la
ingeniera de requerimientos en la academia, se enviaron cinco invitaciones a las
principales universidades de Popayn, Manizales y Pereira, que ofertan el programa
de ingeniera de sistemas de manera presencial, de estas solamente particip una,
diligenciando el formulario virtual. Para el caso de los egresados se envi por correo
electrnico la informacin y el enlace para diligenciar la encuesta de manera virtual.
De los cuarenta egresados convocados se obtuvo respuesta de diez y seis egresados,
estos correspondan a diferentes universidades de la regin.
Para recopilar la informacin tanto de la muestra de empresas como de la academia se
estructuraron dos herramientas las cuales fueron encuestas (preguntas que usan la escala de
Likert, con el fin de medir el grado de aceptacin por cada una de ellas) y entrevista abierta.
Estas forman un componente mixto en la investigacin en la cual se aportan tcnicas
cualitativas y cuantitativas [18]
Para este proceso se estructuraron tres perfiles (De los cuales se deseaba evaluar su
percepcin), los cuales son:

Sector pequeas empresas relacionadas con el desarrollo de software.

Docentes y directores de pregrados universitarios de ingeniera de sistemas.
Egresados de pregrados en ingeniera de sistemas.

12
Las temticas abordadas para los tres perfiles fueron: Stakeholders, priorizacin,
dependencias, trazabilidad, diseo centrado en usuario (UCD), restricciones,
documentacin, requerimientos funcionales, requerimientos no funcionales, meta-modelos
y tcnicas usadas para elicitacin. (Los resultados, entrevistas y encuestas aplicadas se
pueden observar en el anexo 2)
La Tabla 2: Sectores y herramientas aplicadas relaciona las herramientas e intenciones para
cada uno de los perfiles, mientras la Tabla 3: Ficha tcnica herramientas

muestra en resumen la informacin de la ficha tcnica.

Perfil Herramientas Intencionalidad.

aplicadas
Pequeas Entrevista Conocer el grado de madurez de las empresas
empresas Encuesta desarrolladores de software segn los
empleados de estas.
Sector pregrados Encuesta Identificar como se encuentran estructuradas
universitarios las temticas relacionadas con la ingeniera de
requerimientos y como se abordan estas en el
pensum acadmico.
Sector egresados Entrevista Conocer la percepcin de los egresados con
respecto a los conocimientos que fueron
adquiridos en sus pregrados en el rea de la
ingeniera de requerimientos.
Tabla 2: Sectores y herramientas aplicadas

Diseo muestra Muestra por convencin.

Poblacin objetivo Pequeas empresas de la regin de
Risaralda.
Egresados de programas en ingeniera de
sistemas.
Directores y docentes programas
acadmicos en ingeniera de sistemas.
Tcnica Encuesta con escala Likert.
Entrevista tipo mertenes
Tamao de la muestra 9 empresas de la regin de Pereira (De 11
empresas convocadas).
16 Egresados (De 40 egresados
convocados)
1 Institucin universitaria (De 5 programas
acadmicos contactados).
Momento estadstico Mayo 2014 Julio 2014
Financiacin Recursos propios.
Tabla 3: Ficha tcnica herramientas

13
 5.1.1 Problemas tericos del anlisis de requerimientos
La ingeniera de requisitos cada vez cobra mayor importancia tanto en la academia como en
la industria, la razn de esto es que cada vez se espera que existan ms funciones centradas
en el usuario, de mayor calidad y seguridad, por tanto es importante comprender las
situaciones que afectan dicha prctica [19]. Sin embargo, un enfoque de trabajo limitado a
los aspectos meramente tcnicos no aseguran el xito del producto y por ende se hace
necesario conocer la forma en cmo se realiza la interaccin entre hombre-computador
[20]. Por otra parte existen aspectos geogrficos en los cuales los equipos de software se
encuentran distribuidos de manera global y uno de los inconvenientes que puede afrontar la
industria es responde a la pregunta Qu tcnica de elicitacin de requisitos de software
se debera aplicar cuando el cliente y/o usuario se encuentra ubicado de manera remota?
[21]. A continuacin se describirn algunos referentes tericos relacionados con los
principales inconvenientes que se presentan en esta rea:
En gran nmero de casos, las empresas a pesar de conocer la importancia de la ingeniera
de requerimientos optan por realizar de forma emprica esta actividad. Como lo menciona
Toni Granollers La comunicacin con los usuarios es un aspecto prioritario para las
empresas que desarrollan sistemas software; aun as confan ms en la experiencia
acumulada que no en la aplicacin de mtodos pensados para capturar la experiencia de los
usuarios y sus verdaderas necesidades(); sin embargo, se suele dar culpabilidad al
usuario por no describir correctamente sus necesidades, que cambian de pensamiento
fcilmente, que tienen diferentes puntos de vista o simplemente que stos no saben cmo
disear un producto interactivo. Lo que nunca piensan es que si hubieran aplicado
correctamente las tcnicas de anlisis de requisitos centradas en los usuarios se habran
ahorrado estos problemas y los usuarios estaran satisfechos [22]; sin embargo, pese a la
importacin de especificacin de requisitos y que esta es una tarea bien entendida an se
realiza seleccin de tcnicas de forma subjetiva, esto se debe a dos razones: 1. El
conocimiento con respecto a la cantidad de tcnicas disponibles actualmente es limitado, lo
que quiere decir que an desconocen una gran cantidad de tcnicas, 2. La informacin de la
que disponen en relacin a las tcnicas es de tipo procedimental (es decir centrada en la
tcnica), siendo la informacin pragmtica(es decir centrada en cuando usar la tcnica) casi
inexistente [23].
Adems de esto se observa como las pequeas empresas manejan sus requerimientos de
forma que no pareciera guardar relacin con lo que se dice en los textos, y gran parte de
estas empresas pareciera no interesarles las investigaciones actuales que se realizan en esta
rea [24]. Es comn ver como en las pequeas empresas manejan la ingeniera de requisitos
de forma diferente, cada una de las empresas realiza la elicitacin y comunicacin de
requerimientos con diferente grado de planificacin, estructura y documentacin, y ellos
consideran que cada eleccin es natural, del mismo modo la diversidad en la prctica de los
requerimientos se da debido a la adaptacin a nichos de mercado de cada empresa [25].
Es de mencionar que la calidad del software depende de la calidad de los requisitos y esta a
su vez de las tcnicas utilizadas para elicitacin [25]. No obstante el desarrollo de software
es una actividad en la cual es necesaria la cooperacin y colaboracin de muchas personas.
Como lo menciona Sergio Zapata, no solo intervienen aspectos tcnicos sino tambin
culturales, sociales, econmicos y psicolgicos. Estos aspectos llevan a que la

14
comunicacin entre los ingenieros de requisitos y los usuarios-clientes sea en algunas
ocasiones compleja y puede llevar a desacuerdos culturales, organizacionales, falta de
generacin de confianza mutua o incapacidades para realizar resolucin de conflictos [21].
A pesar que la mayora de empresas aseguran uso de metodologa, esta no se realiza o
aplica de forma correcta. Para el caso de las empresas de software de la ciudad de
Cali(Colombia) el 48.7% de la industria no se establecen criterios para la aceptacin de los
requerimientos, el 43.6% no realizan administracin de requerimientos [10], en la misma
lnea para el caso de Santiago de Chile(Chile) se observa cmo las empresas emergentes no
cuentan con el personal calificado, se cuenta con escasos recursos o no se encuentran roles
definidos en la organizacin [11], de manera similar en Nueva Zelanda se observa como en
la industria no hace uso de herramientas de soporte de la ingeniera de requerimientos y
solo algunas empresas de dicho pas asocian herramientas como Rational, Trac, Together y
Door como herramientas que soportan la ingeniera de requerimientos [26]. A su vez los
principales problemas que ellos identifican son: Cambios en el alcance y requerimientos,
aceptacin del cliente para costos, tiempo y esfuerzo necesarios para la fase de requisitos y
calidad de las especificaciones [26]. Asimismo las tcnicas de entrevista y encuesta suelen
ser las ms usadas para realizar elicitacin [3].
Entre los principales tems relevantes alrededor de la ingeniera de requerimientos se tiene:
Alta frecuencia de revisin de cambios en requerimientos, aumento del nmero de
requerimientos, poca capacidad de confirmar la trazabilidad y cambios en los
requerimientos [15], otro inconveniente es el uso de lenguajes naturales, lo cual genera
ambigedad entre los requerimientos o conflictos entre los interesados [8]. Adems la
insatisfaccin en el anlisis del software puede darse por los siguientes factores: 1. Fallas
no relacionados con tcnicas de elicitacin, 2. Fallas causadas por la falta de efectividad en
las tcnicas de elicitacin, 3. Falta de disponibilidad, lo cual genera mal uso de tcnicas de
elicitacin [27]. Adems factores como el tipo de cliente, la experiencia y aptitudes de los
desarrolladores, las preferencias del fundador, el ambiente del negocio, la distribucin
espacial y geogrfica de las oficinas son factores que influyen en cmo cada compaa
obtiene los requerimientos. [25]
Con respecto a las tcnicas usadas en elicitacin es de mencionar que las entrevistas sirven
para obtener una comprensin general de lo que hacen los stakeholders, como podran
interactuar con el sistema y las dificultades a las que se enfrentan con los sistemas actuales.
A la gente le gusta hablar sobre su trabajo y normalmente se alegran de verse implicados en
las entrevistas; Sin embargo, no son de tanta utilidad para la compresin de los
requerimientos del dominio de la aplicacin. [28]
Del mismo modo en la fase de especificacin de requerimientos es posible que se presenten
muchos inconvenientes, entre estos estn: Los requerimientos no son obvios y viene de
muchas fuentes, son difciles de expresar en palabras (se genera ambigedad), la cantidad
de requerimientos se puede tornar difcil, los requerimientos pueden cambiar a lo largo de
ciclo de vida, los usuarios no pueden explicar lo que hacen, se recuerda los casos de
excepcin pero se olvida lo rutinario, se habla de lo que no funciona, existe un vocabulario
distinto entre usuarios y desarrolladores, se hace uso de los mismos trminos para
diferentes significados, el nivel de detalle es vago, algunos requerimientos son ms
importantes (o estables) que otros, existe relacin entre los requerimientos y por ultimo

15
cada uno tiene funcionalidades nicas y abarcan reas funcionales especficas [29] [30].
Otros mencionan que las metodologas han sido concebidas para sistemas alfanumricos, en
donde no existen atributos espaciales, y que al existir stakeholders heterogneos y dada la
complejidad de la informacin se generan inconvenientes al momento de aplicar la
ingeniera de requerimientos [31].
Otros aspectos complejos relacionados con la elicitacin se presentan a causa de que las
fronteras del sistema no se encuentran bien definidas, los detalles tcnicos pueden
confundir (ms que aclarar), problemas de comprensin por parte del cliente, donde ellos
no estn totalmente seguros de lo que necesitan o tiene dificultades para comunicar sus
necesidades [32].
En sntesis los inconvenientes de la ingeniera de requerimientos presentados en esta
seccin se encuentran relacionados con:

Seleccin de las tcnicas de elicitacin adecuadas.

Omisin de requerimientos parte del cliente, vaguedad en la descripcin del
requerimiento y trminos que denotan diferentes interpretaciones segn el lector.
Poco uso de tcnicas orientadas a mejorar la usabilidad (Deficiencia en tcnicas
relacionadas con diseo centrado en el usuario).
En gran parte las pequeas empresas no realiza documentacin y gestin de los
requerimientos (Trazabilidad).
La gran mayora de pequeas empresas desconocen las tcnicas de elicitacin de
requerimientos tanto en su forma procedimental como pragmtica y por ende solo
hacen uso de las entrevistas y encuestas como tcnicas de elicitacin de
requerimientos.
Desacuerdos culturales entre los diferentes stakeholders.
Poca disponibilidad entre los stakeholders con el proceso de ingeniera de
requerimientos, adems de no comprender el tiempo y esfuerzo requerido.
Poco uso de herramientas que soporten la ingeniera de requerimientos.
Realizacin de cambios y ajustes por fuera del alcance del proyecto.
Uso de lenguaje natural en el proceso de ingeniera de requerimientos lo que
conlleva a imprecisiones y ambigedad.
Los clientes no se encuentran totalmente seguros de lo que necesitan o se presentan,
dificultad para expresar sus necesidades.
5.1.2 Inconvenientes en las pequeas empresas y la academia de la regin de
Risaralda
A continuacin se mencionan los principales hallazgos evidenciados en las empresas y la
academia luego de aplicar las tcnicas mencionadas (Los resultados, entrevistas y encuestas
aplicadas se pueden observar en el anexo 2)
Primero es de mencionar que al realizar un anlisis de correlacin interna entre los tems se
identifica que existe un grado de fiabilidad de los datos, esto se puede constatar al aplicar
un estadstico de fiabilidad en el cual se observa que el alfa de cronbach() es de 0,863, el
cual se encuentra en un valor cercano a uno y tal como lo menciona Hernndez, Fernndez
y Baptista en su libro Metodologa de la investigacin el valor uno representa el nivel

16
mximo de confiabilidad total. Para nuestro caso al obtener un valor aproximado al 0.87 es
posible afirmar que se tiene una confiabilidad aceptable. [18]
Al procesar y contrastar la informacin recolectada con las diferentes tcnicas en las
empresas se observa como estas perciben que poseen un buen proceso para realizar la
ingeniera de requerimientos, esto es ms notorio en temas relacionados con validacin de
requerimientos ante el cliente y la verificacin de dependencias y gestin de cambios
usando matrices de trazabilidad, en donde el grado de aceptacin de las empresas es alta;
Sin embargo se evidencia que es complejo para ellos interpretar de una manera clara las
solicitudes realizadas por los clientes, ms aun cuando en ocasiones los clientes no conocen
totalmente las dificultades o necesidades que desean resolver con el uso de las tecnologas
de informacin. La seleccin de stakeholders en los proyectos es bsica, ya que es comn
delegar a una persona dentro de la organizacin para identificar a los involucrados o
simplemente se dirigen a la persona que paga el desarrollo y como lo menciona Mary Ann
Crow, profesional certificada en PMP identificar los stakeholders, es uno de los ms
importantes pasos para establecer las bases tempranas dirigidas a la posterior planificacin,
ejecucin, as como monitoreo y control de la informacin y comunicacin del proyecto,
para alcanzar el xito en ste [33].
En conclusin los principales inconvenientes que presentan las empresas son:

En ocasiones los clientes no conocen sus necesidades o presentan inconvenientes

para expresarlas.
En general falta conocimiento por parte del equipo de desarrollo del proyecto en el
dominio del problema del cliente.
No hacen uso de metodologas, sin embargo realizan adecuaciones a plantillas ad-
hoc para realizar el proceso de elicitacin.
Es complejo realizar la estimacin de tiempos.
En la mayora de empresas no se identifica con claridad los stakeholders
involucrados en el proyecto.
En algunos casos no realizan identificacin de requerimientos no funcionales.
En la mayora de empresas no se realiza gestin de requerimientos.
Tan solo hacen uso de entrevistas, prototipos y plantillas ad-hoc como tcnicas de
elicitacin de requerimientos
Al contrastar los inconvenientes tanto tericos como prcticos (En empresas), se observa
como las empresa manifiestan un grado de satisfaccin con respecto al proceso de
ingeniera de requerimientos interno de cada una de las empresas, sin embargo al analizar
los procesos (mtodos, tcnicas, herramientas) que aplican se identifica que en la mayora
de casos se est distante de ser modelos que puedan ser replicados como casos de xito en
otras empresas del sector.
En cuanto al sector acadmico se observa que los estudios de pregrado no abordan con la
respectiva importancia la ingeniera de requerimientos, esto se evidencia en la forma como
son abordados los tpicos de esta rea puesto que no existe una ctedra en la cual se
agrupen los contenidos epistmicos. Solo algunos de los tpicos son impartidos a lo largo
del programa acadmico sin tener una relacin interna entre estos. Si bien se imparten
tcnicas de elicitacin, las nicas que generan recordacin en los estudiantes son el
17
prototipado, lluvia de ideas, cuestionario y entrevista. Adems existe un gran vaco en
temas como: priorizacin de requerimientos, tcnicas de diseo centrado en el usuario,
clasificacin de stakeholders, gestin de requerimientos (Trazabilidad).
Los hallazgos mencionados han sido publicados como artculo de reflexin analtica e
interpretativa en la revista Lmpsakos en su edicin nmero 12 (ver ANEXO 3:
PUBLICACIONES REALIZADAS).

5.2 Construccin de la metodologa para la adquisicin y gestin de

requerimientos en la industria de Risaralda
Los proyectos de ingeniera de software nacen a partir de la necesidad de solucin de las
necesidades o problemas de un cliente especfico o de un nicho de mercado. El anlisis de
necesidades es la fase previa de cualquier tipo de estudio que tenga como objeto implantar
cualquier tipo de programa o servicio. Segn Prez este anlisis es un estudio sistemtico
de un problema, que se realiza incorporando informacin y opiniones de diversas fuentes,
para tomar decisiones sobre lo que hay que hacer a continuacin [34].
El anlisis y la especificacin de los requisitos puede parecer una tarea relativamente
sencilla, pero las apariencias engaan [35]. Esta es una labor complicada porque consiste en
la traduccin de unas ideas de necesidades de software enmarcadas en una serie de
restricciones y reglas de negocio. Se debe obtener informacin dialogando con muchas
personas y cada una de ellas se expresar de una forma distinta, tendr conocimientos
informticos y tcnicos distintos, y tendr unas necesidades y una idea del proyecto muy
particulares [36]. La Ilustracin 1 muestra las posibles fuentes de informacin al realizar un
proceso de ingeniera de requerimientos y sus resultados esperados.

Ilustracin 1: Entradas y salidas del proceso de ingeniera de requerimientos.

18
El proceso de ingeniera de requerimientos pudiera ser vista como una especie de caja
negra, donde cada quien trata de realizar su propia implementacin. Esto ocasiona que
realmente el resultado no sea siempre el esperado. La Ilustracin 2 presenta las fases de la
metodologa propuesta por los autores. En el desarrollo de cada una de las fases se toman
elementos y prcticas de CMMI [37], SWEBOK [5], MPIU+a [38], Competisoft [39], ITIL
[40], SOMA [41], METRICA V3 [42].

Ilustracin 2: Fases de la metodologa propuesta por los autores.

5.3 Validacin de la metodologa

En relacin con la metodologa se ha validado el contenido de esta usando juicio de
expertos. Para esto se estructur un resumen ejecutivo y un instrumento de evaluacin. En
el resumen ejecutivo fueron incluidos los principales aspectos de cada fase que componen
la metodologa y las herramientas e instrumentos que contiene cada una de estas, todo esto

19
soportado en el aplicativo web creado para esta metodologa. En cuanto al instrumento de
evaluacin este consta de doce tems. Por cada uno de estos se solicit una valoracin bajo
los criterios de suficiencia, claridad, coherencia y relevancia (Este instrumento se encuentra
en el anexo 6 del presente documento). Dicha valoracin fue realizada por cinco expertos
de las instituciones Universidad Nacional de San Juan (Argentina), BHP (Argentina) y
Universidad del Cauca (Colombia)

20
 6. PRE-ANALISIS

Resumen
Entradas --
Salidas Creacin glosario de trminos.
Acuerdos de nivel de servicio y confidencialidad.

6.1 Entrega de procesos organizacionales

Es fundamental antes de empezar el proceso de obtencin de requisitos investigar y
examinar en detalle la situacin o "mundo real" en el que el sistema finalmente va a
interactuar (a veces llamado el dominio de aplicacin) [4] [5]. El entorno actual tiene que
ser completamente explorado incluyendo aspectos polticos, organizativos y sociales
relacionados con el sistema, adems de las restricciones que pueden aplicar sobre el sistema
y su desarrollo. Los procesos de trabajo existentes y los problemas relacionados a ser
resuelto por el sistema necesitan ser descritos con respecto a las metas del negocio.
Los procesos organizacionales cortan horizontalmente las reas funcionales tradicionales y
exigen un diseo que asegure un funcionamiento coordinado y eficiente del conjunto de
actividades que las componen. Una forma de apoyar este diseo es a travs de procesos
organizacionales apoyados en la TI (Tecnologas de la Informacin), los cuales hacen fluir
las unidades de informacin, facilitan la coordinacin y dan soporte a la realizacin de las
actividades [6]. Los procesos organizacionales se clasifican en un conjunto bsico de
procesos de alto nivel, los cuales se consideran que aplican a todas las organizaciones:

Procesos estratgicos son aquellos mediante los cuales la organizacin planea y

desarrolla su futuro. Aqu queda incluida la planeacin estratgica, la elaboracin de
productos y servicios y los procesos de produccin de nuevos procesos.
Procesos operacionales son aquellos mediante los cuales la organizacin lleva a
cabo sus funciones normales da a da, como es convencer al cliente, satisfacerlo,
apoyar al cliente, administracin de efectivo y fiscal e informes financieros.
Procesos de apoyo son aquellos que permiten que se lleve a cabo los procesos
estratgicos y operacionales, como la administracin de los sistemas de
informacin. [43]
Durante las primeras visitas, es labor del gerente de proyectos realizar la identificacin de
los procesos organizacionales del lado del cliente, con el fin de poder conocer un poco las
restricciones y reglas de negocio que a partir de all puedan surgir para el sistema.
Principalmente se busca identificar:

Poder y conflicto: Poder como relacin reciproca interdependiente entre los sujetos
involucrados, por ende, con enorme influencia e importancia tanto en el mbito
relacional dentro de la organizacin como tambin en la efectividad de la misma.
Liderazgo y toma de decisiones: De qu manera un lder o gua, es responsable para
con su trabajo, compaeros, trabajadores y las decisiones que toma, como tambin
la claridad con que anuncia esta informacin y la buena comunicacin subyacente a
esta, influye y afecta en gran medida a la organizacin.

21
 Comunicaciones: Punto primordial dentro de la organizacin, complejo a la razn
de la propia subjetividad, pero que no solo condiciona, sino que afecta y caracteriza
a las organizaciones tanto en su desempeo como relacionalmente segn la manera
en que se aborda, de ello depende, es decir, es fundamental para generar cambios
Cambio e innovacin: Aluden a momentos crticos de la organizacin, los cuales
ponen en riesgo tanto la permanencia como el desarrollo o crecimiento de esta.
Movilizan a la misma, a lograr adaptarse a los cambios de la mejor manera en pro
de evitar su desaparicin [4].
El anlisis de la documentacin de las aplicaciones existentes y afines es una forma
muy til de reunir los requisitos de manera temprana, as como la comprensin y la
captura del conocimiento del dominio, adems de la identificacin de los conceptos
y componentes reutilizables. Estos tipos de investigaciones son particularmente
importantes cuando el proyecto consiste en la sustitucin o mejora de un sistema
heredado existente, o tambin cuando existe algn sistema similar en el mercado y
se quiere observar las funcionalidades y caractersticas que este posee. Los tipos de
documentos que pueden ser tiles para la obtencin de requisitos incluyen los
documentos de diseo y manuales de instrucciones de los sistemas existentes,
formularios en papel y archivos que se utilizan en los procesos de negocio actuales.
Esta labor sirve de apoyo a los ingenieros de requerimientos al facilitar el trabajo en
grupo y la realizacin de entrevistas, ya que se puede utilizar como puntos de
referencia para obtener informacin especfica y detallada, y ayudar en la creacin
de un entendimiento comn entre el analista y las partes interesadas. Estos enfoques
tambin ofrecen la oportunidad de reutilizar las especificaciones y validar nuevos
requerimientos contra otras instancias de dominio [4]. En este punto se logra tener
un entendimiento inicial del modelo de negocio y a partir de este conocimiento se
hace necesario establecer unas pautas que garanticen de cierta manera que la
informacin recopilada en el proceso de elicitacin de requerimientos se encuentre
normalizada y est libre de ambigedades. En este punto se requiere elaborar un
glosario de trminos, el cual contendr la totalidad de expresiones usadas durante el
proceso de elicitacin de requerimientos y el cual deber ser diligenciado y validado
con los stakeholders durante todo el proceso, el formato 0-Glosario_Terminos
describe la estructura del documento usado para dicho glosario (anexo 1: formatos,
instrumentos y herramientas).

6.2 Reunin Inicial (Kick off)

Para nivelar las expectativas de las personas involucradas en un proyecto y de los que no
estn directamente relacionados a la ejecucin pero tienen relacin con el resultado, se debe
realizar un actividad inicial de lanzamiento conocida como Kickoff.
El propsito de la reunin de kickoff es notificar formalmente a los miembros del equipo y
a los que estn interesados en el proyecto (Stakeholders) que ese momento es el inicio
formal y asegurarse que todos y cada uno tienen un entendimiento comn del proyecto y
cules sern sus roles. Como todo encuentro formal, debera haber una agenda. He aqu una
serie de tems especficos que el director del proyecto debera incluir en la reunin de
kickoff [44]:

22
 Presentar a cada persona que fue convocada a la reunin.
Resumir y presentar la informacin relevante. Por ejemplo:
o El propsito del proyecto.
o El alcance.
o Los entregables ms importantes.
o Los riesgos.
o Las suposiciones iniciales.
o La estimacin de esfuerzo y presupuesto.
o Las fechas claves.
Mostrar los roles y responsabilidades del equipo de proyecto y del resto de los que,
en algn momento, estarn involucrados.
Revisar el abordaje general del proyecto y la lnea de tiempo que tomar la
ejecucin. Esto da a la gente una idea de cunto se extender. Particularmente, el
director del proyecto querr asegurarse que las personas entiendan que es lo que se
necesita de ellos para dar soporte al proyecto.
Mostrar los procedimientos de administracin del proyecto. Es importante que cada
uno entienda cmo el gerente o lder del proyecto manejar el programa de trabajo,
los asuntos rspidos, el alcance, los riesgos y otros aspectos ya que mucha gente
juega un rol en esos procedimientos. Por ejemplo, se necesita tener un
procedimiento para manejar las solicitudes de cambios, determinar su impacto en
tiempo y costos y, finalmente, acordar cmo se aprueban o desaprueban dichas
solicitudes. El director no querr lidiar con la gente acerca del procedimiento de
control de cambios una vez que el proyecto se inici. La reunin de Kickoff es el
momento para estar seguro que cada uno entiende, acuerda y acepta cmo sern los
procedimientos.
Discutir y responder cada una de las dudas. La discusin y el intercambio de ideas
no solo puede enriquecer al proyecto sino que permite que las cuestiones especficas
o dudas que las personas puedan tener, sean escuchadas y consideradas.
Confirmar que el proyecto est en proceso.
Los que deberan asistir a la reunin de Kickoff son los miembros del equipo de
seguimiento y de ejecucin, los usuarios claves, tal vez algn proveedor y los que sin ser
parte de la ejecucin estarn involucrados de alguna forma. Por ejemplo: los miembros de
la alta gerencia, los directores y otros [44].

6.3 Acuerdo de nivel de servicio y confidencialidad

Luego de haber realizado el kick-off es necesario mantener el inters y la participacin
activa de los stakeholder dentro del proceso completo de ingeniera de requerimientos. En
busca del cumplimiento de los compromisos de los stakeholders, para lograr esto la
metodologa se apoya en los acuerdos de nivel de servicio (SLA) que define ITIL. El SLA
es un documento que describe el entendimiento formal entre dos o ms partes, en este
sentido entre un proveedor de servicios de IT y un cliente. Este describe el servicio de TI,
documenta los objetivos de nivel de servicio y especifica las responsabilidades del
proveedor de servicio de TI y del cliente, un nico SLA puede cubrir varios servicios de TI

23
o varios clientes. ITIL promueve el uso de los SLA ms hacia el nivel operativo de un
sistema; sin embargo, la metodologa adopta el uso de estos acuerdos con el fin de medir el
nivel de compromiso y desarrollo del proceso de ingeniera de requerimientos, con miras de
que el proceso funcione y fluya de acuerdo a los compromisos que inicialmente se
acordaron en el kick-off [45]. Este proceso inicia con la definicin de requisitos de nivel de
servicio, los cuales deben preocuparse por cubrir principalmente los siguientes aspectos:

Cumplimiento de citas programadas por cada una de las partes involucradas.

Calidad y nivel mnimo de detalle de la informacin suministrada por stakeholders
del lado del cliente.
Nivel mnimo de conocimiento previo del modelo de negocio o acerca de los temas
a tratar en reunin por cada una de las partes involucradas.
Disponibilidad para la resolucin de dudas resultantes luego de tratar el tema de la
reunin por cada una de las partes involucradas.
Nivel mnimo de aceptacin del proceso realizado, por cada una de las partes
involucradas.
Definicin de accin a realizar en caso de que no se haya cumplido con los niveles
mnimos de aceptacin del proceso realizado.
Multas o penalidades por incumplimiento de citas programadas por cada una de las
partes.
Clusulas de confidencialidad de la informacin.
El formato 1P_001 (disponible en el anexo 1: formatos, instrumentos y herramientas)
define un ejemplo de lo que sera la estructura de un SLA, el cual puede ajustarse de
acuerdo a los compromisos y acuerdos que se quieran definir entre las partes involucradas,
el seguimiento y aseguramiento del cumplimiento de estos acuerdos de nivel de servicio
debe ser verificado por parte del gerente o sponsor de proyectos de las partes involucradas.

6.4 Descripcin del problema

6.4.1 Identificacin del problema

En la seccin 6.1 se ha dado una perspectiva inicial del problema, lo cual da una amplia
ventaja ms aun cuando los clientes no conocen sus necesidades o presentan problemas
para expresarlas. En esta labor de la identificacin del problema la metodologa propone el
anlisis de tareas u operaciones que realiza la empresa utilizando un enfoque top-down,
donde se descomponen tareas de alto nivel en sub-tareas secuenciales detalladas hasta que
todas las acciones finalmente sean descritas. El principal objetivo de esta tcnica es
construir una jerarqua de las tareas realizadas por los usuarios y el sistema, para determinar
el conocimiento utilizado o requerido para llevarlas a cabo. El anlisis de tareas
proporciona informacin de las interacciones entre usuario y el sistema con respecto a las
tareas, as como una descripcin contextual de las actividades que se realizan. En la
mayora de los casos considerables se requiere un esfuerzo para llevar a cabo el anlisis de
tareas a fondo, y es importante para establecer qu nivel de detalle se requiere y cuando los
componentes de las tareas se deben explorar ms.

24
Por cada una de las acciones identificadas es necesario determinar si actualmente esta se
puede ejecutar eficazmente, en caso de que se detecte algn aspecto a mejorar o solucionar
es necesario llegar al fondo de la raz del problema. Para esta labor la metodologa propone
el uso de las siguientes herramientas:

Diagrama Causa Efecto: Es un diagrama donde se listan las posibles causas de un

problema. Estas causas pueden ser producidas por materiales, maquinas, mtodos de
trabajo, naturaleza, sistema de medicin y causa humanas.
5 Por qu? (5P): Una vez realizado el diagrama causa-efecto, hay que comenzar a
preguntar a la persona involucrada Porque est ocurriendo tal problema?.
Despus de escuchar su respuesta hay que preguntar nuevamente porque ocurre lo
que dijo en su respuesta y as sucesivamente (La razn de un problema, en algunos
casos, conduce a otra pregunta). Se espera que a la quinta vez (o quiz antes) se
encuentra la verdadera causa raz del problema. [46]

6.4.2 Planteamiento de la solucin

Al momento de plantear una posible solucin al (a los) problema(s) identificado(s) es
necesario realizar un modelo de dicha solucin. La metodologa adopta inicialmente el
enfoque dado en el uso de prototipos que propone la metodologa MPIu+a 4, trabajando de
la mano con el usuario dicha metodologa proporciona una manera organizada y
formalizada de proceder para conseguir usabilidad y accesibilidad (aspectos que no se
acostumbran tener en cuenta) en el diseo de interfaces de usuario durante el desarrollo de
un sistema interactivo [47]. Un prototipo en el sentido genrico es una implementacin
parcial pero concreta de un sistema o una parte del mismo que principalmente se crean para
explorar cuestiones sobre aspectos muy diversos del sistema durante el desarrollo del
mismo. El uso de los prototipos en el desarrollo de sistemas software no se limita slo a
probar las interacciones que los usuarios deben realizar, sino que son tiles tambin para
otras actividades que se realizan durante el proceso, como por ejemplo su gran utilidad en
la fase de recogida o anlisis de requisitos en cuanto que ampla y mejora y la informacin
necesaria para el desarrollo del sistema [38].
Es impensable llegar al final del desarrollo sin haber realizado comprobaciones a lo largo
del camino, en este sentido los prototipos son precisamente el mecanismo que permite
realizar estas comprobaciones, constituyen una herramienta muy til para hacer participar
al usuario en el desarrollo y poder evaluar el producto desde las primeras fases del
desarrollo. Constituyen mucho ms que simples demostraciones del producto; se utilizan
para recoger las impresiones del usuario para repercutirlas en el diseo de la interfaz.

Las tcnicas de prototipado suelen catalogarse en dos categoras bsicas:

Baja fidelidad (low-fidelity o low-fi): Los prototipos de baja fidelidad implementan
aspectos generales del sistema sin entrar en detalle. Permiten abarcar un espectro mayor de
la interaccin a realizar, la Ilustracin 3 presenta las ventajas e inconvenientes que se
presentan al hacer uso de los prototipos de baja fidelidad, en estos prototipos es posible
aplicar la primera ley de la creatividad de FUDD: Para obtener una buena idea, obtn un
montn de ideas, y en este caso obtienes adems mucha realimentacin [48].

4
MPIu+a: Modelo de Proceso de la Ingeniera de la usabilidad y de la accesibilidad de Toni Granollers.

25
 Ilustracin 3: Ventajas y desventajas de los prototipos de baja fidelidad

Alta fidelidad (high-fidelity o hi-fi): Con los prototipos de alta fidelidad se representan
aspectos ms precisos. Sirven, por ejemplo, para detallar el proceso interactivo global de
una o varias tareas concretas. En la Ilustracin 4 se puede observar ventajas e
inconvenientes al hacer uso de esta categora de prototipos.

Ilustracin 4: Ventajas y desventajas de los prototipos de alta fidelidad

Dado que en esta etapa se tiene la idea del problema a un nivel muy superficial se sugiere
utilizar prototipos de baja fidelidad, estos se caracterizan por ser econmicos, rpidos de
construir, rpidos de arreglar y no precisan de tcnicos expertos.

26
El prototipado comprende dos procesos diferenciados:

La presentacin: Partiendo de entender el propsito de la interfaz a desarrollar se

activa un proceso de pensar en cmo se va a mostrar este propsito a los usuarios
para posteriormente trasladar estos pensamientos en elementos visibles para los
ellos.
La interaccin: Necesaria para que la presentacin presente la componente
interactiva y as el prototipo muestre sus posibilidades.
A continuacin, se enumeran las tcnicas de prototipado que adopta la metodologa y las
cuales son propuestas como actividades del MPIu+a:
Bocetos (esbozos) [47]: Los bocetos son maneras de representar primeras ideas, ya sea
sobre lo que se pretende representar, sobre alguna funcionalidad concreta o sobre qu
metforas se utilizarn. Se usan en la etapa ms inicial del diseo, a menudo antes incluso
de determinar muchos aspectos del anlisis de requisitos, con la finalidad de recoger las
primeras impresiones del espacio de trabajo de la interaccin. La clave de los bocetos es su
velocidad de produccin: Un boceto se realiza en unos 15 o 20 segundos, de manera que se
pueden generar gran cantidad de bocetos en muy poco tiempo. Se trata slo de una recogida
de ideas iniciales, la ilustracin 5 brinda un ejemplo del uso de esta tcnica.

Ilustracin 5: Ejemplo de un boceto.

Se sugiere que se haga uso de esta tcnica como primera herramienta para establecer si
efectivamente los problemas fueron correctamente identificados y entendidos por las partes
involucradas en el proceso, en caso de surgir algn desacuerdo o la incapacidad de realizar
estos bocetos iniciales se sugiere aplicar otra tcnica llamada Storyboards, la cual ayuda a
entender ms el proceso y ver como se adapta la solucin planteada en dicho proceso.
Storyboards [47]: La tcnica del storyboarding bsicamente consiste en una serie de
dibujos o imgenes dispuestas en formato secuencial de vietas que aplicada al diseo de
sistemas interactivos, representan cmo un determinado sistema ser usado durante la
consecucin de una determinada tarea. Muestran la evolucin de la situacin del usuario y
su entorno mientras est interactuando con el sistema y resultan especialmente indicados
para aquellos proyectos en los que la implantacin del nuevo sistema cambiar la forma de

27
trabajar o de realizar ciertas tareas de las personas afectadas por l. Representando de una
manera grfica, eficiente e informal la situacin actual de un determinado contexto, que
ser modificado con la implantacin de un nuevo sistema interactivo, y la situacin futura
que describa cmo cambiar la realizacin de las tareas tras la implantacin del nuevo
sistema. As, con una representacin actual y una futura se favorece la comprensin y
evaluacin por las partes involucradas.
Prototipos de papel [47]: Luego de que se haya verificado con las tcnicas anteriores que
el problema se encuentra correctamente identificado y entendido por las partes
involucradas, es de gran utilidad la aplicacin de esta tcnica. La cual se basa en la
utilizacin de materiales tan bsicos como lpiz, el papel y las tijeras para la creacin de
prototipos simples pero enormemente verstiles.
El objetivo de un prototipo de papel no es probar o verificar lo bonito que es el diseo, sino
que se trata de verificar si los usuarios son capaces de realizar sus tareas con la interfaz
propuesta. La utilizacin de esta tcnica de prototipado no precisa incorporar avances
tecnolgicos; slo es necesario que capture la funcionalidad del sistema y que comunique la
informacin y sus interacciones adecuadamente.
Tal como se observa en la ilustracin 6, la tcnica de prototipado consiste en dibujar en un
papel, sin entrar en grandes detalles estticos, las interfaces que se van a probar y valorar.
Los diferentes estados de la interfaz se van dibujando en hojas separadas y mediante un
proceso de ordenacin que el diseador determina permite que el usuario final interacte
con este material simulando el funcionamiento del sistema. Al realizar un prototipo de
papel se trata de reflejar aquellos aspectos de la interfaz del usuario referidos a las
interacciones que el sistema le proporciona. Esto indica un prototipo de papel que deber
mostrar dos aspectos muy importantes: Uno es la presentacin que hace referencia a qu
elementos proporciona dicha interfaz para la interaccin y el otro es la navegacin en forma
de informacin complementaria con diseo claramente perceptible que facilite la movilidad
durante la fase de evaluacin del prototipo.

28
 Ilustracin 6: Ejemplo de prototipos en papel.

Es entendible que en este punto al aplicar esta tcnica los prototipos no sern tan detallados,
puesto que esta etapa del proceso se tiene apenas una visin inicial del problema y de la
solucin a desarrollar puesto que formalmente no se ha iniciado el proceso de elicitacin de
requerimientos, por lo tanto el alcance de esta tcnica se ver delimitado por la informacin
recopilada hasta el momento.
El principal beneficio de la creacin de un prototipo de software es poder obtener
informacin sobre un diseo propuesto en la fase inicial de un proyecto. Esta informacin
puede ser usada para ayudar a refinar los requisitos del proyecto y las especificaciones,
establecer la usabilidad y apoyo de los futuros usuarios. Cuanto estos prototipos sean
aprobados por las partes involucradas en el proceso, es necesario redisearlos de una
manera ms formal, con el fin de puedan hacer parte de la propuesta formal que se va a
entregar al cliente. Para ello se har uso de mockups5, lo cual implica tomar los prototipos
que ya se tienen construidos en papel para disearlos en alguna herramienta computacional.
Algunas de estas herramientas son: Justinmimnd, Flairbuilder, Axure, Foreui Mockingbird,
Mockup Builder, entre otras [49]. En la ilustracin 7 se muestra un ejemplo de mockup
realizado en balsamiq mockups.

5
Mockup: Representacin de la estructura de la informacin, visualiza el contenido y demuestra las
funcionalidades bsicas de una manera esttica

29
 Ilustracin 7: Ejemplo de mockup realizado en balsamiq mockups

6.4.3 Estimacin costo inicial

En esta seccin la metodologa propone la aplicacin de modelos existentes para estimar el
tamao del software y la gestin de costos. Para determinar que modelos aplicar se tom
como referencia la tesis titulada Propuesta de un modelo de anlisis para estimacin del
tamao del software y gestin de costos y riesgos a partir de requerimientos funcionales
realizado por parte de Sandra Patricia Forigua y Oscar Arturo Ballesteros de la Pontificia
Universidad Javeriana. All se propone aplicar el modelo de puntos de funcin para realizar
la estimacin del tamao del software y para estimar el costo el modelo COCOMO II.
La caracterstica principal de este mtodo es la flexibilidad que presenta para ser utilizado
en etapas tempranas del desarrollo del software, en donde no es mucho lo que se sabe con
respecto a las caractersticas del proyecto: esta metodologa se basa en la funcionalidad del
sistema a implementar y no en el producto a crear.
El mtodo puede ser utilizado en diversas etapas del proyecto, a medida que aumente el
conocimiento acerca del proyecto tambin aumentar la calidad de las estimaciones,
hacindolas cada vez ms acercadas a la realidad. Otra caracterstica destacable del anlisis
de puntos de funcin, es su independencia del lenguaje, esto debido a que se basa en la
funcionalidad, lo que hace que esta metodologa sea ideal para cualquier tipo de sistema.
Por qu se eligi COCOMO II para estimar el costo del software?
La caracterstica principal por la que se escogi este mtodo es porque cuenta con la
ventaja de usar para su estimacin un amplio dominio de factores que inciden sobre el costo
del proyecto, tales como: retrasos en el cronograma, prdida de personal, etc.

30
Adicionalmente el modelo se divide en 3 submodelos, dependiendo del conocimiento del
proyecto se aplica determinado submodelo para realizar la estimacin [50].

Estimacin basada en puntos de funcin:

El Anlisis de Punto Funcin se basa de manera terica en que las funciones de una
aplicacin son la mejor medida del tamao de un sistema. El Punto Funcin mide el
software mediante la cuantificacin de la funcionalidad que el sistema le brinda al usuario
basado fundamentalmente en el diseo lgico. Es independiente del lenguaje de
computacin, de la metodologa de desarrollo, de la tecnologa utilizada y de la capacidad
del equipo de trabajo para desarrollar la aplicacin. [51]
El mtodo realiza su estimacin contando el nmero de componentes de cada clase de
punto funcional, luego se estima la complejidad de cada uno de los componentes medidos,
alta o baja, segn sea el caso, luego se multiplica cada contador de puntos de funcin por el
valor adecuado, y se suma el total de puntos de funcin.
Cada uno de los tipos de puntos de funcin se describe a continuacin:

Entradas externas: Datos o entradas de control al sistema que causan que el sistema
lleve a cabo algn procesamiento.
Salidas Externas: datos o salidas de control que salen del sistema, luego de que un
procesamiento ha sido llevado a cabo.
Peticiones Externas: Solicitudes del sistema que requieren inmediata atencin.
Interfaces Externas: Archivos o programas que salen del sistema.
Archivos Internos: agrupamiento lgico de informacin almacenada en el sistema.
Con cada uno de estos elementos se determina qu tan grande va a ser el sistema a
desarrollar.
Al aplicar esta tcnica se tendr como resultado los puntos de funcin por componente del
sistema, lo cual podr traducirse en la cantidad de esfuerzo requerido para desarrollar dicho
componente, la suma total de los puntos de funcin nos darn el estimado del tamao total
del sistema [50].

Estimacin de costos utilizando COCOMO II:

Este modelo permite estimar el costo, el esfuerzo y el tiempo de duracin de un proyecto de
software, fue creado para su utilizacin junto a los ciclos de vida modernos en los proyectos
de software y sigue las necesidades de los usuarios de la estimacin de costos en los
proyectos de software. Estas necesidades son apoyo: en la planificacin de proyectos,
previsin del personal del proyecto, preparacin del proyecto, re-planificacin, seguimiento
del proyecto. [52]
Para realizar todo esto, COCOMO II proporciona tres modelos de estimacin cada vez ms
detallado, que tienen en cuenta cada sector y tipo de informacin necesaria en cada etapa
del desarrollo de un proyecto de software. Cada uno de estos modelos ofrece mayor

31
fidelidad en las estimaciones a medida que se avanza en la planificacin y el diseo del
mismo. Los modelos indicados son:
1. Modelo de composicin de aplicaciones: Este modelo cubre los proyectos
realizados con herramientas modernas de construccin de interfaces grficas.
2. Modelo de Diseo Anticipado: Este modelo est diseado para aplicarse en etapas
iniciales del desarrollo en las cuales la arquitectura del mismo no haya sido
totalmente definida.
3. Modelo de Post-arquitectura: Este es el modelo ms completo incluido en
COCOMO II, y est diseado para aplicarse luego que se ha terminado la etapa de
diseo y luego de que la arquitectura del proyecto se encuentra bien planificada.
La aplicacin de los tres sub-modelos anteriores depende del nivel de conocimiento que se
tiene del proyecto, es decir si no se conoce mucho acerca del proyecto, para una estimacin
inicial se usara el modelo de composicin de aplicaciones , en una etapa ms avanzada del
proyecto, se podra utilizar el modelo de diseo anticipado, y en el momento que se
encuentren diseada la arquitectura del proyecto, se podra utilizar el modelo de post-
arquitectura, estos modelos aumentan en complejidad a medida que se avanza las diferentes
fases del proyecto [50].

6.4.4 Presentacin propuesta solucin

Una propuesta de desarrollo de software est destinada a proporcionar informacin sobre
una solucin de software para automatizar un proceso o resolver un problema de un
negocio. Las propuestas de desarrollo de software pueden ser diferentes en el formato,
dependiendo del proyecto objetivo previsto. Por lo menos, una propuesta de software debe
contener un diseo de alto nivel, una introduccin y un cuerpo principal, con una
conclusin que describa los costos y cualquier otra informacin pertinente. La metodologa
propone que una propuesta de desarrollo de software debe estar estructurada de la siguiente
manera:

Portada
Glosario de trminos: Se incluir el glosario de trminos que ha sido diligenciado
mediante el formato 1P-001 (anexo 1: formatos, instrumentos y herramientas)
Introduccin: Esta seccin tiene como fin ubicar a los lectores en el contenido del
documento, aclarando que se trata de una propuesta de proyecto, el tipo de proyecto
y las condiciones que estarn regulando la ejecucin del proyecto.
Antecedentes: Esta seccin tiene como fin ubicar a los lectores en el contexto en el
cual se desarrollar el proyecto, los aspectos especficos del proyecto se reservarn
para otras secciones, limitndose sta a describir el contexto general para el
desarrollo del proyecto.
Definicin del problema: El propsito de esta seccin es la especificacin clara de
cul es el problema a resolver, no pueden incluirse aspectos de la solucin del
problema.
Objetivo general: Esta seccin describe de manera clara, cul es el objetivo general
que me impulsa a desarrollar el proyecto

32
 Objetivos especficos: Los proyectos tienen asociados una serie de objetivos ms
especficos, estos objetivos deben establecerse de manera que sean:
Claros.
Sencillos.
Retadores pero alcanzables.
Medibles.
Acotados en el tiempo.
Asociados con entregables.
Apoyan claramente el objetivo general
Alcance: Esta seccin delimita exactamente qu estar incluido en el proyecto y qu
no. Es trascendental porque marca el contrato entre proponente y contratante
bajo el cual se regir la ejecucin del proyecto.
Entregables: Los objetivos especficos deben estar directamente asociados con los
entregables, estos deben relacionarse con puntos de control en el cronograma. De
manera que se pueda saber con certeza en qu momento del tiempo es que se
materializaran.
Metodologa: La metodologa indica el cmo se va a desarrollar la solucin al
problema, debe ser lo suficientemente detallada de manera que se pueda dar
seguimiento al avance del proyecto. Esta metodologa puede obedecer a estndares
internacionales, nacionales o a metodologas especficas del campo o concebidas
especficamente para este proyecto.
Aspectos metodolgicos pueden incluir:
1. Metodologas de anlisis, diseo y desarrollo de software. Las cuales estn inmersas
en las siguientes categoras [53]:
a. Metodologas no agiles: Las metodologas no giles son aquellas que estn
guiadas por una fuerte planificacin durante todo el proceso de desarrollo;
llamadas tambin metodologas tradicionales o clsicas, donde se realiza una
intensa etapa de anlisis y diseo antes de la construccin del sistema. Estas
incluyen:
i. Metodologas estructuradas: Los mtodos estructurados comenzaron
a desarrollarse a fines de los 70s con la programacin estructurada,
son particularmente apropiadas en proyectos que utilizan para la
implementacin lenguajes de 3ra y 4ta generacin.
ii. Metodologas orientadas de objetos: Su historia va unida a la
evolucin de los lenguajes de programacin orientada a objetos.
Algunas metodologas orientadas a objetos que utilizan la notacin
UML son: Rational Unified Process (RUP), OPEN, MTRICA (que
tambin soporta la notacin estructurada)
b. Metodologas agiles: Un proceso es gil cuando el desarrollo de software es
incremental (entregas pequeas de software, con ciclos rpidos), cooperativo
(cliente y desarrolladores trabajan juntos constantemente con una cercana
comunicacin), sencillo (el mtodo en s mismo es fcil de aprender y
modificar, bien documentado), y adaptable (permite realizar cambios de
ltimo momento). Las principales metodologas giles identificadas son:

33
 Extreme Programming, Scrum, Familia de Metodologas Crystal, Feature
Driven Development, Proceso Unificado Rational, una configuracin gil,
Dynamic Systems Development Method, Adaptive Software Development,
Open Source Software Development
2. Estrategia general para atacar el problema (ej. definicin de diferentes fases o etapas
del proyecto).
3. Metodologas de trabajo en grupo y relaciones entre miembros del equipo.
4. Estndares, ambientes, y herramientas de software por utilizar

Cronograma de actividades: El cronograma de actividades es un componente muy

importante dentro de la propuesta pues brinda informacin sobre:
o Listado total de las actividades
o Precedencia y relaciones entre las actividades.
o Estimado de esfuerzo requerido para las actividades.
o Responsable de la actividad.
o Puntos de control y eventos clave.
ANEXO A - Otros componentes de la propuesta: Algunos de los componentes
adicionales se describen a continuacin:
o Plan de administracin de riesgos. Un anlisis (cualitativo y/o cuantitativo)
de los eventos que pueden afectar la ejecucin del proyecto, incluyendo la
identificacin del evento, el impacto que tendr si sucede y la estrategia de
administracin del riesgo a utilizar en cada caso.
o Plan de adquisiciones. Utilizado principalmente en proyectos que requieren
de recursos adicionales a humanos, para considerar las cantidades, los
procedimientos y los momentos dnde se requieren inversiones.
o Plan de administracin de cambios. Indica qu debe suceder en caso de que
suceda alguna circunstancia que obligue a hacer cambios en el plan general
de proyecto
o Plan de seguimiento y control. Indica quin y de qu manera le darn
seguimiento al proyecto, especificando las tcnicas por aplicar
o Plan de administracin de la calidad. Indica de qu manera es que se
asegurar que el proyecto satisfacer los objetivos y las necesidades de los
interesados en el proyecto
o Plan de comunicacin. Indica cmo el proyecto comunicar y difundir,
tanto interna como externamente, lo que pasa en el proyecto as como sus
resultados
ANEXO B- Lista de entregables del proyecto: Los siguientes son considerados a
nivel general los artefactos que sern generados y utilizados por el proyecto y que
son considerables como como entregables:
o Modelo de Casos de Uso
o Diagramas elaborados durante el anlisis y planteamiento de la solucin al
problema: Por ejemplo diagramas de colaboracin, de actividades y de
clases.
o Especificaciones de Casos de Uso
o Prototipos de Interfaces de Usuario
o Modelo de Anlisis y Diseo

34
 o Modelo de Datos
o Modelo de Implementacin
o Modelo de Despliegue
o Casos de Prueba
o Solicitud de Cambio
o Lista de Riesgos
o Manual de Instalacin
o Material de Apoyo al Usuario Final
o Producto

6.5 Documentacin
Al finalizar la etapa de pre-anlisis se deber contar con los siguientes documentos:

Glosario de trminos.Creacin del glosario de trminos en el cual se aclara la

terminologa especifica del rea de influencia del proyecto u
otras que puedan generen ambigedad durante el proceso de
ingeniera de requerimientos.
Documento: 0-Glosario_Terminos (anexo 1: formatos,
instrumentos y herramientas).
Acuerdos de nivel de Se deben de crear los acuerdos de nivel de servicio y
servicio y confidencialidad que sean necesarios para cubrir todos los
confidencialidad aspectos que caben dentro del proceso.
Documento: 1P-001 (anexo 1: formatos, instrumentos y
herramientas).

35
 7. ELICITACIN

Resumen
Entradas Glosario de trminos.
Acuerdos de nivel de servicios.
Presentacin de la propuesta.
Prototipos de baja resolucin (StoryBoard).
Salidas Clasificacin del proyecto.
Mapa de stakeholders.
Documentacin de resultados tcnicas de elicitacin.
Actualizacin glosario de trminos.
SRS-Software requirement specification.
Gua identificacin de requerimientos

7.1 Clasificacin del proyecto

Al iniciar el proceso de elicitacin de requerimientos es importante comprender que tan
complejo es el proyecto a desarrollar y cul es la magnitud del desarrollo. Quispe et. Al
[11]menciona algunos factores que influyen en las pequeas empresas del software, los
cuales son: tamao del proyecto, equipo de trabajo, recurso, calidad del personal, procesos
de gestin de proyectos, estructura organizacional, comunicacin y coordinacin. De
manera similar Shenar, Widema y Reiner citados por Campo [54] identifican los criterios o
factores que se deben tener en cuenta para planificar los proyecto de software, estos son:
conocimiento del negocio del cliente, cultura organizacional, normas gubernamentales o de
la industria, experiencias conocidas del cliente, recursos humanos disponibles, condiciones
del mercado, volatilidad de los requisitos, conocimientos del equipo en gestin de
proyectos, naturaleza del proyecto, riesgos del proyecto, complejidad estimada de las
actividades, participacin de los stakeholders en el proyecto, tiempo destinado a conocer las
necesidades del negocio, frecuencia de los entregables del proyecto, limitacin de costo,
tiempo y alcance. Todos los factores mencionados influyen de manera directa para
culminar el proyecto de forma exitosa.
En la presente metodologa se dan una serie recomendaciones, las cuales permiten
categorizar los proyectos. Para esto es importante identificar si el proyecto a desarrollar es
un desarrollo a la medida o el desarrollo de una idea de negocio (Este ltimo por lo general
se da hacia la creacin de un producto para un pblico en general). Como lo menciona
Merchan, Urrea y Rebollar [10] es necesario tener en cuenta que en ambos tipos de
proyecto cambian las fuentes de requerimientos y los stakeholders. Una de las principales
diferencias entre ambos es que las ideas de negocio por lo general se encuentran enfocadas
a desarrollar un producto que sea de consumo masivo en un determinado segmento de
mercado, mientras los desarrollos a la medida de manera comn son dados para un grupo
de personas u organizacin que presenta un problema y desea por medio del software
generar una solucin.

36
 7.1.1 Tipo de proyecto idea de negocio
La principal caracterstica que encontramos en estos proyecto est dada por el desarrollo de
un producto para un pblico masivo en un determinado segmento de mercado, estos tipo de
proyectos tambin son denominados StartUp. Los cuales por definicin son
organizaciones temporales en bsqueda de un modelo de negocio escalable y replicable
[55], tambin es comn que para estos proyectos se desconozca como el mercado adoptar
dicho producto y si este tendr xito, esto hace que el grado de incertidumbre sea mayor.
Tal como lo mencionan Merchan, Urrea y Rebollar en el caso de buscar los posibles
stakeholders es necesario identificar cules son los posibles futuros consumidores del
producto o personas con amplio conocimiento en el rea relacionada con el producto; Por
ejemplo si el producto es un desarrollo para dispositivos mviles enfocados al transporte
ser necesario preguntar a los directivos de empresas de transporte y conductores acerca de
ciertos tems de esta rea y a la vez preguntar a los consumidores por las futuras
funcionalidades que esperaran del producto.
Algo importante a tener en cuenta para este tipo de proyectos es que se debe crear versiones
rpidas y sencillas del producto, esto con el fin de verificar la aceptacin en el mercado y
obtener una retroalimentacin pronta, a su vez, es fundamental incluir de manera oportuna
funcionalidades sencillas y tiles para el usuario.

7.1.2 Tipo de proyecto desarrollo a la medida.

Una caracterstica importante de los desarrollos a la medida es que existe un problema
identificado por un grupo de individuos o una organizacin y por medio de soluciones de
TI (Tecnologas de informacin) se espera solucionar o mitigar dicho problema; sin
embargo, dichas soluciones pueden ser tan sencillas o complejas segn sea el caso. Para
ilustrar esto Alistair Cockburn en su artculo Metodologa por proyecto menciona que por
ptima que sea una metodologa seria complejo aplicarla de la misma manera en todos los
tipos de proyectos. En particular Cockburn define que los criterios necesarios para
seleccionar la(s) metodologa(s) en un proyecto son: el tamao del equipo, la criticidad y
las prioridades, por ejemplo el proyecto del ao 2000 para el banco nacional, la creacin de
un software para un transbordador espacial, la creacin de una aplicacin para solicitud de
alimentos en horarios extras, el software para el seguimiento a promociones y la creacin
de una aplicacin tipo procesador de texto son proyectos en los cuales se ejemplifica que
cada uno tiene diferencias en el nmero de personas, el grado de criticidad y las prioridades
de cada uno de estos. De aqu que Cockburn propone el uso de una matriz bidimensional en
donde cada una de las celdas hace referencia al tamao y la criticidad del proyecto. La
Ilustracin 8 describe el sistema de rejillas propuestas por Cockburn y adaptado para la
presente metodologa [56].
Para el caso de la presente metodologa usaremos la escala propuesta por Cockburn como
herramienta para clasificar los desarrollos a la medida, puesto que los siguientes tems son
acordes a las necesidades de la ingeniera de requerimientos evidenciadas en la regin [33]
[56].

37
Cockburn en Metodologa por proyecto menciona que:

Al usar dos dimensiones permite una mayor comprensin y fcil uso de la

herramienta.
Permite visualizar de manera fcil el costo y rigor que requiere el proyecto ya que al
moverse a la derecha o arriba de las celdas se tendr un mayor costo y nivel
rigurosidad, caso contrario obtenemos al desplazarnos hacia abajo o hacia la
izquierda (Ver Ilustracin 8).
La escala puede ser usada para cualquier tipo de proyecto.
La escala de Cockburn permite clasificar los proyectos segn dos aspectos, los cuales son:
1. que tan crtico puede ser el proyecto y 2. Cul es el nmero estimado de personas
necesarias involucradas en el desarrollo de la solucin [57].
De manera similar es necesario tener en cuenta que segn la complejidad del proyecto
mayor ser el nmero de stakeholders involucrados en el proceso de desarrollo (En la
seccin 7.2 se ampliaran los conceptos relacionados con stakeholders)
Para aplicar la escala de Cockburn es necesario analizar el impacto que tendr el proyecto
siguiendo los siguientes dos parmetros [57]:

1. Evaluacin de la criticidad del proyecto

Cockburn [56] [58] define cuatro categoras para identificar la criticidad las cuales son:
Perdida de Vida (Loss of Life - L); Perdida esencial de dinero (Essential money - E);
Perdida discrecional de dinero (Discretionary Money - D) y perdida de confort (Loss of
confort- C). Para evaluar que tan crtico es el proyecto a realizar se debe analizar siguiendo
la siguiente pregunta: Qu puede suceder en el peor de los casos si ocurre un fallo en el
sistema? Segn la respuesta obtenida se deber clasificar el proyecto de la siguiente manera

Si al ocurrir un fallo es posible perder una vida humana como consecuencia a este,
se debe asignar el valor L (Life).
Si al ocurrir un fallo existe una importante prdida econmica que puede poner en
riesgo la continuidad de la organizacin asignar el Valor E (Essential money).
Si al ocurrir un fallo existe una prdida econmica la cual no es significativa asignar
el Valor D (Discretionary Money).
Si al ocurrir un fallo se genera tan solo prdida de comodidad en la organizacin
asignar Valor C (confort).

2. Evaluacin de nmero de personas en el proyecto

Desde el punto de vista del tamao es necesario asignar un valor en funcin al nmero de
personas que participaran en el proceso del desarrollo del proyecto, por regla general para
los proyectos entre 1 y 6 personas se debe asignar el valor de 6, entre 7 y 20 personas se
asigna el valor 20, entre 21 y 40 personas se asigna el valor de 40 y por ltimo los
proyectos de ms de 41 personas se asigna el valor de 100. La tabla 4 resume el valor
asignar segn el nmero de personas que participan en el proyecto [59].

38
 Nmero de personas por proyecto Valor
Proyectos entre 1 y 6 personas (p) (1 6) 1
Proyectos entre 7 y 20 personas (p) (7 20) 20
Proyectos entre 21 y 40 personas (p) (21 40) 40
Proyectos ms de 41 personas (p) ( 41) 100
Tabla 4: Valor segn personas por proyecto

Por ultimo para determinar el grado de formalidad del proyecto Cockburn propone crear
una matriz bidimensional en donde se combinan ambos parmetros (criticidad x nmero de
personas) para obtener un cdigo alfanmero [58] [59]. A dicho cdigo alfanumrico le
corresponde una posicin en la matriz bidimensional representado en la ilustracin 8. Para
el caso de esta metodologa se ha adicionado un cdigo de colores (Azul, verde, amarillo,
naranja, rojo) para agrupar los proyectos en cinco categoras. Esto con el fin de crear una
adaptacin para el contexto regional segn los inconvenientes encontrados. En dicha
clasificacin el nivel uno (Azul) representa los proyectos que requieren menor formalidad y
el nivel cinco (Rojo) representa el mayor grado. La tabla 5 representa la agrupacin de las
cinco categoras con cada uno de los cdigos alfanumricos definidos por Cockburn en la
matriz bidimensional.

Ilustracin 8: Matriz bidimensional de escala de Cockburn adaptada para la presente metodologa.

Es necesario identificar cual es la categora a la que pertenece el proyecto a desarrollar, esta

etapa constituye un aspecto fundamental para la metodologa debido a que segn sea la
categora del proyecto cambiaran las tcnicas, herramientas y procesos que se debern
aplicar durante esta. Las categoras han sido creadas para simplificar el proceso de
ingeniera de requerimientos en los proyectos de baja formalidad y a su vez no escatimar
detalles para los de alta formalidad.

39
 Grado de complejidad Escalas Cockburn incluidas
Nivel 1 (Azul) C6
Nivel 2 (Verde) D6 - C20
Nivel 3 (Amarillo) E6 - D20 - C40
Nivel 4 (Naranja) L6 - L20 - E20 - E40 - D40- D100 -
C100
Nivel 5 (Rojo) L40 - L80 - E80
Tabla 5: Clasificacin de los proyectos para metodologa

7.2 Identificacin de stakeholders

Es de suma importancia comprender el rol que juegan los stakeholders o tambin llamados
grupos de inters dentro del proyecto, ya que ellos son los que brindaran la informacin
necesaria para culminar el proyecto con xito. El punto clave es Cmo identificar las
personas interesadas en que este proyecto salga en buen trmino?, ms aun cmo
clasificarlos?
Como lo menciona Mary Ann Crow [33] es necesario aclarar los conceptos bsicos que
permiten la identificacin de stakeholders, los cuales son:

Identificar las personas que podrn impactar de manera positiva o negativa el

proyecto.
Quienes Podrn ganar o perder segn el xito del proyecto.
Sobre quien recae la autoridad del proyecto.
Quienes tiene afectacin directa de los resultados esperados.
Para realizar la clasificacin de estos usaremos el Mapa de stakeholders (ilustracin 9), el
cual permite ubicar a los interesados en categoras y con esto segn su ubicacin podremos
identificar el poder de inters e influencia que cada uno de ellos tiene (Formato 2E-002, en
anexo 1: formatos, instrumentos y herramientas) [60]:

40
 Ilustracin 9: Mapa de stakeholders

Es importante identificar los principales stakeholders y centrar los esfuerzos en estos. Por
ende citando a Corporate Excellence [61] es importante:

Identificar quienes son y cmo se llama.

Expectativas de que buscan y que esperan.
Que derechos tienen y que obligaciones tenemos.
Priorizar quienes son los ms importantes segn lo anterior.
Para esto se tomar como gua las recomendaciones de Martinez [62], con el fin de
identificar y ubicar los stakeholders en la matriz (Formato 2E-002, en anexo 1: formatos,
instrumentos y herramientas).
1. Identificar los stakeholders: Realizar lluvia de ideas que permita identificar los
stakeholders. Para esto es necesario pensar en todas las personas que estarn
afectadas de alguna manera en el proyecto (Sea de manera positiva o negativa),
personas que tiene inters en el xito o fracaso de este.
2. Priorizar los stakeholders: Es importante ubicar a los stakeholders dentro del
mapa de stakeholders. Los cuales podrn estar en una de las siguientes reas:
Gente con mucho inters y poder: Ubicacin en seccin Administrar de
cerca.
Gente con mucho poder, pero menos inters: Ubicacin en seccin
Mantener satisfecho.
Gente con poco poder y mucho inters: Ubicacin en seccin Mantener
informados.
Gente con poco poder y poco inters: Ubicacin en seccin Monitorear.
3. Entender a los stakeholders: Es necesario entender cmo reaccionan los
stakeholders, como se sienten y cmo reaccionan. Las siguientes preguntas
ayudarn a identificar dichas caractersticas:

41
 Qu inters financiero o emocional tienen en el resultado del proyecto? Es
positivo o negativo?
Qu es lo que ms los motiva?
Qu informacin del proyecto requieren?
Cmo quieren recibir la informacin? Cul es la mejor forma de
comunicarse con ellos?
Cul es su opinin actual del proyecto? Esta opinin, est basada en buena
informacin?
Quin influencia sus opiniones en general? Quin influencia su opinin
sobre el proyecto? Convierte esto a las personas que generan influencia en
Stakeholders? (La ilustracin 9 nos permite identificar y ubicar estos
Stakeholders)
Si es probable que no sean positivos, Cul es la forma de ganar su apoyo al
proyecto?
Si no es probable que se pueda ganar su apoyo al proyecto, Cmo se puede
manejar su oposicin?
En este punto es posible aplicar un cuestionario con el fin de llegar de manera masiva a
varios stakeholders y de esta manera poder identificar sus actitudes. Al diligenciar la matriz
de la ilustracin 10 es necesario usar un cdigo de colores en los cuales, verde representa
personas a favor del proyecto, rojo opositores y naranja los neutrales.

Julio
Mara Clara. Otalvaro.

Manuel

Ilustracin 10: Ejemplo mapa de stakeholders

42
Aunque identificar los stakeholder puede ser un proceso complejo, es importante para la
aplicacin de las tcnicas de elicitacin identificar los principales, los cuales para nuestro
caso particular (Realizar elicitacin de requerimientos) debemos centrarnos en los
stakeholders que se ubican en la parte superior de la matriz, sobre las reas de mantener
satisfechos y administrar de cerca.

7.3 Tcnicas de elicitacin

La elicitacin de requerimientos (tambin llamada educcin de requisitos) consiste en la
aplicacin de tcnicas que permitan obtener las necesidades que debe cumplir un sistema a
desarrollar, ms aun como lo mencionan Lorena Castaeda Bueno La elicitacin de
requerimientos consiste en la indagacin o levantamiento de los requerimientos, por medio
de una serie de tcnicas [63]. La aplicacin de dichas tcnicas permite generar un
acercamiento de las necesidades que presentan los interesados en el proyecto (Llamados
stakeholders); a su vez, el proceso de elicitacin es un paso fundamentalt para obtener un
mejor entendimiento del problema a resolver y depende de manera directa de las tcnicas
seleccionadas y la forma como estas son aplicadas.
Es comn encontrar en la literatura relacionada con elicitacin de requerimientos contrastes
entre las tcnicas que se deben aplicar y la forma en como estas deben ser usadas. Para este
caso se usaran las tcnicas que describen Aurum y Wohlin en su libro Engineering and
managing software requirements [4]. Dichos autores han sido seleccionados dado que
entre ambos existe una combinacin de experiencia en el mbito acadmico e industrial.
Para el caso de la Dra. Aybke Aurum se evidencia conocimiento acadmico como lder y
fundadora del grupo Requirements Engineering Research Group (ReqEng) en la
universidad de New South Wales, mientras el Phd Claes Wohlin aporta conocimiento como
docente y experiencia en la industria [64]. En el siguiente apartado se realiza una breve
descripcin de las tcnicas propuestas por dichos autores.

7.3.1 Descripcin tcnicas de elicitacin

Entrevistas: Probablemente es la tcnica ms usada para realizar elicitacin, se trata de
entrevistas informales en la cual la calidad de la entrevista depende de manera directa de la
interaccin lograda con los participantes. Esta tcnica permite recoger gran cantidad de
datos de forma rpida. Existen tres tipos de entrevistas las cuales son: no estructura, semi-
estructuradas y estructuradas. La entrevista no estructurada nos permite conocer el lmite
del sistema y el dominio del problema, mientras la entrevista estructurada devela
informacin especfica del problema a solucionar.
Cuestionarios: Es usada en las primeras etapas de los requerimientos, las preguntas
formuladas en este pueden ser abiertas o cerradas. El uso de esta tcnica nos permite
conocer de manera rpida la percepcin de mltiples stakeholders, sin embargo el principal
inconveniente es no permitir aclarar la ambigedad que se da al momento de obtener
requerimientos.

43
Anlisis de tareas: Permite descomponer tareas en un enfoque de arriba hacia abajo (Top-
down), donde todas las tareas de alto nivel se descomponen en sub-tareas, hasta llegar al
nivel en donde se describen eventos o acciones. El principal objetivo de esta tcnica es
construir jerarquas que permitan ilustrar la interaccin entre los usuarios y el sistema con
las tareas.
Anlisis de dominio: Usada para examinar documentacin y aplicaciones existentes con el
fin de reunir informacin de los requisitos. Es til cuando se tiene sistemas previos
(Sistemas heredados). En esta tcnica es de utilidad la experiencia de los analistas o
persona encargada de los requisitos en sistemas similares. El anlisis de dominio ayuda a
generar un entendimiento comn entre las partes.
Introspeccin: Tcnica la cual requiere que el ingeniero de requisitos tome como base las
creencias de los usuarios y stakeholders hacia el sistema. Es usada solo al inicio de la fase
de elicitacin y es efectiva cuando el personal encargado de los requerimientos conoce el
dominio del negocio y los procesos de la organizacin.
Grilla de reportes: Es usado para categorizar los elementos del sistema en una matriz,
detallando las instancias del sistema y asignado variables correspondientes. Esta labor es
realizada por los stakeholders. Esta tcnica debe ser usada acompaado por un experto en el
dominio del tema.
Ordenacin de Tarjetas (Card Sorting): Corresponde a la ordenacin de una serie de
tarjetas por parte de los stakeholders. Las tarjetas contienen los nombres de dominios segn
su propia comprensin, de cada tarjeta los stakeholders deben ordenarlas y explicar por qu
la ordenacin. Esta tcnica es usada para representar la responsabilidad entre el usuario y
los componentes del sistema, debido a que esta representa un alto nivel de abstraccin.
Laddering: Tcnica la cual usa preguntas cortas para que los stakeholders expresen su
entendimiento del dominio del problema de manera organizada y lgica. Es posible
complementar usando las tarjetas de ordenacin como herramientas para clasificar
requerimientos y re-categorizarlos.
Grupos de trabajo: Los grupos de trabajo constituyen una de las tcnicas ms comunes, se
trata de reuniones colaborativas, sin embargo pueden ser complejidad de organizar dado el
nmero de stakeholders implicados en los proyecto. Es importante obtener cohesin entre
el grupo con el fin de generar un ambiente confortable lo cual permite a los participantes
dialogar de manera abierta.
Lluvia de ideas: Proceso en el cual diferentes stakeholders participan en una discusin
informal para la generacin rpida de ideas. Es usada para exploraciones preliminares del
sistema, en ocasiones permite nuevas e innovadoras soluciones. Es importante tener en
cuenta que no es comn resolver cuestiones relevantes del sistema usando esta tcnica.
Desarrollo de aplicaciones de agregacin (Joint Application Design -JAD): Involucra a
los diferentes stakeholders en donde a travs de discusiones se indaga los problemas
existentes y las posibles soluciones, su diferencia con la lluvia de ideas consisten en que el
principal objetivo a indagar se encuentra definido. El foco de esta reunin es centrarse en
necesidades y deseos del negocio.

44
Taller de requerimientos: Nombre genrico impartido al grupo de talleres donde se
buscan los requerimientos de software. Existen diferentes tcnicas que permiten obtener
los requerimientos en talleres. Es de suma importancia involucrar a los stakeholders de
diferentes arias, esto con el fin de obtener requerimientos de manera colaborativa.
Etnografa: Basado en el estudio de las personas en el ambiente natural. Su principal
objetivo es recolectar informacin de las actividades que realizan en la organizacin. Esta
tcnica es til para fortalecer factores de usabilidad y contextos colaborativos con el
sistema. Resulta una tcnica muy til para la creacin de nuevos sistemas.
Observacin: Tcnica usada en la etnografa, basada como su nombre lo indica en la
observacin directa sobre el(los) problema(s) a resolver. Esta tcnica usa como
complemento entrevistas y anlisis de tareas.
Anlisis de protocolos: Tcnica en la cual las personas dialogan en voz alta sobre las
acciones que llevan a cabo en su entorno y los procesos que existen detrs de estas. El uso
de esta tcnica permite obtener informacin especfica del problema.
Aprendiz: Para realizar esta tcnica es necesario que exista al menos una persona que se
involucre en las tareas actuales y cotidianas de la organizacin, esto realizado bajo la
supervisin de un usuario experto. Es de suma importancia que la persona se inmiscuya en
el mundo real de las actividades del negocio.
Prototipo: Tcnica que permite obtener retroalimentacin por parte de los stakeholders,
adems es comn que los prototipos sean dados en conjunto con otras tcnicas de
elicitacin como las entrevistas o tcnica JAD. Es una tcnica usada para desarrollar
interaccin humano-computador o cuando los stakeholders no se encuentran familiarizados
con la solucin. Existen diferentes mtodos para realizar prototipos como lo son
Storyboards y aplicaciones ejecutables. Los prototipos motivan a generar sistema con mejor
interaccin para usuarios.
Enfoques basados en metas: Consiste en identificar las metas de alto nivel (Basado en los
objetivos deseados) y estos descomponerlos en sub-objetivos, refinarlos con la intensin de
llegar a requerimientos individuales. El enfoque de esta tcnica est en representar detalles
entre las entidades del dominio, requerimientos y objetivos del sistema.
Escenarios: Son ampliamente utilizados para obtener los requisitos, consiste en una
narrativa y especificacin del actual y futuro proceso incluida acciones e interacciones entre
los usuarios y el sistema. Es una tcnica usada para entender y validar los requerimientos,
as como el desarrollo de pruebas.
Puntos de vista: permite ver el modelo desde diferentes puntos de vista con el fin de
desarrollar una visin completa y coherente del sistema, por ejemplo un sistema puede ser
descrito en trminos de operacin, implementacin e interfaces visuales. Usado para
soportar la organizacin y priorizacin de requerimientos.
Cada una de las tcnicas mencionadas cumple una funcin especfica para la elicitacin de
requerimientos. En la tabla 6 se puede observar cuales son los enfoques de algunas de las

45
tcnicas segn Aurum y Wohlin [4], asimismo la matriz representada en la tabla 7 presenta
los complementos y alternativas entre tcnicas [4].

Puntos de vista
Escenarios
Etnografa
Grupos de
Entrevista

Prototipos

Objetivos
Dominio

trabajo
Comprender el X X X X X X X
dominio
Identificar el X X X X X X
origen de los
requerimientos

Analizar los X X X X X X X
stakeholders
Seleccionar las XX X X
tcnicas y
enfoques

Elicitacin de X X X X X X X X
requerimientos
Tabla 6: Tcnicas y enfoques

Puntos de vista
Escenarios
Etnografa
Grupos de
Entrevista

Objetivos
Prototipo
Dominio

trabajo

Entrevista C A A A C C C
Dominio C C A A A A A
Grupos de A C A C C C C
trabajo
Etnografa A A A C C A A
Prototipo A A C C C C C
Objetivos C A C C C C C
Escenarios C A C A C C A

46
Puntos de vista C A C A C C A
Tabla 7: Complementos y alternativas entre tcnicas, tcnicas complementarias (Representadas con la letra C) y
alternativas (Representadas con la letra A)

Otra forma de usar las tcnicas de elicitacin es observar segn la definicin de cada una,
cul es su finalidad. Para esto los autores del presente documento toman de referencia la
definicin descrita en Engineering and managing software requeriments [4] y con esto
proponen agruparlas en las siguientes categoras: obtencin de datos generales, obtencin
de datos especficos, validacin de requerimientos, identificacin de prioridades y tcnicas
orientadas a la experiencia del usuario (Usabilidad). Dicha agrupacin se representa en la
tabla 8.

Validacin de
Obtencin de

Obtencin de

requerimient

Priorizacin

Usabilidad
especficos
generales
datos

datos

os
Entrevista X
Lluvia de ideas X
Grilla de reportes X
Anlisis de protocolos X
Etnografa X
Observacin (*) X
Prototipos X X
Escenarios X
Puntos de vista X
Tabla 8: Tcnicas vs objetivos propuestos para la metodologa

*Estatcnica es usada de manera similar a la etnografa y es pertinente aplicar como

complemento a las tcnicas de entrevista y el anlisis de tareas.

7.3.2 Tcnicas para ideas de negocio (Start Up)

Como se mencion en la seccin 7.1.1 las ideas de negocio son proyectos en los cuales el
conocimiento acerca de las funciones y necesidades que debera tener el sistema es
conocido por los posibles consumidores del producto y expertos en el tema, por ende las
tcnicas que nos permiten abordar a estas personas con mayor facilidad estn enfocadas a la
obtencin de datos generales que nos ayuden a comprender el dominio del problema. Por
consiguiente se propone aplicar como tcnicas de elicitacin las entrevistas y el desarrollo
de aplicaciones de agregacin (JAD) entre los futuros consumidores y las personas expertas
en el rea que se desea incursionar (Stakeholders), la tabla 9 nos presenta el resumen de los
stakeholders y las tcnicas que se deben aplicar para este tipo de proyectos.

Stakeholders Tcnicas aplicar

Futuros consumidores Entrevistas.
Expertos en el rea de influencia del Desarrollo de aplicaciones de agregacin
problema (JAD).
Tabla 9: Stakeholders y tcnicas usadas para las ideas de negocio (startUp)

47
 7.3.3 Tipo de proyecto desarrollo a la medida.
Al momento de realizar el proceso de elicitacin de requerimientos es importante
seleccionar las tcnicas que se deben aplicar, para el caso de la presente metodologa las
tcnicas deben ser seleccionadas dependiendo del nivel de formalidad del proyecto descrito
en la tabla 5 (Seccin clasificacin del proyecto literal 7.1.2). Cada una de las tcnicas ha
sido seleccionada con el objetivo de simplificar el proceso de elicitacin para los primeros
niveles segn la clasificacin del proyecto y a la vez no perder rigurosidad en los niveles
ms altos. Se toma como base los fundamentos y clasificaciones dados por Aurum y
Wohlin [4] para segmentar las tcnicas y sus enfoques (representando en la tabla 6), as
mismo los complementos y alternativas entre las tcnicas (tabla 7) y el anlisis propuesto
en la presenta metodologa para las tcnicas vs objetivos (tabla 8).
En cada uno de los niveles se busca obtener diversidad de tcnicas, las cuales permitan
obtener datos generales y especficos, identificar la prioridad de los requerimientos,
abstraer informacin para la usabilidad del producto, validar los requerimientos,
comprender la interaccin con el usuario, identificar los stakeholders y describir los
componentes en el sistema. Las tcnicas que se deben aplicar para cada nivel se encuentran
detalladas en la tabla 10. En cada una de las fases se incluye tcnicas relacionadas con
protitipado (tomado como aparte de la metodologa MPIU+a [65]) con la intencin de
identificar elementos relacionados con la usabilidad.
De cada una de las tcnicas aplicadas es necesario generar un registro con los resultados
obtenidos al aplicar dicha tcnica, para esto se ha dispuesto el formato 2E-001 disponible
en el anexo 1.

Grado de Tcnicas aplicar Objetivo al aplicar la tcnica

complejidad
Entrevista y lluvia de ideas Obtencin de datos generales.
Nivel 1 (*).
Prototipos. Validacin y usabilidad.
Entrevista y lluvia de ideas Obtencin de datos generales.
(*).
Anlisis de protocolos (*). Obtencin de datos especficos.
Nivel 2
Anlisis de tareas. Interaccin entre el usuario y el sistema.
Prototipos. Validacin y usabilidad.
Puntos de vista (*). Priorizacin.
Entrevista, anlisis de Obtencin de datos generales.
dominio y lluvia de ideas (*)
Anlisis de protocolos. Obtencin de datos especficos.
Nivel 3 Anlisis de tareas. Interaccin entre el usuario y el sistema.
Prototipos. Validacin y Usabilidad.
Observacin. Usabilidad.
Puntos de vista. Priorizacin.
Entrevista y anlisis de Obtencin de datos generales.
Nivel 4 dominio.
Cuestionarios. Obtencin de datos generales y puntos
vista Stakeholders.

48
 Anlisis de protocolos. Obtencin de datos especficos.
Grilla de reportes (*). Obtencin de datos especficos.
Enfoque basado en metas. Obtencin de datos especficos (Dominio
requerimientos y objetivos del sistema).
Anlisis de tareas. Interaccin entre el usuario y el sistema.
Prototipos. Validacin y usabilidad.
Etnografa. Usabilidad.
Puntos de vista. Priorizacin.
Introspeccin (*). Aproximacin tcnica hacia la solucin.
Entrevista, lluvia de ideas y Obtencin de datos generales.
anlisis de dominio.
Cuestionarios. Obtencin de datos generales y puntos
vista Stakeholders.
Anlisis de protocolos y grilla Obtencin de datos especficos.
de reportes (*).
Enfoque basado en metas. Obtencin de datos especficos (Dominio
requerimientos y objetivos del sistema).
Nivel 5 Anlisis de tareas. Interaccin entre el usuario y el sistema.
Prototipos. Validacin y usabilidad.
Etnografa. Usabilidad.
Escenarios. Validacin.
Puntos de vista. Priorizacin.
Introspeccin. Aproximacin tcnica hacia la solucin.
JAD Necesidades y deseos del negocio
Ordenacin de tarjetas. Responsabilidad entre usuario y
componentes del sistema
Tabla 10: Tcnicas segn clasificacin del proyecto

(*)Tcnicas opcionales

7.4 Lista de requisitos.

Luego de aplicar las tcnicas y procesar sus resultados, el paso siguiente es identificar cada
una de las funciones que debe tener el sistema y a la vez que se encuentran dentro del
dominio del problema. Una recomendacin til para identificar los requerimientos es
resaltar las partes claves de los requisitos en cada una de los formatos 2E-001 del anexo 1,
en este punto es necesario identificar los requisitos que son obligatorios y los que son
deseables a realizar [66]. Es posible identificar los requisitos por medio de frases generales
sobre lo que el sistema debe hacer sea a nivel de producto, reglas organizacionales y
factores externos. Todos estos debern estar enfocados a los objetivos del sistema.
De otro lado para facilitar la identificacin de requisitos se presenta el formato 2E-003
ubicado en el anexo 1, el cual por medio de preguntas puntales nos permite identificar los
aspectos que deba tener el sistema.

49
Para identificar las funciones del sistema es necesario plasmar los requisitos identificados
en el documento 0-SRS

7.5 Documentacin.
Al finalizar la etapa de elicitacin se deber contar con los siguientes documentos:

Documentacin Segn el tipo de proyecto y las tcnicas aplicadas es necesario

resultados tcnicas de almacenar la evidencia. De cada una de las tcnicas es
elicitacin necesario generar un informe, para esto se puede seguir el
instrumento.
Documento: 2E-001 (anexo 1: formatos, instrumentos y
herramientas).
Mapa de stakeholders. Matriz en la cual se plasme con nombre completo los
principales stakeholders, ubicados en los respectivos
cuadrantes del mapa de stakeholders.
Documento: 2E-002 (anexo 1: formatos, instrumentos y
herramientas).
Gua identificacin de Herramienta generada para ayudar a identificar los
requerimientos requerimientos del sistema.
Documento: 2E-003 (anexo 1: formatos, instrumentos y
herramientas).
Glosario de trminos. Actualizacin del glosario de trminos en el cual se aclaren la
terminologa especifica del rea de influencia del proyecto u
otras que puedan generen ambigedad durante el proceso de
ingeniera de requerimientos.
Documento: 0-GlosarioTerminos (anexo 1: formatos,
instrumentos y herramientas).

50
 8. ANALISIS

Resumen
Entradas Clasificacin del proyecto.
Mapa de stakeholders.
Documentacin de resultados tcnicas de elicitacin.
Glosario de trminos.
SRS - Software Requirements Specification.
Salidas SRS - Software Requirements Specification.
Matriz de trazabilidad.
Matriz de rastreo
Descomposicin jerrquica.

El anlisis de requerimientos es la actividad situada entre la elicitacin (fase en la cual los

requerimientos son identificados y descritos) y especificacin (etapa donde se realiza la
respectiva documentacin y definicin de modelos que permitan la comprensin de los
requerimientos) [67]. El objetivo del anlisis de requerimientos es detectar y resolver
conflictos, descubrir los lmites del sistema y elaborar los requisitos del software [5]. Esto
se logra realizando un anlisis de calidad a cada uno de los requisitos, se hace necesario
evaluar criterios como: Requerimientos realizables, no ambiguos, verificables, concisin,
independientes del diseo, entre otros [67].
Durante este captulo se describirn las fases de la etapa de anlisis de requerimientos, las
cuales se observan en la Ilustracin 11. Al inicio de esta etapa es fundamental contar con la
lista de requerimientos, la cual ha sido obtenida en la seccin de elicitacin (Ver 0-SRS).

Ilustracin 11: Proceso de anlisis de requerimientos

51
La primera etapa de esta fase consiste en verificar los requerimientos, para esto es posible
aplicar dos tcnicas, las cuales son: el checklist de anlisis y la matriz de interaccin (En
esta primera parte segn sea el caso puede ser necesario aplicar negociacin de
requerimientos). De manera posterior es necesario delimitar las funciones que realizar el
sistema, luego se deben clasificar los requerimientos (Usando descomposicin funcional) ,
lo cual permitir observar el software como una estructura jerrquica a nivel de mdulos
[7]. Asimismo definir los requerimientos funcionales y no funcionales, tambin asignar
prioridad a cada uno de los requerimientos identificados. Por ltimo se describir la
estimacin de costo y tiempo que se debe realizar en el proyecto.
En el caso de los sistemas complejos estos por lo general implican una gran cantidad de
requerimientos y por ende se hace complicado identificar la totalidad de requerimientos
necesarios que satisficieran el sistema. Es por esto que se recomienda seguir un modelo en
espiral, el cual se describe en la ilustracin 12. Esta metodologa se da debido a que durante
el desarrollo del sistema una parte significativa de los requerimientos cambiarn [68], por
esto se recomienda que para los proyectos los cuales se encuentran en nivel tres o superior
se haga uso del modelo en espiral.

Ilustracin 12: Mtodo en espiral para proceso requerimientos

52
 8.1 Verificacin requerimientos
El propsito de realizar verificacin de requerimiento es garantizar que cada uno de los
requerimientos sea de calidad. Para asegurar esto es necesario que cada requerimiento sea
completo, correcto, realizable, necesario, priorizable, no ambiguo, verificable, conciso e
independiente del diseo [7] [67].
Completo: Debe tener toda la informacin necesario para poder realizar un diseo que
permita implementar la funcionalidad requerida.
Correcto: Describe de manera precisa la funcionalidad a construir, no debe entrar en
conflicto con otros requerimientos. Los usuarios ms expertos del sistema pueden dar fe si
un requerimiento se encuentra completo.
Realizable: Debe de ser posible implementar de acuerdo a las capacidades y limitaciones
del sistema, es necesario tener presente las limitaciones tcnicas tanto en hardware,
software, tiempo y costos.
Necesario: Es algo que el sistema realmente necesita, para verificar este criterio es
necesario conocer el origen del requerimiento.
Priorizable: Se debe indicar que tan esencial es el requerimiento para realizar el producto,
para esto es posible asignar un valor en una escala de 1 a 5 donde 1 representa el grado ms
bajo y 5 el grado ms alto.
No ambiguo: Al leer el requerimiento si y solo si debe generar una nica comprensin al
lector. Toda persona que realice la lectura del requerimiento debe llegar a la misma
interpretacin.
Verificable: Es necesario que exista una forma en la cual se puede determinar el
cumplimiento del requerimiento posterior a la implementacin. Estos pueden ser por medio
de: inspeccin, anlisis, demostracin o pruebas.
Conciso: Debe ser expresado de la manera ms simple posible, no debe mesclar
descripcin de varios requerimientos.
Independencia de diseo: El requerimiento no debe mesclar aspecto relacionados con el
cmo hacer implementacin del software.
Para realizar esta labor es de gran ayuda iniciar con la matriz de trazabilidad (Documento
0-Matriz Trazabilidad, disponible en anexo 1) y la matriz de interaccin (3A-002 - Matriz
de interaccin disponible en el anexo 1: formatos, instrumentos y herramientas), la primera
nos permite identificar el origen de los requerimientos y poder realizar negociacin de
conflictos, mientras la segunda identifica los conflictos entre los requerimientos.
Del mismo modo existen dos tcnicas las cuales permiten asegurar la calidad de los
requerimientos, estas son: Checklist de anlisis y Matriz de interaccin (Tabla 11).
Para los proyectos de nivel 1 y 2 es necesario implementar la tcnica de checklist, mientras
para los proyectos de nivel igual o superior a tres es necesario implementar ambas tcnicas.

53
Con la intensin de localizar los defectos de manera efectiva es necesario que la persona
encargada de verificar dichos criterios sea una persona ajena al grupo que confeccion la
lista de requisitos [67]. Siguiente a la aplicacin de las tcnicas es necesario comunicar los
resultados al personal encargado de la creacin de la lista de requerimientos para sus
respectivas correcciones.

CheckList Matriz de interaccin

Las listas de chequeo nos permitirn Matriz de doble entrada donde se cruzan
identificar [68]: todos los requisitos entre s, en el cual es
Requisitos combinados. necesario: comprobar [67]:
Requisitos innecesarios. Redundancia.
Conformidad con objetivos del Consistencia interna.
negocio.
Ambigedad entre requisitos.
Viables de cada uno.
Facilidad de realizar pruebas.
Instrumento 3A-001 ver anexo 1 Instrumento 3A-002 ver anexo 1
Aplicar solo a proyectos con clasificacin igual o
superior a nivel tres
Tabla 11: Principales ventajas y desventajas referentes tericos

8.1.1 Matriz de trazabilidad

La tabla de matriz de requisitos permite monitorear los requisitos a lo largo del ciclo de
vida del proyecto. Dicha matriz permite [69]:

Realizar vnculos entre los requisitos con los objetos de la empresa y el proyecto.
Vincular los requisitos con el origen de este.
Es necesario que todos los proyectos implementen la matriz de trazabilidad (Documento 0-
MatrizTrazabilidad), para este punto de la metodologa es necesario alimentar la
informacin de esta rea en dicha matriz.

8.1.2 Matriz de rastreo

En una matriz de rastreo de requerimientos, cada requerimiento se representa en una fila y
en una columna de la matriz. Cuando existen dependencias entre diferentes requerimientos,
estas se registran con la letra D en la celda en la interseccin fila/columna; por otra parte
una letra R significa que existe alguna otra relacin ms dbil entre los requerimientos
[28]
Las matrices de rastreo pueden utilizarse cuando se tiene un nmero pequeo de
requerimientos, en este caso el formato 0 - Matriz de Rastreo (disponible en el disponible
en el anexo 1: formatos, instrumentos y herramientas) describe la forma en que se debe
elaborar la matriz de rastreo; sin embargo, son difciles de manejar y caras de mantener
cuando se tiene sistemas grandes con muchos requerimientos. En el caso de sistemas
grandes con muchos requerimientos la descomposicin funcional realizada en el formato

54
3A-003 (disponible en el anexo 1: formatos, instrumentos y herramientas), puede ser de
gran utilidad para disminuir la complejidad del uso de estas matrices al tener una matriz por
modulo del sistema. En algunos casos puede ser necesario el uso de herramientas de gestin
especializadas, la ilustracin 13 muestra las principales caractersticas relacionadas con
trazabilidad y creacin de asociaciones de las cuatro herramientas ms importantes segn la
encuesta realizada por INCOSE (International Council on Systems Engineering) [70].

Ilustracin 13: Principales caractersticas relacionadas con trazabilidad y creacin de asociaciones de las cuatro
herramientas ms importantes de gestin de requerimientos [71]

8.1.3 Negociacin y resolucin de conflictos.

En algunas ocasiones existen requerimientos contradictorios, por lo general el problema de
estos radica en diferentes versiones por parte de los usuarios con respecto al sistema. Para
este punto es necesario que el personal encargado de la ingeniera de requerimientos realice
negociacin entre los implicados, por ende es necesario identificar el origen del conflicto
con sus respectivos implicados e intentar poner en comn acuerdo las partes (el personal
encargado de requerimientos no podr tomar partido en la negociacin, sin embargo podr
realizar sugerencias que ayuden a resolver el problema), en la seccin 10.2.2 (Negociacin
de requerimientos) se puede ver el detalle de esta actividad. Si no es posible llegar a un
acuerdo es necesario recurrir a la resolucin por decreto la cual consiste en acudir al cliente
y este deber establecer una alternativa al conflicto o una seleccionar cul de los requisitos
se debe implementar.

8.2 Lmites del sistema

Al avanzar y conocer de manera clara los requerimientos del sistema surgen las
funcionalidades que el sistema deber implementar y cuales no [67]. Tomando la definicin
del SWEBOK, el alcance del proyecto se define como El trabajo que debe realizarse para
entregar un producto, servicio o resultado con las caractersticas y funciones especificadas
[69].
Es por esto que la delimitacin correcta del alcance nos permitir llevar a la ejecucin del
proyecto de manera completa y con xito, con este podremos controlar que se incluye. La

55
definicin de los lmites del sistema debern ser actualizados en el documento 0-SRS en la
seccin de aspectos generales.

8.3 Clasificacin
Existen diversas formas en las cuales es posible realizar la clasificacin de los
requerimientos, para el caso de esta metodologa iniciaremos con la clasificacin entre
requerimientos funcionales y no funcionales, posterior a esta clasificaremos los
requerimientos funcionales por mdulos usando la descomposicin funcional y de manera
final se describir como realizar priorizacin de los requerimientos.
Requerimientos funcionales: Se refiere a las acciones que proveer el sistema, la manera
en como reaccionar dada una entrada particular, en algunas ocasiones tambin describe lo
que no realizara el sistema [7].
Requerimientos no funcionales: No se refieren directamente a las funciones del sistema,
sino de las propiedades que debe tener el sistema, como lo son la fiabilidad, tiempos de
respuesta, capacidad de almacenamiento entre otras. De otro lado tambin define las
restricciones las cuales deber cumplir el sistema [7].

8.3.1 Descomposicin funcional

La descomposicin funcional permite identificar los mdulos del sistema y que
requerimientos se deben incluir para cada uno de estos. Para lograr eso es necesario una
estructura top-down (Estructura jerrquica), en la cual se identifica la funcionalidad del
sistema como un todo y se descompone en conjunto de funciones y sub-funciones. La
ventaja es realizar descomposicin es que nos permite identificar los mdulos del sistema.
Para realizar esta descomposicin es necesario tomar como insumo la informacin
suministrada en el documento 0-SRS (disponible en el disponible en el anexo 1: formatos,
instrumentos y herramientas).
Esta descomposicin es necesaria para los proyectos de nivel igual o superior a tres los
cuales debern diligenciar el documento 3A-003 (disponible en el disponible en el anexo 1:
formatos, instrumentos y herramientas), en el cual se agruparan los requerimientos por
modulo del sistema.

8.3.2 Priorizacin
Es importante indicar la importancia que tiene cada requerimiento en el sistema (Tanto del
lado de los usuarios como para el cliente) [7], esta prioridad deber expresarse como un
valor Alto, medio y bajo. Al realizar priorizacin de requerimientos es importante
determinar Cul aspecto ser usado para realizar priorizacin de los requerimientos? En
este los stakeholders debern decidir si realizan priorizacin basados en la importancia,
penalidad, costo, tiempo, riesgo o volatilidad [4].

56
Del mismo modo es necesario actualizar el valor asignado en trminos de prioridad al
documento 0-SRS (disponible en el disponible en el anexo 1: formatos, instrumentos y
herramientas).

8.4 Estimacin
La estimacin en tiempo y costo de un sistema es uno de los principales inconvenientes que
se presentan, debido a que se desconoce con exactitud el esfuerzo que ser necesario
realizar para finalizar el sistema en buen termino
Para facilitar esta labor es importante pensar cada requerimiento funcional como una
actividad a realizar necesaria a satisfacer dentro de un proyecto, por lo tanto es necesario
estimar el esfuerzo a realizar por cada una de las etapas, es por esto que se debe identificar
los recursos (materiales y humanos), el tiempo y costo que sern necesarios utilizar para
cada uno de los requerimientos. [7]
No obstante es importante identificar las dependencias que existen entre los requerimientos.
Se recomienda para todos los proyectos realizar un diagrama de Gantt, el cual permita una
mejor administracin de estos tems (Aunque este tema hace parte de la gerencia de
proyectos, es bueno tenerlo en cuenta ya que al tener identificados los requerimientos en el
anlisis se facilita la estimacin de costos, tiempo y recursos), en la seccin 6.4.3
(Estimacin costo inicial) se puede ver el detalle de esta actividad.

8.5 Documentacin
Al finalizar la etapa de elicitacin se deber contar con los siguientes documentos:

SRS - Software El documento de especificaciones de software (SRS- Software

Requirements Requirements Software) es el documento maestro que me
Specification permite plasmar la informacin general como propsito,
alcance, restricciones, suposiciones e informacin especfica
relacionada con los requerimientos.
Documento: 0-SRS (Anexo 1).
Matriz de trazabilidad. Permite dar seguimiento a los requerimientos a lo largo del
ciclo de vida.
Documento: 0-MatrizTrazabilidad (Anexo 1).
Checklist de Instrumento la cual nos permite verificar la calidad de los
requerimientos requerimientos.
Documento: 3A-001 (Anexo 1).
Matriz de interaccin Instrumento la cual nos permite verificar la calidad de los
requerimientos.
Documento: 3A-002 (Anexo 1).
Descomposicin Es necesario agrupar los requerimientos que son transversales
jerrquica. en el sistema y por cada uno de los mdulos identificados.
Documento: 3A-003 (Anexo 1).
Matriz de rastreo Permite conocer la relacin de dependencia u otro tipo entre
los requerimientos.
Documento: 0 - Matriz de Rastreo (Anexo 1).

57
 9. ESPECIFICACION

Resumen
Entradas Clasificacin del proyecto.
SRS - Software Requirements Specification.
Descomposicin jerrquica.
Salidas Actualizacin SRS - Software Requirements Specification.
Especificacin interfaz subsistemas.
Especificacin en lenguaje Z.
Modelado de flujo de datos.
Modelado de contexto.
Modelado de objetos.
Modelado redes Petri-net.
Prototipos.

La especificacin de requerimientos es la etapa donde se describe por completo el sistema

que se pretende desarrollar [72] por medio de modelos y especificaciones las cuales
permitan su comprensin y validacin. Hasta este punto se ha seleccionado el tipo de
proyecto, se ha obtenido la informacin necesaria para comprender el dominio del
problema (Elicitacin), se han verificado, delimitado, clasificado y estimado los
requerimientos (Anlisis). Ahora es necesario documentarlos de una manera estructurada y
grfica. En primer lugar es necesario comprender la diferencia semntica entre un modelo y
una especificacin (Del verbo especificar), dado que ambos trminos sern usados a lo
largo de este captulo.
Modelo [Definicin]: 1.Representacin en pequeo de alguna cosa, 2.Esquema terico,
generalmente en forma matemtica, de un sistema o de una realidad compleja, como la
evolucin econmica de un pas, que se elabora para facilitar su comprensin y el estudio
de su comportamiento [73]. Etimologa: Se origina en la palabra italiana modello surgida
durante el renacimiento en el siglo XVI, a su vez modello es diminutivo de la palabra
modus en latn que hace referencia a la manera o medida [74]. Por consiguiente modelos
de requerimientos hace referencia a las representaciones (Graficas y textuales) de un
sistema, a la vez estas permite comprender el comportamiento, dicha representacin son la
gua para presentar la manera de cmo se debe desarrollar el sistema.
Especificar [Definicin]: 1.Explicar, declarar con individualidad algo, 2.Fijar o
determinar de modo preciso [73]. Etimologa: Su origen nos lleva al latn specificus,
compuesto por species (Como adjetivo) cuyo concepto denota vista, visin y faceres
(Como verbo) denota hacer [75]. Por ende las especificaciones de requerimientos se
comprenden como la visin del cmo se debe hacer el sistema.
En conclusin los modelos mencionados durante este captulo sern una representacin del
sistema (Desde diferentes vistas) mientras las especificaciones definirn como deben ser
implementados. Los modelos y especificaciones propuestos en este captulo tienen relacin
directa con la categora de proyecto definida en el literal 7.1.2 (Tipo de proyecto desarrollo
58
a la medida). La seleccin de cada uno de los modelos y especificaciones para aplicar ha
sido seleccionada acorde a las rigurosidades de cada tipo de proyecto (Ilustracin 14). As
pues los proyectos de nivel 1 usan poca documentacin lo cual permite disminuir los costos
de la fase de especificaciones, del mismo modo para los niveles 2 y 3 se incluyen
modelados y especificaciones que describen el flujo del sistema y permiten comprender su
arquitectura sin entrar en detalles formales mientras los niveles 4 y 5 finalizan con
documentaciones de alto nivel tanto a nivel de modelado como de especificacin, estos
ltimos se encuentran orientados a sistemas crticos donde es importante asegurar un alto
nivel de rigurosidad. Otro aspecto importante que ha sido tenido en cuenta para la seleccin
de la documentacin segn el tipo de proyecto es el costo econmico que conlleva la
documentacin formal, como lo expone Sommerville, el costo de realizar especificaciones
formales puede ser igual o superior al costo del diseo e implementacin del software [28],
esto se puede observar de la Ilustracin 15.

Ilustracin 14: Especificacin y modelos segn tipo proyecto

59
 Ilustracin 15: Costos usando especificacin formal

En el caso de los proyectos de nivel 1 se recomienda adems del documento SRS (Software
requirement Specification), usar como complemento las historias de usuario, similares a las
usadas en las metodologas giles.
El objetivo de la ingeniera de requerimientos es crear y mantener la documentacin
necesaria tanto a clientes como a ingenieros de requerimientos. En teora la documentacin
debe ser interpretada por todos los participantes de la misma manera, sin dar lugar para
ambigedades, sin embargo en la realidad es complejo lograr este cometido, por ende la
documentacin generada en los inicios del proceso debe ser orientada hacia el cliente y al
final hacia el sistema, enfocada al equipo de ingenieros del proyecto (Ilustracin 16
representa la situacin planteada) [28]. En este captulo se explican los modelos y
especificaciones en dos secciones, en la primera seccin se encuentra orientada a la
comprensin del cliente usando lenguaje natural y en la segunda orientada a la comprensin
del sistema de manera formal.

Ilustracin 16: Proceso documentacin requerimientos

Como se ha observado en la Ilustracin 16, el proceso de documentacin se encuentra

agrupado en dos secciones las cuales son los documentos de requerimientos orientados al
usuario (Representados en marrn en la Ilustracin 14) y los documentos de requerimientos
orientados al sistema (Representados en amarillo en la Ilustracin 14)

60
 9.1 Documentacin con historias de usuario.
Las tarjetas de historias o historias de usuario son herramientas en las cuales se describe de
manera breve los requerimientos de un sistema, se estructuran de modo que la historia
pueda ser realizada en periodo entre los 10 y 20 das, adems son usadas para estimar
prioridades, alcance y tiempo de realizacin [76]. En las metodologas agiles es comn
utilizarlas para especificar los requisitos [77]. Por lo general se componen de tres partes las
cuales son [78]:

Una descripcin escrita de la historia (usada en la planeacin).

Una conversacin que define detalles del requerimiento.
Pruebas que permitan determinar que la historia de usuario est completa.
El formato 4E-001 (anexo 1: formatos, instrumentos y herramientas) ilustrara como hacer
uso de una historia de usuario.

9.2 Documentacin requerimientos del usuario

Los requerimientos de usuario deben describir los requerimientos funcionales y no
funcionales del sistema de tal forma que sean de fcil comprensin para los usuarios
finales. Estos deben evitar detalles tcnicos y caractersticas de diseo tanto como sea
posible, adems conviene ser redactados de forma sencilla para permitir una mejor
comprensin por parte de los usuarios. Esta documentacin permite usar lenguaje natural,
notacin estructurada o formal, sin embargo al definir un requerimiento en lenguaje natural
pueden surgir problemas de falta de claridad, confusiones de requerimientos y ambigedad
[28] sin embargo al usar lenguaje natural estructurado (Como lo son SRS) y diagramas
intuitivos es posible acotar dichos problemas. Los requerimientos de usuarios se encuentran
centrados en comprender el dominio del problema y son el principal medio de
comunicacin entre clientes y desarrolladores para el anlisis [4]

9.2.1 Especificacin de requerimientos del usuario

SRS (Software requirement specification)
El documento SRS debe presentar un equilibrio entre la comunicacin de los
requerimientos a los clientes, la definicin de requerimientos en detalle para desarrolladores
y probadores y la inclusin de informacin sobre la evolucin. Los SRS limitan la libertad
del redactor por ende todos los requerimientos deben usar el mismo formato estndar. Su
principal ventaja es mantener la expresividad y comprensin que permite el lenguaje
natural pero asegurando cierto grado de formalidad en la especificacin [28]
Para cada uno de los requerimientos especificados se debe incluir mnimo las secciones
descritas en la tabla 12.

Nombre o funcin Breve descripcin de la funcin que realizara el

requerimiento
Entradas y salidas Descripcin de las entradas y salidas requeridas para dicho
requerimiento (Descrito en lenguaje natural)

61
Pre-condicin Indica que se debe cumplir antes de invocar la funcin.
Post-condicin Indica lo que ser correcto posterior a realizar la funcin.
Descripcin del Indica al detalle cmo debe ser procesada la informacin
requerimiento (Entradas) recibidas en la funcin.
Fuente del requerimiento Describe de donde ha sido obtenido el requerimiento
Tabla 12: Elementos mnimos formato SRS

El nivel de detalle que presenta el documento depende del sistema y proceso de software
usado, es recomendable que los desarrollos realizados por terceros tengan una
especificacin detallada tanto de los requerimientos funcionales como no funcionales [28]
El formato 0-SRS (anexo 1: formatos, instrumentos y herramientas) define el documento
usado en la presente metodologa. En este punto dicho formato deber estar diligenciado en
su totalidad y con la mayor claridad posible, del mismo modo debe existir una descripcin
de las funciones que realizara el sistema a la vez que deben estar descritos todos los
requerimientos funcionales y no funcionales del sistema. Para generar mayor claridad en el
SRS se recomienda complementar con modelados de flujo de datos por cada uno de los
requerimientos funcionales descritos en el SRS.

9.2.2 Modelado de requerimientos del usuario

Modelado de flujo de datos
Son la forma intuitiva de representar como los datos son procesados en el sistema, usan
secuencias de pasos para ilustrar como fluyen los datos a travs de secuencias. Su principal
ventaja es su sencillez y es por esto que son una herramienta valiosa para realizar
validacin del sistema. El modelado de flujo de datos usa rectngulos para representar
procesamiento funcional, rectngulos sin bordes ilustrando almacenes de datos y flechas
para representar el flujo de la informacin (Ilustracin 17). Este modelado nos permite
representar el sistema de inicio a fin [28].
Como muchas de otras tcnicas las jerarquas se encuentran estratificadas de modo que los
diferentes niveles de detalle se muestran en capas o estratos diferentes [79]. Para la presente
metodologa se recomienda realizar un modelado de flujo de datos para cada uno de los
requerimientos funcionales y no funcionales descritos en el SRS (Formato 0-SRS,
disponible en el anexo 1: formatos, instrumentos y herramientas).

Ilustracin 17: Diagrama flujo de datos

62
 9.3 Documentacin requerimientos del sistema
Son el punto inicial para el diseo del sistema, agregan detalles relacionados con los
requerimientos del usuario. En teora deben describir el comportamiento externo del
sistema y sus restricciones [28]. Por otra parte los requerimientos del sistema nos permiten
organizar los requerimientos de usuario para dar solucin(es) al domino del problema. Sus
principales caractersticas es el alto nivel de detalle impuesto en cada una de las
especificaciones y modelos. [4]

9.3.1 Especificacin requerimientos del sistema

Para especificar los requerimientos del sistema hacemos uso de las especificaciones
formales, estas son usadas para referirse a cualquier actividad relacionada con
representaciones matemticas del software, cuyo vocabulario, sintaxis y semntica estn
formalmente definidas, adems la especificacin formal es una medio excelente para
descubrir errores en los requerimientos y presentar la documentacin de un sistema de
forma no ambigua [28]. Sin embargo como se ha mencionado en este captulo la
especificacin formal hace que los costos del proceso de requerimientos sean elevados ya
que son complejos y hacen uso de gran parte del tiempo del proyecto para su
especificacin, aunque como lo menciona Sommerville esta rea (Especificacin formal) se
encuentra creciendo en el desarrollo de sistemas crticos, donde la seguridad, fiabilidad y
proteccin son muy importantes [28].
Al desarrollar especificacin formal del software normalmente debe ir despus que se haya
realizado la especificacin de requerimientos del sistema y antes del diseo detallado (alto
nivel) del sistema (Ilustracin 18), asimismo esta puede ser un insumo para realizar
retroalimentacin hacia las dems fases de la especificacin de requerimientos. En este
punto las implicaciones del cliente disminuyen mientras las del equipo de ingenieros del
proyecto se incrementan [28]. La Ilustracin 18 presenta una alternativa al proceso del
software presentado por Ian Sommerville en Ingeniera del software

Ilustracin 18: Proceso de especificacin y modelado del software

63
Especificacin de interfaz para sub-sistemas
Los grandes sistemas por lo general son desarrollados como subsistemas, en donde cada
uno es tratado como un sistema independiente, por ende es importante especificar como se
realiza la comunicacin entre los sistemas adems de proporciona informacin para que los
desarrolladores conozcan que servicios estarn disponibles en los dems subsistemas y
como acceder a ellos. Es por esto que la especificacin formal de interfaz para sub-sistemas
define como se deben comunicar los diferentes sistemas, esta consta de cuatro componentes
(Ilustracin 19) los cuales son [28]:
1. Introduccin: Declara la clase de la entidad que se est especificando. La clase es
el nombre de un conjunto de objetos con caractersticas comunes. La introduccin
puede incluir declaracin de imports para especificar nombres que definen otras
clases, al importar una especificacin hace que esta clase est disponible para ser
usadas.
2. Descripcin: Se describen las operaciones de manera informal, esto hace que sea
ms fcil de entender. La especificacin formal complementa la descripcin
proporcionado una sintaxis y semntica no ambigua.
3. Signatura: Define la sintaxis de la interfaz de la clase objeto o tipo abstracto de
dato. La signatura describe los nombres de las operaciones, la clase de parmetros y
la clase de resultados de las operaciones.
4. Axiomas: Semntica de las operaciones mediante axiomas que caracterizan el
comportamiento del tipo abstracto de datos.

Ilustracin 19: Estructura de una especificacin algebraica para un sub sistema

Para desarrollar una especificacin formal de la interfaz para sub-sistemas se deben

desarrollar las siguientes actividades [28]:
1. Estructurar la especificacin: Organizar la informacin en un conjunto de tipos
abstractos de datos o clases de objetos. Definir de manera informal las operaciones
de cada clase.
2. Nombrar la especificacin: Crear un nombre para la especificacin de cada tipo
abstracto de dato, definir los parmetros (Si los requieren) y determinar los nombres
de las clases.
3. Seleccionar las operaciones: Elegir el conjunto de operaciones segn las
funcionalidades identificadas. Se deber incluir operaciones para crear instancias

64
 (Constructores), modificar valores (operaciones set) e inspeccionar las instancias
(Operaciones get).
4. Especificar de manera informal las operaciones: Redactar una especificacin
informal para cada operacin.
5. Definir la sintaxis: Definir la sintaxis y parmetros de las operaciones identificando
los parmetros y los tipos de retorno de cada una (Seccin de la signatura de la
especificacin).
6. Definir axiomas: Semntica de las operaciones, definiendo que condiciones son
siempre verdaderas para diferentes combinaciones de las operaciones.
Al realizar especificacin de interfaz para sub-sistemas se reduce la posibilidad de
malentendidos en la comunicacin que existen entre ellos

Especificacin de sistemas crticos

La necesidad de obtener confiabilidad en los sistemas crticos genera requerimientos
funcionales y no funcionales del sistema, dichas funcionalidades estn enfocadas hacia:
comprobar errores, facilitar la recuperacin y las caractersticas de proteccin frente a fallos
del funcionamiento del sistema. Estos tipos de requerimientos son conocidos como
requerimientos No debera ya que definen el comportamiento indeseado del sistema.
Especificacin de la seguridad: La especificacin de seguridad es recomendada para los
sistemas crticos en los cuales una falla del sistema puede afectar la salud o seguridad de
quienes lo usa o quienes se encuentra con proximidad a l [79]. Los requerimientos de
seguridad deben ser descritos como requerimientos de seguridad funcional en donde se
define las funciones de seguridad del sistema y requerimientos de integridad, las cuales
definen la fiabilidad y disponibilidad de la proteccin del sistema. El proceso de garantas
de seguridad hace parte de los estndares de seguridad IEC 61508 en donde las primeras
etapas definen el mbito del sistema, las contingencias potenciales del sistema y la
estimacin de los riesgos que se presentan, de manera posterior el estndar define las
actividades de desarrollo las cuales comprenden la planificacin y la implementacin. Por
ltimo se define el sistema de seguridad como se debe disear e implementar [28].
Especificacin de la proteccin: Son a menudo requerimientos No debera los cuales
definen el comportamiento inaceptable del sistema en lugar de funcionalidades requeridas
del mismo. La aproximacin convencional para el anlisis de la proteccin se basa en los
activos a proteger y su valor en la organizacin. La misma aproximacin se puede utilizar
para especificar la proteccin de los sistemas informticos. Firesmith citado por
Sommerville identifica 10 tipos de requerimientos de proteccin que pueden incluirse en un
sistema, estos son [28]:
1. Requerimientos de identificacin.
2. Requerimientos de autenticacin.
3. Requerimientos de autorizacin.
4. Requerimientos de inmunidad.
5. Requerimientos de integridad.
6. Requerimientos de deteccin de intrusos.
7. Requerimientos de no rechazo.

65
 8. Requerimientos de privacidad.
9. Requerimientos de auditoria de seguridad.
10. Requerimientos de seguridad de mantenimiento del sistema.
Especificacin de la fiabilidad: La fiabilidad es un concepto que debe considerarse a nivel
general del sistema. Debido a que los sistemas se encuentran (Por lo general)
interconectados es necesario tener en cuenta que el fallo de un componente puede afectar al
resto del sistema. Por ende se debe considerar tres dimensiones cuando se especifica la
fiabilidad de un sistema en su totalidad, estas son: Fiabilidad de hardware (Probabilidad que
un componente falle y tiempo que tarda en ser reparado), fiabilidad de software
(probabilidad que produzca una salida incorrecta), fiabilidad del operador (probabilidad que
el operador de un sistema cometa un error). La fiabilidad de los sistemas deber
especificarse como requerimientos no funcionales [28]. El modelado usando especificacin
o modelados formales son un complemento preciso que permite definir las especificaciones
de seguridad.

Especificacin en lenguaje Z
Se trata de un lenguaje formal para realizar especificacin, proporciona una notacin
(subdominio sintctico) un universo de objetos (su dominio semntico) y una regla precisa
que define cuales objetos satisfacen cada especificacin. El lenguaje Z (Pronunciado
lenguaje zeta) requiere la combinacin de modelado de datos abstractos con teora de
conjunto y lgica de predicados de primer orden. Es recomendado para especificar sistemas
de seguridad crtica en la cual una falla del sistema puede afectar la salud o seguridad del
personal que lo usan o que se encuentran con proximidad a l. Puede usarse para especificar
estados del sistema y validar los cambios de este ya que existen herramientas automatizadas
que permiten comprobar la especificacin en cuanta inconsistencia o no integridad [79].
Para comprender el lenguaje Z es necesario entender el concepto de mquinas de estado
finito, las cuales sirven para realizar proceso bien definido en un tiempo discreto, reciben
una entrada, hacen un proceso y entregan una salida. Las mquinas de estado finito son
modelos abstractos que usando smbolos permiten saber si un conjunto de smbolos
pertenecen a un lenguaje o pueden generar otro conjunto de smbolos como resultados. [80]

Las mquinas de estado finito se definen como una quntupla {, , 0, , } donde [81]:

es el conjunto de estados finitos.

es un alfabeto finito.

0 es el estado inicial.

: es una funcin de transicin.

es un conjunto de estados finales o aceptacin

La Ilustracin 20 muestra un ejemplo de una mquina de estado finito.

66
 Ilustracin 20: Ejemplo de mquina de estado finito

El lenguaje Z permite especificar desde mquinas de estado hasta maquinas jerrquicas de

estados. Las mquinas de estado usadas en Z son idnticas a una mquina de estado finito,
solo que la cantidad de estados es potencialmente infinita. Las mquinas de estado se
describen en dos grandes fases las cuales son definicin del conjunto de estados, el cual
contiene las variables de estado de la maquina en la cual cada estado est definido por una
tupla de valores particulares que se asocia a cada variable de estado y la definicin de las
operaciones del estado, las cuales todas las operaciones juntas definen la relacin de
transiciones de la mquina. Existen operaciones que producen una transicin de estado y
aquellas que solo consultan el estado actual. [82].
Una especificacin en lenguaje Z consta de cuatro secciones las cuales son: 1. Conjuntos,
tipos de datos y constantes, 2. Definicin de estado, 3. Estado inicial y 4.Operaciones. A su
vez una especificacin consta de esquemas el cual contiene un grupo de declaraciones de
variables y la lista de predicados que restringen los valores de las variables. La Ilustracin
21 muestra un esquema de la especificacin en Z [83].

Ilustracin 21: Esquema de especificacin en Z

9.3.2 Modelado requerimientos del sistema

Modelado de contexto
Al inicio del modelado de requerimientos es necesario definir los lmites del sistema, si
bien esta actividad se ha desarrollado durante el captulo anterior en este captulo es
necesario retmala para definir los costes del sistema y el tiempo necesario para el anlisis.
De manera posterior es necesario analizar las dependencias que el sistema tiene sobre su
entorno, por ende la produccin de un modelo arquitectnico sencillo es el primer paso en
esta actividad, esta representa el entorno del sistema. Estos modelos arquitectnicos

67
normalmente se expresan como sencillos diagramas de bloques en donde cada subsistema
representa un rectngulo con nombre y las lneas indican la asociacin entre los
subsistemas. La Ilustracin 22 presenta un ejemplo para un modelo de contexto de un
cajero automtico [28] .

Ilustracin 22: Modelo contexto cajero automtico

Modelado de objetos
El modelado orientado a objetos se enfoca en las entidades involucradas ms que en las
transformaciones de entradas/salidas. Se fundamenta en el paradigma de la programacin
orientada a objetos en donde cada entidad del sistema debe ser tratado como un objeto. Los
mtodos (Operaciones) que hacen parte de la definicin del objeto son acciones las cuales
pueden ser ejecutadas por el objeto o pueden llegar a l. Al igual que el paradigma
orientado a objetos el modelado de objetos soporta el uso de envi de mensajes entre
objetos para compartir informacin, adems de las representaciones de encapsulamiento,
jerarqua de clases, herencia simple, herencia mltiple y polimorfismo [79]. Para realizar
representacin de estos se hace uso de los diagramas UML de clases (Ilustracin 23) y
secuencias (Ilustracin 24) [84].

Ilustracin 23: Ejemplo modelo de objetos

68
 Ilustracin 24: Ejemplo diagrama de secuencias UML

Modelado con redes Petri

Los diagramas de red Petri nets son una representacin matemtica o grafica que permiten
modelar acciones concurrentes usando paralelismo, sincronizacin, recursos compartidos y
memorizacin [4]. Para estos casos varios eventos pueden ocurrir antes que el sistema
pueda dejar el estado A y moverse a un estado B. El fuerte de las redes Petri es representar
la coordinacin para actividades que se ejecutan en paralelo y necesitan de alguna forma
controlar el conjunto de eventos para cambiar de estado. Las transiciones son descritas por
un conjunto de reglas de disparo las cuales definen las condiciones para ejecutar una
transicin.
Las redes Petri representan grficamente un sistema dibujando un nodo por cada estado y
una flecha para marcar las transiciones [79]. La Ilustracin 25 muestra un ejemplo de una
red Petri.

Ilustracin 25: Ejemplo red Petri.

69
Las redes Petri estn compuestas por dos elementos un grafo bipartito dirigido y una
marcacin.
El grafo est compuesto por nodos (que representan lugares) y transiciones. Los lugares
son dibujados como crculos que representan condiciones mientras las transiciones son
dibujadas como barras y representan eventos. A cada arco se le asigna un peso positivo. La
estructura de la red puede ser representada por dos matrices. Las filas de las matrices
corresponde a las transiciones y las columnas corresponden a los lugares. Los elementos de
la matriz dan el peso a los arcos salientes [85].

La marcacin () es una funcin de una red Petri, donde = que asigna

cospeles a los lugares de la red. Los cospeles representan eventos que ocurren y son
representados como pequeos puntos negros dentro de los lugares y se utilizan para
mostrar la evolucin de la red [85].

9.4Generacin de prototipos
Los prototipos son implementaciones parcial pero concreta de un sistema, su objetivo es
explorar diversos aspectos en el proceso de la ingeniera de requerimientos, sin embargo los
prototipos no constituyen una demostracin del producto, su finalidad es recoger las
opiniones de los usuarios para retroalimentar y validar en el proceso de ingeniera de
requerimientos. Desde las primeras etapas en el proceso de ingeniera del software es
importante probar multitud de objetos con el fin de verificar funcionalidades, averiguar
aspectos relacionados con la interfaz del sistema, validar la navegacin, probar nuevas
posibilidades tcnicas entre otras, es impensable llegar al final de un desarrollo sin haber
realizado comprobaciones durante el proceso, por ende los prototipos son los mecanismos
que me permiten realizar dichas comprobaciones [38].
El uso de los prototipos como herramienta en la ingeniera de requerimientos permite hacer
partcipe al usuario en el proceso, evaluar el producto desde las primeras fases. Tambin la
creacin de prototipos permite validar el diseo antes de ser creado, adems de ser una
ayuda para que los desarrolladores comprendan los requerimientos y decidan aspectos
sobre la interfaz grfica. La generacin de prototipos es una tcnica que permite enfocar el
diseo centrado hacia el usuario (DCU). El uso de prototipos debe ser implementado de
manera sistemtica desde el inicio hasta la finalizacin del sistema [79] [38]. Entre las
principales caractersticas mencionadas por Toni Granollers son [38]:

Aumentar la comunicacin y participacin entre los usuarios y los desarrolladores.

Mejorar la calidad y completitud de las especificaciones.
Son esenciales para la documentacin tanto de conceptos funcionales como de
tareas concretas.
Si bien en el captulo 6 se tomaron detalles de la generacin de prototipos como
herramienta que permita plantear una solucin al problema en este captulo es abordada a
mayor profundidad de modo que los prototipos sean una herramienta que permita validar
los requerimientos obtenidos del sistema. Se recomienda realizar un conjunto de prototipos

70
por cada una de las funciones especificadas en los modelo de flujo de datos descritos en la
seccin 9.2.2 (Sea usando maquetacin digital o StoryBoard de navegacin), esto con el fin
de ilustrar cada una de las funciones que realiza el sistema y que han sido descritas desde el
documento de especificacin de requerimientos (SRS). La Ilustracin 26: Proceso de
creacin de prototipo representa el proceso para la creacin de los prototipos

Ilustracin 26: Proceso de creacin de prototipo

9.4.1 Categoras del prototipado

Existen dos categoras de prototipado las cuales son baja fidelidad y alta fidelidad. Los
prototipos de baja fidelidad permiten implementar aspectos generales del sistema sin entrar
en detalles, en estos se aplica la primera ley de la creatividad de FUDD: Para obtener una
buena idea, obtn un montn de ideas. Estos prototipos se caracterizan por ser
econmicos, rpidos de construir, rpidos de arreglar y no precisan de tcnicos expertos
para su creacin. De otro lado los prototipos de alta fidelidad representan aspectos ms
precisos, asimismo permiten detallar el proceso interactivo global de una o varias tareas
concretas, por lo general es necesario hacer uso de herramientas especializadas de
prototipado que permitan ofrecer mayor detalle y precisin. Las Ilustracin 3 e Ilustracin
4 de la seccin 6.4.2 nos muestran un comparativo de las ventajas y desventajas que
presentan cada uno de estos [38].
De modo semejante los prototipos se dividen en dos dimensiones (verticales y
horizontales), su finalidad es la reduccin en costes y tiempos, por ende la reduccin se
puede conseguir bien reduciendo el nmero de caractersticas o bien reduciendo el nivel de
implementacin de las funcionalidades de las caractersticas. La dimensin de prototipos
verticales son el resultado de implementar pocas caractersticas, sin embargo sus
funcionalidades estn totalmente implementadas. Un prototipo vertical puede probar una
parte limitada del sistema, pero puede ser probado en profundidad bajo circunstancias
reales. Del otro lado tenemos a la dimensin de prototipos horizontales los cuales incluyen
todas las interfaces graficas con todas las caractersticas del sistema pero no contiene
funcionalidad subyacente. Un prototipo horizontal es una simulacin de la interfaz en la
que no se puede realizar ningn trabajo real [38].
En esta seccin nos concentraremos en las tcnicas de prototipado de alta fidelidad debido a
que estas son un complemento a la especificacin de los requerimientos.

71
 9.4.2 Tcnicas de prototipado
Cuando hablamos de la interfaz de usuario lo hacemos en trminos presentacin e
interaccin (tambin llamado look and feel). La presentacin (look) comprende la
disposicin de los elementos de la interfaz (grficos y texto en la pantalla, botones en un
mando a distancia, entre otros), mientras que la interaccin (feel) hace referencia al
procesamiento y a su rendimiento [38].
En la actualidad es posible hacer uso de software en la nube o de escritorio que facilitan la
aplicacin de las tcnicas mencionadas haciendo uso de creacin de wirframes6 o
mockups7. Algunas de estas herramientas son: Justinmimnd, Flairbuilder, Axure, Foreui,
mockflow, cacoo, ninjamock, balsamiq, Mockingbird, Mockup Builder, pidoco, Mockflow,
hotgloo, inversin, JustPro, Proto.io, inPresso screens, entre otras [49] [86].
Maquetas digitales: Las maquetas digitales son representaciones de calidad en formato
digital que normalmente llenan el espacio que hay entre el prototipo de papel y la versin
definitiva de una interfaz o parte de ella. Es necesario utilizar herramientas como editores
grficos o herramientas para crear wireframes o mockups que permitan realizar estas
maquetaciones. El nivel de detalle de estas permite visualizar de una manera muy
aproximada la versin final del diseo de la interfaz (colores, estructura de navegacin,
botones, etc.). La Ilustracin 27 presenta un ejemplo de maquetacin [38].

Ilustracin 27: Ejemplo de maquetacin presentada por Toni Granollers

Storyboard navegacin: Un storyboard navegacional (o de uso) consiste en desarrollar una

serie de dibujos o imgenes que representan el espacio de navegacin, bien sea de todo el
sistema, de una parte de l o de una tarea concreta. Con esta tcnica se representan en un
espacio bidireccional (con papel, en una pizarra, con impresiones de pantalla y flechas con
rotulador, etc.) todos los estados de las interfaces (pantallas) de la parte del sistema que se
examinar y todas las posibilidades a nivel interactivo desde cada uno de los estados para
visualizar las posibles acciones o movimientos que el usuario puede realizar mientras

6
Representacin esttica en baja calidad de un diseo [113].
7
Representacin esttica de un diseo en calidad media o alta [113].

72
interacta con la interfaz. Esta tcnica permite comprender el flujo del trabajo de los
usuarios, as como el soporte que la interfaz ofrece al usuario en cada paso de la interaccin
durante la consecucin de las diferentes tareas. Los Storyboards Navegacionales pueden
implementarse tanto a partir de secuencias realizadas con prototipos de papel como con
maquetacin digital. Lo que cambiar ser la definicin y el nivel de detalle, as como el
tiempo necesario para su materializacin, repercutiendo principalmente en la percepcin
que el usuario observar [38]. La Ilustracin 28 presenta un ejemplo de un storyboard de
navegacin.

Ilustracin 28: Ejemplo de Storyboard navegacin presentado por Toni Granollers

9.5 Documentacin
Al finalizar la etapa de especificacin de requerimientos se deber contar con los siguientes
documentos:

SRS - Software El documento de especificaciones de software (SRS- Software

Requirements Requirements Software) realizado de manera completa en
Specification donde se describe la informacin general como propsito,
alcance, restricciones, suposiciones e informacin especfica
relacionada con los requerimientos y cada una de las funciones
del sistema.

73
 Documento: 0-SRS (Anexo 1).
Historias de usuario Tarjetas que describen de manera breve y resumida las
acciones a realizar por un sistema.
Documento: 4E-001 Historia de usuario (Anexo 1).
Especificacin interfaz Descripcin formal de los componentes externos del sistema o
subsistemas sub-sistema
Solo aplica para proyectos nivel 3 o superior.
Especificacin en Especificacin formal en lenguaje de programacin Z,
lenguaje Z enfocado a sistemas crticos.
Solo aplica para proyectos nivel 4 o superior.
Modelado de flujo de Descripcin de cada una de las funciones del sistema.
datos

Modelado de contexto Descripcin grafica de los componentes que conforman el

sistema.
Solo aplica para proyectos de nivel 2 o superior.
Modelado de objetos Diagramas UML de clases y secuencias para describir
entidades involucradas
Solo aplica para proyectos de nivel 3 o superior.
Modelado redes Petri- Representacin matemtica para modelar acciones
net concurrentes
Solo aplica para proyectos de nivel 4 o superior.
Prototipos Descripcin grafica de las funciones del sistema.

74
 10.VALIDACION

Resumen
Entradas Clasificacin del proyecto.
SRS - Software Requirements Specification.
Descomposicin jerrquica.
Matriz de trazabilidad
Matriz de rastreo
Salidas Actualizacin SRS - Software Requirements Specification.
Acta de aceptacin del documento SRS - Software Requirements
Specification

La validacin de requerimientos es el proceso en el cual se demuestra lo definido por el

sistema contra los deseos del cliente, esta etapa cobra importancia debido a que los errores
en el documento de requerimientos pueden conducir a elevar el costo en las fases de
desarrollo del sistema o fases posteriores al lanzamiento del sistema. El coste de corregir un
problema en los requerimientos haciendo un cambio en el sistema es mucho mayor que
reparar los errores introducidos en fase de diseo o codificacin. La razn de esto es que un
cambio en los requerimientos normalmente significa que el diseo y la codificacin del
sistema tambin deben cambiar y que este debe probarse nuevamente.
Durante el proceso de validacin de requerimientos, se deben llevar a cabo verificaciones
que comprendan:
a) Verificaciones de validez: Un usuario puede pensar que se necesita un sistema para
llevar a cabo ciertas funciones. Sin embargo, el razonamiento y el anlisis pueden
identificar que se requieren funciones adicionales o diferentes. Los sistemas tienen
diversos stakeholders con diferentes necesidades, y cualquier conjunto de
requerimientos es inevitable un compromiso en el entorno del stakeholder.
b) Verificaciones de consistencia: Los requerimientos en el documento no deben
contradecirse. Esto es, no debe haber restricciones o descripciones contradictorias
de la misma funcin del sistema.
c) Verificaciones de completitud: El documento de requerimientos debe incluir
requerimientos que definan todas las funciones y restricciones propuestas por el
usuario del sistema.
d) Verificaciones de realismo: Utilizando el conocimiento de la tecnologa existente,
los requerimientos deben verificarse para asegurar que se pueden implementar.
Estas verificaciones tambin deben tener en cuenta el presupuesto y la confeccin
de agendas para el desarrollo del sistema.
e) Verificabilidad: Para reducir la posibilidad de discusiones entre el cliente y el
contratista, los requerimientos del sistema siempre deben redactarse de tal forma
que sean verificables. Esto significa que debe poder escribir un conjunto de pruebas
que demuestren que el sistema a entregar cumple cada uno de los requerimientos
especificados. [28]

75
 Los documentos de los requisitos pueden estar conformes a la validacin y
procedimientos de verificacin. Los requisitos pueden ser validados para asegurarse de
que el ingeniero del software entiende los requisitos, y es tambin importante para
verificar que un documento de requisitos se conforma con la compaa de los
estndares, y este es comprensible, constante, y finito. Las anotaciones formales ofrecen
la ventaja importante de permitir que las dos caractersticas pasadas sean probadas (en
un sentido estricto, por lo menos). Diversos stakeholders, incluyendo los representantes
del cliente y del revelador deben tambin repasar los documentos. Los documentos de
los requisitos son conformes a las mismas prcticas de gerencia de la configuracin del
software como otro de los puntos relevantes de los procesos del ciclo de vida del
software [5].

10.1 Validacin con prototipos no funcionales

Prototipar es comnmente el medio usado para validar la interpretacin del ingeniero del
software con los requisitos del software obtenidos, as como para sacar nuevos requisitos.
La ventaja de usar prototipos es que pueden hacer ms fcil la interpretacin de las
asunciones del ingeniero del software y, donde lo necesite, dan la explicacin til del
porque son incorrectas [5]. En la seccin 9.4 de este documento se plante la construccin
de prototipos no funcionales, en este punto la labor es realizar una validacin de dichos
prototipos. Por otra parte, la finalidad principal de los prototipos realizados durante la
etapa anterior no es otra que comprobar caractersticas o propiedades para mejorar el
sistema y garantizar la completitud del mismo.
Para MPIu+a la fase de evaluacin de prototipos constituye un factor crucial para garantizar
un sistema interactivo usable y accesible. La evaluacin no debe ser pensada solamente
como una simple etapa del proceso general del diseo, y mucho menos de la
implementacin del sistema, sino que sta debe realizarse durante todo el ciclo de vida del
proceso de desarrollo, los resultados de la cual deben aportar mejoras respecto a las
soluciones evaluadas y correcciones respecto a errores reportados [87]. En la ilustracin 29
se puede observar el proceso realizado durante la evaluacin de prototipos.

Ilustracin 29: Proceso de evaluacin de requerimientos mediante el uso de prototipos

10.1.1 Objetivos de la evaluacin

La evaluacin, segn DIX [88], tiene definidos tres objetivos principales:

Comprobar la extensin de la funcionalidad del sistema.

Comprobar el efecto de la interfaz en el usuario.
Identificar cualquier problema especfico con el sistema.

76
La funcionalidad del sistema es importante en tanto a que deba estar completamente de
acuerdo con la especificacin de los requisitos. En otras palabras, el diseo del sistema
debe permitir al usuario llevar a trmino las tareas de forma ms fcil, el cual incluye que el
sistema no slo debe realizar apropiadamente las funcionalidades disponibles, sino que
adems debe permitir alcanzar dichas funcionalidades de manera clara en trminos de las
acciones que el usuario necesita realizar para completar dichas tareas. Adicionalmente a la
comprobacin del diseo del sistema en trminos de su capacidad funcional, es importante
comprobar el impacto de dicho diseo sobre el usuario. Ello incluye considerar aspectos
como conocer lo fcil que le resulta su aprendizaje, su manejabilidad en el espectro ms
amplio de usuarios posibles (sin excluir aquellos con necesidades especiales), o identificar,
por ejemplo, aquellas reas del diseo que puedan requerir una sobrecarga de la cantidad de
informacin que el usuario debe recordar. El objetivo final de la evaluacin es la
identificacin de los problemas especficos del diseo, que pueden ser aspectos del mismo
que, estando el usuario en su contexto, causen resultados inesperados o confusin entre
varios usuarios [38].

10.1.2 Previo al proceso de evaluacin

Para que la evaluacin del prototipo sea lo ms efectiva posible, deben seleccionarse
adecuadamente los stakeholders que participarn en la evaluacin. Siempre que sea posible,
debe seleccionarse un conjunto de stakeholders representativos de los distintos perfiles, de
tal modo que sea posible validar el software en todos sus modos de utilizacin. Por
ejemplo: Si un software es utilizado por administrativos, ingenieros y contables, al menos
un usuario de cada uno de estas reas debern evaluar los prototipos. En la mayora de los
casos, los usuarios pueden identificarse directamente a partir del detalle de la
especificacin. [89]
Las evaluaciones pueden realizarse en espacios especialmente equipados (como un
laboratorio), en salas de reuniones, en el propio entorno donde los usuarios realizan sus
tareas habitualmente o simplemente en cualquier lugar donde puedan reunirse usuarios y
evaluadores. Incluso con las posibilidades de conexin actuales, algunas evaluaciones
pueden realizarse desde cualquier punto del planeta (la oficina, la casa, un parque). Por
tanto, no existe ninguna restriccin fsica que limite las posibilidades para poder realizar
evaluaciones de sistemas interactivos diversos. [38]

La metodologa sugiere en lo posible realizar este proceso de evaluacin con los

stakeholders directamente en el entorno natural o habitual donde se realizan las tareas a
evaluar, ya que de esta manera se reproduce el contexto de la interaccin. La tabla 13
muestra las ventajas e inconvenientes de realizar la evaluacin en el entorno natural.

77
 Tabla 13: Ventajas e inconvenientes de la evaluacin realizada en el entorno

Para evaluar correctamente el prototipo es necesario elaborar un checklist, formato 5V-001

disponible en el anexo 1: formatos, instrumentos y herramientas, donde se identifican una
serie de escenarios o tareas, los cuales deben ser llevadas a cabo por los stakeholders
utilizando el prototipo. Ejemplos de estos escenarios podran ser: crear un pedido para el
que hay existencias, crear un pedido con algn producto sin existencias suficientes, crear un
pedido para un producto inexistente, etc. En la mayora de los casos, dichos escenarios
pueden identificarse directamente a partir del detalle de la especificacin encontrado en el
SRS-Software requirement specification (formato 0-SRS disponible anexo 1: formatos,
instrumentos y herramientas) [28]. Para los proyectos de nivel igual o superior a tres se
puede apoyar para ello en el documento 3A-003 en el cual se agrupan los requerimientos
por modulo del sistema.

10.1.3 Ejecucin de la evaluacin

En los mtodos de evaluacin por test, los usuarios representativos trabajan en tareas
concretas utilizando el sistema (o el prototipo) y los evaluadores utilizan los resultados para
ver cmo la interfaz de usuario da soporte a los usuarios con sus tareas. En esta actividad
se validar la correspondencia entre los requisitos documentados con las necesidades de los
clientes y usuarios, se verificar que la especificacin cumple los criterios de calidad
oportunos. El mtodo propone recurrir a los prototipos para los aspectos de validacin y
verificacin formal [38].
Para realizar esta evaluacin se pide a los usuarios que realicen las tareas y que expliquen
en voz alta lo que piensan al respecto, mientras estn trabajando con el prototipo. Ellos
deben describir qu es lo que creen que est pasando, el por qu toman una u otra accin o
qu es lo que estn intentando realizar. Pensando en voz alta permite a los evaluadores
comprender cmo el usuario se aproxima al objetivo con la interfaz propuesta y qu
consideraciones tiene en la mente cuando la usa. El usuario puede expresar que la secuencia
de etapas que le dicta el producto para realizar el objetivo de su tarea es diferente de la que
esperaba [38]. En el checklist se debe ir indicando si la tarea pudo ser realizada por el
usuario, al igual que se califica en una escala de 1 a 5 el nivel de dificultad que tuvo el
usuario al realizar dicha tarea (Donde 5 indica el valor mximo de dificultad para realizar la
tarea y 1 indica la menor dificultad). En caso de encontrarse inconvenientes o sugerencias
por parte de los usuarios al realizar la tarea, es necesario anotar el respectivo comentario
para realizar el anlisis correspondiente.

78
Aunque el principal beneficio del mtodo es una mejor comprensin del modelo mental del
usuario y la interaccin con el producto, existen otros beneficios como por ejemplo:
conocer la terminologa que el usuario utiliza para expresar una idea o funcin. Esta
terminologa se encuentra descrita en el glosario de trminos (Formato 0-Glosario de
trminos disponible en el anexo 1: formatos, instrumentos y herramientas), por lo cual el
evaluador deber ir anotando estos trminos para posteriormente validarlo con el usuario de
acuerdo a lo registrado en dicho glosario y de ser necesario realizar los ajustes
correspondientes. Este mtodo tiene como ventaja la simplicidad, a su vez requiere poca
experiencia para poderlo llevar a cabo y puede proporcionar ideas muy tiles acerca de los
problemas con una interfaz grfica. [88]
Posterior a la ejecucin de la validacin de prototipos, el ingeniero de requerimientos debe
evaluar los resultados obtenidos tomando los checklist diligenciados (formato 5V-001,
anexo 1: formatos, instrumentos y herramientas). Es necesario identificar los
requerimientos de aquellas tareas que efectivamente no se pudieron ejecutar en el proceso
de validacin o cuya complejidad de ejecutarlos fue alta (mayor o igual a 3), con el fin de
volverlos a llevar a la fase de validacin de requerimientos y estos sean corregidos. Cuando
se realicen los ajustes necesarios a nivel de especificacin y de prototipo es necesario
volver a realizar la ejecucin de la evaluacin de prototipos. Esto es necesario, ya que se
debe garantizar que cada requerimiento es completo, correcto, realizable, necesario,
priorizable, no ambiguo, verificable, conciso e independiente del diseo [7] [67]

10.2 Validacin y negociacin de requerimientos

10.2.1 Verificacin y validacin de requerimientos

De forma tradicional, la verificacin y validacin de requisitos han sido las actividades
consideradas parte del SQA (Software Quality Assurance) en la fase de ingeniera de
requisitos. La verificacin de requisitos puede considerarse como la actividad cuyo objetivo
es alcanzar la calidad interna exigible a la especificacin de requisitos conforme a las
normas establecidas previamente, mientras que la validacin tiene como objetivo asegurar
que los requisitos elicitados, documentados, analizados y verificados representan realmente
las necesidades de clientes y usuarios. Los trminos de validacin y verificacin suelen
usarse a veces como sinnimos o aparecer unidos en la mayor parte de la literatura sobre
ingeniera del software e ingeniera de requisitos [90]. Pohl [91] define ambos trminos
dejando ver sus diferencias:
La verificacin de requerimientos es el conjunto de actividades relacionadas con la calidad
de las especificaciones de requisitos, se encarga de comprobar que la especificacin de
requisitos es acorde a restricciones definidas formalmente, mientras la validacin de
requisitos es un conjunto de actividades encaminadas a llegar a un acuerdo entre todos los
participantes en el que se ratifique que los requisitos elicitados y analizados representan
realmente las necesidades de los stakeholders y que, por lo tanto, deberan llevar a la
construccin de software til.

79
 10.2.1.1 Inspecciones internas
Para llevar a cabo la evaluacin de calidad de los requisitos de manera manual se aplican
tcnicas de lectura que consisten en realizar una lectura detenida de la especificacin de
requisitos al objeto de encontrar irregularidades que sea necesario eliminar [92], una de
estas tcnicas es la inspeccin. La cual se es una tcnica de anlisis que confa al examen
visual los productos de desarrollo para detectar errores, violaciones de recomendaciones
estndar y otros problemas [93].
En este proceso se realiza una verificacin al SRS (Software Requirements Specification,
formato 0-SRS anexo 1: formatos, instrumentos y herramientas) en cuanto a anomalas y
contradicciones, dicha verificacin debe ser realizada siguiendo el procedimiento definido
en la seccin 8.1 (Verificacin requerimientos). En esta etapa el equipo revisor debe
comprobar adems los siguientes aspectos [28]:

Verificabilidad. Puede probarse el requerimiento de modo realista?

Compresibilidad. Las personas que adquieren el sistema o los usuarios finales
comprenden correctamente el requerimiento?
Trazabilidad. Est claramente establecido el origen del requerimiento?
La metodologa propuesta sugiere realizar estas inspecciones principalmente con los lderes
de cada proceso. Estas inspecciones abarcan:

Revisin par ingeniero de requisitos: Un ingeniero de requerimientos que no ha sido

parte activa del proceso se encarga de realizar la verificacin desde el enfoque de la
ingeniera de requisitos.
Inspeccin arquitecto/lder tcnico del proyecto: Esta inspeccin se realiza desde el
enfoque tcnico. Se deben enfocar principalmente en las llamadas verificaciones de
realismo, utilizando el conocimiento de la tecnologa existente, los requerimientos
deben verificarse para asegurar que se pueden implementar.
Inspeccin lder equipo de aseguramiento de calidad (QA): Esta inspeccin se
enfoca en validar la viabilidad de poder escribir un conjunto de pruebas que
demuestren que el sistema a entregar cumple cada uno de los requerimientos
especificados.
El resultado de dichas inspecciones debe ser registrado en el documento 5V-002 disponible
en el anexo 1: formatos, instrumentos y herramientas. El analista de requerimientos realiza
la revisin de dichos resultados corrigiendo el documento de especificacin (SRS) aquellos
errores de nivel menor, los errores de nivel mayor se corregirn siempre y cuando la
solucin no altere la esencia de los requerimiento, en caso contrario deber ser validado con
los stakeholders. En el documento 5V-003 (disponible en el anexo 1: formatos,
instrumentos y herramientas) quedar registrado el proceso de revisin de los resultados de
las inspecciones.

10.2.1.2 Validacin de requerimientos con los stakeholders

La validacin de los requisitos representa un compromiso entre los stakeholders y
desarrolladores, por lo cual antes de empezar este proceso se debe concientizar a los

80
stakeholders de la importancia de esta etapa. Esto porque los stakeholders pueden
considerar el acuerdo como un ritual necesario pero sin sentido, que es aceptado porque es
la nica forma de que comience el desarrollo. Esta actitud suele ir acompaada de cierto
desinters en la revisin de las especificaciones de requisitos y por lo tanto es probable que
surjan problemas durante el desarrollo. Si el cliente no recibe el producto que esperaba,
suele delegar culpas en la falta de profesionalidad de los encargados del desarrollo de
software, en los cuales confi para que interpretaran correctamente sus necesidades. La
validacin de requisitos se considera como la actividad de la ingeniera de requisitos en la
que stakeholders con la ayuda del ingeniero de requisitos, revisan los productos obtenidos
durante las actividades anteriores para confirmar que realmente reflejan sus necesidades y
que definen el producto deseado [94].
Este proceso incluye tres tareas fundamentales [95]:
1. Validar los requisitos de almacenamiento de informacin y funcionales: Su
propsito es asegurarse que estn representados realmente las necesidades de los
stakeholders.
2. Validar los requisitos no funcionales: El objetivo de esta tarea es validar los
requisitos no funcionales y los posibles conflictos que pudieran aparecer.
3. Cerrar la revisin de los requisitos: Si no han aparecido nuevos conflictos durante el
proceso de validacin, se debe llegar a un acuerdo con el cliente para cerrar la
versin actual de los requisitos.
Para realizar el proceso de validacin de requerimientos la metodologa propone el uso de
la tcnica denominada Walkthroughs (recorridos). Esta es una tcnica de anlisis esttico
en la que un programador o diseador dirige a miembros del equipo de desarrollo u otras
personas interesadas a travs de un segmento de documentacin o cdigo y los
participantes realizan comentarios sobre posibles errores, violaciones de estndares de
desarrollo y otros problemas [93].
Los objetivos de una sesin de walkthrough es encontrar conflictos (defectos, omisiones,
contradicciones) en el producto, de forma que puedan plantearse alternativas y los
participantes aumenten su conocimiento sobre el producto en cuestin. Durante las sesiones
de walkthrough, el autor recorre la documentacin en detalle, permitiendo que los
participantes pongan de manifiesto sus opiniones sobre el mismo [92].
Para la aplicacin de esta validacin se requiere apoyo de por lo menos una persona
adicional, aparte del ingeniero de requerimientos, el cual debe encargarse de registrar en el
formato 5V-004 (disponible en el anexo 1: formatos, instrumentos y herramientas) la hora
de comienzo de la reunin, los conflictos expresados por los stakeholders durante la sesin,
las acciones sugeridas por estos y la hora de finalizacin. Durante la ejecucin de la sesin
de validacin el ingeniero de requerimientos debe recorrer en detalle el documento de
especificacin SRS de forma que los stakeholders puedan plantear las consideraciones que
consideren oportunas, en aquellos casos en que sea necesario resolver dudas o ampliar ms
el detalle de un requerimiento se debe apoyar en los modelos de flujo de datos (seccin
9.2.2 Modelado de requerimientos del usuario), al igual que en los modelos realizados para
los requerimientos del sistema (Modelado de contexto, Modelado de objetos, Modelado con
redes Petri. Seccin 9.3.2 Modelado requerimientos del sistema). Es necesario que el

81
ingeniero de requerimientos evite que los stakeholders busquen soluciones a los conflictos
encontrados, sino que solamente se limiten a exponerlos.
En esta etapa es importante tener en cuenta la revisin del formato 5V-003 (disponible en el
anexo 1: formatos, instrumentos y herramientas), para realizar la validacin de aquellos
requerimientos que durante el proceso de inspeccin interna de requerimientos qued
pendiente de validar con los stakeholders, ya que de esta manera se da la claridad necesaria
a estos requerimientos o pueden surgir aspectos a considerar que deben corregirse o que
representan alguna clase de conflicto.
Como resultado de la reunin pueden detectarse conflictos, los cuales deben llevarse a una
fase de negociacin de requerimientos (seccin 10.2.2), descubrirse nuevos requerimientos
o validar los requisitos ya existentes. De esta manera el documento de especificacin SRS
puede aceptarse, recomendarse cambios o acordarse una nueva sesin de validacin si la
naturaleza de los cambios as lo requiriese.
En caso de que el documento de especificacin SRC sea aceptado, los gestores del proyecto
pueden considerar el acuerdo como una forma de congelar los requisitos, y de esta forma
rechazar cualquier solicitud de cambio posterior que conlleva la necesidad de cambios en la
planificacin o en la asignacin de recursos, argumentando que cualquier consideracin
adicional deber ser llevada a una fase de gestin de cambios (seccin 11 del presente
documento). Para evitar posibles interpretaciones errneas del acuerdo sobre un documento
de requisitos, es necesario considerar este como un punto de partida en el proceso de
desarrollo [94]. Cerrando as el acuerdo por medio del acta de aceptacin del documento de
especificacin de requisitos, encontrada en el formato 5V-008 (disponible en el anexo 1:
formatos, instrumentos y herramientas).

10.2.2 Negociacin de requerimientos

El proceso de negociacin es considerado como un enfoque de colaboracin para solucin
de conflictos en donde se realiza la exploracin de las posibilidades. Se caracteriza porque
los participantes tratan de encontrar una solucin que satisfaga a todas las partes en la
medida de lo posible [96]. Un proceso de negociacin debe considerar las siguientes fases:
Pre-Negociacin (reconocimiento del problema inicial), negociacin (bsqueda de
solucin), post-negociacin (mantenimiento a la solucin) [4].
El objetivo de esta actividad es alcanzar acuerdos entre todos los participantes sobre los
requisitos elicitados en la actividad anterior, avanzando en la dimensin de acuerdo del
proceso. Para ello, MPIu+a [38] propone tener en cuenta cuatro factores:

Hacer explcitos los conflictos y evitar los conflictos emocionales entre los
participantes.
Hacer explcitos para cada conflicto las alternativas, las argumentaciones y las
razones subyacentes que los provocan.
Tomar las decisiones correctas a partir de un consenso en los resultados de la
negociacin entre la mayora de los participantes.

82
 Asegurarse de involucrar a las personas adecuadas en el momento adecuado y evitar
las renegociaciones innecesarias

10.2.2.1 Pre-Negociacin
Las actividades de esta fase son: la definicin del problema de negociacin, la
identificacin de los stakeholders involucrados, los objetivos de elicitacin de los
stakeholders y el anlisis de los objetivos para encontrar los conflictos. Un problema es un
tema de especial inters en una negociacin, cada problema tiene una amplia gama de
alternativas u opciones, las cuales deben ser acordadas por los negociadores con el fin de
lograr un compromiso [97].
Para identificar los stakeholders involucrados en el proceso de negociacin es necesario
tomar la lista de los problemas o conflictos a tratar, los cuales fueron identificados en la
etapa anterior (10.2.1.2 Validacin de requerimientos con los stakeholders), y se
encuentran registrados en el formato 5V-004 (disponible en el anexo 1: formatos,
instrumentos y herramientas). En este formato se encuentran registrados los stakeholders
que presentaron algn tipo de conflicto con determinado requerimiento, adicionalmente por
cada uno de los requerimientos donde se identific el conflicto es necesario apoyarse en la
matriz de trazabilidad (Formato 0-Matriz trazabilidad, disponible en el anexo 1: formatos,
instrumentos y herramientas) y en la matriz de rastreo (Formato 3A-003, disponible en el
anexo 1: formatos, instrumentos y herramientas), con el fin de buscar posibles relaciones
con otros requerimientos y as poder identificar a otros stakeholders que deben estar
involucrados en el proceso de negociacin.
Es necesario realizar una reunin previa al proceso de negociacin con cada uno de los
stakeholders que presentaron algn tipo de conflicto durante el proceso de validacin de
requerimientos. En esta reunin se debe realizar con el fin de conocer los objetivos que
cada stakeholder tiene sobre cada requerimiento donde este haya identificado un conflicto,
estos objetivos se registran usando el formato 5V-005 (anexo 1: formatos, instrumentos y
herramientas) y se formulan en distintos niveles de granularidad, que van desde un alto
nivel en aspectos tales como las capacidades generales del sistema, los presupuestos, etc, o
la programacin a nivel inferior relacionado a problemas tcnicos tales como entornos de
desarrollo o las plataformas destino. Posteriormente los objetivos de cada stakeholder sern
evaluados en conjunto por los lderes de las reas de proceso de requerimientos, desarrollo
y pruebas en reuniones programadas, con el fin de realizar un proceso conjunto de anlisis
determinando la viabilidad de cada uno de ellos y plantear posibles soluciones. El resultado
de este proceso de evaluacin deber ser actualizado en el formato 5V-005 (Columnas
resaltadas, disponible en el anexo 1: formatos, instrumentos y herramientas).

10.2.2.2 Negociacin
Esta fase consiste en la realizacin de negociacin de requerimientos en bsqueda de la
resolucin de conflictos. En este proceso se citan a una sesin de reunin a los stakeholders
que deben estar involucrados en el proceso de negociacin. Este proceso se enfoca en
resolver la lista de conflictos relacionados en el formato 5V-004 (disponible en el anexo 1:
formatos, instrumentos y herramientas), tomando el anlisis realizado a los objetivos que

83
cada stakeholder plante previamente con el fin de buscar soluciones mutuamente
beneficiosas que sean aceptables para todas las partes [98].
En el desarrollo de esta actividad se debe ir revisando de manera individual cada uno de los
requerimientos que presenta alguna clase de conflicto, presentando la solucin que plante
el equipo de desarrollo a nivel interno y que se encuentra descrita en el formato 5V-005
(disponible en el anexo 1: formatos, instrumentos y herramientas). Esta solucin es
debatida por parte del grupo negociador evaluando su aceptacin siguiendo el proceso
definido en la ilustracin 30. Tras ser aceptada una solucin, esta debe ser redactada y
registrada en el formato 5V-006 (disponible en el anexo 1: formatos, instrumentos y
herramientas) por parte de los participantes de la sesin de validacin, cumpliendo
totalmente los criterios definidos en la seccin 10.1 - Verificacin requerimientos. La
Ilustracin 30: Proceso de evaluacin de solucin de conflictos, basado en QARCC
(Quality Attribute Risk and Conflict Consultant) representa la informacin planteada.

Ilustracin 30: Proceso de evaluacin de solucin de conflictos, basado en QARCC (Quality Attribute Risk and
Conflict Consultant) [99]

84
 10.2.2.3 Post-Negociacin:
En esta fase los asistentes a la reunin de negociacin realizan una ltima revisin completa
a los conflictos existentes y a las soluciones dadas, con el fin de analizar y evaluar el
resultado de la negociacin y sugerir una re-negociacin si es necesario. Se puede
determinar si el actual acuerdo satisface las preferencias de las contrapartes y si existe una
mejor solucin posible para realizar una nueva negociacin, sin causar la prdida en los
intereses y objetivos del resto de stakeholders [4].
Una de las ventajas de la etapa del proceso de post-negociacin es que al final de la
negociacin los asistentes deben firmar un acta de reunin, descrita en el formato 5V-007
(disponible en el anexo 1: formatos, instrumentos y herramientas), donde se adquiere un
compromiso que involucra a los stakeholders en etapas procesos de validacin y re-
negociaciones en caso de ser necesarias. Esto es fundamental en aquellos procesos que se
guen por un modelo de ciclo de vida iterativo, ya que los resultados de la negociacin
deben ir evolucionado constantemente y nuevas metas siempre puede surgir y,
posiblemente, provocar nuevos conflictos [94].
Finalmente el documento de especificacin SRS debe actualizarse de acuerdo a los nuevos
ajustes realizados a los requerimientos durante el proceso realizado, posteriormente este
documento debe llevarse nuevamente a un proceso de validacin y negociacin de
requerimientos (punto 10.2), este proceso se repite las veces que sean necesarias hasta que
no existan temas a ajustar al SRS y este se pueda dar por aceptado en el proceso de
validacin.

10.3 Documentacin
Al finalizar la etapa de validacin de requerimientos se deber contar con los siguientes
documentos:

SRS - Software El documento de especificaciones de software (SRS- Software

Requirements Requirements Software) validado y aceptado por el cliente: 0-
Specification SRS (Anexo 1).
Acta de aceptacin del Documento que evidencia la finalizacin del proceso de
documento SRS - validacin de requerimientos y cuyo resultado es la aceptacin:
Software Requirements 5V-008 (Anexo 1).
Specification

85
 11.GESTION DE CAMBIOS

Resumen
Entradas Clasificacin del proyecto.
SRS - Software Requirements Specification.
Descomposicin jerrquica.
Matriz de trazabilidad
Matriz de rastreo
Salidas Acta de evaluacin de la propuesta de desarrollo de los cambios
Propuesta

El software, independientemente de su tamao, sufrir indudablemente cambios despus de

que ste sea entregado al cliente. Especialmente para sistemas de software grande, los
requerimientos son siempre cambiantes, debido a que el problema no puede definirse
completamente y por ende es probable que los requerimientos del software sean
incompletos [28]. Estos cambios ocurrirn debido a [38]:

Que se han encontrado errores.

Que el software debe adaptarse por cambios del entorno externo (un nuevo sistema
operativo, perifrico, etc.).
Que el cliente requiere aumentos funcionales o de rendimiento
Para Leffingwell y Widrig [100] los factores que pueden infligir cambios en los requisitos,
tanto durante el desarrollo inicial as como en la evolucin del software son:

Los cambios que se realizan para resolver un problema actual en el sistema, por
ejemplo: por razones econmicas, razones polticas, tecnolgicas, entre otros.
Los usuarios cambian de opinin sobre lo que quieren que haga el sistema, ya que
comprenden mejor sus necesidades. Esto puede suceder debido a que los usuarios
inicialmente tenan incertidumbre sobre lo que queran, o porque nuevos usuarios
entran en escena.
Cambios en el entorno que se encuentra implantado el sistema, por ejemplo
aumento en la capacidad y velocidad de los servidores.
Cuando el sistema es desarrollado y puesto en servicio a los usuarios
Conforme se va desarrollando la definicin de los requerimientos, normalmente se tiene
una mejor compresin de las necesidades del usuario. Esto retroalimenta la informacin del
usuario, quien puede entonces proponer un cambio en los requerimientos, tal como se
puede observar en la ilustracin 31.

86
Ilustracin 31: Evolucin de los requerimientos a lo largo del tiempo a causa de cambios en la comprensin del problema.

Desde una perspectiva evolutiva los requerimientos se dividen en dos clases [28]:
A. Requerimientos duraderos: Requerimientos relativamente estables que se derivan
de la actividad principal de la organizacin y que estn relacionados directamente
con el dominio del sistema.
A. querimientos voltiles: Requerimientos que probablemente cambian durante el
proceso de desarrollo del sistema o despus que este se ha puesto en
funcionamiento. Esta clase de requerimientos se divide en cuatro subclases:

i. querimientos cambiantes: Cambian debido al entorno al que opera la

organizacin.
ii. erimientos emergentes: Emergen al incrementar la comprensin del cliente en el
desarrollo del sistema.
iii. erimientos consecuentes: Son el resultado de la introduccin del sistema
informtico, que puede desarrollar nuevas formas de trabajar en la organizacin
y a su vez generar nuevos requerimientos.
iv. erimientos compatibles: Dependen de sistemas particulares o procesos de
negocios dentro de la organizacin. Cuando estos ltimos cambian, los
requerimientos de compatibilidad del sistema encargado o entregado tambin
pueden cambiar.
La gestin de los requerimientos se basa en la capacidad de identificar, documentar y
mantener informacin sobre la interdependencia de los requisitos [4]. Es el proceso de
comprender y controlar los cambios en los requerimientos del sistema, es importante
mantener vnculos entre los requerimientos dependientes, de forma que se pueda evaluar el
impacto de los cambios en los requerimientos. Es necesario establecer un proceso formal
para realizar propuestas de cambios y vincular estos requerimientos al sistema [28], para
ello la metodologa propone seguir el proceso indicado en la ilustracin 32.
La ventaja de utilizar un proceso formal para gestionar el cambio es que todos los cambios
propuestos son tratados de forma consistente y que los cambios en el documento de
requerimientos se hacen de forma controlada [28].

87
Ilustracin 32: Proceso realizado para elaborar y evaluar propuestas de cambios

11.1 Identificacin de las necesidades de cambio

La primera actividad en la gestin de cambios es realizar una serie de reuniones con los
stakeholders, con el fin de identificar las necesidades reales del cambio. Las peticiones
realizadas por los stakeholders deben ser tan expresivas y completas como sea posible para
facilitar la labor de evaluacin del impacto sobre los requerimientos actuales [101]. Para
aquellos casos en que el cambio solicitado no se logre describir de forma clara y concreta,
se sugiere realizar el anlisis de tareas u operaciones que realiza la empresa utilizando un
enfoque top-down y aplicacin de herramientas descritas en el punto 4.4.1 identificacin
del problema, cada una de estas peticiones deber ser registrada en el artefacto 6C-001
(disponible en el anexo 1: formatos, instrumentos y herramientas) adjuntando adems
aquellos documentos que sustenten la necesidad del cambio (por ejemplo: documentos de
resoluciones, normatividades).

Con el fin de validar el mutuo entendimiento y completitud de las peticiones de cambio se

sugiere realizar una validacin por medio de prototipos, tal como se describe en la seccin
6.4.2 - Planteamiento de la solucin.

11.2 Medir el impacto de los cambios sobre los requerimientos actuales

Uno de los propsitos del establecimiento de procedimientos para la gestin de cambios en
los requisitos es asegurar que al existir cambios en los requerimientos, su impacto en el
proyecto pueda cuantificarse y acordarse con los stakeholders en cuanto a plazo, esfuerzo y
costo al aplicar los cambios de la aplicacin [101].
En muchos casos el deterioro del software es ocasionado por cambios realizados, los cuales
previamente no se evalu el impacto de dichos cambios sobre el sistema. El anlisis de
impacto es una herramienta para controlar los cambios y por lo tanto evitar el deterioro del
software [4]. Bohner y Arnold [102] definen anlisis de impacto como "la actividad de la
identificacin de las consecuencias potenciales, incluyendo los efectos secundarios y
efectos de onda, de un cambio, o la estimacin de lo que se necesita modificar para lograr
desarrollar un cambio antes de que se realice". En esta etapa se realiza un anlisis funcional
88
de alto nivel de los nuevos requerimientos y el correspondiente diseo tcnico a grandes
rasgos, ya que es necesario contemplar ambos para poder estimar adecuadamente el
esfuerzo de desarrollo que conlleva [101], ya que la salida del anlisis de impacto se puede
utilizar como una base para estimar el costo asociado con un cambio.
Existen muchas relaciones entre los requerimientos y entre estos y el diseo del sistema.
Tambin existen vnculos entre los requerimientos y las razones fundamentales por lo que
estas se propusieron. Cuando se proponen cambios, se debe rastrear el impacto de estos
cambios en los otros requerimientos y en el diseo del sistema. El rastreo es una propiedad
de la especificacin de requerimientos que refleja la facilidad de encontrar requerimientos
relacionados. Existen dos tipos de informacin de rastreo que pueden ser mantenidos [28]:

La informacin de rastreo de la fuente: Vincula los requerimientos con los

stakeholders que propusieron los requerimientos y la razn de estos. Cuando se
propone un cambio, esta informacin se utiliza para encontrar y consultar a los
stakeholders sobre el cambio
La informacin de rastreo de los requerimientos: Vincula los requerimientos
dependientes en el documento de requerimientos. Se utiliza para evaluar como es
probable que muchos requerimientos se vean afectados por un cambio propuesto y
la magnitud de los cambios consecuentes en los requerimientos.
Tomando la matriz de rastreo (3A-003, disponible en el anexo 1: formatos, instrumentos y
herramientas), es necesario identificar en la matriz de trazabilidad (Formato 0-Matriz
trazabilidad, disponible en el anexo 1: formatos, instrumentos y herramientas) los
stakeholders involucrados con cada uno de los requerimientos dependientes o que tienen
otro tipo de relacin con los cambios solicitados ya que durante este proceso se deber
mantener las entrevistas necesarias con los stakeholders involucrados con estos
requerimientos para aclarar todas las dudas y poder efectuar un anlisis completo del
impacto real de los cambios [101].

11.3 Estimacin costo inicial

Para realizar la estimacin de costo habr que realizar las mismas operaciones que en la
actividad 6.4.3-Estimacin costo inicial, pero con una importante caracterstica que es
fundamental tener en cuenta: cuando se pide un cambio, se pueden dar las siguientes
circunstancias [101]:

La parte del sistema que hay que modificar est totalmente desarrollada. En este
caso la estimacin del esfuerzo para el cambio es neta.
La parte del sistema que hay que modificar est parcialmente desarrollada. En este
caso hay que descontar el esfuerzo correspondiente a la parte no desarrollada en la
estimacin original del total del esfuerzo estimado para el cambio.
La parte del sistema que hay que modificar est sin desarrollar. En este caso hay que
descontar el esfuerzo correspondiente en la estimacin original del total del esfuerzo
estimado para el cambio.

89
 11.4 Presentacin propuesta
La propuesta puede ser presentada de acuerdo a los puntos dados en la seccin 6.4.4
Presentacin propuesta del presente documento.
Es fundamental que la propuesta contenga claramente la estimacin de costo y de esfuerzo
realizada por cada uno de los cambios solicitados, adems de la debida justificacin del
porqu de dicha estimacin. Para ello es de utilidad que se presente un resumen del anlisis
de impacto realizado anteriormente, exponiendo cuales requerimientos y el cmo se ven
afectados por determinado cambio.

11.5 Negociacin de aplicacin de los cambios

En esta etapa se define la aplicacin o no de las peticiones de cambios solicitadas, adems
de determinar las condiciones en que dichos cambios se efectuaran. Para ello es necesario
realizar una reunin con los stakeholders y sponsor del proyecto con el fin de llegar a
acuerdos en cuanto los costes que los cambios van a ocasionar y la posible dilatacin que se
producir en los plazos de entrega (en caso de que los cambios surjan durante el desarrollo
del proyecto). Como consecuencia de esta evaluacin de la propuesta pueden darse cinco
posibilidades [101]:
a) Los stakeholders o sponsor del proyecto rechazan la peticin. En este caso la
peticin se archiva como rechazada indicndose los motivos.
b) Los stakeholders o sponsor del proyecto estiman que la peticin es necesaria pero
que el coste o la dilatacin en los plazos de entrega son excesivos. Se pide al equipo
del proyecto (proveedor) que revise las condiciones, en este caso se debe ajustar la
propuesta y volver a citar a una reunin de negociacin de aplicacin de cambios.
c) Los stakeholders y sponsor del proyecto aprueban la peticin. En este caso se
desarrolla como se haba previsto.
d) Los stakeholders y sponsor del proyecto aprueban la peticin, pero se decide aplazar
su desarrollo hasta otro momento.
e) Los stakeholders y sponsor del proyecto deciden aprobar el desarrollo de solamente
aquellos cambios que sean prioritarios o estrictamente necesarios y aplazar el
desarrollo de los dems hasta otro momento. En este caso es necesario realizar una
nueva estimacin del costo de los cambios aprobados para desarrollo y nuevamente
citar a una reunin de negociacin de aplicacin de cambios.
En caso de que la propuesta sea rechazada o presente observaciones (casos a, b, e), es
necesario diligenciar el formato 6C-002 (disponible en el anexo 1: formatos, instrumentos y
herramientas). Por otro lado si la propuesta es aprobada, se debe diligenciar el formato 6C-
003 (disponible en el anexo 1: formatos, instrumentos y herramientas). En este caso hay
que resaltar que debe seguirse estrictamente las fases que propone la metodologa en la
ilustracin 2. (5-elicitacion, 6-analisis, 7-especificacion, 8-validacion)

90
 11.6 Documentacin
Al finalizar la etapa de gestin de cambios se deber contar con los siguientes documentos:

Acta de evaluacin de Documento que evidencia la finalizacin del proceso de

la propuesta de evaluacin de la propuesta de desarrollo de los cambios
desarrollo de los solicitados: 6C-002: En caso de que la propuesta sea rechazada
cambios o presente observaciones, 6C-002: Si la propuesta es aprobada
(Anexo 1).

91
 12.LA INGENIERIA DE REQUERIMIENTOS EN LA ACADEMIA

La ingeniera de requerimientos comprende todas las tareas relacionadas con la

determinacin de las necesidades o de las condiciones a satisfacer para un software nuevo o
modificado [103], sin embargo como lo ha mencionado Ackoff citado por Antonelli y
Oliveros: Fallamos ms a menudo porque resolvemos el problema incorrecto que porque
obtenemos una solucin deficiente del problema correcto [3], por ende es necesario
profundizar en la bsqueda de estrategias que permitan disminuir las falencias de la
ingeniera de requerimientos, falencias de las que no son ajenas el sistema educativo. De
otro lado como lo menciona Ruiz y Roman la correccin de errores es ms costosa a
medida que se avanza en las etapas de software, por ejemplo los errores de diseo son 1,6
veces ms costosos de detectar en los errores de codificacin [104] esto hace que la
ingeniera de requerimientos sea tomada con mayor importancia, dado que es el primer
paso a la hora de elaborar o modificar un software.
En la seccin 5.1.2 se abordaron los principales inconvenientes de la ingeniera de
requerimientos en la academia, entre estos se observ que por lo general los tpicos
relacionados con esta temtica son abordados de forma incompleta y en diferentes
asignaturas del currculo acadmico, adems existe un desconocimiento en el uso de las
tcnicas para realizar elicitacin, tambin existen falencias para realizar priorizacin de
requerimientos, distinguir las tcnicas de diseo centrado en el usuario, realizar
clasificacin de stakeholders y hacer gestin de requerimientos (Trazabilidad).
Es por esto que se ha estructurado una gua la cual permita a las instituciones universitarias
fortalecer el pensum acadmico al introducir esta catedra en su currculo. La gua presenta
los pre-saberes necesarios, los objetivos de aprendizaje, contenido con los cuales se
pretende guiar a travs de un proceso epistmico, propuestas para evaluacin y bibliografa
del curso. Esta gua se encuentra en el ANEXO 4: GUA DE ENSEANZA DE LA
INGENIERA DE REQUERIMIENTOS, en la cual se estructura como ensear la ingeniera
de requerimientos en las instituciones de educacin superior. La fundamentacin de
contenidos del curso ha sido tomada de las fases establecidas en la presente metodologa.

92
 13.DESARROLLO DE APLICATIVO SOPORTE A LA

METODOLOGIA

Con el fin de dar soporte a la metodologa se construy un aplicativo web, el cual tiene
como fin apoyar el proceso de implementacin de la metodologa en las empresas, al igual
que brindar las herramientas e informacin necesaria para la academia. En el ANEXO 5:
ARTEFACTOS CONSTRUCCION APLICATIVO WEB, se puede observar los artefactos
resultantes realizados durante el proceso de especificacin de requerimientos del aplicativo
construido.
El aplicativo web fue desarrollado en lenguajes PHP, manejando la persistencia por medio
del gestor de base de datos MySQL. En la ilustracin 33 se puede observar la pantalla de
inicio del aplicativo, este se encuentra disponible en la url:
http://mrpyme.appsdecolombia.com/

Ilustracin 33: Pantalla de inicio del aplicativo web

93
 Ilustracin 34: Funcionalidades del aplicativo web

La ilustracin 34 se muestra las funcionalidades desarrolladas en el aplicativo, las cuales se

detallarn a continuacin:

Consultar marco terico: Tal como se observa en la ilustracin 35, el aplicativo

permite consultar el marco terico, mediante la opcin de men superior subrayada
en rojo.

Ilustracin 35: Pantalla consulta marco terico

94
 Consultar gua acadmica: En ilustracin 36 se observa que la aplicacin permite
realizar la consulta de la gua acadmica, como apoyo a las instituciones
universitarias con el fin de fortalecer el pensum acadmico, mediante la opcin de
men superior subrayada en rojo.

Ilustracin 36: Pantalla consulta gua acadmica

Descargar resumen metodolgico: En la ilustracin 37 se observa la pantalla de

descarga del resumen de la metodologa, mediante la opcin de men superior
subrayada en rojo.

Ilustracin 37: Pantalla descarga resumen metodolgico

95
 Descargar formatos transversales: En la ilustracin 38 se muestran los botones
de descarga de los formatos que son transversales a todas las fases de la
metodologa los cuales son: Formato 0-Glosario de trminos, 0-Matriz
Trazabilidad, Formato 0 - Matriz de Rastreo,0-SRC todos disponibles en el
ANEXO 1: FORMATOS, INSTRUMENTOS Y HERRAMIENTAS.

Ilustracin 38: Pantalla descarga resumen metodolgico

Mostrar los formatos obligatorios que se han diligenciado por fase: En la

ilustracin 39 se puede observar la cantidad de formatos obligatorios que se han
diligenciado por fase (en la ilustracin 39 subrayado en rojo)

Ilustracin 39: Pantalla formatos obligatorios diligenciados por fase

96
 Descargar/Cargar formatos diligenciados: En la ilustracin 40 se muestra la
pantalla de la fase de pre-anlisis. En esta pantalla se observa al frente del nombre
del formato un indicador verde/rojo, el cual se muestra en verde cuando el formato
se encuentra diligenciado y cargado a la aplicacin, rojo en caso contrario.
Adicionalmente al dar clic sobre el nombre del formato, este ser descargado, al
igual que la aplicacin permite cargar el formato. En caso de tener alguna duda
sobre la finalidad y de cmo se diligencia dicho formato, al dar clic sobre el icono
de informacin se abre en una ventana emergente un video en donde se despejan
estas dudas.

Ilustracin 40: Pantalla fase metodologa

97
 Mostrar advertencia de formatos sin diligenciar de fases previas: En caso de
que se intente acceder a fases posteriores de la metodologa, el sistema valida que
los formatos obligatorios de las fases anteriores se encuentre diligenciados y
cargados al sistema. En la ilustracin 41 se muestra el mensaje de advertencia,
donde informa que faltan formatos por llenar en la fase de pre-anlisis, ya que
como se puede observar en la fase de pre-anlisis se ha diligenciado y cargado un
solo formato de los dos obligatorios en esta fase. En la ilustracin 41 se puede
observar adems que cada fase posee unos formatos opcionales, los cuales algunos
de ellos pertenecen a fases previas y es opcional el hecho de actualizarlos por
alguna necesidad.

Ilustracin 41: Pantalla advertencia de formatos sin diligenciar de fases previas

98
 14.RESULTADOS Y DISCUSIN

Esta investigacin tuvo como propsito identificar los inconvenientes que se presentan en
el rea de la ingeniera de requerimientos para los desarrollos de sistemas. Se realiz desde
tres perspectivas, en la primera se identificaron los problemas comunes que se presenta en
las PYMES del departamento de Risaralda relacionadas. En la segunda se indago a los
directores de programa y egresados de pregrado en ingeniera de sistemas y carreras afines
por los conocimientos adquiridos relacionados con ingeniera de requerimientos. Por ltimo
desde la tercera perspectiva se realiz una revisin terica para identificar los problemas
ms comunes que se presentan durante la ingeniera de requisitos en Colombia y a nivel
global.
Al analizar e interpretar la informacin recolectada en las PYMES, se deduce que en la
mayora de casos se encuentran conformes con el proceso de ingeniera de requerimientos
que llevan actualmente, sin embargo se descubre que pocas de las empresas presentan un
proceso estructurado para esta rea. En la mayora de casos analizados estas solo se limitan
en aplicar una entrevista o encuesta como tcnicas de elicitacin y algunas veces a
diligenciar documentos ad-hoc establecidos por ellos, sin embargo no existe un proceso
riguroso de elicitacin, modelado, validacin, y gestin de requerimientos, ms aun las
PYMES aplican el mismo proceso y las mismas tcnicas de elicitacin para todos los
proyectos, sin importar la complejidad de estos.
La mayora de las apreciaciones obtenidas hasta este punto no difieren de lo encontrado
desde la perspectiva terica, en donde se identificaron los inconvenientes ms comunes que
se presentan en el proceso de ingeniera de requerimientos en las industrias. Ahora bien, el
panorama del lado de la academia no es muy diferente, ya que la mayora de egresados
manifiestan gran desconocimiento en temas como: tcnicas de elicitacin, validacin de
requerimientos, stakeholders, dependencia entre requerimientos, diseo centrado en el
usuario, modelado y gestin de requerimientos.
Esto nos ha motivado a estructurar un marco de trabajo de manera metodolgica que
permita a las empresas mejorar su proceso de ingeniera de requisitos, la cual fue realizada
pensando en las necesidades que presentan las PYMES de la regin de Risaralda. Esta se
encuentra estructurada por fases, en donde las herramientas que se deben aplicar en cada
una de estas se encuentran segmentadas segn el tipo de proyecto. Esto permite hacer que
sea modular y flexible para las empresas que deseen adoptar esta metodologa. La intensin
de esta es reducir el nmero de errores que se generan en la fase de adquisicin y gestin
de requerimientos. Al disminuir los errores en estas fases se impacta de manera directa
costos y tiempos del desarrollo de un proyecto, haciendo que estos sean menores, logrando
mejorar la calidad del sistema. La metodologa se encuentra apoyada por medio de una
aplicacin que da soporte a los procesos que conforman el marco de trabajo planteado para
la PYMES de la regin de Risaralda.
En relacin con la metodologa se ha validado el contenido de esta usando juicio de
expertos (En la seccin 5.3 Validacin de la metodologa, se puede encontrar ms detalles

99
 expertos.
de esta actividad), el grafico 42 presenta el resumen de las valoraciones obtenidas por los
100%
10%

20%

30%

40%

50%

60%

70%

80%

90%
0%
Mejorar la abstraccin de requerimientos

Grafico resultados juicio de expertos

Aumentar usabilidad y el DCU

Definir como usar las tcnicas elicitacin

Ilustracin 42: Resultado juicio de expertos

Definir como documentar y gestionar requerimientos

Realizar validacin de requerimientos

Hacer negociacin entre stakeholders

Establecer recursos humanos para ing. Requerimientos

Estructurar herramientas para dar soporte

Definir el manejo de cambios en el alcance

Generar mayor compromiso en el cliente

Realizar estimacin de tiempo

Disminuir costo, numero de errores y tiempo

Claridad
Relevancia
Coherencia
Suficiencia
100
Al observar el grfica 42 se evidencia lo siguiente:

En general la mayora de los expertos han valorado la metodologa como efectiva

para los doce tems evaluados. Esto se concluye ya que solamente un criterio de los
doce tems valorados se encuentra por debajo del 75%.
Los tems relacionados con cambios de alcance, la estimacin de tiempos y la
disminucin de costos son tems que los evaluadores considera completamente
relevantes a incluir en la metodologa.
La nica puntuacin menor al 75% fue el criterio de suficiencia para el tem
relacionado con los recursos humanos necesarios en cada una de las fases, por ende
segn el instrumento es necesario dar mayor claridad al uso de los roles que deben
existir en cada una de estas fases y las labores a desempear.
Otras recomendaciones dadas por los expertos de manera explcita en el documento de
validacin fueron:

Ampliar los conceptos de recursos humanos y negociacin de conflictos para los

desarrollos de ideas de negocio.
Analizar la inclusin del lenguaje Z como elemento para la especificacin formal,
ya que es un factor que puede aumentar de manera considerable el tiempo de los
proyectos.
Considerar el nmero de documentos que se generan en la metodologa con el fin de
no crear documentacin innecesaria la cual sea compleja de mantener en el tiempo.
Aumentar el nmero de puntos de validacin por parte de los clientes y de ser
posible definir un lder por parte de los stakeholders para la toma de decisiones.
Profundizar en cmo implementar cada una de las herramientas descritas en la
metodologa.
En algunas ocasiones es posible que con la metodologa propuesta no aclare la
ambigedad que se genera en la obtencin de requerimientos.
La metodologa permite realizar una documentacin completa del proceso de
ingeniera de requerimientos e involucra de manera activa la participacin de los
stakeholders.
La metodologa resuelve en gran parte los problemas para la cual fue creada, sin
embargo el apoyo de herramientas de software es fundamental para la consolidacin
de esta.
Por ltimo se ha estructurado una gua curricular para los programas de ingeniera de
sistemas y afines en las instituciones de educacin superior, las cuales le permitan incluir
componentes de formacin que generen en las profesionales habilidades para realizar
procesos de ingeniera de requerimientos sin ninguna dificultad.

101
 15.CONCLUSIONES Y TRABAJOS FUTUROS

Al analizar el comportamiento de la ingeniera de requerimientos tanto en las PYMES

como en las instituciones de educacin superior hemos obtenido las siguientes
conclusiones:
El principio fundamental de la gestin de proyectos es llevar a cabo la ejecucin de estos
dentro del tiempo y presupuesto establecido, sin embargo esto depende de una acertada
planificacin al inicio del proyecto. En el caso de los proyectos relacionados con la
creacin de sistemas esta fase de planificacin tiene relacin directa con la ingeniera de
requerimientos, ya que es esta en donde se comprende y delimita el problema, se definen
las restricciones del proyecto y se precisan las funcionalidades del sistema. Es por esto que
se ha estructurado una metodologa dividida en fases, en la cual cada una de estas describe
las herramientas que se deben aplicar segn el tipo de proyecto, todo esto con la finalidad
de realizar la deteccin de los posibles errores del sistema y as poder disminuir el tiempo y
costo en la ejecucin de un proyecto.
Ahora bien al inicio de esta investigacin se identific que los proyectos realizados por las
PYMES de la regin son de diferente ndole, desde los proyectos relacionados con el
transporte pblico, pasando por proyectos de software contable hasta los proyectos
relacionados con el rea de la salud. Del mismo modo los equipos para la construccin de
estos sistemas estn conformado desde tres hasta cuarenta personas. Es por esto que las
herramientas mencionadas en el punto anterior se encuentran agrupados segn el tipo de
proyecto, donde la agrupacin parte de dos criterios, el primero se encuentra orientado
hacia el nmero de personas necesarias para ejecutar el proyecto y el segundo criterio
relacionado con la criticidad del proyecto segn factores econmicos y factores humanos.
Al realizar esta agrupacin se brindan herramientas a las PYMES las cuales permitan
ejecutar proyectos con mayores probabilidades de xito, teniendo en cuenta el personal del
cual disponen y el tipo de proyecto que realizan.
Si bien para el desarrollo de sistemas existen guas de trabajo como lo son CMMI y
SWEBOK las cuales permiten orientar a los ingenieros en la creacin de sistemas de
calidad, estas se encuentran estructuradas de tal forma que definen los pasos o etapas que
deben incluir para realizar ingeniera de requerimientos, sin embargo no se define el cmo
y con qu herramientas deben ser aplicadas. Es por esto que la presente metodologa fue
estructurada como principal fundamento en ser una gua de trabajo que permita profundizar
en cmo esto a travs de las fases planteadas por la metodologa. La intencionalidad es
permitir crear proyectos de calidad para la regin definiendo las herramientas que deben
aplicar por cada una de las fases.
De otro lado la mayora de instituciones de educacin superior dan poca valoracin a las
temticas relacionadas con la ingeniera de requerimientos en los pregrados, siendo esta un
factor importante para el xito de los proyectos y la creacin de sistemas de calidad. Por
ende esto debera ser abordado con mayor rigor. Primero, se evidencia que los tpicos no se
encuentran concentrados en una materia relacionada slo con esta rea. Segundo, se
observa un grado de desconocimiento en la realizacin de priorizacin de requerimientos,

102
el diseo centrado en el usuario, las tcnicas para clasificar stakeholders, las herramientas
para medir dependencias e impacto y la medicin de trazabilidad. Son muy bsicos los
conocimientos que adquiere el estudiante sobre las tcnicas para efectuar elicitacin de
requerimiento.
Tomando los resultados obtenidos en el juicio de expertos se evidencia que la aplicacin de
este mtodo en la industria de la regin permitira disminuir los tiempos para el desarrollo
de software, ya que, al aumentar la calidad y gestin de los requisitos se disminuye el
reprocesamiento de trabajo en las diferentes fases del proceso de la ingeniera del software.
De manera similar hemos identificado algunas temticas que son de gran valor para el rea
de la ingeniera de requerimientos. Los temas propuestos a continuacin permitiran
aumentar el nivel de calidad a la vez que se disminuye el tiempo para el desarrollo de
sistemas (dados por los reprocesos). Estas temticas son:
Si bien la ingeniera de requerimientos es un rea de conocimiento joven, cada vez son ms
las investigaciones, publicaciones y dems que pretenden aportar en esta rea, por el
contrario es poco lo que se encuentra en relacin a los aplicativos (software) que apoyen
esta labor, por ende es de inters profundizar en como al hacer uso de aplicativos que den
soporte a este proceso y se aumente la calidad de los requerimientos obtenidos, a su vez
disminuya el tiempo que esto demanda. Estas herramientas pueden ser enfocadas desde dos
puntos de vista. El primero hace referencia a la validacin de los requerimientos de manera
automatizada, ya que en la mayora de casos este procesos es realizado de manera manual y
debe ser ejecutado por el equipo de ingenieros de requisitos, haciendo que esta se convierta
en una tarea que demanda tiempo considerable en la gestin del proyecto, por ende la
creacin de herramientas que de manera autnoma permitan buscar ambigedad o
conflictos entre los requerimiento haciendo uso del anlisis semntico de los
requerimientos fuese de gran ayuda al momento de validar los requisitos del sistema. En
segundo lugar tenemos las herramientas que apoyen la gestin de la ingeniera de requisito
desde sus diferentes fases. La intencin de esta es tener un mejor control, almacenamiento y
gestin de cambios de los requisitos adquiridos durante el ciclo de vida de proyecto.
A su vez es comn ver como cada da toma fuerza el desarrollo de sistemas usando
metodologas agiles como SCRUM, Programacin extrema (XP), entre otras, sin embargo
es necesario identificar como el proceso de ingeniera de requerimientos se puede
involucrar de manera directa con este tipo de metodologas y las herramientas que cada una
de estas usa para su soporte (Un ejemplo de esto es como integrar requerimientos bien
definidos al product backlog usado en SCRUM), esto sin perder su esencia de agilidad en
las entregas que se deben realizar del sistema.
Por ultimo mencionamos la aplicacin de esta metodologa en diferentes sectores de la
PYMES de la regin, y no solo el del software, sino en otras reas de la ingeniera como la
ingeniera ambiental, las telecomunicaciones, la ingeniera elctrica y electrnica entre
otros, esto con el fin de verificar si la metodologa es aplicable para otras reas del
conocimiento que sean afines, ya que los requerimientos estn presente en la mayora de
proyectos y no solo en los relacionados con la generacin de software. Se propone aplicar
la metodologa, analizar los datos obtenidos y con los resultados de estos refinar la
metodologa y as hacerla transversal a diferentes tipos de proyectos de mbito ingenieril.

103
 16.ANEXO 1: FORMATOS, INSTRUMENTOS Y HERRAMIENTAS

Formato 0-Glosario de trminos Fecha creacin dd/mm/aaaa

Fecha ltima dd/mm/aaaa
actualizacin
GLOSARIO DE TERMINOS
TERMINO DESCRIPCION
Termino 1 Definicin
Termino 2 Definicin

104
Formato 0-Matriz trazabilidad Fecha creacin dd/mm/aaaa

Fecha ltima actualizacin

MATRIZ TRAZABILIDAD [105]

Nro Cod. Requisito Nombre requisito Cod. guion de prueba Origen requisito Verificado

1 Identificador del Nombre del requerimiento Identificador del guion de Documentos que
Si
requerimiento prueba que permite verificar dan origen y
segn el 0-SRS el cumplimiento del describen el No
requerimiento requerimiento

2 Si

No

3 Si

No

Si

No

105
 MODIFICACIONES O ACTUALIZACIONES AL INSTRUCTIVO

Versin Fecha Descripcin resumida del cambio Realizado por

000 dd/mm/aaaa XXX XXX

ELABORADO POR: REVISADO POR: APROBADO POR:

XXXX XXXX XXXX

106
 Formato 0-SRC Fecha creacin dd/mm/aaaa

SOFTWARE REQUIREMENT SPECIFICATION [106]

Nombre del
proyecto

Autor

Cliente

Versin actual Fecha ltima

dd/mm/aaaa
del documento modificacin

Versiones del documento(Historial)

Versin del Fecha Razn del cambio

documento modificacin

GENERALES

Propsito
Mencione los objetivos a los cuales debe dar solucin el sistema

Alcance
Describe en detalle los lmites del proyecto, mencione lo que acciones que realizara el sistema y las que no
se han identificado que no se realizaran

Restricciones
Describa las restricciones que debern tener el sistema, tales como metodologas, lenguajes de programacin,
normas particulares, restricciones de hardware, restricciones de software, entre otras

107
Suposiciones y dependencias
Descripcin de aquellos factores que, si cambian, pueden afectar la realizacin de los requisitos.

Funciones del sistema

Describir todas las acciones que realizaran el sistema sean iniciadas por usuarios o de manera autnoma, esta
seccin puede estar acompaada de grficos y tablas que ayuden a explicar las funciones del sistema.

Se recomienda hacer uso del diagrama de casos de uso para ilustrar las funcionalidades del sistema.

REQUERIMIENTOS

Funcional.
Cdigo del Identificador nico del requerimiento Tipo
requerimiento requerimiento No
funcional.

Alta
Nombre o Breve descripcin de la funcin que realizara el Media
requerimiento Prioridad
funcin
Baja

Entradas y Describir las entradas y salidas requeridas para el requerimiento

salidas

Pre- Que se debe cumplir antes de ser invocar el requerimiento

Condicin

108
Post- Que cambia en el sistema de manera posterior al ser realizado el requerimiento
Condicin

Descripcin del requerimiento

Describa de manera detallada el requerimiento(Debe cumplir los criterios de calidad establecidos en la fase de
anlisis)

Fuentes del requerimiento

Describa en que documentos (2E-001) se encuentra la informacin que ha llevado a generar el presente
requerimiento

Funcional.
Cdigo del Identificador nico del requerimiento Tipo
requerimiento requerimiento No
funcional.

Alta

Nombre Nombre que describe el requerimiento Prioridad Media

Baja

Entradas y Describir las entradas y salidas requeridas para el requerimiento

salidas

Pre- Que se debe cumplir antes de ser invocar el requerimiento

Condicin

Post- Que cambia en el sistema de manera posterior al ser realizado el requerimiento

Condicin

Descripcin del requerimiento

Describa de manera detallada el requerimiento(Debe cumplir los criterios de calidad establecidos en la fase de
anlisis)

Fuentes del requerimiento

109
Describa en que documentos (2E-001) se encuentra la informacin que ha llevado a generar el presente
requerimiento

Replique esta seccin cuantas veces sea necesaria

Acuerdo legal

Entre las partes acordamos haber ledo el documento y comprendemos las acciones que se
realizaran y se procede a la firma el da del mes de del ao

Cliente Representante empresa

Nombre: Nombre:

Firma. Firma.
C.C C.C

110
 Formato 0 - Matriz de Fecha creacin/actualizacin matriz dd/mm/aaaa
Rastreo
Matriz de rastreo
Nombre
(Persona encargada de diligenciar Matriz)

Instructivo:

Cada valor R1, R2,, Rn representa un requerimiento (Obtenido de la lista de requerimientos), es necesario escribir el cdigo
del requerimiento al cual se hace referencia. Ejemplo R1: Req001, R2:Req002.
Es necesario analizar cada dupla (fila x columna) segn los criterios de Dependencia y Relacin dbil:
Dependencia: Si el requerimiento de la fila depende del requerimiento ubicado sealado en la columna se deber Resaltar la
casilla con la letra D. Ejemplo: Si R1 depende de R6 resaltarse la casilla con la letra D (celda resaltada en la tabla).
Relacion debil: Si los requerimientos analizados tienen algn tipo de relacin dbil, la cual no genera dependencia, se deber
resaltar la casilla R.

Requerimientos R1:CodReq R2: CodReq R3: CodReq R4: CodReq R5: CodReq R6: CodReq Rn: CodReq
R1: CodReq R D R D R D R D R D R D R D R D

R2: CodReq R D R D R D R D R D R D R D R D

R3: CodReq R D R D R D R D R D R D R D R D

R4: CodReq R D R D R D R D R D R D R D R D

R5: CodReq R D R D R D R D R D R D R D R D

R D R D R D R D R D R D R D R D

Rn: CodReq R D R D R D R D R D R D R D R D

111
 Formato 1P-001 Versin X.X Fecha dd/mm/aaaa

ACUERDOS DE NIVEL DE SERVICIO

TABLA DE CONTENIDO

1. OBJETIVO
2. ALCANCE
3. DEFINICIONES
4. DESCRIPCIN DE LOS ACUERDOS DE NIVEL DE SERVICIO

1. OBJETIVO
Este documento describe los Acuerdos de Nivel de Servicio (ANS) para llevar a cabo el
proceso de ingeniera de requerimientos, estos acuerdos garantizaran un cumplimiento de
los compromisos adquiridos por las partes involucradas.

2. ALCANCE
Aplica a todas las actividades y compromisos descritos en este documento, las cuales en
gran parte las entradas del proceso de Ingeniera de requerimientos. Las salidas sern el
resultado de este proceso, por lo cual se hace estrictamente necesario el cumplimiento de
estos acuerdos de servicio.

3. DEFINICIONES
Acuerdo de niveles de servicio: un Acuerdo de Niveles de Servicio (ANS) es un convenio
formal celebrado entre dos partes con el fin de establecer las caractersticas de un servicio;
as como las responsabilidades y las prioridades de las partes.
IT: Tecnologa de la Informacin
Requerimiento: Caracterstica que se desea, posea un sistema o un software, el cual se
programa con anterioridad y no afecta la operacin normal del servicio.

112
4. DESCRIPCIN DE LOS ACUERDOS DE NIVEL DE SERVICIO

Servicio Compromiso Contacto personas Penalidad por incumplimiento

involucradas en el acuerdo

Cumplimiento de citas 99.6% de cumplimiento en Ingeniero requerimientos En caso de que la parte involucrada
programadas por cada una las citas programadas, en caso proveedor: por parte del cliente no logre cumplir
de las partes involucradas de requerir cambiar hora y con el 99.6% de cumplimiento en las
fecha de la cita es necesario citas programadas, deber agregar
que la parte solicitante del como penalidad en la factura del
cambio realice la solicitud via periodo en curso el valor de 1 salario
correo electrnico con por lo Ing. XXX mnimo.
menos 72 horas de
anticipacin frente a la fecha Cel: ###
y hora de la cita actual, la En caso de que la parte involucrada
contraparte deber responder mail: [email protected]
por parte del proveedor no logre
dicha solicitud por lo menos cumplir con el 99.6% de
24 horas antes de la hora y cumplimiento en las citas
fecha de la cita actual. Stakeholder Cliente: programadas, deber descontar como
penalidad en la factura del periodo
en curso el valor de 1 salario
Ing. XXX mnimo.

Cel: ###

mail: [email protected]

Calidad y nivel mnimo de

detalle de la informacin
suministrada por
stakeholders del lado del

113
cliente

Nivel mnimo de
conocimiento previo del
modelo de negocio o acerca
de los temas a tratar en
reunin por cada una de las
partes involucradas

Disponibilidad para la
resolucin de dudas
resultantes luego de tratar el
tema de la reunin por cada
una de las partes
involucradas

Nivel mnimo de
aceptacin, por parte de las
partes involucradas, del
proceso realizado

Definicin de accin a
realizar en caso de que no
se haya cumplido con los
niveles mnimos

Definicin de accin a
realizar en caso de que no
se haya cumplido con los
niveles mnimos de
aceptacin del proceso
realizado

114
FIRMA GERENTE PROVEEDOR: FIRMA SPONSOR DEL PROYECTO:

XXXX XXXX

115
 Formato 2E-001 Fecha aplicacin tcnica dd/mm/aaaa
INFORME RESULTADOS APLICACIN TCNICA ELICITACIN
Tipo de Idea de negocio Clasificacin del proyecto Nivel 1.
proyecto Desarrollo a la medida (solo para desarrollos a la medida) Nivel 2.
Nivel 3.
Nivel 4.
Nivel 5

Responsable
aplicacin
Tcnica
aplicada
Existe Si En caso que
evidencia de No existan describa
los resultados el lugar donde se
(Documentos, pueden
audios, videos, encontrar estas
etc)
Nombre de los
stakeholders a
los cuales se les
aplico la
tcnica
Descripcin de resultados
Describa de manera completa los resultados obtenidos al aplicar dicha tcnica

116
 Formato 2E-002 Fecha realizacin dd/mm/aaaa
MAPA DE STACKEHOLDERS
Nombre
(Persona encargada de diligenciar el documento)

Alto Stakeholders a mantener satisfecho: Stakeholders que se deben administrar de cerca:

Stakeholders 1. Stakeholders 1.
Stakeholders 2. Stakeholders 2.
. .
Stakeholders n. Stakeholders n.

Stakeholders que se deben monitorear: Stakeholders que se deben mantener informado:

Poder

Stakeholders 1. Stakeholders 1.
Stakeholders 2. Stakeholders 2.
. .
Bajo Stakeholders n. Stakeholders n.

Alto Bajo

Inters

117
Formato 2E-003 Fecha aplicacin tcnica dd/mm/aaaa

GUIA IDENTIFICACION DE REQUERIMIENTOS [107]

Nombre
(Persona encargada de diligenciar
la gua)

Preguntas generales.
Responder de manera breve e indicar en cuales de los formatos 2E-001 se puede encontrar ms informacin
de cada pregunta.

1 Cul es el proceso
bsico de la empresa?

Referencias
2E-001

2 Qu datos utiliza o
produce este proceso?

Referencias
2E-001

3 Cules son los lmites

impuestos por el
tiempo? Cul es el
tiempo mximo de
respuesta esperado de
cada uno de los Referencias
procesos identificados 2E-001
en el punto anterior?

118
4 Cul es el volumen de
trabajo estimado que
reciben cada uno de los
procesos identificados
en el punto anterior?
Referencias
2E-001

5 Quines emplean la
informacin resultante?

Referencias
2E-001

Cuntos empleados
laboran para la
organizacin en el rea
(s) que se pretende
desarrollar el sistema; o
sea, cuntos tienen
relacin directa con el Referencias
proyecto? 2E-001

Cules son las

personas claves en el
sistema? Por qu son
importantes?
Referencias
2E-001

Existen obstculos o
influencias de tipo
poltico que afectan la
eficiencia del sistema?
Referencias
2E-001

Existen manuales de
procedimientos,
polticas o lineamientos
de desempeo
documentados oficial o
no oficialmente? Si los
hay, Se cumplen en
forma cabal en el 100%

119
de las ocasiones?, es Referencias
decir, se respetan 2E-001
dichos procedimientos?

Existen mtodos para

evadir el sistema?, Por
qu se presentan?

Referencias
2E-001

Qu reas necesitan un
control especfico?

Referencias
2E-001

Qu criterios se
emplean para medir y
evaluar el desempeo?
Referencias
2E-001

120
Formato 3A-001 Fecha aplicacin tcnica dd/mm/aaaa
CHECKLIST DE REQUERIMIENTO [67]
Nombre
(Persona encargada de
diligenciar checkList)

Duplicar esta seccin las veces que sea necesaria por cada uno de los requerimientos
Nombre requerimiento
Cdigo y nombre del
requerimiento
Independencia del diseo
1 La lista de requisitos anticipa el diseo o incluye informacin Valor
de
Implementacin? 1 2 3 4 5

Concisin
1 Cada requisito es simple o, por el contrario, podra dividirse en Valor
varios
Requisitos? 1 2 3 4 5

2 Existe algn requisito que no parezca aadir ninguna Valor

informacin til acerca del sistema a desarrollar?
1 2 3 4 5

Realizabilidad
1 Es realizable el requisito en la plataforma de implementacin? Valor
1 2 3 4 5

2 Existe algn requisito irrealizable con la tecnologa actual? Valor

1 2 3 4 5

3 Es realizable el requisito en el presupuesto acordado con el Valor

cliente?
1 2 3 4 5

4 Es realizable el requisito en los tiempos esperados de entrega Valor

por parte del cliente?
1 2 3 4 5

Completitud
1 Es claro y describe la funcionalidad completa que debe cumplir Valor
el requerimiento?
1 2 3 4 5

Correctitud
1 Existe algn requisito que contradiga requisitos organizativos Valor
explcitamente formulados?

121
 1 2 3 4 5

Necesario
1 El no realizar el requerimiento perjudica algn proceso de la Valor
organizacin o del sistema?
1 2 3 4 5

Ambigedad
1 Es posible interpretar de varias formas un requisito? Valor
1 2 3 4 5

Verificable
1 Es posible idear algn caso de prueba que permita establecer Valor
que el requisito NO SE CUMPLE?
1 2 3 4 5

Independencia de diseo
1 La lista de requisitos anticipa el diseo o incluye informacin Valor
de implementacin?
1 2 3 4 5

Nota: Las escala con valor de 0 a 5 es una escala subjetiva en la cual el evaluador deber
dar una dar una nota exacta segn su criterio, los valores iguales o inferiores a tres debern
ser revisados y ajustados antes de pasar a la siguiente fase y de ser necesario volver aplicar
este checklist.

122
 Formato 3A-002 Fecha aplicacin tcnica dd/mm/aaaa
Matriz de interaccin [67]
Nombre
(Persona encargada de diligenciar Matriz)

Instructivo:

Cada valor R1, R2,, Rn representa un requerimiento (Obtenido de la lista de requerimientos), es necesario escribir el cdigo
del requerimiento al cual se hace referencia. Ejemplo R1: Req001, R2:Req002.
Es necesario analizar cada dupla (fila x columna) segn los criterios de Repitencia y Conflicto:
Repitencia: Si los requerimientos analizados trata aspectos iguales se deber Resaltar la casilla con la letra R. Ejemplo: Si
R1 y R6 son requerimientos relacionados con la generacin de facturas deber resaltarse la casilla.
Conflicto: Si los requerimientos analizados trata aspectos los cuales ambos entran en contradiccin se deber resaltar la casilla
C Ejemplo: Si R1 y R6 son requerimientos relacionados con la generacin de pedidos y R1 menciona que los pedidos son
generados envos todos los das a las 8am y R6 que los pedidos deben enviarse al instante deber marcarse con la letra

Requerimientos R1:CodReq R2: CodReq R3: CodReq R4: CodReq R5: CodReq R6: CodReq Rn: CodReq
R1: CodReq R C R C R C R C R C R C R C R C

R2: CodReq R C R C R C R C R C R C R C R C

R3: CodReq R C R C R C R C R C R C R C R C

R4: CodReq R C R C R C R C R C R C R C R C

R5: CodReq R C R C R C R C R C R C R C R C

R C R C R C R C R C R C R C R C

Rn: CodReq R C R C R C R C R C R C R C R C

123
 Formato 3A-003 Fecha aplicacin tcnica dd/mm/aaaa
Descomposicin jerrquica
Nombre
(Persona encargada de
diligenciar Matriz)
Requerimientos transversales del sistema.
Indique los requerimientos que son transversales al sistema y por ende afectan ms de un modulo
Requerimientos por mdulos
Modulo Cdigo Nombre requerimiento
Requerimiento
Nombre del modulo

Nombre del modulo

124
 Formato 4E-001 NUMERO #
HISTORIA DE USUARIO [108]
Nombre de la
historia
(Nombre breve que
describa la funcionalidad)
Prioridad en negocio Riesgo en desarrollo
(Alta/Media/Baja) (Alta/Media/Baja)
Prioridad en Puntos estimados
desarrollo (Describa un valor
(Alta/Media/Baja) numrico para estimar el
costo de la historia )
Descripcin

Validacin

125
 Formato 5V- Fecha aplicacin validacin dd/mm/aaaa
001
CHECKLIST DE VALIDACIN DE PROTOTIPOS
Cdigo del prototipo a
evaluar
Nombre evaluador
(Persona encargada de diligenciar
checkList)
Stakeholders que realizan
la actividad
(Nombres de stakeholders que
hacen parte de la actividad de
evaluacin)
LISTA DE TAREAS A EVALUAR
Descripcin tarea Realizada Nivel de dificultad Observaciones
al ejecutar la tarea
S Valor
No 1 2 3 4 5

S Valor
No 1 2 3 4 5

S Valor
No 1 2 3 4 5

S Valor
No 1 2 3 4 5

S Valor
No 1 2 3 4 5

126
 Formato 5V- Fecha aplicacin inspeccin dd/mm/aaaa
002
INSPECCIN INTERNA SRS (SOFTWARE REQUIREMENTS
SPECIFICATION)
rea que realiza revisin:
Nombre revisor:
(Persona encargada de realizar la
inspeccin)
OBSERVACIONES
Id Cdigo Descripcin del error Nivel
erro requerimient
r o
Mayor
Menor
Mayor
Menor
Mayor
Menor
Mayor
Menor
Mayor
Menor
Mayor
Menor
Mayor
Menor
Mayor
Menor
Mayor
Menor
Mayor
Menor

127
 Formato 5V- Fecha revisin resultados dd/mm/aaaa
003 inspeccin
REVISIN RESULTADOS INSPECCIN INTERNA SRS - SOFTWARE
REQUIREMENTS SPECIFICATION
rea que realiza revisin:
Nombre revisor:
(Persona encargada de realizar la
inspeccin)
SOLUCIN DE LAS OBSERVACIONES
Id Estado Comentario
erro (Solucionado,
r Aclarado, Validar
con stakeholders)

128
Formato 5V-004 Fecha aplicacin dd/mm/aaaa Hora Hora fin
validacin inicio
requerimientos
FORMATO DE OBSERVACIONES SESION DE VALIDACIN DE REQUERIMIENTOS
Nombre analista de requerimientos:
Nombre anotador:
Nombres de stakeholders que asisten a la sesin de
validacin:

OBSERVACIONES
Id error Cdigo Descripcin del error/conflicto Acciones sugeridas Nombre stakeholder que
requerimient reporta error
o

129
 Formato 5V-005 Fecha aplicacin formato dd/mm/aaaa
FORMATO DE RECOLECCIN OBJETIVOS STAKEHOLDER PROCESO NEGOCIACIN
Nombre
stakeholder:
Id error Cdigo Objetivos del stakeholder sobre el Objetivos Observaciones/soluciones planteadas
registrado requerimiento requerimiento viables proveedor
formato 5V-
004
S No

S No

S No

S No

130
Formato 5V-006 Fecha aplicacin dd/mm/aaaa Hora Hora fin
negociacin inicio
requerimientos
FORMATO RESULTADOS SESION DE NEGOCIACIN DE REQUERIMIENTOS
Nombre analista de requerimientos:
Nombre anotador:
Nombres de stakeholders que asisten a la sesin de
negociacin:

OBSERVACIONES
Id error Cdigo Solucionado Solucin/observacin
registrado requerimient
formato 5V- o
004
S No

S No

S No

S No

131
Formato 5V-007 Fecha acta reunin dd/mm/aaaa
ACTA DE REUNIN VALIDACIN Y NEGOCIACIN DE
REQUERIMIENTOS
<<Nombre proyecto>>
Por medio de la presente se deja evidencia de la ejecucin del proceso de negociacin de
requerimientos asociado al proyecto (nombre_proyecto) . Realizada el da
del mes de del ao , iniciando a las :__ y terminando a las : .
Los stakeholders firmantes del presente documento se comprometen a suministrar la
informacin necesaria que sea requerida por parte del proveedor, con el fin de apoyar el
proceso a ejecutar para realizar los ajustes respectivos al documento de especificacin de
requisitos.
Se fija una prxima reunin para realizar un nuevo proceso de validacin/negociacin de
requisitos para el da del mes de del ao , a las :__.

Atentamente,

Asistentes proceso de negociacin de requerimientos

Nombre asistente Firma Cargo - rea

132
Formato 5V-008 Fecha aceptacin acuerdo: dd/mm/aaaa

Acta de aceptacin del documento de especificacin de requisitos

Nombre del proyecto:

Nombre del cliente o sponsor:

Nombre gerente proyectos proveedor:

Declaracin de la aceptacin formal

Los abajo firmantes acordamos que el documento de especificacin de requisitos representa nuestro
conocimiento actual de los requisitos del proyecto al da de hoy. Los futuros cambios de este documento
se realizarn de acuerdo al procedimiento de cambio definido para el proyecto. Entendemos que los
cambios aprobados podrn requerir que se renegocien los acuerdos actuales sobre costes, recursos
asignados y fecha de entrega del proyecto.

Nombre stakeholder Firma Cargo rea

involucrado en proceso de
validacin

Observaciones adicionales

Aceptado por:

Firma cliente o
sponsor:
Firma gerente de
proyecto proveedor:

133
Formato 6C-001 Fecha peticin cambio: dd/mm/aaaa

Origen de la solicitud
Nombre de quien realiza la solicitud rea Cargo

Naturaleza de la solicitud de cambio (marque con una X)

Cambio en los Procesos operativos Proceso de gestin Procesos
requerimientos del proyecto contables/financiero

Otros Especifique

Descripcin del Cambio propuesto (Incluya referencias a documentos que contengan ms

detalles)

Justificacin del cambio

Impacto en el proyecto si el cambio no se implementa

Alternativas

Fecha lmite para decisin sobre el cambio dd/mm/aaaa

Impacto en el proyecto si la decisin sobre el cambio se dilata

Firma de quien hace la solicitud

134
Formato 6C-002 Fecha acta reunin dd/mm/aaaa
ACTA DE REUNIN RECHAZO/OBSERVACIONES PROPUESTA
DESARROLLO CAMBIOS SOLICITADOS
<<Nombre proyecto>>
Por medio de la presente se deja evidencia de la ejecucin del proceso de evaluacin de
la propuesta de desarrollo de los cambios solicitados, asociada al proyecto
(nombre_proyecto) . Realizada el da del mes de del ao
, iniciando a las : y terminando a las :__.
Los stakeholders firmantes del presente documento se comprometen a suministrar la
informacin necesaria que sea requerida por parte del proveedor, con el fin de ajustar la
propuesta de acuerdo a las observaciones realizadas.
Se fija una prxima reunin para realizar un nuevo proceso de evaluacin de la propuesta
para el da del mes de del ao , a las :__.

Atentamente,

OBSERVACIONES/MOTIVO RECHAZO

Asistentes proceso de evaluacin de la propuesta

Nombre asistente Firma Cargo - rea

135
Formato 6C-003 Fecha aceptacin propuesta: dd/mm/aaaa

Acta de aceptacin de la propuesta de desarrollo de cambios solicitados

Nombre del proyecto:

Nombre del cliente o sponsor:

Nombre gerente proyectos proveedor:

Declaracin de la aceptacin formal
Los abajo firmantes acordamos que la propuesta de desarrollo de cambios solicitados
representan nuestros intereses y necesidades de los cambios solicitados. Por lo tanto a
partir da del mes de del ao debe iniciar formalmente el proceso de
elicitacin de requerimientos de los cambios solicitados, con miras a incorporar dichos
cambios al sistema.

Nombre stakeholder Firma Cargo rea

involucrado en proceso de
validacin

Observaciones adicionales

Aceptado por:

Firma cliente o
sponsor:
Firma gerente de
proyecto proveedor:

136
 17.ANEXO 2: INFORME RESULTADOS FASE RECOLECCION

DE DATOS

17.1 Introduccin:
La ingeniera de requerimientos es una rea la cual se puede abordar desde
diferentes perspectivas, como lo son los mtodos que definen procesos para su
adquisicin y administracin, los lenguajes o meta-modelos que permiten realizar sus
especificacin, la innovacin que puede presentarse frente la ingeniera de
requerimientos, software existente para la administracin de los requerimientos, entre
otros ; La ingeniera de requisitos es en esencia la aplicacin de principios, mtodos
tcnicas y herramientas en pro de descubrir los requisitos de un producto de software, al
igual que permite el anlisis la documentacin de objetivos, funciones y restricciones de
dicho sistemas, sin embargo existe una falencia, no existe un acuerdo sobre lenguajes,
mtodos o herramientas para su ejecucin [2], ms aun como lo define Ackoff citado por
Antonelli & Oliveros Fallamos ms a menudo porque resolvemos el problema
incorrecto, que porque obtenemos una solucin deficiente del problema correcto [3],
por ende es necesario profundizar en la bsqueda de estrategias que permitan mejorar y
potenciar esta rea. Para la ingeniera de requerimientos es importante ocuparse de la
identificacin de objetivos para un sistema propuesto, la operacin y la conversin de estos
objetivos en los servicios y restricciones [4].
A su vez el mantenimiento del software sostiene el producto en todo su ciclo de vida (desde
el desarrollo hasta las operaciones). Las solicitudes de modificacin se registran y realiza
seguimiento, se determina el impacto de los cambios propuestos, tanto el cdigo y otros
artefactos de software se modifican, se lleva a cabo el proceso de pruebas, y una nueva
versin del producto de software se libera [5]. All es fundamental la trazabilidad de
requerimientos, la cual describe y sigue la vida de un requisito desde su origen, desarrollo,
especificacin, distribucin y uso [6].
El estudio realizado se enfoca en las pequeas empresas de desarrollo de software, ya que
la mayora de este tipo de empresas no posee un musculo econmico fuerte que les permita
implementar y mantener un modelo de calidad como lo es por ejemplo CMMI y por ende
sus procesos de la ingeniera de software no estn claramente definidos. Si nos centramos
en la situacin actual colombiana, es fcil denotar que las pequeas y medianas empresas
son el motor del pas. Segn un estudio del Centro de Investigaciones de la Escuela de
Finanzas y Comercio Exterior de la Universidad Sergio Arboleda, estas generan ms del
50% del empleo nacional, significan el 36% del valor agregado industrial, el 92% de los
establecimientos comerciales y el 40% de la produccin total del pas [26].
Del mismo modo durante el proceso para la creacin de una metodologa que permita
mejorar la obtencin de requerimientos funcionales y no funcionales en las pequeas
empresas de la regin de Risaralda, se opt por conocer la percepcin de las personas
relacionadas en esta rea tanto a nivel laboral como acadmico. Para lograr esta se
estructuraron dos herramientas las cuales fueron encuestas y entrevista, estas forman un

137
componente mixto en la investigacin en la cual se aportan tcnicas cualitativas y
cuantitativas [18]. Para este proceso se estructuraron tres perfiles (De los cuales se deseaba
evaluar su percepcin), los cuales son:
Sector pequeas empresas relacionadas con el desarrollo de software.
Docentes y directores de pregrados universitarios de ingeniera de sistemas.
Egresados de pregrados en ingeniera de sistemas.
Las temticas abordadas para los tres perfiles fueron: Stakeholders, priorizacin,
dependencias, trazabilidad, diseo centrado en usuario (UCD), restricciones,
documentacin, requerimientos funcionales, requerimientos no funcionales, meta-modelos
y tcnicas usadas para elicitacin.
A continuacin se relaciona las herramientas e intenciones para cada uno de los perfiles.

Herramientas
Perfil Intencionalidad.
aplicadas
Pequeas Entrevista Conocer el grado de madures de las empresas
empresas Encuesta desarrolladores de software segn los
empleados de estas.
Sector pregrados Encuesta Identificar como se encuentra estructurada las
universitarios temticas relacionadas con la ingeniera de
requerimientos y como se abordan estas en el
pensum acadmico.
Sector egresados Entrevista Conocer la percepcin de los egresados con
respecto a los conocimientos que fueron
adquiridos en sus pregrados en el rea de la
ingeniera de requerimientos.

Las herramientas mencionadas fueron creadas y aplicadas por los candidatos a magister en
Ingeniera de sistemas y computacin Cristian Andres De la cruz Londoo y Gustavo
Andres Castro Guevara, los cuales durante los meses de mayo a julio de 2014 enviaron y
aplicaron las diferentes herramientas a cada uno de los perfiles mencionados. Cada una de
las herramientas mencionadas se encuentra detallada en las secciones 17.6 y 17.7.
En el caso de las pequeas empresas y los programas de pregrado, se envi invitacin
formal, comunicando el objetivo de la investigacin e incentivndolos a participar en este
proceso. En el caso de las pequeas empresas se enviaron once invitaciones a empresas de
Pereira, que de manera posterior haban realizado procesos similares con el grupo de
investigacin GRANDE de la Universidad Tecnolgica de Pereira. De estas, nueve
empresas respondieron las invitaciones realizadas y se inici un proceso para acordar
fechas en los cuales se realizara la visita. En algunos casos era necesario realizar trmites
relacionados con acuerdos de confidencialidad, en los cuales las empresas aceptaban
participar, sin embargo sus nombres no sern divulgados en los resultados de la
investigacin. Al momento de realizar la visita, la empresa asignaba una persona a la cual
se realizaba la entrevista y a esta misma se solicitaba diligenciar la encuesta. En algunas
138
ocasiones las empresas dispusieron de ms de una persona para diligenciar estas encuestas,
la cual se poda realizar de manera fsica o en lnea a travs de un formulario virtual.
Por otro parte para el caso de las programas de pregrado se enviaron cinco invitaciones a
las principales universidades de Popayn, Manizales y Pereira, que ofertan el programa de
ingeniera de sistemas de manera presencial, de estas solo participo una, diligenciando el
formulario virtual.
Para el caso de los egresados se envi por correo electrnico la informacin y el enlace para
diligenciar la encuesta de manera virtual. De los cuarenta egresados convocados se obtuvo
respuesta de diez y seis egresados, estos correspondan a diferentes universidades de la
regin.

17.2 Ficha tcnica

Diseo muestra Muestra por convencin.
Poblacin objetivo Pequeas empresas de la regin de
Risaralda.
Egresados de programas en ingeniera de
sistemas.
Directores y docentes programas
acadmicos en ingeniera de sistemas.
Tcnica Encuesta con escala Likert.
Entrevista tipo mertenes
Tamao de la muestra 9 empresas de la regin de Pereira.
16 Egresados
1 Institucin universitaria.
Momento estadstico Mayo 2014 Julio 2014
Financiacin Recursos propios.

17.3 Revisin terica

La ingeniera de requisitos cada vez cobra mayor importancia tanto en la academia como en
la industria, la razn de esto es que cada vez se espera que existan ms funciones centradas
en el usuario, de mayor calidad y seguridad, por tanto es importante comprender las
situaciones que afectan dicha prctica [19], sin embargo un enfoque de trabajo limitado a
los aspectos meramente tcnicos no aseguran el xito del producto y por ende se hace
necesario conocer la forma en cmo se realiza la interaccin entre hombre-ordenador [20].
Por otra parte existen aspectos geogrficos en los cuales los equipos de software se
encuentran distribuidos de manera global y uno de los inconvenientes que puede afrontar la
industria es responde a la pregunta Qu tcnica de elicitacin de requisitos de software
se debera aplicar cuando el cliente y/o usuario se encuentra ubicado de manera remota?
[26]. A continuacin se describirn algunos referentes tericos relacionados con los
principales inconvenientes que se presentan en esta rea:
En gran nmero de casos las empresas a pesar de conocerse la importancia de la ingeniera
de requerimientos se optan por realizar de forma emprica esta actividad, como lo menciona
Toni Granollers La comunicacin con los usuarios es un aspecto prioritario para las
139
empresas que desarrollan sistemas software; aun as confan ms en la experiencia
acumulada que no en la aplicacin de mtodos pensados para capturar la experiencia de los
usuarios y sus verdaderas necesidades(), sin embargo se suele dar culpabilidad al
usuario por no describir correctamente sus necesidades, que cambian de pensamiento
fcilmente, que tienen diferentes puntos de vista o simplemente que stos no saben cmo
disear un producto interactivo. Lo que nunca piensan es que si hubieran aplicado
correctamente las tcnicas del anlisis de requisitos centradas en los usuarios se habran
ahorrado estos problemas y los usuarios estaran satisfechos [22], sin embargo pese a la
importacin de especificacin de requisitos y que esta es una tarea bien entendida an se
realiza seleccin de tcnicas de forma subjetiva, esto se debe a dos razones: 1. Los
conocimiento con respecto a la cantidad de tcnicas disponibles actualmente es limitado, lo
que quiere decir que an desconocen una gran cantidad de tcnicas, 2. La informacin de la
que disponen en relacin a las tcnicas es de tipo procedimental (es decir centrada en la
tcnica), siendo la informacin pragmtica(es decir centrada en cuando usar la tcnica) casi
inexistente [23].
Adems de estos se observa como las pequeas empresas manejan sus requerimientos de
forma que no pareciera guardar relacin con lo que se dice en los textos, y gran parte estas
parecieran no interesarles las investigaciones actuales que se realizan en esta rea [24]. Es
comn ver como en las pequeas empresas manejan la ingeniera de requisitos de forma
diferente, cada una de las empresas realiza la elicitacin y comunicacin de requerimientos
con diferente grado de planificacin, estructura y documentacin, y ellos consideran que
cada eleccin es natural, del mismo modo la diversidad en la prctica de los requerimientos
se da debido a la adaptacin a nichos de mercado de cada empresa [25].
Es de mencionar que la calidad del software depende de la calidad de los requisitos y esta a
su vez de las tcnicas utilizadas para elicitacin [25]. No obstante el desarrollo de software
es una actividad en el cual es necesaria la cooperacin y colaboracin de muchas personas.
Y como lo menciona Sergio zapata no solo se interviene aspectos tcnicos sino tambin
culturales, sociales, econmicos y psicolgicos. Estos aspectos llevan a que la
comunicacin entre los ingenieros de requisitos y los usuarios-clientes sea en algunas
ocasiones compleja y puede llevar a desacuerdos culturales, organizacionales, falta de
generacin de confianza mutua o capacidades para realizar resolucin de conflictos [21].
A pesar que la mayora de empresas aseguran uso de metodologa, esta no se realiza o
aplica de forma correcta, para el caso de las empresas de software de la ciudad de Cali
(Colombia) el 48.7% de la industria no se establecen criterios para la aceptacin de los
requerimientos, el 43.6% no realizan administracin de requerimientos [10], en la misma
lnea para el caso de Santiago de Chile(Chile) se observa cmo las empresas emergentes
no cuentan con el personal calificado, se cuenta con escasos recursos o no se encuentran
roles definidos en la organizacin [11], de manera similar en Nueva Zelanda se observa
como en la industria no hace uso de herramientas de soporte de la ingeniera de
requerimientos y al indagar por estas herramientas solo unas pocas asocian a Rational,
Trac, Together and door como herramientas que soportan la ingeniera de requerimientos.
A su vez los principales problemas que ellos identifican esta: Cambios en el alcance y
requerimientos, aceptacin del cliente para costos, tiempo y esfuerzo necesarios para la fase

140
de requisitos y calidad de las especificaciones [26]. Asimismo las tcnicas de entrevista y
encuesta suelen ser las ms usadas para realizar elicitacin [3].
Entre los principales tems relevantes alrededor de la ingeniera de requerimientos se tiene:
Alta frecuencia de revisin de cambios en requerimientos, aumento del nmero de
requerimientos, pocas capacidades de confirmar la trazabilidad y cambios en los
requerimientos [15], otro inconveniente es el uso de lenguajes naturales, lo cual genera
ambigedad entre los requerimientos o conflictos entre los interesados [8], adems la
insatisfaccin en el anlisis del software puede darse por los siguientes factores: 1. Fallas
no relacionados con tcnicas de elicitacin, 2. Fallas causado por la falta de efectividad en
las tcnicas de elicitacin, 3. Falta de disponibilidad los cual genera mal uso de tcnicas de
elicitacin [18]. Adems factores como el tipo de cliente, la experiencia y aptitudes de los
desarrolladores, las preferencias del fundador, el ambiente del negocio, la distribucin
espacial y geogrfica de las oficinas son factores que influyen en cmo cada compaa
obtiene los requerimientos [25]. Con respecto a las tcnicas usadas en elicitacin es de
mencionar que las entrevistas sirven para obtener una comprensin general de lo que hacen
los stakeholders, como podran interactuar con el sistema y las dificultades a las que se
enfrentan con los sistemas actuales. A la gente le gusta hablar sobre su trabajo y
normalmente se alegran de verse implicados en las entrevistas. Sin embargo, no son de
tanta utilidad para la compresin de los requerimientos del dominio de la aplicacin [28].
Del mismo modo en la fase de especificacin de requerimientos es posible que se
presenten muchos inconvenientes entre estos estn: Los requerimientos no son obvios y
viene de muchas fuentes, son difciles de expresar en palabras (Se genera ambigedad), la
cantidad de requerimientos se puede tornar difcil, los requerimientos pueden cambiar a lo
largo de ciclo de vida, los usuarios no pueden explicar lo que hacen, se recuerda lo
excepcin pero se olvida lo rutinario, se habla de lo que no funciona, existe un vocabulario
distinto entre usuarios y desarrolladores, se hace uso de los mismos trminos para
diferentes significados, el nivel de detalle es vago, algunos requerimientos son ms
importantes (o estables) que otros, existe relacin entre los requerimientos y por ultimo
cada uno tiene funcionalidades nicas y abarcan reas funcionales especficas [29] [30].
Otros mencionan que las metodologas han sido concebidas para sistemas alfanumricos, en
donde no existen atributos espaciales, y que al existir stakeholders heterogneos y
complejidad de la informacin se generan inconvenientes al momento de aplicar ingeniera
de requerimientos [31].
Otros aspectos complejos relacionados con la elicitacin se presentan ya que las fronteras
del sistema no se encuentran bien definidas, los detalles tcnicos pueden confundir (ms
que aclarar), problemas de comprensin por parte del cliente, donde ellos no estn
totalmente seguros de lo que necesitan o tiene dificultades para comunicar sus necesidades
[32].

17.4 Anlisis de resultados en las empresas

17.4.1 Anlisis general de las empresas y los encuestados

Primero se analizara la informacin de las empresas, en la cual se cont con la participacin
de nueve pequeas empresas de la ciudad de Pereira, todas estas empresas desarrolladoras

141
de software, sin embargo el tipo de aplicaciones, productos, clientes y nichos de mercado
de cada una de estas son diferente.
Con respecto al nmero de empleados se menciona que para el momento de la visita la
empresa ms pequea contaba con 3 empleados y en caso contrario 40 empleados
aproximadamente para la empresa de mayor tamao. En total fueron dieciocho personas de
las empresas los cuales participaron en esta, siendo la empresa 8 con mayor participacin
(27,8% de los encuestados), el grafico 1 representa la distribucin de las empresas por
nmero de empleados.

Grfico 1, empresas participantes

142
En cuanto al rol que desempeaban dentro de la organizacin es de mencionar que la
mayora de encuestas fueron realizadas a desarrolladores de software con un 55,6%, los
cuales representan que ms de la mitad de las respuestas a esta encuesta fueron dadas por
un nico rol, el grafico 2 representa la distribucin de los roles de las personas encuestadas.

Grfico 2, roles de encuestados

17.4.2 Anlisis de fiabilidad.

Al realizar anlisis de correlacin interna entre los tems se identifica que existe un grado
de fiabilidad de los datos, esto se puede constatar al aplicar un estadstico de fiabilidad en el
cual se observa que el alfa de cronbach () es de 0,863, el cual se encuentra en un valor
cercano a uno y tal como lo menciona Hernndez, Fernndez y Baptista en su libro
Metodologa de la investigacin el valor uno representa el nivel mximo de confiabilidad
total. Para nuestro caso al obtener un valor aproximado al 0.87 es posible afirmar que se
tiene una confiabilidad aceptable [18].

17.4.3 Anlisis proceso ingeniera de requerimientos general de las empresas.

En primer lugar se pregunt por el nivel de aceptacin con respecto a que tan claro y
efectivo es el proceso para realizar captura de informacin ante los clientes, en el cual el

143
57,1% los encuestados manifiestas que se encuentran algo de acuerdo, en contraposicin el
grado de desacuerdo es de tan solo el 7,1% (Grafico 3).
Al contrastar esta respuesta con la entrevista realizada, en donde se indagaba por el
proceso que ellos perciben como ms crtico en la ingeniera del software ellos identifican a
la ingeniera de requerimientos como la etapa ms crtica en el desarrollo de software. Los
entrevistados mencionan que es muy comn que los clientes desconocen sus necesidades
relacionadas con lo el producto de software que solicitan y las caractersticas que este
debera tener, es por esto que los entrevistados manifiestan que es complejo interpretar las
necesidades de los clientes.
Del mismo modo se menciona que nos solo el cliente debe conocer del tema a solucionar,
ya que debe existir un grado de conocimiento del problema por parte de las personas que
realizan el proceso de elicitacin ante el/los clientes. Por otro lado los entrevistados
mencionan que hacen uso de plantillas pre-construidas que ellos han realizado para aplicar
en procesos de elicitacin ante los clientes.
Por el contrario los entrevistados manifiestan que es necesario realizar mejoras en los
procesos relacionados con la estimacin de tiempo, etapa que se da posterior a realizar la
ingeniera de requerimientos.

Grafico 3, percepcin de las empresas en su proceso de ingeniera de requerimientos

Con respecto a la identificacin de stakeholders se nota un que ms del 57% de los

encuestados se encuentran de acuerdo en la forma como las empresas identifican al grupo
de personas involucradas en los proyectos (grafico 4). De forma semejante al contrastar

144
estos datos con la entrevista se observa que la forma que ms se destaca para identificar los
stakeholders en cada proyecto son:
1. Elegir una persona dentro de la compaa para definir los usuarios, por lo general el
gerente o la persona que paga por el desarrollo.
2. Definirlos segn el organigrama de la compaa.
3. Identificar los usuarios finales.

Grfico 3, identificacin de stakeholders.

Por otro lado, segn los encuestados al 35,7% les es indiferente realizar clasificacin de
stakeholders en los proyectos. Sin embargo si se suma el grupo de encuestados que se
encuentran algo de acuerdo y los que se encuentran totalmente de acuerdo se obtiene que el
50% se encuentran en acuerdo con la clasificacin que realizan las empresas de los
stakeholders (Grafico 5). En particular se observa que en las entrevistas ellos mencionaban
que en el caso de existir conflictos entre requerimientos no se hace uso de grupos de
stakeholders y por lo general esta decisin es tomada por la persona que tiene ms poder de
decisin por parte del cliente, que a la vez es relacionada con la persona que paga el
desarrollo.
Como lo menciona Mate Despus de obtener los requerimientos de los stakeholders,
deben ser analizados en el contexto de requerimientos de negocio (perspectiva de gestin)
la rentabilidad como tal, la organizacin y los requisitos polticos. Adems, las relaciones

145
entre requerimientos, es decir, dependencias, conflictos, superposiciones, omisiones e
inconsistencias deben ser examinados y documentados [109].

Grfico 4, clasificacin de stakeholders.

As mismo, al observar el grafico 6 se evidencia la existencia de una relacin entre la

identificacin y clasificacin de los stakeholders por cada una de las empresas

146
 Grfico 5, identificacin vs clasificacin stakeholders

En la misma lnea, al preguntar por las personas encargadas de realizar el proceso de

elicitacin al interior de la compaa se encuentra que el 64,3% de los encuestados se
encuentran totalmente de acuerdo en cuanto a las personas que realizan estas acciones
dentro de la organizacin (Grafico 7).

147
 Grfico 6, personas encargadas de requerimientos en la organizacin

Al preguntar a los encuestados con respecto al uso de tcnicas que permitan definir diseos
centrados en el usuario se observa que ms del 50% se encuentran de acuerdo en relacin a
la creacin de software el cual se enfoca a generar aplicaciones de fcil uso para los
usuarios (Grafico 8).

Grfico 7, uso de diseo centrado en el usuario.

148
Por otra parte al indagar por las restricciones que debe cumplir el software ms del 35,7%
de los encuestados est de acuerdo con que se define de manera correcta las limitantes con
las cuales debe este. Adems si se suma los encuestados que se encuentran algo de acuerdo
y totalmente de acuerdo se observa que corresponde al 64,3% por ende ms de la mitad de
estos se encuentran de acuerdo con la forma en cmo se definen las restricciones en las
organizaciones (Grafico 9).

Grfico 8, restricciones del sistema

Otro punto que se solicito fue la construccin de un documento donde se defina de manera
clara los requerimientos posteriores a ser obtenidos, en esta los encuestados manifestaron
estar en un alto grado de acuerdo con la construccin de estos documentos al interior de
cada compaa y al sumar las respuesta que se encuentran algo de acuerdo y totalmente de
acuerdo se obtiene un 85.7% de resultados positivos (Grafico 10).

149
 Grfico 9, documento alcance proyecto.

Acto seguido, se indago por el proceso de validacin ante el cliente, en donde se observa
que la mayora de encuestados se encuentran totalmente de acuerdo con el proceso de
validacin de requerimientos, ms aun, al sumar los encuestados que se encuentran algo de
acuerdo y los que estn totalmente de acuerdo se obtiene un 92,9% lo que muestra un alto
grado de confianza con respecto a la validacin que se realiza de los requerimientos con los
clientes (Grafico 11).

150
 Grfico 10, validacin de requerimientos con cliente

Con respecto a las tcnicas que se aplican en los procesos de ingeniera de requerimientos,
los encuestados mencionan con un 57, 1% que las tcnicas que aplican para el proceso de
ingeniera de requerimientos deben cambiar segn el tipo de proyecto, sin embargo esta es
una de las pregunta donde ms se marca la polaridad de las respuesta ya que se encuentran
opiniones divididas entre las empresas (Grafico 12).

151
 Grfico 11, cambio de tcnicas segn el tipo de proyecto

Por otro lado ms del 42,9% de los encuestados se encuentran de acuerdo con respecto a la
priorizacin que se deber realizar en cada iteracin. Al sumar las respuestas de los
encuestados que se encuentran algo de acuerdo y totalmente de acuerdo se obtiene un
85,8% de aceptacin (Grafico 13). Al confrontar esta informacin con las entrevistas se
observa que los mtodos para realizar priorizacin que las empresas realizan son las
siguientes
1. Segn criterio y decisin del cliente.
2. Construccin de mdulos que lleven de manera rpida versiones de un producto
funcional.
3. Construcciones de mdulos que permitan al cliente obtener un retorno a la inversin
(ROI) de manera rpida.
La priorizacin temprana indica qu partes del negocio se deben investigar primero, y que
se puede ignorar sin problemas hasta ms tarde, o en algunos casos, abandonar. Adems, se
utiliza una priorizacin inicial para guiar sus iteraciones y la planificacin de la versin
[110].
Ahora bien, entre los entrevistados se menciona el uso de la matriz de trazabilidad como
herramienta usada para realizar trazabilidad y verificacin de dependencias de
requerimientos ante el cliente.

152
 Grfico 12, Priorizacin de requerimientos

Ahora bien, para los encuestados es claro definir cules son los requerimientos no
funcionales (atributos de calidad) que debe cumplir el sistema y que estos se deben definir
de forma clara. Por ende el 57% de los encuestados se encuentra algo de acuerdo en que
para las empresas es clavo definir de forma clara los atributos de calidad que debe cumplir
el sistema (Grafico 14). Adems segn las entrevistas realizas estos son obtenidos en las
primeras etapas del proceso de ingeniera del software, en algunos casos las etapas de
anlisis y diseo es en donde ms se identifican estos.

153
Grfico 13, definicin de requerimientos no funcionales.

154
Por otra parte los encuestados manifiestan que en un 35,7% existe un total acuerdo con
respecto a la definicin de las dependencias y su respectivo anlisis de impacto entre los
requerimientos funcionales y no funcionales, incluso al sumar el grupo de encuestados que
se encuentran algo de acuerdo y total de acuerdo se obtiene un 64,3% de encuestados que
se encuentran de acuerdo frente a este tem(Grafico 15).
De modo similar segn las entrevistas realizas en las empresas los mtodos comnmente
usados para analizar y verificar dependencias son:
1. Realizar revisin de todos los requerimientos y verificar cuales de estos se cruzan.
2. Usar formatos que permitan identificar ambigedades en los requerimientos.
3. Usar la matriz de trazabilidad.

Grfico 14, Dependencia y anlisis de impacto

En la misma lnea de definicin de alcances y documento de requerimientos se encuentra

que los encuestados se encuentran en un 50% totalmente de acuerdo en el documento de
especificacin de requerimientos (SRS software requirement specification) que realizan las
empresas. Adems los encuestados que estn algo de acuerdo y totalmente de acuerdo
representan el 85,7% de las respuestas, donde se nota una alta aprobacin con respecto a los
documentos SRS que se construye en cada empresa (Grafico 16).

155
 Grfico 15, creacin de SRS en el proyecto

As mismo al observar el grafico 17 se evidencia que existe una relacin entre la definicin
del alcance del proyecto y los documentos de especificacin de requerimientos (SRS),
segn el grafico la mayora de las empresas dan un importancia similar a la definicin del
alcance como a la construccin del documento de especificacin de requerimientos en el
cual por lo general se incluye el alcance, stakeholders, definicin y descripcin de cada uno
de los requerimientos.

156
 Grfico 16, Definicin del alcance vs construccin de SRS

Con respecto a la trazabilidad y gestin de cambios que realizan de los requerimientos

durante el transcurso del proyecto el 50% de los encuestados se encuentran totalmente de
acuerdo, adems los encuestados que se encuentran algo de acuerdo y totalmente de
acuerdo representan el 71,4% de modo contrario ninguno de los encuestados manifiesta
algn grado en desacuerdo (Grafico 18). Tambin al observar las respuestas de los
entrevistados con respecto a l como realizan gestin y trazabilidad se encuentra que los
mtodos ms usados son:
1. Matriz de trazabilidad.
2. Formatos para gestin de cambios

157
 Grfico 17, trazabilidad de los requerimientos

Ms aun en el grafico 19 se observa una relacin directa en todas las empresas entre el
proceso de analizar las dependencias de los requerimientos e identificar una trazabilidad de
cada uno de estos.

158
 Grfico 18, dependencias anlisis de impacto vs trazabilidad gestin de cambios

Otro punto de analizar es relacionado con las metodologas usadas para el desarrollo de
software en donde ms del 35.7% se encuentran de acuerdo en que el proceso interno de
las compaas son de forma incremental e iterativa, de igual manera los encuestados que se
encuentran totalmente de acuerdo son el 21.4% por ende ms de la mitad de las respuestas
muestran que el desarrollo en la regin corresponde a procesos incrementales e iterativos
(Grafico 20). A su vez los entrevistados manifiestan que hacen uso de las tcnicas
personales y de equipo como TSP y PSP y metodologas agiles como SCRUM y RUP.

159
 Grfico 19, proceso iterativo ingeniera

Adems como se observa en el grafico 21 para cinco de las nueve empresas encuestadas
existe una relacin entre el proceso de realizar priorizacin y seleccionar en cada iteracin
los requerimientos a implementar.

160
 Grfico 20, Priorizacin vs metodologas incrementales e iterativas.

A su vez los encuestados manifiestan que ms del 35,7% de las empresas est algo acuerdo
con el uso de meta-modelos para especificar los requerimientos del sistema, del mismo
modo si se toman estos con los que se encuentran totalmente de acuerdo se tiene un 64,3%
de encuestados que manifiestan el uso de meta modelos para especificar los requerimientos
(Grafico 22).

161
 Grfico 21, uso de meta-modelos

17.4.4 Anlisis del uso de tcnicas en ingeniera de requerimientos en las empresas

En cuanto el uso de las tcnicas se ha divido en una segunda parte, la cual consta de un
anlisis de las tcnicas que usan las empresas para el proceso de elicitacin de
requerimientos, en esta se observa que la tcnica ms usada por las empresas es la
entrevista y el prototipado. Caso contrario se observa con las tcnicas de etnografa, card
sorting, introspeccin, anlisis de dominio y anlisis de tareas las cuales son muy poco
usadas.

162
 Tecnicas de elicitacion usadas por las empresas
Prototipado 7,70 30,7 23,1 38,5
Observacion directa 0 23,08 30,77 30,77 15,38
Etnografia 69,2 23,1 07,7
Grupos de trabajo 15,4 7,7 38,4 15,4 23,1
Muy poco usada
Card sorting 76,9 0 15,4 7,7
Poco usada
Lluvia de ideas
23,1 7,7 30,7 7,7 30,8 Usada algunas veces
Intraspeccion 46,1 23,1 0 15,4 15,4
Usada de manera frecuente
Analisis de dominio 38,5 15,4 30,7 15,4 0 Muy usada
Analisis de tareas 46,1 23,1 15,4 0 15,4
Cuestionario 15,4 7,7 38,4 30,8 7,7
Entrevista 7,70 23,1 69,2

0 25 50 75 100

17.4.5 Anlisis agrupado de los resultados por empresas

Al analizar los datos a nivel general de empresa, se us el valor medio ponderado para
identificar el valor por cada una de las nueve empresas. Este valor constituye una medida
de tendencia central en donde se asigna un peso a cada clase y un promedio de los pesos
[111], adems cada uno de los valores se le pondera de acuerdo a su importancia con el
grupo general [112].
Al observar cada empresa se puede ver como la mayora de empresas presentan una
percepcin superior a 4, por ende para la mayora se encuentran algo de acuerdo con
respecto al proceso de ingeniera de requerimientos que se tiene. As mismo la empresa con
la percepcin ms baja en su proceso ha obtenido una puntuacin de 2,6% y la ms alta de
4,6%
De otro modo la media ponderada total de todas las empresas es de 4,1 de lo que se
concluye que las empresas se encuentran algo de acuerdo con su experticia para el
desarrollo de la ingeniera de requerimientos. La percepcin general de cada una de las
empresas se puede observar en el grafico 24.

163
 5
4,6 4,6
4,5 4,4
4,1 4,1
4 3,8
3,6
3,5 3,3

3
2,6
2,5

1,5

0,5

0
Empresa 1 Empresa 2 Empresa 3 Empresa 4 Empresa 5 Empresa 6 Empresa 7 Empresa 8 Empresa 9

Nombre Empresa Promedio

Grfico 22, media ponderada por empresa

17.5 Anlisis de resultados en pregrados y egresados.

17.5.1 Anlisis general de las enseanzas de la ingeniera de requerimientos en

pregrados segn personal docente y egresados
Para iniciar es de mencionar que los resultados de los representantes de las universidades y
egresados se encuentran agrupados, dado que las preguntas en ambos grupos fueron
iguales. Las preguntas se encuentran disponibles en las secciones 17.8 y 17.9
Primero se analiza la informacin de las universidades, en la cual es de mencionar que el
total de participantes fue de diecisis entre el sector de los egresados y sector pregrados. En
el grafico 25 se observa como instituciones Universidad 1 y 2 representan la mayora de la
poblacin encuestada.

164
 Grfico 23, universidades participantes

De las universidades mencionadas de manera anterior se distribuyen de la siguiente manera,

el 93,8% son egresados de una de las universidades que se observa en el grafico 25
mientras el 6,3% restante corresponde al sector de los pregrados universitarios (Grafico 26).

165
 Grfico 24, tipo de encuestado

Para empezar se menciona que el primer tem a indagar fue si los tpicos que componen la
ingeniera de requerimientos son impartidos en una nica materia, en esta los egresados y
docente manifestaron en un 75% que no es as y estos temas son dados a lo largo de
diferentes materias del currculo (Grafico 27).

166
 Grfico 25, tpicos de ingeniera de requerimientos impartidos en nica materia

De manera posterior se indago por las tcnicas de elicitacin y si estas son abordadas
durante el pregrado. En este se observa que el 56,3% de los encuestados manifiestan que si
se imparten tcnicas de elicitacin (Grafico 28).

167
 Grfico 26, tcnicas enseadas de elicitacin en pregrados

De modo semejante se indaga por la priorizacin de requerimientos en la cual el 81,3%

manifestaron desconocimiento con respecto a este tema (Grafico 29)

168
 Grfico 27, tcnicas de priorizacin enseadas en pregrado

Por otro lado se observa que los encuestados en un 81,3% desconocen las tcnicas de
diseo centrado en el usuario - UCD (Grafico 30).

169
 Grfico 28, tcnicas de diseo centrado en el usuario.

Igualmente con un 56,3% los encuestados manifiestan que no se imparten tcnicas que
permitan a saber cmo debe realizarse la clasificacin de los stakeholders en los proyectos
(grafico 31)

170
 Grfico 29, tcnicas para realizar clasificacin de stakeholders

As tambin se presenta un desconocimiento de un 75% por parte de los encuestados

relacionado con las tcnicas que permiten verificar la dependencia y el impacto que se
generan entre requerimientos (Grafico 32)

171
 Grfico 30, tcnicas/herramientas para medir dependencia e impacto

Tambin se indago con respecto a la diferencia entre requerimientos funcionales y no

funcionales y en este los encuestados en un 81,3% manifestaron que en el pregrado se
comprenden cuales son cada uno de estos y se entiende las diferencias entre ambos (Grafico
33).

172
 Grfico 31, diferencia entre requerimientos funcionales y no funcionales

A su vez los encuestados con un 93,8% manifiestan que desconocen las herramientas que
permitan realizar la trazabilidad de los requerimientos (Grafico 34)

173
 Grfico 32, herramientas para realizar trazabilidad de los requerimientos

17.5.2 Anlisis de las tcnicas enseadas en ingeniera de requerimientos en los

pregrados segn personal docente y egresados
En un segundo lugar a los encuestados se les indago por las tcnicas de elicitacin de las
cuales adquirieron conocimiento en el pregrado. Para esta segn el grafico 35 se observa
que se destacan cuatro tcnicas para realizar elicitacin las cuales son prototipado, lluvia
de ideas, cuestionarios y entrevistas, las otras seis tcnicas preguntadas son dadas en muy
baja proporcin y para el caso de las tcnicas de introspeccin y card sorting las
desconocen por completo.

174
 Tecnicas enseadas segun universidades y
egresados
Prototipado 62,5 37,5
Observacion directa 37,5 62,5
Etnografia 6,3 93,7
Grupos de trabajo 37,5 62,5
Card sorting 0 100
Lluvia de ideas 50 50 Si
Intraspeccion 0 100 No
Analisis de dominio 6,3 93,7
Analisis de tareas 31,3 68,7
Cuestionario 81,3 18,7
Entrevista 93,7 6,3

0 25 50 75 100

Grfico 33, tcnicas de elicitacin impartidas en pregrado.

17.6 Encuesta ingeniera de requerimientos para empresas

Seccin: Descripcin
Nombre empresa
Rol Gerente Gerente de Desarrollador Otro: Cual
encuestado general proyecto de software
Seccin: Preguntas generales:
A las siguientes preguntas se desea conocer el grado de acuerdo del encuestado por cada
uno de los enunciados planteados en cada pregunta, donde 1 representa el grado ms bajo y
5 representa el grado ms alto en acuerdo. Si desea expresar alguna consideracin del
enunciado con respecto como este sucede en la compaa, lo puede realizar en la ltima
columna de cada una de las preguntas.
1. Considera que el proceso actual para la captura de requerimientos ante los clientes
es claro y efectivo?
2. Al momento de iniciar el proceso de elicitacin Se identifica el o los grupo de
stakeholders que hacen parte del proyecto para realizar el proceso de ingeniera de
requerimientos ante todos ellos?
3. Posterior a definir el grupo de stakeholders a participar Se Realiza clasificacin de
estos segn su rol en el proyecto?
4. Se encuentran definidas de manera clara dentro de la organizacin las personas
encargadas de realizar el proceso de elicitacin ante el cliente?
5. Al momento de obtener requerimientos ante los clientes, Se hace uso de tcnicas
que permitan definir criterios para generar productos e interfaces (GUI) que sean de fcil
uso para el usuario (Diseo Centrado en el Usuario UCD)?
6. Al momento de realizar el proceso de elicitacin Se consideran las restricciones

175
que debe cumplir el sistema? (Lenguajes de programacin, plataformas, tiempos, etc)
7. Se define de manera clara el alcance del proyecto o producto por medio de un
documento?
8. Se realiza una verificacin a los requerimientos obtenidos ante el cliente antes de
iniciar los desarrollos?
9. Las tcnicas usadas para la obtencin de los requerimientos cambian segn el tipo
de proyecto a desarrollar?
10. Por cada entrega a realizar del producto Se tiene en cuenta realizar priorizacin de
los requerimientos a implementar en cada iteracin?
11. Durante la fase de ingeniera de requerimientos, Quedan claros y definidos los
requerimientos no funcionales (Tambin llamados atributos de calidad) que debe cumplir
el sistema?
12. Al obtener los requerimientos funcionales y no funcionales, Se estima la
dependencia y el anlisis de impacto de estos?
13. Posterior a realizar el proceso de elicitacin, Se realiza un SRS (Software
requirement Specification) donde quedan plasmadas y claras todas las especificaciones del
software?
14. Se realiza una trazabilidad de los requerimientos que permitan documentar la
gestin de cambios durante todo el proyecto?
15. El proceso de ingeniera de requerimientos se realiza de manera incremental e
iterativa?
16. Se hace uso de metamodelos que permitan especificar de forma clara los
requerimientos?
Respuestas 1. Muy en 2. En 3. 4. Algo de 5.
desacuerdo. desacuerdo. Indiferente. acuerdo. Totalmente
de acuerdo.
Seccin: Tcnicas requerimientos
De las siguientes tcnicas planteadas seleccione cuales son impartidas a los estudiantes
como tcnicas para realizar elicitacin de requerimientos
Entrevista
Cuestionario
Anlisis de tareas
Anlisis de dominio
Introspeccin
Lluvia de ideas
Card Sorting (Ejemplo tarjetas clasificatorias usadas en SCRUM)
Grupos de trabajo
Etnografa
Observacin directa
Prototipado
Respuestas 1. Muy poco 2. Poco 3. Usada en 4. Usada de 5. Muy
usada usada algunas manera usada
veces frecuente

176
 17.7 Entrevista ingeniera de requerimientos para empresas
# Pregunta
Cul cree usted, segn la experiencia que ha tenido en proyectos de software, que
1
es la etapa ms crtica del proceso completo del desarrollo de software?, Por qu?
Teniendo presente la etapa ms crtica del proceso de desarrollo de software, Cree
2
usted que su empresa se encuentra preparada para afrontar esta etapa?
En los proyectos de software que han realizado que metodologas de desarrollo
3
han implementado?, Con cuales ha obtenido mejores resultados?
En qu etapa del proyecto se logra la identificacin de los requerimientos no
4
funcionales?, En qu nivel de detalle especifican estos tipos de requerimientos?
Cuando est realizando un diseo a la medida y encuentra que el usuario no sabe
exactamente qu es lo que quiere (o necesita segn los problemas que actualmente
5
presente), Qu estrategias cree usted que deben utilizarse para lograr establecer los
requerimientos del sistema?
Qu tcnicas de elicitacin de requerimientos conoce?, cules ha aplicado? Las
6 que no ha aplicado, cules son los motivos por los que no las usado? y Cmo es
el proceso actual usado para la ingeniera de requerimientos?
Para usted que diferencias en cuanto al proceso de ingeniera de software
7 encuentra entre los diferentes tipos de proyecto (desarrollos a la medida/productos
para mercados de masa)?
Suponiendo que ustedes tienen un proceso muy estable de elicitacin de
8 requerimientos, cree usted que existe una receta nica para la labor de elicitacin
de requerimientos, que se adapte para cualquier tipo de proyecto?, Por qu?
Si existe conflicto entre los stakeholders con respecto a un determinado
9
requerimiento Cmo es el proceso que uso para realizar la negociacin de estos?
10 Cmo es el proceso que usa para la identificar los Stakeholders de un proyecto?
En caso de que llegara un proyecto de una complejidad superior a los que ha
manejado, Siente usted que con las tcnicas de elicitacin de requerimientos que
11
ha usado son suficientes para levantar de manera completa los requerimientos del
sistema?
Luego de que se tienen los requerimientos definidos, De qu manera evala usted
12 que no existan contradicciones o errores en la especificacin de estos
requerimientos?
Si usted realiza priorizacin de requerimientos, Qu aspecto usa para realizar esta
13
priorizacin (importancia, costo, tiempo, riesgo, etc)?
Si usted usa gestin de cambios para requerimientos durante el proyecto Cmo lo
14
realiza?
Cuando finalmente tiene la seguridad total de los requerimientos a desarrollar
(aprobado por el cliente), estos pasan a construccin. Dado que para el cliente de
cierta forma todo es urgente y necesario de qu manera se logra establecer por
15
cuales requerimientos se debe iniciar y si surge posteriormente un nuevo
requerimiento, tiene algn mecanismo para identificar que otros requerimientos
afecta esa nueva solicitud?
Suponga que usted se encuentra del lado cliente, que en esta ocasin tiene una
16
necesidad especfica y debe contratar un desarrollo de software a la medida.

177
 Cules son los aspectos claves por los cuales elegira al proveedor del producto o
servicio que necesita?
Cunto tiempo en promedio se toma el proceso de la ingeniera de requerimiento
17
durante todo el proyecto?

17.8 Encuesta ingeniera de requerimientos para universidades

Seccin: Descripcin
Nombre de la institucin
Seccin: Preguntas generales:
Las siguientes preguntas son preguntas cerradas donde solo podr seleccionar una de las
dos opciones, Si desea expresar alguna consideracin para ampliar la respuesta a la
pregunta, lo puede realizar en la ltima columna de comentarios de cada una de las
preguntas.
1. Los temas que componen la ingeniera de requerimientos (Elicitacin, gestin de
requerimientos, trazabilidad, priorizacin,) son tpicos de una sola materia en la
malla curricular o son componentes que se imparten dentro de en otra(s) materia(s)?
2. En la malla curricular existen temticas donde se d a conocer a los estudiantes las
tcnicas de elicitacin?
3. En la malla curricular existen temticas donde se d a conocer a los estudiantes las
tcnicas como se puede realizar priorizacin de requerimientos?
4. En la malla curricular existen temticas donde se d a conocer a los estudiantes el
diseo centrado en el usuario (UCD)?
5. Se ensea a identificar y clasificar los stakeholder?
6. Se concientiza a los estudiantes que entre los diferentes requerimientos existen
dependencias entre estas y a la vez estas pueden generar impacto en el tiempo del
desarrollo de software?
7. Se realiza diferenciacin entre los requerimientos funcionales y no funcionales?
8. En la malla curricular existen temticas donde se d a conocer a los estudiantes como
realizar la trazabilidad de los requerimientos para poder realizar seguimiento y control
de estos?
Respuestas 1. Falso. 2. Verdadero. 3. No sabe/No responde.
Seccin: Tcnicas requerimientos
De las siguientes tcnicas planteadas seleccione cuales son impartidas a los estudiantes
como tcnicas para realizar elicitacin de requerimientos
Entrevista
Cuestionario
Anlisis de tareas
Anlisis de dominio
Introspeccin
Lluvia de ideas
Card Sorting (Ejemplo tarjetas clasificatorias usadas en SCRUM)
Grupos de trabajo
Etnografa

178
Observacin directa
Prototipado
Respuestas 1. Si 2. No

17.9 Encuesta ingeniera de requerimientos para egresados

Seccin: Descripcin
Nombre de la institucin educativa donde obtuvo su pregrado
Seccin: Preguntas generales:
Las siguientes corresponden a preguntas cerradas donde solo podr seleccionar una de las
opciones, Si desea expresar o ampliar algo con relacin a la pregunta, lo puede realizar en
la ltima columna de comentarios de cada una de las preguntas.
1. Los temas que componen la ingeniera de requerimientos (Elicitacin, gestin de
requerimientos, trazabilidad, priorizacin,) fueron temas que se abordaron en una
nica materia de su pregrado?
2. Durante su pregrado se le impartieron cursos donde se ensearan las tcnicas para
realizar elicitacin de requerimientos?
3. Durante su pregrado se le impartieron cursos donde se ensearan las tcnicas para
realizar priorizacin de requerimientos?
4. Durante su pregrado se le impartieron cursos donde se ensearan las tcnicas
relacionadas con diseo centrado en el usuario (UCD)?
5. En su pregrado se le enseo el cmo identificar y clasificar los stakeholder?
6. Durante el pregrado obtuvo conocimientos en herramientas o procesos que
permitieran identificar las dependencias de los requerimientos y a la vez cuantificar el
impacto entre estas para el desarrollo de software?
7. Se comprendi las diferenciaciones entre los requerimientos funcionales y no
funcionales?
8. Durante el pregrado obtuvo conocimientos herramientas o procesos que permitieran
generar trazabilidad de los requerimientos para poder generar un seguimiento y control
a estos?
Respuestas 1. Falso. 2. Verdadero. 3. No sabe/No responde.
Seccin: Tcnicas requerimientos
De las siguientes tcnicas planteadas seleccione cuales son impartidas a los estudiantes
como tcnicas para realizar elicitacin de requerimientos
Entrevista
Cuestionario
Anlisis de tareas
Anlisis de dominio
Introspeccin
Lluvia de ideas
Card Sorting (Ejemplo tarjetas clasificatorias usadas en SCRUM)
Grupos de trabajo
Etnografa
Observacin directa

179
Prototipado
Respuestas 1. Si 2. No

17.10 Conclusiones
En trminos generales las empresas siente que poseen un buen proceso para realizar
ingeniera de requerimientos, esto es ms notorio en temas relacionados con
validacin de requerimientos ante el cliente y la verificacin de dependencias y
gestin de cambios usando matrices de trazabilidad, en donde el grado de
aceptacin de las empresas es alta. Sin embargo se evidencia como es complejo para
ellos interpretar de una manera clara las solicitudes realizadas por los clientes, ms
aun cuando en ocasiones los clientes no conocen en un todo sus dificultades que
desean resolver con el uso de la tecnologa.
La seleccin de stakeholders por las empresas es muy bsica, ya que es muy comn
que ellos deleguen a una persona dentro de la organizacin para identificar los
involucrados o simplemente dirigirse con la persona que paga el desarrollo y como
lo menciona Mary Ann Crow, profesional certificada en PMP menciona que
Identificar los stakeholders es uno de los ms importantes para establecer las bases
tempranas dirigidas a la posterior planificacin, ejecucin, as como monitoreo y
control de la informacin y comunicacin del proyecto, para alcanzar el xito en
ste [33].
Para los programas de pregrado la de ingeniera de requerimientos es un tema que
debera tomarse con ms rigurosidad, primero se evidencia como los tpicos no se
encuentran concentrados en una materia relacionada solo a esta rea y segundo se
nota un grado de desconocimiento en la realizacin de priorizacin de
requerimientos, el diseo centrado en el usuario, las tcnicas para clasificar
stakeholders, las herramientas para medir dependencias e impacto y la medicin de
trazabilidad, por ultimo son muy bsicos los conocimientos que adquiere el
estudiante con respecto a las tcnicas para realizar elicitacin de requerimientos.
Es interesante observar el contraste entre la teora y la prctica, en la cual las
empresa manifiestan un grado de satisfaccin con respecto al proceso de ingeniera
de requerimientos interno de cada una de las empresas, sin embargo al analizar los
procesos (mtodos, tcnicas, herramientas) que aplican se identifica que en la
mayora de casos se est distante de ser modelos los cuales puedan ser replicados
como casos de xitos en otras empresas del sector.

180
 18.ANEXO 3: PUBLICACIONES REALIZADAS

LA INGENIERA DE REQUERIMIENTOS EN LAS PEQUEAS EMPRESAS DEL

DEPARTAMENTO DE RISARALDA
Cristian Andrs De La Cruz Londoo, Gustavo Andrs Castro Guevara, Ing.
Ing.
Universidad Tecnolgica de Pereira.
Universidad Catlica de Manizales. Facultad de Ingenieras.
Grupo de investigacin GIDTA. Pereira, Colombia
Manizales, Colombia [email protected]
[email protected]

REQUIREMENTS ENGINEERING IN SMALL BUSINESS OF RISARALDA DEPARTMENT

Resumen La finalidad de este artculo es mostrar el centered design (UCD), restrictions, documentation,
estado actual del proceso de ingeniera de functional and non-functional requirements, meta-
requerimientos en las pequeas empresas que models and elicitation techniques. In the case of
desarrollan software en el departamento de Risaralda, industry, the average is 4.1 (on a scale of 1-5) from
adems de observar cmo se aborda esta rea desde there, it is concluded that the companies agree in
la academia. Para lograr esto se estructuraron dos some aspects according to their expertise in the
herramientas las cuales fueron encuesta y entrevista, development of engineering of requirements.
asimismo se realiz una bsqueda terica. Se opt
por conocer la percepcin de las personas Keywords: elicitation, industry, methodology,
relacionadas en esta rea, las temticas abordadas requirements, software, stakeholders, techniques,
fueron: Stakeholders, priorizacin, dependencias, tools.
trazabilidad, diseo centrado en usuario (DCU),
restricciones, documentacin, requerimientos 1. INTRODUCCIN
funcionales, requerimientos no funcionales, meta-
modelos y tcnicas usadas para elicitacin. Para el La ingeniera de requerimientos es una rea que se
caso de la industria la media ponderada es de 4,1 (en puede abordar desde diferentes perspectivas, como
una escala de 1 a 5) de lo que se concluye que las lo son los mtodos que definen procesos para su
empresas se encuentran algo de acuerdo con su adquisicin y administracin, los lenguajes o
experticia para el desarrollo de la ingeniera de meta-modelos que permiten realizar sus
requerimientos. especificaciones, la innovacin que puede
presentarse frente la ingeniera de requerimientos,
Palabras clave: elicitacin, herramientas, industria, software existente para la administracin de los
metodologa, requerimientos, requisitos, software, requerimientos, entre otros. La ingeniera de
stakeholders, tcnicas. requisitos es en esencia la aplicacin de
principios, mtodos, tcnicas y herramientas en
Abstract The purpose of this paper is to show the pro de descubrir los requisitos de un producto de
current state of the process of engineering of software, al igual que permite el anlisis, la
requirements in the small companies developing documentacin de objetivos, funciones y
software in Risaralda department, and besides to restricciones de dicho sistemas, sin embargo
check the way how this area of knowledge is existe una falencia, no existe un acuerdo sobre
approached by the academic sector. To do this, we lenguajes, mtodos o herramientas para su
created two tools which were: survey and interviews; ejecucin [1], ms aun como lo define Ackoff
additionally, a theoretical search was done. We chose Fallamos ms a menudo porque resolvemos el
to study the perceptions of those involved in this problema incorrecto, que porque obtenemos una
area, and the topics covered were: Stakeholders, solucin deficiente del problema correcto [2], por
prioritization, dependencies, traceability, user- ende es necesario profundizar en la bsqueda de

Lmpsakos | N o. 12 | julio-diciembre 2014 181

 estrategias que permitan mejorar y potenciar esta el cliente y/o usuario se encuentra ubicado de
rea. Para la ingeniera de requerimientos es manera remota? [8]. A continuacin se describirn
importante ocuparse de la identificacin de algunos referentes tericos relacionados con los
objetivos para un sistema propuesto, la operacin principales inconvenientes que se presentan en esta
y la conversin de estos objetivos en los servicios rea:
y restricciones. [3].
En gran nmero de casos las empresas a pesar de
conocer la importancia de la ingeniera de
A su vez el mantenimiento del software sostiene el requerimientos optan por realizar de forma emprica
producto en todo su ciclo de vida (desde el esta actividad, como lo menciona Toni Granollers
desarrollo hasta las operaciones). Las solicitudes de La comunicacin con los usuarios es un aspecto
modificacin se registran y se realiza seguimiento, prioritario para las empresas que desarrollan
se determina el impacto de los cambios propuestos, sistemas software; aun as confan ms en la
tanto el cdigo y otros artefactos de software se experiencia acumulada que no en la aplicacin de
modifican, se lleva a cabo el proceso de pruebas, y mtodos pensados para capturar la experiencia de
una nueva versin del producto de software se los usuarios y sus verdaderas necesidades(), sin
libera [4]. All es fundamental la trazabilidad de embargo se suele dar culpabilidad al usuario por no
requerimientos, la cual describe y sigue la vida de describir correctamente sus necesidades, que
un requisito desde su origen, desarrollo, cambian de pensamiento fcilmente, que tienen
especificacin, distribucin y uso [5]. diferentes puntos de vista o simplemente que stos
no saben cmo disear un producto interactivo. Lo
El estudio realizado se enfoca en las pequeas que nunca piensan es que si hubieran aplicado
empresas desarrolladoras de software, ya que la correctamente las tcnicas del anlisis de requisitos
mayora de este tipo de empresas no posee un centradas en los usuarios se habran ahorrado estos
msculo econmico fuerte que les permita problemas y los usuarios estaran satisfechos [9],
implementar y mantener un modelo de calidad sin embargo pese a la importacin de la
como lo es por ejemplo CMMI y por ende sus especificacin de requisitos y que esta es una tarea
procesos en ingeniera de software no estn bien entendida an se realiza seleccin de tcnicas
claramente definidos. Si nos centramos en la de forma subjetiva, esto se debe a dos razones: 1.
situacin actual colombiana, es fcil denotar que las Los conocimiento con respecto a la cantidad de
pequeas y medianas empresas son el motor del tcnicas disponibles actualmente es limitado, lo que
pas. Segn un estudio del Centro de quiere decir que an desconocen una gran cantidad
Investigaciones de la Escuela de Finanzas y de tcnicas, 2. La informacin de la que disponen en
Comercio Exterior de la Universidad Sergio relacin a las tcnicas es de tipo procedimental (es
Arboleda, estas generan ms del 50% del empleo decir centrada en la tcnica), siendo la informacin
nacional, significan el 36% del valor agregado pragmtica(es decir centrada en cuando usar la
industrial, el 92% de los establecimientos tcnica) casi inexistente [10].
comerciales y el 40% de la produccin total del pas
[6]. Adems de estos se observa como las pequeas
empresas manejan sus requerimientos de forma que
2. DESARROLLO DEL ARTCULO no pareciera guardar relacin con lo que se dice en
los textos, y a gran parte de estas parecieran no
2.1 Revisin terica interesarles las investigaciones actuales que se
realizan en esta rea [11]. Es comn ver como en las
La ingeniera de requisitos cada vez cobra mayor pequeas empresas manejan la ingeniera de
importancia tanto en la academia como en la requisitos de forma diferente, cada una de las
industria, la razn de esto es que cada vez se espera empresas realiza la elicitacin y comunicacin de
que existan ms funciones centradas en el usuario, requerimientos con diferente grado de planificacin,
de mayor calidad y seguridad, por tanto es estructura y documentacin, y ellos consideran que
importante comprender las situaciones que afectan cada eleccin es natural [12].
dicha prctica [7]. Por otra parte existen aspectos
geogrficos en los cuales los equipos de software se Es de mencionar que la calidad del software
encuentran distribuidos de manera global y uno de depende de la calidad de los requisitos y esta a su
los inconvenientes que puede afrontar la industria es vez de las tcnicas utilizadas para elicitacin [12].
responde a la pregunta Qu tcnica de elicitacin No obstante el desarrollo de software es una
de requisitos de software se debera aplicar cuando actividad en el cual es necesaria la cooperacin y

182
colaboracin de muchas personas. Y como lo Con respecto a las tcnicas usadas en elicitacin es
menciona Sergio Zapata no solo se intervienen de mencionar que las entrevistas sirven para obtener
aspectos tcnicos sino tambin culturales, una comprensin general de lo que hacen los
sociales, econmicos y psicolgicos. Estos stakeholders, como estos podran interactuar con el
aspectos llevan a que la comunicacin entre los sistema y las dificultades a las que se enfrentan con
ingenieros de requisitos y los usuarios-clientes sea los sistemas actuales. A la gente le gusta hablar
en algunas ocasiones compleja y puede llevar a sobre su trabajo y normalmente se alegran de verse
desacuerdos culturales, organizacionales, falta de implicados en las entrevistas. Sin embargo, no son
generacin de confianza mutua o capacidades para de tanta utilidad para la compresin de los
realizar resolucin de conflictos [8]. requerimientos del dominio de la aplicacin [19].

A pesar de que la mayora de las empresas aseguran Del mismo modo en la fase de especificacin de
el uso de una metodologa., esta no se realiza o requerimientos es posible que se presenten muchos
aplica de forma correcta, para el caso de las inconvenientes entre estos estn: Los
empresas de software de la ciudad de requerimientos no son obvios y viene de muchas
Cali(Colombia) en el 48.7% la industria no se fuentes, son difciles de expresar en palabras (Se
establecen criterios para la aceptacin de los genera ambigedad), la cantidad de requerimientos
requerimientos, el 43.6% no realizan administracin se puede tornar difcil, los requerimientos pueden
de requerimientos [13], en la misma lnea para el cambiar a lo largo de ciclo de vida, los usuarios no
caso de Santiago de Chile(Chile) se observa cmo pueden explicar lo que hacen, se recuerda la
las empresas emergentes no cuentan con el personal excepcin pero se olvida lo rutinario, se habla de lo
calificado, se cuenta con escasos recursos o no se que no funciona, existe un vocabulario distinto entre
encuentran roles definidos en la organizacin [14], usuarios y desarrolladores, se hace uso de los
de manera similar en Nueva Zelanda se observa mismos trminos para diferentes significados, el
como en la industria no hace uso de herramientas de nivel de detalle es vago, algunos requerimientos son
soporte de la ingeniera de requerimientos y al ms importantes (o estables) que otros, existe
indagar por estas herramientas solo unas pocas relacin entre los requerimientos y por ultimo cada
asocian a Rational, Trac, Together and door como uno tiene funcionalidades nicas y abarcan reas
herramientas que soportan la ingeniera de funcionales especificas [20], [21]. Otros mencionan
requerimientos. A su vez los principales problemas que las metodologas han sido concebidas para
que ellos identifican estn: Cambios en el alcance y sistemas alfanumricos, en donde no existen
en los requerimientos, aceptacin del cliente para atributos espaciales, y que al existir stakeholders
costos, tiempo y esfuerzo necesarios para la fase de heterogneos y complejidad de la informacin se
requisitos y calidad de las especificaciones [15]. generan inconvenientes al momento de aplicar
Asimismo las tcnicas de entrevista y encuesta ingeniera de requerimientos [22].
suelen ser las ms usadas para realizar elicitacin
[2]. Otros aspectos complejos relacionados con la
elicitacin se presentan ya que las fronteras del
Entre los principales tems relevantes alrededor de sistema no se encuentran bien definidas, los detalles
la ingeniera de requerimientos se tiene: Alta tcnicos pueden confundir (ms que aclarar),
frecuencia de revisin de cambios en problemas de comprensin por parte del cliente,
requerimientos, aumento del nmero de donde ellos no estn totalmente seguros de lo que
requerimientos, pocas capacidades de confirmar la necesitan o tiene dificultades para comunicar sus
trazabilidad y cambios en los requerimientos [16], necesidades [23].
otro inconveniente es el uso de lenguajes naturales,
lo cual genera ambigedad entre los requerimientos 2.2 Metodologa
o conflictos entre los interesados [17], adems la
insatisfaccin en el anlisis del software puede Para realizar la investigacin se opt por conocer la
darse por los siguientes factores: percepcin de las personas relacionadas en esta rea
tanto a nivel laboral como acadmico, adems de
1. Fallas no relacionadas con tcnicas de elicitacin, realizar bsqueda terica de los problemas que
2. Fallas causado por la falta de efectividad en las presenta esta rea. Para lograrlo se estructuraron dos
tcnicas de elicitacin, 3. Falta de disponibilidad los herramientas, las cuales fueron encuestas y
cual genera mal uso de tcnicas de elicitacin [18]. entrevista. Estas forman un componente mixto en la
investigacin en la cual se aportan tcnicas
cualitativas y cuantitativas [24].

183
 programas en
Para este proceso se estructuraron tres perfiles (De ingeniera de sistemas.
los cuales se deseaba evaluar su percepcin), los Directores y docentes
cuales fueron: programas acadmicos
en ingeniera de
Sector pequeas empresas relacionadas con el sistemas.
desarrollo de software. Tcnica Encuesta con escala
Docentes y directores de pregrados Likert.
universitarios de ingeniera de sistemas. Entrevista tipo
Egresados de pregrados en ingeniera de mertenes.
sistemas. Tamao de la muestra 9 empresas de la regin
de Pereira.
A continuacin se relaciona las herramientas e 16 Egresados.
intenciones para cada uno de los perfiles. 1 Institucin
universitaria.
Herramientas Momento estadstico Mayo 2014 Julio
Perfil Intencionalidad. 2014
aplicadas
Pequeas Entrevista Conocer el grado Financiacin Recursos propios.
empresas Encuesta de madures de las Tab2. Ficha tcnica de la encuesta
empresas
desarrolladoras de
software. 2.2.2 Anlisis de fiabilidad
Sector Encuesta Identificar como
pregrados se encuentra Al realizar anlisis de correlacin interna entre
universitarios estructurada las los tems se identifica que existe un grado de
temticas fiabilidad de los datos, esto lo podemos
relacionadas con constatar al aplicar un estadstico de fiabilidad
la ingeniera de en el cual observamos que el alfa de
requerimientos y cronbach() es de 0,863, el cual se encuentra
como se abordan en un valor cercano a uno y tal como lo
estas en el menciona Hernndez, Fernndez y Baptista en
pensum su libro Metodologa de la investigacin el
acadmico. valor uno representa el nivel mximo de
Sector Entrevista Conocer la confiabilidad total. Para nuestro caso al
egresados percepcin de los obtener un valor aproximado al 0.87 es posible
egresados con afirmar que se tiene una confiabilidad
respecto a los aceptable [24].
conocimientos
que fueron 2.3 Resultados
adquiridos en sus
estudios de 2.3.1 Anlisis de resultados en empresas
pregrado en el En primer lugar se pregunt por el nivel de
rea de la aceptacin con respecto a que tan claro y efectivo es
ingeniera de el proceso para realizar captura de informacin ante
requerimientos. los clientes, en el cual el 57,1% los encuestados
Tab1. Herramientas e intencionalidad para cada uno de
manifiestas que se encuentran algo de acuerdo, en
los perfiles.
contraposicin el grado de desacuerdo es de tan solo
el 7,1%.
2.2.1Ficha tcnica.

Diseo muestra Muestra por

convencin.
Poblacin objetivo Pequeas empresas de
la regin de Risaralda.
Egresados de

184
 Fig1. Proceso captura informacin es claro y
efectivo.

Con respecto a la identificacin de stakeholders se Fig2. Uso de diseo centrado en el usuario

nota un que ms del 57% de los encuestados se
encuentra de acuerdo en la forma como las Con respecto a las tcnicas que se aplican en los
empresas identifican al grupo de personas procesos de ingeniera de requerimientos, los
involucradas en los proyectos. De forma semejante encuestados mencionan con un 57, 1% que las
al contrastar estos datos con la entrevista se observa tcnicas que aplican para el proceso de ingeniera de
que la forma que ms se destaca para identificar los requerimientos deben cambiar segn el tipo de
stakeholders en cada proyecto son: proyecto, sin embargo esta es una de las pregunta
donde ms se marca la polaridad de las respuesta ya
1. Elegir una persona dentro de la compaa para que se encuentran opiniones divididas entre las
definir los usuarios, por lo general el gerente o la empresas.
persona que paga por el desarrollo.
2. Definirlos segn el organigrama de la compaa. Por otro lado ms del 42,9% de los encuestados se
3. Identificar los usuarios finales. encuentran de acuerdo con respecto a la priorizacin
que se deber realizar en cada iteracin. Al sumar las
En particular se observ que en el caso de existir respuestas de los encuestados que se encuentran
conflictos entre requerimientos no se hace uso de algo de acuerdo y totalmente de acuerdo obtenemos
grupos de stakeholders y por lo general esta un 85,8% de aceptacin. Al confrontar esta
decisin es tomada por la persona que tiene ms informacin con las entrevistas observamos que los
poder de decisin por parte del cliente, que a la vez mtodos para realizar priorizacin que las empresas
es relacionada con la persona que paga el desarrollo. realizan son las siguientes:

Como lo menciona Mate Despus de obtener los 1. Segn criterio y decisin del cliente.
requerimientos de los stakeholders, deben ser 2. Construccin de mdulos que lleven de manera
analizados en el contexto de requerimientos de rpida versiones de un producto funcional.
negocio (perspectiva de gestin) la rentabilidad 3. Construcciones de mdulos que permitan al cliente
como tal, la organizacin y los requisitos polticos. obtener un retorno a la inversin (ROI) de manera
Adems, las relaciones entre requerimientos, es rpida.
decir, dependencias, conflictos, superposiciones,
omisiones e inconsistencias deben ser examinados y La priorizacin temprana indica qu partes del
documentados [25]. negocio se deben investigar primero, y que se puede
ignorar sin problemas hasta ms tarde, o en algunos
Al preguntar a los encuestados con respecto al uso casos, abandonar. Adems, se utiliza una
de tcnicas que permitan definir diseos centrados priorizacin inicial para guiar sus iteraciones y la
en el usuario se observa que ms del 50% se planificacin de la versin. [26]
encuentran de acuerdo en relacin a la creacin de
software el cual se enfoca a generar aplicaciones de Para los encuestados es claro definir cules son los
fcil uso para los usuarios. requerimientos no funcionales (atributos de calidad)

185
 que debe cumplir el sistema y que estos se deben
definir de forma clara. Por ende el 57% de los
encuestados se encuentra algo de acuerdo en que
para las empresas es clave definir de forma clara los
atributos de calidad que debe cumplir el sistema.
Adems segn las entrevistas realizas estos son
obtenidos en las primeras etapas del proceso de
ingeniera del software, en algunos casos las etapas
de anlisis y diseo es en donde ms se identifican
estos.

Fig.4 Dependencia y anlisis de impacto

Con respecto a la trazabilidad y gestin de cambios
que realizan de los requerimientos durante el
transcurso del proyecto el 50% de los encuestados
se encuentran totalmente de acuerdo, adems los
encuestados que se encuentran algo de acuerdo y
totalmente de acuerdo representan el 71,4% de
modo contrario ninguno de los encuestados
manifiesta algn grado en desacuerdo. Tambin al
observar las respuestas de los entrevistados con
Fig.3 Definicin de requerimientos no funcionales. respecto a l como realizan gestin y trazabilidad
encontramos que los mtodos ms usados son:
Por otra parte los encuestados manifiestan que en un
35,7% existe un total acuerdo con respecto a la 1. Matriz de trazabilidad.
definicin de las dependencias y su respectivo 2. Formatos para gestin de cambios.
anlisis de impacto entre los requerimientos
funcionales y no funcionales, incluso al sumar el
grupo de encuestados que se encuentran algo de
acuerdo y total de acuerdo obtenemos un 64,3% de
encuestados que se encuentran de acuerdo frente a
este tem.

De modo similar segn las entrevistas realizas en

las empresas los mtodos comnmente usados para
analizar y verificar dependencias son:

1. Realizar revisin de todos los requerimientos y

verificar cuales de estos se cruzan.
2. Usar formatos que permitan identificar
ambigedades en los requerimientos.
3. Usar la matriz de trazabilidad.
Fig.5 Trazabilidad de los requerimientos.

Por otra parte se observa que ms del 35,7% de las

empresas est algo acuerdo con el uso de meta-
modelos para especificar los requerimientos del
sistema, del mismo modo si tomamos estos con los
que se encuentran totalmente de acuerdo tenemos
un 64,3% de encuestados que manifiestan el uso de
meta modelos para especificar los requerimientos.

186
 2.3.2 Anlisis del uso de tcnicas en ingeniera
de requerimientos en las empresas

Se observa que la tcnica ms usada por las

empresas es la entrevista y el prototipado. Caso
contrario se observa con las tcnicas de etnografa,
card sorting, introspeccin, anlisis de dominio y
anlisis de tareas las cuales son muy poco usadas.

Fig.7 media ponderada por empresa

2.3.4 Anlisis de resultados en pregrados y

egresados
Fig.6 Uso de tcnicas de elicitacin en la industria
Para empezar se menciona que el primer tem a
2.3.3 Anlisis agrupado de los resultados por indagar fueron los tpicos que componen la
empresas ingeniera de requerimientos, y si estos son
impartidos en una nica materia, en esta los
Al analizar los datos a nivel general de empresa, se egresados y docente manifestaron en un 75% que no
us el valor medio ponderado para identificar el es as y estos temas son dados a lo largo de
valor por cada una de las nueve empresas. Este diferentes materias del currculo. De manera
valor constituye una medida de tendencia central en posterior se indago por las tcnicas de elicitacin y
donde se asigna un peso a cada clase y un promedio si estas son abordadas durante el pregrado. En este
de los pesos [27], adems cada uno de los valores se se observa que el 56,3% de los encuestados
le pondera de acuerdo a su importancia con el grupo manifiestan que si se imparten tcnicas de
general [28]. elicitacin. En cuanto a priorizacin de
requerimientos el 81,3% manifestaron
Se puede observar como la mayora de empresas desconocimiento con respecto a este tema.
presentan una percepcin superior a 4 (en escala de
1 a 5), por ende para la mayora se encuentran algo En un segundo lugar a los encuestados se les indago
de acuerdo con respecto al proceso de ingeniera de por las tcnicas de elicitacin de las cuales
requerimientos que se tiene. As mismo la empresa adquirieron conocimiento en el pregrado. Para esta
con la percepcin ms baja en su proceso ha segn el grafico 8 se observa que se destacan
obtenido una puntuacin de 2,6% y la ms alta de cuatro tcnicas para realizar elicitacin las cuales
4,6%. son prototipado, lluvia de ideas, cuestionarios y
entrevistas, las otras seis tcnicas preguntadas son
De otro modo la media ponderada total de todas las dadas en muy baja proporcin y para el caso de las
empresas es de 4,1 de lo que se concluye que las tcnicas de introspeccin y card sorting las
empresas se encuentran algo de acuerdo con su desconocen por completo.
experticia para el desarrollo de la ingeniera de
requerimientos. La percepcin general de cada una
de las empresas se puede observar en la Fig. 7.

187
 posterior planificacin, ejecucin, as como
monitoreo y control de la informacin y
comunicacin del proyecto, para alcanzar el xito
en ste. [29]

Para los programas de pregrado la de ingeniera de

requerimientos es un tema que debera tomarse con
ms rigurosidad, primero se evidencia como los
tpicos no se encuentran concentrados en una
materia relacionada solo a esta rea y segundo se
nota un grado de desconocimiento en la realizacin
de priorizacin de requerimientos, el diseo
Fig.8 Tcnicas de elicitacin impartidas en pregrado
centrado en el usuario, las tcnicas para clasificar
stakeholders, las herramientas para medir
dependencias e impacto y la medicin de
3. TRABAJOS FUTUROS trazabilidad, por ultimo son muy bsicos los
Al identificar que es complejo lograr una conocimientos que adquiere el estudiante con
comprensin clara de los requerimientos entre respecto a las tcnicas para realizar elicitacin de
stakeholders y grupos de desarrolladores, se requerimientos.
propone indagar acerca de la generacin de tcnicas
y/o herramientas que permita reducir la brecha que Es interesante observar el contraste entre la teora y
se produce al usar el lenguaje natural como medio la prctica, en la cual las empresa manifiestan un
de comunicacin usado en la elicitacin de grado de satisfaccin con respecto al proceso de
requerimientos. En este mismo sentido se encontr ingeniera de requerimientos interno de cada una de
dificultad al momento de identificar los las empresas, sin embargo al analizar los procesos
requerimientos que tienen cierto tipo de (mtodos, tcnicas, herramientas) que aplican se
contradicciones, conflictos o problemas entre s (La identifica que en la mayora de casos se est distante
mayora no son obvios a simple vista), por ende de ser modelos los cuales puedan ser replicados
surge la necesidad de crear una metodologa o como casos de xitos en otras empresas del sector.
herramienta que ayude a solucionar este problema.
5. REFERENCIAS
4. CONCLUSIONES

En trminos generales las empresas siente que [1] Alarcon, A., & Sandova, E. Herramientas
poseen un buen proceso para realizar ingeniera de case para la ingenieria de requisitos. pp. 70-74.
requerimientos, esto es ms notorio en temas 2008
relacionados con validacin de requerimientos ante [2] Antonelli, L., & Oliveros, A. Fuentes
el cliente y la verificacin de dependencias y
utilizadas por desarrolladores de software en
gestin de cambios usando matrices de trazabilidad,
Argentina para elicitar requerimientos. Buenos
en donde el grado de aceptacin de las empresas es
Aires: Laboratorio de investigacion LIFIA. 2002
alta. Sin embargo se evidencia como es complejo
para ellos interpretar de una manera clara las [3] Aurum, W. Engineering and managing
solicitudes realizadas por los clientes, ms aun software requeriments. Sydney, Australia. 2005
cuando en ocasiones los clientes no conocen en un
todo sus dificultades que desean resolver con el uso [4] Bourque, P., & Fairley, R. Swebok. Nd: IEEE
de la tecnologa. Computer society. 2004

La seleccin de stakeholders por las empresas es [5] Gotel, O., & Finkelstein, A. An Analysis of
muy bsica, ya que es muy comn que ellos the Requirements Traceability Problem. Londres,
deleguen a una persona dentro de la organizacin 1994.
para identificar los involucrados o simplemente
dirigirse con la persona que paga el desarrollo y [6] Zambrano, A. N. Disponible:
como lo menciona Mary Ann Crow, profesional http://www.javeriana.edu.co/biblos/tesis/ingenieri
certificada en PMP menciona que Identificar los a/Tesis189.pdf Junio de 2005
stakeholders es uno de los ms importantes para
establecer las bases tempranas dirigidas a la

188
[7] Westfall, L. LAS FALLAS EN LA Work in Design (pgs. 657-662). Taiwan: IEEE.
INGENIERA DE REQUISITOS. Revista 2007
facultad de ingenierias USBMed, 40-47. 2011
[17] Ashfa, U., & Sarwar Bajwa, I. Minimizing
[8] Zapata, S. Efectividad de Tcnicas Ambiguity in Natural Language Software
Tradicionales de Elicitacin de Requisitos de Requirements Specification. Digital Information
Software. Buenos Aires, Buenos Aires, Management (ICDIM) (pg. Nd). Nd: Digital
Argentina Mayo de 2013 Information Management (ICDIM). 2011

[9] Granollers, T. Anlisis de Requisitos. 2014 [18] Hickey, A. M., & Davis, A. M. Elicitation
Disponible: Technique Selection: How Do Experts Do It?
http://www.grihotools.udl.cat/mpiua/fases- IEEE International Requirements Engineering
mpiua/analisis-de-requisitos/ Conference (pgs. 169-178). Colorado: IEEE
Computer Society. 2003
[10] Carrizo Moreno, D. Marco para la seleccin
de tcnicas de educcion de requisitos. Madrid, [19] Sommerville, I. Ingeniera del software.
Espaa. Mayo de 2009 Madrid (Espaa): Pearson Education, S.A. 2005

[11] Aranda, J., Easterbrook, S., & Wilson, G. [20] Arias Chaves, M. La ingeniera de
Requirements in the wild: How small companies requerimientos y su
do it. IEEE International Conference on importancia en el desarrollo de proyectos de
Requirements Engineering (pgs. 39-48). New software.
delhi: IEEE. 2007
Revista InterSedes Universidad de Costa Rica,
[12] Aranda, G., Vizcano, A., & Cechich, A. Nd. 2007
Mejora del Proceso de Elicitacin de Requisitos
en Proyectos GSD. Buenos Aires, Buenos Aires, [21] Perez Huebe, M. Monografa: Ingeniera de
Argentina. 2007 requerimientos. Pachuca, Estado de Hidalgo,
Mexico. 2005
[13] Merchan, L., Urrea, A., & Rebollar, R.
Definicin de una metodologa agl de ingenieria [22] Medina Cardona, L. F. Caracterizacin del
de requerimientos para empresas emergentes de proceso y herramientas metodolgicas de la
desarrollo de software del su occidente ingeniera de requerimientos para aplicaciones de
colombiano. Revista cientfica Guillermo de sistemas de informacin geogrfica. Revista
Ockham, 37-50. 2008 ingenieria e investigacion, 123-131. 2007

[14] Quispe, A., Marques, M., Silvestre, L., [23] Manies, M., & Nikual , U. La elicitacin de
Ochoa, S., & Robbes, R.. Requirements requisitos en el contexto de un proyecto de
Engineering Practices in Very Small Software software. Revista Facultad de Ingenieras
Enterprises: A . XXIX International Conference USBMed, 25-29. 2011
of the Chilean Computer Science Society (pgs.
81-87). Santiago de Chile: IEEE Computer [24] Hernndez Sampieri, R., Fernndez Collado,
Society. 2010 C., & Baptista Lucio, P. Metodologia de la
investigacion. Mexico, D.F: Mc Graw Hill. 2008
[15] Talbot, A., & Connor, A..Requirements
Engineering Current Practice and Capability in [25] Mat, J. L. Requirements Engineering for
Small and Medium Software Development sociotechnical systems. Nd: Idea Group Inc.
Enterprises in New Zealand. Conference on 2005
Software Engineering Research, Management and
Applications (pgs. 17-25). New Zealand: IEEE [26] Robertson, S., & Robertson , J. Mastering
Computer Society 2011 the Requirements Process: Getting Requirements
Right. Westford: Pearson Education, Inc 2012.
[16] Lin, J., & Lin, Y.-S. Collaborative
Requirement Management System Developed for [27] Estevez Delgado, J., & Estevez Delgado, G.
CMMI-Coherent Software Engineering. universidad Michoacana de san Nicols de
Proceedings of the 2007 11th International Hidalgo. Disponible:
Conference on Computer Supported Cooperative http://dieumsnh.qfb.umich.mx/estadistica/media_p
ond.htm

189
[28] Mrquez Zambrano, L. Material
estadstica". Disponible:
http://cesarguerra10.files.wordpress.com/2011/04/
material-estadc3adstica-i.pdf Abril de 2011

[29] Crow, M. Identificar Stakeholders... Por

qu molestarse en esto?: Disponible en:
http://www.liderdeproyecto.com/articulos/identifi
car_stakeholders_por_que_molestarse_en_esto.ht
ml

190
 19.ANEXO 4: GUA DE ENSEANZA DE LA INGENIERA DE

REQUERIMIENTOS

GUIA PARA LA ENSEANZA DE LA INGENIERA

Fecha creacin 13/Marzo/2015
DE REQUERIMENTOS

1) INFORMACIN GENERAL
Asignatura: Ingeniera de requisitos.
Pre-saberes: Ingeniera del software.
Crditos: 3 Crditos
Horas presenciales: 3
Horas independientes: 6
Horas semestrales: 144
Conocimientos requeridos del Generales:
docente: Gestin de proyectos.
Anlisis y diseo de software.
Especficos:
Elicitacin de requisitos.
Anlisis de requisitos.
Especificacin de requisitos.
Gestin de requisitos.
rea de formacin Ingeniera aplicada

2) JUSTIFICACIN DE LA ASIGNATURA.
La ingeniera de requerimientos es una rea la cual se puede abordar desde diferentes
perspectivas, como lo son los mtodos que definen procesos para su adquisicin y administracin,
los lenguajes que permiten especificarlas. . La ingeniera de requisitos es en esencia la aplicacin
de principios, mtodos, tcnicas y herramientas con el propsito de descubrir los requisitos de un
producto de software, al igual que el anlisis, la documentacin de objetivos, funciones y
restricciones de dichos sistemas.

3) OBJETIVOS DE APRENDIZAJE.
Comprender las etapas de la ingeniera de requerimientos.
Apropiar las tcnicas y usos de la elicitacin de requerimientos.
Comprender las temticas relacionadas con stakeholders.
Analizar, interpretar y usar las herramientas usadas en la ingeniera de requerimientos.

191
 4) COMPETENCIAS GENERALES
Analizar, plantear, modelar y resolver problemas de requerimientos.
Identificar, analizar y comprobar los elementos que inciden en la captura de una necesidad.
Usar las tcnicas adecuadas para la elicitacin (Educcin) de requisitos.

5) CONTENIDOS.

UNIDAD 1: CONTEXTO DE LA INGENIERIA DE REQUERIMIENTO

Resumen del anlisis y diseo del software.
La ingeniera de requisitos y sus principales actividades.
Definicin de Stakeholders.
Introduccin a las fases de la ingeniera de requisitos.
Herramientas: Software requirement specification(SRS), matriz de trazabilidad
UNIDAD 2: PRE-ANALISIS
Descripcin del problema.
Identificacin del problema.
Estimacin de costos iniciales de la solucin.
Presentacin de propuesta.
UNIDAD 3: ELICITACION
Tcnicas de elicitacin.
Clasificacin de proyectos.
Seleccin y clasificacin de stakeholders.
UNIDAD 4: ANALISIS
Verificacin y priorizacin de requerimientos.
Definicin de lmites del sistema.
Seleccin y clasificacin de stakeholders.
Clasificacin de requerimientos.
Estimacin del desarrollo.
UNIDAD 5: ESPECIFICACION
Modelos conceptuales.
Construccin de prototipos no funcionales.
UNIDAD 6: VALIDACION
Uso de prototipos no funcionales para validacin de requerimientos.
Negociacin de requerimientos.
Solicitudes de cambios (RFC).
UNIDAD 7: GESTION DE CAMBIOS
Identificacin de las necesidades de cambio
Medir el impacto de los cambios sobre los requerimientos actuales
Estimacin costo inicial
Presentacin propuesta
Negociacin de aplicacin de los cambios
6) METODOLOGA.
El curso se desarrollara de manera presencial, durante el periodo se realizaran las siguientes
actividades:

Presentacin de temas por parte del profesor.

Preparacin por parte de los estudiantes de los temas propuestos para la sesin.
Asignacin de temas complementarios.
Laboratorios de caso para aplicacin de tcnicas de elicitacin, anlisis, especificacin,
validacin y gestin de los requisitos.
Lecturas y exposiciones.
Trabajos extra clases individuales y grupales.

192
7) EVALUACIN PROPUESTA.
CRITERIO COMPETENCIAS A DESARROLLAR
Desarrollo de competencias cognitivas
Trabajos individuales individuales.
Aprendizaje autnomo
Desarrollo de competencias cognitivas
grupales.
Trabajos grupales
Aprendizaje colectivo.
Trabajo en equipo.
Comprensin lectora
Proyecto Capacidad de anlisis y sntesis
Resolucin de problemas

8) ESTRATEGIAS PEDAGGICAS Y DIDCTICAS.

ESTRATEGIA DESCRIPCIN
Corresponde a los talleres, tareas y exposiciones,
Trabajos individuales ensayos que presenta el alumno en el proceso de
aprendizaje de la asignatura.
Actividades como mesas grupales, foros y
disertaciones que se crean con los estudiantes del
Trabajos grupales
grupo con el fin de fortalecer el conocimiento con
cada uno de los tpicos.
Actividad en la cual el estudiante demuestra de forma
aplicada los conocimientos para realizar elicitacin de
Proyecto
requisitos, analizar, especificar y gestionar la
informacin de estos.

9) BIBLIOGRAFA DE LA ASIGNATURA.
AYBKE, Aurum. CLAES, Wohlin. Engineering an Managing Software
Requirements. Springer, EEUU, 2005. ISBN10 3-540-25043-3
BOURQUE, Pierre. DUPUIS, Robert. SWEBOK Versin 2004: Guide to
Software Engineering Body of Knowledge. IEEE Computer Society, EEUU,
2004. ISBN 0-7695-2330-7.
HULL, Elizabeth. JACKSON, Ken. DICK, Jeremy. Requirements Engineering,
Springer, EEUU, 2010. ISBN 978-1849964043
POHL, Klaus. RUPP Chris. Requirements Engineering Fundamentals,
Alemania, 2011, ISBN 978-1-933952-81-9
SOMMERVILLE, Ian. SAWYER Pete. Requirements Engineering: A Good
Practice Guide, USA, 1997, ISBN 978-0471974444
WIEGERS, Karl. BEATTY, Joy. Software Requirements (3rd Edition),
Microsoft Press, EEUU, 2013, ISBN 978-0735679665

193
20.ANEXO 5: ARTEFACTOS CONSTRUCCION APLICATIVO

WEB

PROTOTIPOS EN PAPEL Fecha creacin 01/Mayo/2015

Prototipo pantalla inicio

Prototipo advertencia validacin fase previa formatos sin diligenciar

194
 Prototipo advertencia cargar archivo previamente diligenciado

SOFTWARE REQUIREMENT SPECIFICATION Fecha creacin 01/Mayo/2015

Formato 0-SRC Fecha creacin 31/05/2015

SOFTWARE REQUIREMENT SPECIFICATION

Nombre del
Software para el soporte de la metodologa MRPYME
proyecto

Autor Cristian Andres De la cruz Londoo

Gustavo Andres Castro Guevara
Cristian Andres De la cruz Londoo
Cliente
Gustavo Andres Castro Guevara

Versin actual Fecha ltima

1.0 31/05/2015
del documento modificacin

Versiones del documento(Historial)

Versin del Fecha Razn del cambio

documento modificacin

195
1.0 31/05/2015 Creacin de primera versin del SRS con las
especificaciones iniciales

GENERALES

Propsito
Dar soporte a la metodologa MRPYME a travs de sus fases de pre-anlisis, elicitacion, anlisis,
especificacin, validacin y gestin de requerimientos.

Alcance
Permitir descargar y cargar los formatos de cada una de las fases de la metodologa MRPYME. Es necesario
mostrar al usuario cuales formatos se encuentran diligenciados y cuales an no.

Los formatos sern archivos de Excel, Word, pdf y zip

Para algunos casos los formatos debern ser subidos como una carpeta comprimida donde el usuario
guardara los diferentes formatos de una misma seccin

No ser necesario guardar versiones del formato (Solo deber guardarse la ltima).

No es necesario analizar la informacin interna de los formatos.

Restricciones
El sistema debe ser desarrollado en lenguaje php y usando motor de base de datos MySQL.

Suposiciones y dependencias
Se cuenta con un hosting de la empresa Apps de Colombia S.A.S para almacenar el aplicativo.

Funciones del sistema

El sistema deber realizar las siguientes acciones

196
REQUERIMIENTOS

Funcional.
Cdigo del 001 Tipo
requerimiento requerimiento No
funcional.

Alta
Nombre o Consultar el marco terico Media
Prioridad
funcin
Baja

Descripcin del requerimiento

El usuario podr visualizar la descripcin del marco terico.

Funcional.
Cdigo del 002 Tipo
requerimiento requerimiento No
funcional.

Nombre Consultar la gua acadmica Prioridad Alta

197
 Media

Baja

Descripcin del requerimiento

El sistema mostrara la informacin de la gua acadmica.

Funcional.
Cdigo del 003 Tipo
requerimiento requerimiento No
funcional.

Alta
Nombre o Descargar el resumen metodolgico Media
Prioridad
funcin
Baja

Entradas y El sistema debe tener todos los formatos cargados y especificadas en cada
salidas una de las secciones

Pre- El sistema debe tener todos los formatos disponibles para descargar en
Condicin cada uno de los formatos especificados

Post-
Condicin

Descripcin del requerimiento

1. El usuario selecciona una de las fases disponibles en el men.
2. El sistema muestra todos los formatos disponibles para esa fase y al dar click sobre el nombre del
formato el sistema descargara el archivo al usuario.

Nota: Los formatos deben estar organizados en formatos obligatorios y opciones por cada una de las fases

Funcional.
Cdigo del 004 Tipo
requerimiento requerimiento No
funcional.

Alta
Nombre o Media
Descargar formatos transversales Prioridad
funcin
Baja

198
Entradas y El sistema debe tener todos los formatos cargados
salidas

Pre- El sistema debe tener todos los formatos disponibles para descargar.
Condicin

Post-
Condicin

Descripcin del requerimiento

1. El usuario desde la parte superior del sitio podr acceder a la descarga de los formatos que son
transversales a la metodologa.

Nota: Los formatos transversales son:

Glosario de trminos, matriz de trazabilidad, matriz de rastreo y SRS.

Estos formatos desde esta seccin solo podrn ser descargados y no se permite ninguna otra opcin

Funcional.
Cdigo del 005 Tipo
requerimiento requerimiento No
funcional.

Alta
Nombre o Mostrar el nmero de formatos faltantes Media
Prioridad
funcin
Baja

Entradas y Entrada:
salidas
Es necesario saber el nmero de formatos obligatorios que tiene cada
seccin y cuntos de estos han sido cargados al sistema.

Pre- El sistema debe conocer cuntos formatos son obligatorios por cada una
Condicin de las fases

Post-
Condicin

Descripcin del requerimiento

Cada una de las opciones del men deber estar acompaada del nmero de formatos obligatorios que
componen cada fase y cuantas han sido diligenciadas.

Se deber mostrar de la siguiente manera

199
Pre-analisis (0/2)

Elicitacion(0/4) (Glosario de trminos es opcional)

Analisis(0/4) (Matriz de interaccin, Glosario de trminos, SRS son opcionales )

Especificacion (0/0) (Historia de usuario, Glosario de trminos, SRS son opcionales)

Validacion(0/8) (Glosario de trminos, SRS son opcionales)

Gestion de requisitos(0/2) (Acta de reunin rechazo/observaciones propuesta desarrollo es opcional)

Funcional.
Cdigo del 006 Tipo
requerimiento requerimiento No
funcional.

Alta
Nombre o Descargar el resumen metodolgico Media
Prioridad
funcin
Baja

Entradas y El sistema debe tener todos los formatos cargados y especificadas en cada
salidas una de las secciones

Pre- El sistema debe tener todos los formatos disponibles para descargar en
Condicin cada uno de los formatos especificados

Post-
Condicin

Descripcin del requerimiento

1. El usuario selecciona una de las fases disponibles en el men.
2. El sistema muestra todos los formatos disponibles para esa fase y al dar click sobre el nombre del
formato el sistema descargara el archivo al usuario.
3. El sistema deber mostrar usando colores si este formato ya ha sido cargado (verde) o si nunca ha
sido cargado (rojo)

Nota: Los formatos deben estar organizados en formatos obligatorios y opciones por cada una de las fases

Los formatos opcionales han sido detallados en el requerimiento 005 y los nombres de los nombre de los
formatos se encuentra como archivos adjuntos.

Cdigo del 007 Tipo Funcional.

requerimiento requerimiento
No

200
 funcional.

Nombre o Cargar formatos Alta

funcin Prioridad Media
Baja
Entradas y El sistema debe tener todos los formatos cargados y especificadas en cada
salidas una de las secciones.

Pre-
Condicin

Post- Almacenamiento de los formatos en el sistema.

Condicin

Descripcin del requerimiento

1. El usuario selecciona una de las fases del proyecto.
2. El sistema muestra la lista de formatos disponibles y frente a este deber estar la opcin de
cargar el formato diligenciado.
3. Si el formato ya se encuentra cargado el sistema deber mostrar una advertencia donde informe
Advertencia, el formato ya se encuentra modificado, desea sobre escribir este archivo
4. Si es subido un archivo por primera vez deber cambiar el estado a diligenciado para ser
mostrado en verde en la lista de formatos diligenciados.

Nota: el sistema deber obligar a que algunos formatos deben ser cargados en formatos .zip estos son

1P-001-Acuerdos de nivel de servicio

2E-001-Informe resultados aplicacin tcnica elicitacion
3A-001-Check list de requerimientos.
4E-001-Historia de usuario.
5V-001-Check list de validacin de prototipo.
5V-002-Inspeccion interna SRS
5V-003-REVISIN RESULTADOS INSPECCIN INTERNA SRS - SOFTWARE
REQUIREMENTS SPECIFICATION
5V-004-Formato de observaciones sesin de validacin de requerimientos
5V-005-Formato de recoleccin objetivo stakeholders proceso de negociacin.
5V-006-Formato resultado sesin de negociacin de requerimientos.
5V-007-Acta de reunin validacin y negociacin de requerimientos.
6E-001-Peticion de cambio.
6E-002-Acta de reunin rechazo propuesta desarrollo de cambio.
6C-003-Acta de aceptacin de la propuesta de desarrollo de cambios solicitados

Cdigo del 008 Tipo Funcional.

requerimiento requerimiento No funcional.

201
Nombre o Mostrar advertencia de formatos sin llenar Alta
Prioridad Media
funcin
Baja
Entradas y El sistema debe tener todos los formatos cargados en el sistema y conocer
salidas la lista de formatos que han sido llenados por fase.

Pre-
Condicin

Post-
Condicin

Descripcin del requerimiento

1. El usuario selecciona una de las fases disponibles en el men.

El sistema deber consultar si los formatos de las fases anteriores han sido diligenciados en su totalidad
(Los obligatorios) si esos no han sido llenados deber ser mostrada una advertencia donde se indique que
an falta formatos por llenar y deber indicar de que fases hace falta por diligenciar formatos.

Acuerdo legal

Entre las partes acordamos haber ledo el documento y comprendemos las acciones que se
realizaran y se procede a la firma el da 31 del mes de Abril del ao 2015

Representante empresa
Cliente
Firma. Nombre:
C.C

Firma.
C.C

202
 21.ANEXO 6: INSTRUMENTO DE VALIDEZ DE CONTENIDOS

UNIVERSIDAD TECNOLOGIA DE PEREIRA

FACULTAD DE INGENIERIA
MAESTRIA EN INGENIERIA DE SISTEMAS Y
COMPUTACION

Pereira (Risaralda-Colombia), Abril de 2015

Estimado (a) seor (a):

El motivo de la presente es solicitar su valiosa colaboracin para realizar la validacin de la

Metodologa para la adquisicin y gestin de requerimientos funcionales y no funcionales
en el desarrollo de software para las pequeas empresas (pyme) de la zona del
departamento de Risaralda, diligenciando el formulario anexo.
Acudo a usted debido a sus conocimientos y experiencias en la materia, los cuales
aportaran una til y completa informacin para la culminacin exitosa de este trabajo de
investigacin.
Gracias por su valioso aporte y participacin
Atentamente,

Cristian Andres De la cruz Londoo

Gustavo Andres Castro Guevara

203
 INSTRUCCIONES

A) Lea detenidamente las preguntas antes de responder.

B) Este instrumento de validacin consta de una primera parte de identificacin del experto,
seguidamente otra en donde se identifica las alternativas de respuesta del cuestionario
objeto de esta validacin. Luego se encuentra una seccin en la que se pide el juicio de
experto con respecto al cuestionario, la cual est formada por doce preguntas, cuyas
respuestas son: no cumple, bajo nivel, moderado nivel y alto nivel.
C) Seguido del juicio del experto se solicita una opinin sobre el instrumento diseado.

IDENTIFICACION DEL EXPERTO

INFORMACIN BSICA
Nombre(s):
Apellido(s):
Institucin donde
labora:

FORMACIN ACADMICA
Ttulo de pregrado:
Institucin donde curso el
pregrado:
Ttulo de postgrado:
Institucin donde curso el
postgrado:
Trabajos publicados:

204
 INSTRUCTIVO PARA CUSTIONARIO
De acuerdo con los siguientes indicadores califique cada uno de los tems segn corresponda.

CATEGORIA CALIFICACION INDICADOR

SUFICIENCIA 1. No cumple con el criterio La metodologa no cumple el tem evaluado.
La metodologa cumple 2. Bajo Nivel La metodologa cumple algunos aspectos del tem evaluado pero no
suficientemente el tem a evaluar. corresponden totalmente.
3. Moderado nivel La metodologa cumple la mayora de aspectos claves del tem
evaluado pero debe incrementar el nivel de suficiencia para ser
completo.
4. Alto nivel La metodologa cumple completamente el tem evaluado.
CLARIDAD 1. No cumple con el criterio En la metodologa, el tem a evaluar no es claro
En la metodologa, el tem se 2. Bajo Nivel En la metodologa, el tem requiere bastantes modificaciones o una
comprende fcilmente, es decir, modificacin muy grande en el uso de las palabras de acuerdo con
su sintctica y semntica son su significado o por la ordenacin de las mismas.
adecuadas 3. Moderado nivel En la metodologa, se requiere una modificacin muy especfica de
algunos de los trminos del tem.
4. Alto nivel En la metodologa, el tem es claro, tiene semntica y sintaxis
adecuada.
COHERENCIA 1 No cumple con el criterio En la metodologa, el tem evaluado no tiene coherencia
En la metodologa el tem 2. Bajo Nivel En la metodologa, el tem evaluado tiene poca coherencia
evaluado es coherente. 3. Moderado nivel En la metodologa, el tem evaluado tiene moderada coherencia. Se
debe mejorar aspectos menores
4. Alto nivel En la metodologa, el tem evaluado tiene total coherencia
RELEVANCIA 1. No cumple con el criterio En la metodologa, el tem puede ser eliminado sin que se vea
En la metodologa el tem es afectado el proceso de ingeniera de requerimientos.
esencial o importante, es decir 2. Bajo Nivel En la metodologa, el tem tiene poca relevancia o puede estar
debe estar incluido. incluido dentro de otro item
3. Moderado nivel En la metodologa, el tem es relativamente importante
4. Alto nivel En la metodologa, el tem es muy relevante

205
 SUFICIENC

CLARIDAD
COHEREN

RELEVAN
CIA
IA
Nro ITEM OBSERVACIONES
CIA

1 La metodologa permite abstraer los requerimientos que en ocasiones son

obvios para cliente, y que adems generan omisin y vaguedad de
informacin.
2 La metodologa permite aumentar usabilidad y generar diseos centrados en el
usuario.
3 La metodologa explica y define como deben ser usadas las diversas tcnicas
de elicitacin de requerimientos.
4 La metodologa define como hacer documentacin y gestin de
requerimientos a lo largo del proyecto, a la vez hacer trazabilidad de los
requerimientos.
5 La metodologa define como realizar validar los requerimientos.
6 La metodologa define como realizar negociacin y as solucionar des-
acuerdos entre los stakeholders.
7 La metodologa define los recursos humanos que son necesarios para realizar
el proceso de ingeniera de requerimientos
8 La metodologa presenta las herramientas que permite dar soporte al proceso
de ingeniera de requerimientos.
9 La metodologa define como manejar los cambios de alcance en los
requerimientos.
10 La metodologa define como generar mayor compromiso con la fase de
ingeniera de requerimientos por parte del cliente.
11 La metodologa define como realizar estimacin de tiempo con base en los
requerimientos obtenidos.
12 Teniendo presente los inconvenientes encontrados inicialmente en las

206
empresas desarrolladoras de software (pgina 3 documento resumen ejecutivo
de la metodologa), al aplicar la metodologa a un proyecto disminuye los
costos de produccin, numero de errores cometidos durante el desarrollo y el tiempo
que se tarda en realizar el producto.

207
 22.BIBLIOGRAFA

[1] F. McGovern, Managing Software Projects with Business - Based Requirements,

Dublin: IEEE Computer Society, 2002.

[2] A. &. S. E. Alarcon, Herramientas case para la ingenieria de requisitos, 2008.

[3] L. Antonelli y A. Oliveros, Fuentes utilizadas por desarrolladores de software en

Argentina para elicitar requerimientos, Laboratorio de investigacion LIFIA, Buenos
Aires, 2002.

[4] W. Aurum, Engineering and managing software requeriments, Sydney, Australia:

Springer, 2005.

[5] P. Bourque y R. E. Fairley, SWEBOK, California: IEEE Computer Society, 2004.

[6] O. C. Z. Gotel y A. C. W. Finkelstein, An Analysis of the Requirements Traceability

Problem, de Requirements Engineering, 1994., Proceedings of the First International
Conference on, Londres, 1994.

[7] A. N. Camacho Zambrano, Herramienta para el anlisis de requerimientos dentro de

la pequea empresa desarrolladora de software en Bogot., Bogota, 2005.

[8] A. Umber y I. Bajwa, Minimizing Ambiguity in Natural Language Software

Requirements Specification, Digital Information Management (ICDIM), 2011.

[9] T. Y. Q. J. X. &. Z. X. Gao, A Process Model of Software Evolution Requirement

Based on Feedback, Information Technology, Computer Engineering and Management
Sciences (ICM), 2011.

[10 L. Merchan, A. Urrea y R. Rebollar, Definicin de una metodologa agl de ingenieria

] de requerimientos para empresas emergentes de desarrollo de software del su occidente
colombiano, Revista cientfica Guillermo de Ockham, pp. 37-50, 2008.

[11 M. M. S. L. O. S. R. R. Quispe. A, XXIX International Conference of the Chilean

] Computer Science Society, de Requirements Engineering Practices in Very Small
Software Enterprises: A Diagnostic Study, Santiago de chile, 2010.

[12 L. Y. C. E. R. M. F. A. Mauro Callejas Cuervo, Heler: Una herramienta para la

] ingeniera de requisitos automatizada, 2010.

[13 W. Yu, Verifying Software Requirements: A Requirement Tracing Methodology and

] Its Software Tool, IEEE Journal on IEEE Xplore, 1994.

208
[14 V. L. J. B. V. Porter. A, Comparing Detection Methods for Software requirements
] Inspections: A Replicated Experiment, Software Engineering, IEEE Transactions,
1995.

[15 J. J. Lin y Y.-S. Lin, Collaborative Requirement Management System Developed for
] CMMI-Coherent Software Engineering, de Proceedings of the 2007 11th
International Conference on Computer Supported Cooperative Work in Design,
Taiwan, 2007.

[16 M. E. T. M. Nicols Aristizbal Meja, Tcnicas de Levantamiento de

] Requerimientos con Innovacin, Cuarto Congreso Colombiano de Computacin
4CCC, 2009.

[17 N. Herrmann, http://www.hbdi.com/, [En lnea]. Available:

] http://www.hbdi.com/uploads/100024_articles/100543.pdf. [ltimo acceso: 28 03
2015].

[18 R. Hernndez Sampieri, C. Fernndez Collado y P. Baptista Lucio, Metodologia de la

] investigacion, Mexico, D.F: Mc Graw Hill, 2008.

[19 L. Westfall , Las fallas en la ingeniera de requisitos, Revista facultad de ingenierias

] USBMed, vol. 2, n 2, pp. 40-47, 2011.

[20 J. Tramullas Saz, El diseo centrado en el usuario para la creacin de productos y

] servicios de informacin digital, Revista Iberoamericana sobre usuarios de
Informacin Forinf@ Online, pp. 6-14, 2004.

[21 S. Zapata, Efectividad de Tcnicas Tradicionales de Elicitacin de Requisitos de

] Software., Universidad de la Matanza Estado: Tesis concluida, Buenos Aires, 2012.

[22 T. Granollers, MPIu+a Modelo de Proceso de la Ingeniera de la usabilidad y de la

] accessibilidad, Granollers, Toni, nd. n.d 2014. [En lnea]. Available:
http://www.grihotools.udl.cat/mpiua/fases-mpiua/analisis-de-requisitos/. [ltimo
acceso: 1 Octubre 2014].

[23 D. H. Carrizo Moreno, Marco para la seleccin de tcnicas de educcion de

] requisitos, Sin Editorial, Madrid, 2009.

[24 J. Aranda, S. Easterbrook y G. Wilson, Requirements in the wild: How small

] companies do it, de IEEE International Conferenceon Requirements Engineering,
New delhi, 2007.

[25 G. N. Aranda, A. Vizcano, A. G. N. Cechich, A. Vizcano y A. Cechich, Mejora del

] Proceso de Elicitacin de Requisitos en Proyectos GSD, Sin Editorial, Buenos Aires,
2007.

[26 A. Talbot y A. Connor, Requirements Engineering Current Practice and Capability in

209
] Small and Medium Software Development Enterprises in New Zealand, de
Conference on Software Engineering Research, Management and Applications, New
Zealand, 2011.

[27 A. M. Hickey y A. M. Davis, Elicitation Technique Selection: How Do Experts Do

] It?, de IEEE International Requirements Engineering Conference, Colorado, 2003.

[28 I. Sommerville, Ingeniera del software, Madrid: Personal Education, 2005.

]

[29 M. Arias Chaves, La ingeniera de requerimientos y su importancia en el desarrollo

] de proyectos de software, Revista InterSedes Universidad de Costa Rica, vol. 6, n
10, p. n.d, 2007.

[30 M. d. L. Perez Huebe, Monografa: Ingenieria de requerimientos, Sin editorial,

] Pachuca, 2005.

[31 L. F. Medina Cardona, Caracterizacin del proceso y herramientas metodolgicas de

] la ingeniera de requerimientos para aplicaciones de sistemas de informacin
geogrfica, Revista ingenieria e investigacion, vol. 27, n 1, pp. 123-131, 2007.

[32 M. Manies y U. Nikual, La elicitacin de requisitos en el contexto de un proyecto de

] software., Revista Facultad de Ingenieras USBMed, vol. 2, n 2, pp. 25-29, 2011.

[33 M. A. Crow, Lider de proyecto.com, nd Octubre 2009. [En lnea]. Available:

] http://www.liderdeproyecto.com/articulos/identificar_stakeholders_por_que_molestars
e_en_esto.html.

[34 E. B. Herreras, Analisis de necesidades en el proceso de diseo de un programa de

] orientacin, 5 Julio 2007. [En lnea]. Available: https://
revistas.utp.edu.co/index.php/repes/article/download/5321/2591. [ltimo acceso: 9
Febrero 2015].

[35 R. S. Pressman, Ingenieria de software. Un enfoque prctico, Madrid, Espaa: MC

] Graw Hill, 1994.

[36 D. G. Pea, Elementos bsicos de ingeniera del software, 2007: Instituto Tecnolgico
] Metropolitano (ITM).

[37 Carnegie Mellon University, http://www.sei.cmu.edu Software Engineering Institute

] (SEI), [En lnea]. Available: http://www.sei.cmu.edu/library/assets/cmmi-dev-v12-
spanish.pdf. [ltimo acceso: 28 03 2015].

[38 T. Granollers I Saltiveri, MPIu+a. una metodologa que integra la ingeniera del
] software, la interaccin personaordenador y la accesibilidad en el contexto de equipos
de desarrollo multidisciplinares, Universidad de Lleida, Lerida, 2004.

210
[39 Universidad del Cauca, [En lnea]. Available:
] http://artemisa.unicauca.edu.co/~ecaldon/docs/spi/COMPETISOFT_v02_27-
11_2315.pdf. [ltimo acceso: 28 03 2015].

[40 A. d. J. A. K. M. P. R. T. A. v. d. V. T. V. Jan van Bon, Fundamentos de ITIL,

] Volume 3, Van Haren Publishing , 2008.

[41 A. e. al, SOMA: a method for developing service-oriented solutions, IBM Systems,
] 2008.

[42 Consejo Superior de Administracin Electrnica, Mtrica v3. Metodologa de

] Planificacin, desarrollo y Mantenimiento de sistemas de Informacin, [En lnea].
Available: http://www.csi.map.es/csi/metrica3/index.html. [ltimo acceso: 28 03
2015].

[43 Universidad Tecnolgica Equinoccial, REINGENIERA EN LOS PROCESOS DE

] NEGOCIOS, [En lnea]. Available:
http://repositorio.ute.edu.ec/bitstream/123456789/9158/12/17740_9.pdf. [ltimo
acceso: 16 02 2015].

[44 Evaluando Software, Cmo alinear a todos los involucrados en un proyecto, 10 07

] 2009. [En lnea]. Available: http://www.evaluandosoftware.com/seccion-33-docs-libre-
acceso.html. [ltimo acceso: 13 02 2015].

[45 A. d. J. A. K. M. P. A. V. D. V. R. T. T. V. Jan Van Bon, Operacion del Servicio:

] basada en ITIL V3 guia de gestion, Van Haren Publishing, Zaltbommel, 2008.

[46 J. R. S. WETZEL, APLICACIN DE LEAN MANAGEMENT AL CICLO DE

] MADURACIN EN UNA, Santiago de Chile, 2008.

[47 J. L. V. J. J. C. D. Toni Granollers i Saltiveri, Diseo de sistemas interactivos

] centrados en el usuario, Barcelona: Editorial UOC, 2005.

[48 M. Rettig, Prototyping for Tiny Fingers, Communications of the ACM, vol. 37, n 4,
] pp. pgs. 21-27., 1994.

[49 M. R. Perez, Evaluacin de herramientas para prototipado de sistemas interactivos,

] 2010.

[50 O. A. B. Sandra Patricia Forigua, PROPUESTA DE UN MODELO DE ANLISIS

] PARA ESTIMACIN DEL TAMAO DEL SOFTWARE Y GESTIN DE COSTOS
Y RIESGOS A PARTIR DE REQUERIMIENTOS FUNCIONALES, 07 2007. [En
lnea]. Available: http://pegasus.javeriana.edu.co/~riesgors/tesis%20definitiva_4-
11.pdf. [ltimo acceso: 22 02 2015].

[51 R. Mulcahy, PMP EXAM PREP, RMC Publications, 2013.

211
]

[52 W. Brown, COCOMO II Model Definition Manual, Center for Software Engineering,
] 2000.

[53 A. A. M. E. C. Q. M. C. Y. J. H. H. E. Q. T. Kenny Acuache Yalle, Ciclo de vida y

] Metodologas de Desarrollo de Software, Universidad Nacional San Luis Gonzaga
de ICA.

[54 L. F. Campo Amaya, Marco metodologico para la administracion de proyectos de

] software utilizando las mejores practicas propuestas por el modelo CMMI-DEV
version 1.2, Universidad del Norte, Barranquilla, 2008.

[55 LeanStarUp.es, QU ES UNA START-UP?, Nd Nd Nd. [En lnea]. Available:

] http://www.leanstart.es/que-es-start-up/. [ltimo acceso: 2015 Enero 30].

[56 A. Cockburn, Alistair Cockburn, Skybend, 04 Diciembre 1999. [En lnea].

] Available: http://alistair.cockburn.us/Cockburn+Scale. [ltimo acceso: Febrero 9
2015].

[57 Gestin de proyectos y desarrollo de software, Jummp, Desarrollo de software.

] Escala Cockburn de clasificacin de proyectos, 16 Mayo 2011. [En lnea]. Available:
https://jummp.wordpress.com/2011/05/16/desarrollo-de-software-escala-cockburn-de-
clasificacion-de-proyectos/. [ltimo acceso: 26 Enero 2015].

[58 Wikipedia contributors, Cockburn Scale, Wikipedia, The Free Encyclopedia., 9

] Marzo 2014. [En lnea]. Available:
http://en.wikipedia.org/w/index.php?title=Cockburn_Scale&oldid=598775969.
[ltimo acceso: 9 Febrero 2015].

[59 Jummp, Desarrollo de software. Escala Cockburn de clasificacin de proyectos, n.d,

] 16 Mayo 2011. [En lnea]. Available:
https://jummp.wordpress.com/2011/05/16/desarrollo-de-software-escala-cockburn-de-
clasificacion-de-proyectos/. [ltimo acceso: 09 Febrero 2015].

[60 E. Mejia, Slideshare, Analisis de interesados(Stakeholders), 25 Mayo 2007. [En

] lnea]. Available: http://es.slideshare.net/jernestomejia/2-analisis-de-los-interesados-
stakeholders. [ltimo acceso: 28 Enero 2015].

[61 Corporate Excellence Centre for Reputation Leadership, Identificar y priorizar

] stakeholders, clave para una buena gestin de crisis, Julio 2011. [En lnea]. Available:
http://www.corporateexcellence.org/index.php/Centro-de-conocimiento/Identificar-a-
los-stakeholders-clave-para-la-gestion-de-crisis. [ltimo acceso: 28 Enero 2015].

[62 S. Martinez, Calidad de proyectos y gestion de servicios informaticos, Analisis de

] stakeholders, 04 Diciembre 2011. [En lnea]. Available:
http://smartinez.me/2011/12/analisis-de-stakeholders/. [ltimo acceso: 29 Enero

212
 2015].

[63 L. Castaeda Bueno, Elicitacin de requerimientos, Biblioteca Digital Icesi, 2010.

] [En lnea]. Available:
https://bibliotecadigital.icesi.edu.co/biblioteca_digital/bitstream/item/4084/1/Presentac
ion_requerimientos_software.pdf. [ltimo acceso: 26 Enero 2015].

[64 Springer, Engineering and Managing Software Requirements, Springer, nd nd 2005.

] [En lnea]. Available:
http://www.springer.com/gp/book/9783540250432#aboutAuthors. [ltimo acceso:
2015 Marzo 04].

[65 T. Granollers, Prototipado, MPIu+a Modelo de Proceso de la Ingeniera de la

] usabilidad y de la accessibilidad, n.d n.d n.d. [En lnea]. Available:
http://www.grihotools.udl.cat/mpiua/fases-mpiua/prototipado/. [ltimo acceso: 2
Marzo 2015].

[66 M. A. Laguna, Miguel A. Laguna Departamento de informatica, 13 Octubre 2009.

] [En lnea]. Available: http://www.infor.uva.es/~mlaguna/is1/apuntes/2-requisitos.pdf.
[ltimo acceso: 16 Febrero 2015].

[67 Universidad Politecnica de Madrid - Departamento de Lenguajes y Sistemas

] Informticos e Ingeniera del Software, Anlisis de Requisitos Software, 31 Octubre
2006. [En lnea]. Available:
http://is.ls.fi.upm.es/docencia/masterTI/ARS/docs/Manual_M2C1U06.pdf. [ltimo
acceso: 6 Febrero 2015].

[68 F. Ruiz, Ingeniera de Software I, Nd Nd 2009. [En lnea]. Available:

] http://www.ctr.unican.es/asignaturas/is1/is1-t03-trans.pdf. [ltimo acceso: 5 Febrero
2015].

[69 Project Management Institute, Inc, Fundamentos para la direccin de proyectos (Guia
] del PMBOK), de Fundamentos para la direccin de proyectos (Guia del PMBOK),
Newtown Square, Pennsylvania, Project Management Institute, 2005, pp. 95, 101.

[70 INCOSE, http://www.incose.org/, [En lnea]. Available:

] https://www.innoslate.com/incose-requirements-management-tool-survey-response/.
[ltimo acceso: 27 04 2015].

[71 M. J. P. S. Francisca Rosique, Evaluacin de herramientas de gestin de requisitos,

] III Jornadas de Introduccin a la Investigacin de la UPCT .

[72 Colaboradores de Wikipedia, Especificacin de requisitos de software, Wikipedia,

] La enciclopedia libre., 02 Marzo 2015. [En lnea]. Available:
http://es.wikipedia.org/w/index.php?title=Especificaci%C3%B3n_de_requisitos_de_so
ftware&oldid=80341402. [ltimo acceso: 02 Abril 2015].

213
[73 Real Academia Espaola , Real Academia Espaola, Real Academia Espaola, nd
] Nd 2012. [En lnea]. Available: http://lema.rae.es/drae/. [ltimo acceso: 02 Abril
2015].

[74 DeChile, Etimologa de modelo, De chile, Octubre 2014. [En lnea]. Available:
] http://etimologias.dechile.net/?modelo. [ltimo acceso: 02 Abril 2015].

[75 DeChile, Etimologia de especfico, De chile, Nd Octubre 2014. [En lnea].

] Available: http://etimologias.dechile.net/?especi.fico. [ltimo acceso: 02 Abril 2015].

[76 S. Rivadeneira, G. Vilanova, M. Miranda y D. Cruz, El modelado de requerimientos

] en las metodologas giles, de XV workshop de investigadores en ciencias de la
computacin, Parana, 2013.

[77 Colaboradores de Wikipedia, Historias de usuario, Wikipedia, La enciclopedia

] libre., 08 Octubre 2013. [En lnea]. Available:
http://es.wikipedia.org/w/index.php?title=Historias_de_usuario&oldid=70080633.
[ltimo acceso: 07 Abril 2015].

[78 Universidad de los Andres, CSOF5101: Conceptos Avanzados de Ingeniera de

] Software, (s.f) (s.f) (s.f). [En lnea]. Available:
https://sistemas.uniandes.edu.co/~csof5101/dokuwiki/lib/exe/fetch.php?media=princip
al:csof5101-agiles.pdf. [ltimo acceso: 07 Abril 2015].

[79 S. Lawrence Pfleeger, Ingeniera del software teora y prctica, de Ingeniera del
] software teora y prctica, Buenos Aires, Prentice hall, 2002, pp. 155-221.

[80 J. A. Gutierrez Orozco, Maquinas de estado finito, 22 Agosto 2008. [En lnea].
] Available:
http://uncomp.uwe.ac.uk/genaro/Papers/Veranos_McIntosh_files/alejandroFinal2008.p
df. [ltimo acceso: 12 Abril 2015].

[81 Colaboradores de Wikipedia, Autmata finito, Wikipedia, La enciclopedia libre., 13

] Noviembre 2014. [En lnea]. Available:
http://es.wikipedia.org/w/index.php?title=Aut%C3%B3mata_finito&oldid=78122434.
[ltimo acceso: 11 Abril 2015].

[82 M. Crsti, Facultad de Ciencias Exactas, Ingeniera y Agrimensura, SF Marzo 2015.

] [En lnea]. Available: http://www.fceia.unr.edu.ar/asist/z-a.pdf. [ltimo acceso: 12
Abril 2015].

[83 C. Sifaqui, Clase-13-91020072243 lenguaje z, 09 Octubre 2007. [En lnea].

] Available: http://www.academia.edu/4715568/Clase-13-91020072243_lenguaje_z.
[ltimo acceso: 11 Abril 2015].

[84 M. d. l. A. Ferraro., Modelamiento Orientado a Objetos, Universidad Nacional de

NordEste, 06 Octubre 2013. [En lnea]. Available:

214
] http://exa.unne.edu.ar/informatica/anasistem2/public_html/apuntes/maf/cap4.htm.
[ltimo acceso: 10 Abril 2015].

[85 E. Miranda, Introduccin a las redes de petri, Revista telegrafica electronica, vol.
] 76, n 890, p. 2002, 1987.

[86 K. Shaver, 9 Excellent Tools for Design Mockups, Mashable, 07 Junio 2012. [En
] lnea]. Available: http://mashable.com/2012/06/07/mockup-tools/. [ltimo acceso: 13
Abril 2015].

[87 S. M. Massa, Objetos de aprendizaje: metodologa de desarrollo y evaluacin de la

] calidad, Tesis doctoral, Universidad Nacional de la Plata, 2012.

[88 A. Dix, Human-Computer Interaction, New Jersey: Prentice Hal, 1993.

]

[89 U. D. d. i. d. s. -. U. P. d. Madrid, Universidad Politcnica de Madrid, [En lnea].

] Available: http://is.ls.fi.upm.es/docencia/masterTI/ARS/docs/Manual_M2C1U11.pdf.
[ltimo acceso: 16 04 2015].

[90 A. D. M. T. B. Bernrdez, UNA PROPUESTA PARA LA VERIFICACIN DE

] REQUISITOS BASADA EN MTRICAS, Revista de Procesos y Mtricas de las
Tecnologas de la Informacin (RPM), 2014.

[91 K. Pohl, Requirements Engineering: An Overview, Encyclopedia of Computer

] Science and Technology, 1997.

[92 B. B. Jimnez, Una Aproximacin Emprica a la Verificacin de Especificaciones de

] Requisitos para Sistemas de Informacin, Tesis doctoral - Universidad de Sevilla,
2003.

[93 IEEE, IEEE Standard Glossary of Software Engineering Terminology, Institute of

] Electrical and Electronics, 1990.

[94 A. D. Toro, Un entorno metodolgico de ingeniera de requisitos para sistemas de

] informacin, Universidad del Sevilla, 2000.

[95 J. C. R. LEAL, Apropiacin de tcnicas de elicitacin de conocimiento y de

] comunicacin personalizadas para potenciar el proceso de Ingeniera de Requisitos,
Universidad EAFIT, Escuela de Ingeniera Departamento de Informtica y Sistemas -
Maestra en Ingeniera, 2013.

[96 E. S, Handling conflict between domain descriptions with computer supported

] negotiation., Knowledge Acquisition: An International Journal, 1991.

[97 S. J. N. ,. P. K. Gregory Kersten Kersten, Negotiation Via the World Wide Web: A

215
] Cross-Cultural Study of Decision Making, 1999.

[98 S. AG, User-Centred Requirements Engineering, Springer, London, 2002.

]

[99 H. I. Barry Boehm, Identifiing Quality - H Requirement Conflicts, University of

] Southern California, 1996.

[10 W. D. Leffingwell D, Managing software requirements - A unified approach, Addison

0] Wesley, 1999.

[10 M. d. A. Pblicas, Portal administracin electrnica, [En lnea]. Available:

1] http://administracionelectronica.gob.es/pae_Home/dms/pae_Home/documentos/Docu
mentacion/Metodologias-y-
guias/Metricav3/METRICA_V3_Gestion_de_Proyectos.pdf. [ltimo acceso: 26 04
2015].

[10 S. B. Robert Arnold, Software Change Impact Analysis, IEEE Computer Society Press,
2] 1996.

[10 Colaboradores de Wikipedia, Ingeniera de requisitos, Wikipedia, La enciclopedia

3] libre., 26 Noviembre 2014. [En lnea]. Available:
http://es.wikipedia.org/w/index.php?title=Ingenier%C3%ADa_de_requisitos&oldid=7
8381222. [ltimo acceso: 16 Marzo 2015].

[10 M. Ruiz Carreira y i. Ramos Roman, Estimacion del coste de la calidad del software a
4] travez de la simulacion del proceso de desarrollo, Revista colombiana de
computacion, vol. 2, n 1, pp. 75-78, 2001.

[10 C. Tom, The project management hut, PM Hut - an itoctopus project, 21 Octubre
5] 2008. [En lnea]. Available: http://www.pmhut.com/requirements-traceability-matrix-
rtm. [ltimo acceso: 2015 Febrero 19].

[10 Universidad de Cantabria, Prcticas, 14 Marzo 2011. [En lnea]. Available:

6] http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-i/practicas-1/.
[ltimo acceso: 13 Febrero 2015].

[10 Metodologa Gestin de Requerimientos, Tcnicas para Identificar Requisitos

7] Funcionales y No Funcionales, 4 Febrero 2015. [En lnea]. Available:
https://sites.google.com/site/metodologiareq/capitulo-ii/tecnicas-para-identificar-
requisitos-funcionales-y-no-funcionales.

[10 Scrum Manager Body Of Konwledge, Historia de usuario, Scrum Manager Body Of
8] Konwledge, 23 Marzo 2014. [En lnea]. Available:
http://www.scrummanager.net/bok/index.php?title=Historia_de_usuario&oldid=929.
[ltimo acceso: 07 Abril 2015].

216
[10 J. L. Mat, Requirements Engineering for sociotechnical systems., Idea Group Inc.,
9] Nd, 2005.

[11 S. Robertson y J. Robertson , Mastering the Requirements Process: Getting

0] Requirements Right., Westford: Pearson Education, Inc, 2012.

[11 J. Estevez Delgado y G. Estevez Delgado, universidad michoacana de san nicolas de

1] hidalgo, 17 Febrero 2013. [En lnea]. Available:
http://dieumsnh.qfb.umich.mx/estadistica/media_pond.htm. [ltimo acceso: 20
Septiembre 2014].

[11 L. Mrquez Zambrano, ALDEA JUAN JOSE RONDON, nd Abril 2011. [En lnea].
2] Available: http://cesarguerra10.files.wordpress.com/2011/04/material-estadc3adstica-
i.pdf. [ltimo acceso: 01 Septiembre 2014].

[11 Otherswise, Diferenciando entre un sketch, mockup, wireframe y prototipo,

3] Otherswise, 08 Abril 2014. [En lnea]. Available:
http://www.otherwiseonline.net/diferencias-entre-sketch-mockup-wireframe-
prototipo/. [ltimo acceso: 13 Abril 2015].

[11 M. B. Chrissis, M. Konrad y S. Shrum, Gua para la integracin de procesos, Madrid:

4] Ctedra de Mejora de Procesos de Software en el Espacio Iberoamericano de la
Universidad Politcnica de Madrid, 2009.

[11 Real Academia Espaola, Diccionario panhispnico de dudas, Real Academia

5] Espaola, Nd Nd 2005. [En lnea]. Available:
http://lema.rae.es/dpd/srv/search?key=elicitar. [ltimo acceso: 2015 Abril 21].

217