TRABAJO DE GRADO

Vista previa del material en texto

OPTIMIZACIÓN DEL PROCESO PARA LEVANTAMIENTO DE 
REQUERIMIENTOS FUNCIONALES EN LA EMPRESA GODOWORKS 
 
 
 
 
 
 
JUAN PABLO ROA FRAGOZO 
 
 
 
 
 
 
 
UNIVERSIDAD CATÓLICA DE COLOMBIA 
FACULTAD DE INGENIERÍA 
PROGRAMA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN 
BOGOTÁ D.C, COLOMBIA 
2023 
 
 
OPTIMIZACIÓN DEL PROCESO PARA LEVANTAMIENTO DE 
REQUERIMIENTOS FUNCIONALES EN LA EMPRESA GODOWORKS 
 
 
 
 
JUAN PABLO ROA FRAGOZO 
 
 
 
 
Trabajo de Grado para optar al título de 
INGENIERO DE SISTEMAS Y COMPUTACIÓN 
 
 
Asesor: GERMAN RICARDO RODRIGUEZ 
grrodriguez@ucatolica.edu.co 
 
 
 
 
UNIVERSIDAD CATÓLICA DE COLOMBIA 
FACULTAD DE INGENIERÍA 
PROGRAMA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN 
BOGOTÁ D.C, COLOMBIA 
2023 
3 
 
 
 
https://creativecommons.org/licenses/by-nc-nd/4.0/deed.es 
4 
 
 
 NOTA DE ACEPTACIÓN 
 
______________________________ 
______________________________ 
______________________________ 
______________________________ 
______________________________ 
 
 
 
 
 
 
 
_____________________________ 
 Firma del Jurado 
 
 
 
 
_____________________________ 
 Firma del Jurado 
 
 
 
 
 
 
_____________________________ 
 MBA. GERMAN RICARDO R.R 
 Asesor 
 
 
5 
 
TABLA DE CONTENIDO 
1. INTRODUCCIÓN ............................................................................................ 13 
2. JUSTIFICACIÓN ............................................................................................. 15 
2.1 IMPACTO ORGANIZACIONAL ................................................................ 18 
3. PLANTEAMIENTO DEL PROBLEMA ............................................................. 23 
3.1 CONTEXTUALIZACIÓN DE LA EMPRESA ............................................. 23 
3.1.1 GoDoWork SERVICES. ..................................................................... 23 
3.1.2 GoDoWork TRADE. ........................................................................... 24 
3.2 MODELO DE CICLO DE VIDA DEL SOFTWARE IMPLEMENTADO EN 
GODOWORKS ................................................................................................... 24 
3.3 FORMULACIÓN DEL PROBLEMA .......................................................... 26 
3.4 PREGUNTA PROBLEMA ......................................................................... 28 
4. OBJETIVOS .................................................................................................... 29 
4.1 OBJETIVO GENERAL .............................................................................. 29 
4.2 OBJETIVOS ESPECÍFICOS ..................................................................... 29 
5. MARCO CONCEPTUAL ................................................................................. 30 
6. MARCO TEÓRICO ......................................................................................... 37 
6.1 INGENIERÍA DE REQUERIMIENTOS...................................................... 37 
6.1.1 Analizar la concepción del sistema. ................................................... 38 
6.1.2 Indagar cuál debe ser el propósito del software. ................................ 38 
6.1.3 Recrear posibles escenarios. ............................................................. 38 
6.1.4 Negociar con el cliente. ...................................................................... 38 
6.1.5 Especificar el funcionamiento. ............................................................ 39 
6.1.6 Validar el funcionamiento de los requerimientos. ............................... 39 
6.1.7 Administrar los requerimientos. .......................................................... 39 
6.2 REQUERIMIENTOS ................................................................................. 40 
6.2.1 Requerimientos Funcionales. ............................................................. 40 
6.2.2 Requerimientos no Funcionales. ........................................................ 40 
6.3 CARACTERÍSTICAS DE LOS REQUERIMIENTOS ................................ 40 
6.4 IMPORTANCIA DE SELECCIONAR UNA BUENA TÉCNICA DE 
LEVANTAMIENTO DE REQUERIMIENTOS ...................................................... 43 
6 
 
6.5 TÉCNICAS DE RECOPILACIÓN DE REQUERIMIENTOS ...................... 43 
6.5.1 Prototipo. ............................................................................................ 43 
6.5.2 Modelado. .......................................................................................... 44 
6.5.3 Etnografía u Observación. .................................................................. 45 
6.5.4 Entrevista. .......................................................................................... 46 
6.5.5 Tormenta de ideas. ............................................................................ 47 
6.5.6 Historias de usuario. ........................................................................... 47 
6.6 CALIDAD DE SOFTWARE ....................................................................... 47 
6.6.1 Modelo ISO/IEC 25000. ..................................................................... 48 
6.6.1.1 ISO/IEC 2500n. ............................................................................ 48 
6.6.1.2 ISO/IEC 2501n. ............................................................................ 48 
6.6.1.3 ISO/IEC 2502n. ............................................................................ 48 
6.6.1.4 ISO/IEC 2503n. ............................................................................ 48 
6.6.1.5 ISO/IEC 2504n. ............................................................................ 49 
6.6.2 Metodología de calidad CMMI. ........................................................... 49 
6.6.2.1 Inicial o Nivel 1. ............................................................................ 50 
6.6.2.2 Gestionado o Nivel 2. .................................................................. 50 
6.6.2.3 Definido o Nivel 3. ........................................................................ 51 
6.6.2.4 Gestionado cuantitativamente o Nivel 4. ..................................... 51 
6.6.2.5 Optimizado o en Optimización Continua o Nivel 5. ...................... 51 
6.6.3 McCall. ............................................................................................... 51 
6.7 CALIDAD A NIVEL DE PROCESO ........................................................... 53 
6.8 CALIDAD A NIVEL DE PRODUCTO ........................................................ 54 
6.9 CALIDAD DE USO ................................................................................... 54 
6.10 METODOLOGÍA SCRUM. ..................................................................... 54 
6.10.1 Roles básicos de SCRUM. .............................................................. 55 
7. ESTADO DEL ARTE ...................................................................................... 57 
8. ALCANCES Y LIMITACIONES ....................................................................... 60 
8.1 ALCANCES .............................................................................................. 60 
8.2 LIMITACIONES ........................................................................................ 60 
9. METODOLOGÍA ............................................................................................. 61 
7 
 
9.1 ENFOQUE ................................................................................................ 61 
9.2 FASES DE LA INVESTIGACIÓN ..............................................................61 
10. DESARROLLO DEL PROYECTO .................................................................. 63 
10.1 RECOLECCIÓN DE DATOS ................................................................. 63 
10.1.1 Diagnóstico e identificación del proceso actual de levantamiento de 
requerimientos en la empresa GoDoWorks. ................................................... 63 
10.1.2 Evaluación del proceso de levantamiento de requerimientos que se 
lleva a cabo actualmente. ............................................................................... 63 
10.2 INVESTIGACIÓN .................................................................................. 71 
10.2.1 CMMI. ............................................................................................. 72 
10.2.2 Metodología TRIZ. .......................................................................... 75 
10.3 OPTIMIZACIÓN DE PROCESO ............................................................ 83 
10.3.1 Implementando la metodología CMMI al proceso de levantamiento de 
requerimientos en la empresa GoDoWorks. ................................................... 83 
10.3.2 Adaptación de la metodología TRIZ al proceso de levantamiento de 
requerimientos. ............................................................................................... 84 
10.3.2.1 Evaluación y análisis de los principios de la metodología TRIZ. . 85 
10.3.2.2 Proceso de adaptación de la metodología TRIZ al proceso de 
levantamiento de requerimientos en la empresa GoDoWorks .................... 91 
10.4 CAPACITACIÓN PARA LA OPTIMIZACIÓN PROCESO DE 
LEVANTAMIENTO DE REQUERIMIENTOS ...................................................... 99 
10.5 ANÁLISIS DE LOS RESULTADOS ....................................................... 99 
10.6 PRESENTACIÓN DE LOS RESULTADOS A GERENCIA .................. 101 
11. CARÁCTER NOVEDOSO DEL PROYECTO ............................................... 103 
12. CONCLUSIÓN .............................................................................................. 104 
13. CRONOGRAMA ........................................................................................... 105 
14. PRESUPUESTO Y RECURSOS .................................................................. 107 
15. REFERENCIAS BIBLIOGRÁFICAS ............................................................. 108 
 
8 
 
LISTADO DE FIGURAS 
 
Figura 1. Cálculo del porcentaje de incidencias originadas por el analista funcional.
 ............................................................................................................................... 17 
Figura 2. Cálculo del KPI de tiempo de ciclo. ........................................................ 19 
Figura 3. Cálculo del KPI de tiempo de producción. ............................................. 19 
Figura 4. Cálculo del KPI de tasa de defectos. ..................................................... 20 
Figura 5. Cálculo del KPI de utilización de recursos ............................................. 20 
Figura 6. Cálculo del KPI de costo de producción ................................................. 21 
Figura 7. Cálculo del KPI de costo de inactividad ................................................. 22 
Figura 8. Desactivación y Activación de un ACL ................................................... 25 
Figura 9. Migración de un componente de una cuenta a otra ............................... 25 
Figura 10. Ciclo de vida del software .................................................................... 30 
Figura 11. Modelo en cascada .............................................................................. 32 
Figura 12. Tipos de modelos evolutivos ................................................................ 33 
Figura 13. Modelo de componentes reutilizables .................................................. 34 
Figura 14. Modelo de papel en Balsamiq .............................................................. 44 
Figura 15. Diagrama de casos de uso de la máquina expendedora de café ........ 45 
Figura 16. Entrevista ............................................................................................. 46 
Figura 17. Tormenta de ideas. .............................................................................. 47 
Figura 18. Modelo de calidad CMMI ..................................................................... 50 
Figura 19. Modelo de calidad McCall .................................................................... 52 
Figura 20. Metodología SCRUM ........................................................................... 55 
Figura 21. Nivel de conocimiento sobre los módulos del software de GoDoWorks
 ............................................................................................................................... 64 
Figura 22. Técnicas de levantamiento de requerimientos empleados por los 
analistas de requerimientos funcionales dentro de GoDoWorks............................ 66 
Figura 23. Responsabilidad en quien recae el caso reportado ............................. 70 
Figura 24. Matriz de contradicciones .................................................................... 82 
Figura 25. Áreas de proceso a mejorar en la empresa GoDoWorks ..................... 84 
Figura 26. Matriz de métodos de levantamiento de requerimiento con 
contradicciones TRIZ ............................................................................................. 94 
Figura 27. Frecuencia de principios en la matriz TRIZ .......................................... 98 
Figura 28. Validación de incidencia reportada .................................................... 100 
Figura 29. Factores que afectan el proceso de levantamiento en la empresa 
GoDoWorks ......................................................................................................... 101 
9 
 
LISTA DE TABLAS 
 
Tabla 1. Casos reportados en el ambiente de producción o preproducción de los 
desarrollos entregados por TI. ............................................................................... 16 
Tabla 2. Casos reportados al encontrar un defecto debido a un requerimiento 
funcional. ............................................................................................................... 16 
Tabla 3. Ventajas y Desventajas de los modelos de ciclo de vida del software. ... 35 
Tabla 4. Característica de los requerimientos ....................................................... 42 
Tabla 5. Conocimiento promedio del equipo de analistas funcionales en los módulos 
de GoDoWorks ...................................................................................................... 65 
Tabla 6. Comparación de técnicas utilizadas para el levantamiento de 
requerimientos por analista funcional .................................................................... 67 
Tabla 7. Factores que afectan el proceso de levantamiento de requerimientos .... 67 
Tabla 8. Fases del proceso de levantamiento de requerimientos.......................... 71 
Tabla 9. Área de proceso ...................................................................................... 73 
Tabla 10. Grupos Funcionales en CMMI. .............................................................. 75 
Tabla 11. Listado de los 39 parámetros de Ingeniería ........................................... 77 
Tabla 12. Listado de los 40 principios de Inventiva ............................................... 81 
Tabla 13. Principios TRIZ aplicables al proceso de levantamiento de requerimientos
 ............................................................................................................................... 91 
Tabla 14. Matriz de métodos de levantamiento de requerimientos positivo y 
contradicción .......................................................................................................... 92 
Tabla 15. Recomendación de Principios inventivos aplicablesal método de 
levantamiento de requerimientos en la empresa GoDoWorks ............................... 95 
10 
 
LISTA DE ANEXOS 
 
[1] ANEXO 1 (Matriz TRIZ de levantamientos de requerimientos): 
https://docs.google.com/spreadsheets/d/1x7gM1h1s3bWyFHOfg6Bzh9oP8U0
_Qm5a/edit?usp=sharing&ouid=104595978071520712419&rtpof=true&sd=tru
e 
https://docs.google.com/spreadsheets/d/1x7gM1h1s3bWyFHOfg6Bzh9oP8U0_Qm5a/edit?usp=sharing&ouid=104595978071520712419&rtpof=true&sd=true
https://docs.google.com/spreadsheets/d/1x7gM1h1s3bWyFHOfg6Bzh9oP8U0_Qm5a/edit?usp=sharing&ouid=104595978071520712419&rtpof=true&sd=true
https://docs.google.com/spreadsheets/d/1x7gM1h1s3bWyFHOfg6Bzh9oP8U0_Qm5a/edit?usp=sharing&ouid=104595978071520712419&rtpof=true&sd=true
11 
 
RESUMEN 
 
Este proyecto de grado busca optimizar el proceso utilizado para el 
levantamiento de requerimientos basado en estándares de calidad de 
software para la empresa uruguaya GoDoWorks. El levantamiento de 
requerimientos es la base fundamental sobre la cual se desarrolla el ciclo de 
vida de un sistema de información, ya que permite comprender qué tipo de 
necesidades debe solucionar un sistema, cómo deben interactuar los 
diferentes tipos de usuarios con la plataforma. En esta fase se recopila toda 
la información sobre el flujo de negocio de un cliente para comprender su 
necesidad y solucionarla por medio de un software. No llevar adecuadamente 
la fase de levantamiento de requerimientos puede generar inconvenientes en 
posteriores fases del desarrollo e implementación de un software, lo cual se 
manifiesta en modificaciones de tiempo, costos, o alcance. 
Un deficiente levantamiento de requerimientos afecta el cronograma 
establecido para un proyecto, debido a que la inconformidad por parte del 
cliente por no haberse compartido abiertamente las limitaciones de la 
plataforma llegan a afectar en fases avanzadas del proyecto, obliga a realizar 
nuevos cambios. Estas modificaciones afectan variables como tiempo, costos 
y el alcance de un proyecto. Lo anterior afecta no solo la reputación de la 
empresa GoDoWorks, sino que además afecta a los clientes interesados de 
adquirir el software, dado a que solo percibe perdidas al identificar que el uso 
de la plataforma no los beneficia en sus trabajos cotidianos. 
Para generar un aporte tangible que permita subsanar esta deficiencia, el 
autor revisó el proceso actual para levantamiento de requerimientos de la 
empresa GoDoWorks, partiendo desde la identificación del modelo de ciclo de 
vida que es utilizado para la elaboración de los proyectos de software. Esto 
se debe a que los requerimientos se encuentran familiarmente relacionados 
con el ciclo de vida del software. De esta forma se logró determinar en qué 
actividades se presentan inconformidades o malas prácticas, las cuales 
conducen a una inadecuada comprensión de los elementos involucrados en 
la solución para un cliente, y posteriores cambios en los componentes del 
proyecto. 
Palabras Clave: Calidad de software, requerimientos funcionales, TRIZ.
12 
 
ABSTRACT 
 
This degree project seeks to optimize the process used for requirements gathering 
based on software quality standards for the Uruguayan company GoDoWorks. The 
requirements gathering is the fundamental basis on which the life cycle of an 
information system is developed, since it allows to understand what kind of needs a 
system must solve, how the different types of users must interact with the platform. 
In this phase, all the information about a customer's business flow is gathered to 
understand their needs and solve them by means of software. Failure to adequately 
carry out the requirements gathering phase can generate inconveniences in later 
phases of the development and implementation of a software, which is manifested 
in modifications of time, costs, or scope. 
A deficient requirements survey affects the schedule established for a project, 
because the client's non-conformity for not having openly shared the platform's 
limitations may affect in advanced phases of the project, forcing new changes to be 
made. These modifications affect variables such as time, costs and the scope of a 
project. This affects not only the reputation of the company GoDoWorks, but also 
affects customers interested in acquiring the software, since they only perceive 
losses when they identify that the use of the platform does not benefit them in their 
daily work. 
In order to generate a tangible contribution to remedy this deficiency, the author 
reviewed the current process for requirements gathering of the company 
GoDoWorks, starting from the identification of the life cycle model that is used for 
the development of software projects. This is due to the fact that the requirements 
are familiarly related to the software life cycle. In this way, it was possible to 
determine in which activities there are nonconformities or bad practices, which lead 
to an inadequate understanding of the elements involved in the solution for a client, 
and subsequent changes in the project components. 
Key Words: software quality, functional requirements, TRIZ.
13 
1. INTRODUCCIÓN 
 
El levantamiento de requerimientos es una de las primeras fases del proceso de 
desarrollo del software, esta etapa permite definir el propósito y las particularidades 
del funcionamiento de un software, además de responder principalmente a las 
necesidades del usuario final, de esta forma se identifican las reglas del negocio, 
logrando obtener un panorama completo de la solución que se puede ofrecer1. 
Así surge la importancia del proceso de levantamiento de requisitos, como una 
técnica para identificar las necesidades de los clientes y adaptarlas a un entorno 
web. Es una de las principales fases en el desarrollo de software, ya que esta etapa 
permite definir el propósito y las particularidades del funcionamiento del software. 
Además, responde principalmente a las necesidades del usuario final al identificar 
las reglas del negocio y los requisitos del usuario. De esta manera, se logra obtener 
una visión completa de la necesidad que se debe satisfacer2. 
 
La evolución del software ha transformado la manera en que las personas 
interactúan con su entorno. Este avance tecnológico ha posibilitado la optimización 
de diversos procesos que previamente se realizaban de forma manual, y que en la 
actualidad han migrado hacia un entorno digital. Con esto en mente, es crucial 
comprender que la base fundamental para traducir una idea desde nuestro plano 
físico al plano digital radica en el proceso de levantamiento de requerimientos. Este 
método permite transformar nuestro lenguaje natural en un lenguaje lógico que una 
máquina puede interpretar. 
La calidad del software puede definirse como la medida en que un programa cumple 
con sus requisitos y objetivos, asegurando además la satisfacción de los usuarios 
finales. Esto se logra al cumplir con cada uno de los requisitos y expectativas de los 
usuarios, al mismo tiempo que garantiza la funcionalidad, seguridad, compatibilidad, 
usabilidad o portabilidad del software3. 
 
1 D. Salazar Castellanos, “Industria de TI y de software colombiana: ¿cuántas empresas hay y cuánto 
venden?,” Mar. 02, 2022. https://www.bloomberglinea.com/2022/03/02/industria-de-ti-y-de-software-
colombiana-cuantas-empresas-hay-y-cuanto-venden/ (accessed May 01, 2023). 
2 J. Enriquez, S. Rosales de la vega, and M. Morales, “PROPUESTA DE LEVANTAMIENTO DE 
REQUERIMIENTOS EN EL DESARROLLO DE SISTEMAS APLICANDO METODOLOGÍA TRIZ,” 
Instituto Politécnico Nacional , Ciudad de México , 2018. Accessed: Oct. 27, 2022. [Online]. Available: 
https://tesis.ipn.mx/jspui/bitstream/123456789/25355/1/PROPUESTA DE LEVANTAMIENTO DE 
REQUERIMIENTOS EN EL DESARROLLO DE SISTEMAS APLICANDO METODOLOGÍA TRIZ.pdf 
3 W. Perdomo and C. M. Zapata, “Software quality measures and their relationship with the states of 
the software system alpha,” Medellin, pp. 4–9, Jun. 20, 2019. Accessed: Oct.22, 2022. [Online]. 
Available: https://web-p-ebscohost-
com.ucatolica.basesdedatosezproxy.com/ehost/detail/detail?vid=2&sid=1b917b26-638a-4cb5-
ae17-
7b8bae53517f%40redis&bdata=Jmxhbmc9ZXMmc2l0ZT1laG9zdC1saXZl#AN=150919812&db=fua 
14 
Para la empresa GoDoWorks, resulta crucial comprender las necesidades de sus 
clientes con el fin de satisfacerlas de manera efectiva. Por ende, el proceso de 
levantamiento de requerimientos emerge como una de las etapas más significativas 
en la elaboración de un proyecto. Esto se debe a que esta fase recopila toda la 
información técnica concerniente al flujo de negocio del cliente, al mismo tiempo 
que proporciona detalles sobre cómo el equipo de desarrollo debe ajustar dichos 
requerimientos a un entorno de programación para su posterior desarrollo. 
Se ha registrado por medio de las incidencias reportadas por los clientes y otros 
analistas funcionales durante los primeros 3 meses del año 2023 se deben a una 
deficiente documentación. En específico, un 15,51% de estas incidencias señalan 
al analista funcional como responsable de los fallos debido a una documentación 
inadecuada en los requerimientos funcionales. Como resultado, fue necesario 
ajustar el alcance de los requerimientos funcionales para satisfacer las necesidades 
de los clientes y considerar posibles eventos que inicialmente no se tuvieron en 
cuenta. 
Este inadecuado levantamiento de requerimientos conllevó a modificaciones en el 
alcance de los mismos, lo que a su vez puede generar desviaciones en términos de 
tiempo, costos y alcance del proyecto. Esto se debe a que, si dichas modificaciones 
se realizan en una fase avanzada del proyecto, pueden impactar en el diseño y el 
desarrollo de los requerimientos. 
Además, esta situación compromete la reputación de la compañía, ya que puede 
dar a entender que la empresa carece de la madurez necesaria para adaptar las 
necesidades de los clientes en el software de manera efectiva. 
En este contexto, es necesario poner en contexto el término "optimizar". De acuerdo 
con el diccionario Larousse (2012), se define como "lograr el mejor resultado posible 
de una actividad o proceso mediante el aprovechamiento máximo de sus 
potencialidades"4. 
 
 
4 Larousse (Firm), “Optimizar,” Larousse (Firm). p. 468, 2012. 
15 
2. JUSTIFICACIÓN 
 
El motivo detrás de la realización de este proyecto de investigación radica en la 
búsqueda de la optimización del proceso de levantamiento de requerimientos para 
la empresa GoDoWorks. Este proceso posee una importancia fundamental en el 
ciclo de vida del desarrollo de proyectos de software. Sin embargo, se han 
identificado debilidades en el mismo, las cuales con frecuencia se traducen en 
diversas insatisfacciones por parte del cliente durante la etapa de aprobación de los 
requerimientos funcionales que habían sido previamente acordados en reuniones. 
En la actualidad, cada una de las incidencias identificadas en la plataforma debe 
ser reportada mediante tickets utilizando la herramienta denominada WorkFlow. 
Esta herramienta constituye el método formal de comunicación para informar sobre 
incidencias dentro de la plataforma de GoDoWorks. A través de ella, es posible 
categorizar cada uno de los eventos presentes en la plataforma, lo que permite 
segmentar cada ticket de acuerdo con los siguientes criterios: 
• El entorno en el que se experimenta el problema. 
• El módulo específico que está experimentando el fallo. 
• La naturaleza o tipo de fallo identificado. 
• La persona o entidad responsable detrás del fallo. 
De acuerdo con la investigación en curso, se ha tomado como referencia el conjunto 
de casos reportados en los últimos 3 meses, cuyo total ascendió a 267 incidentes. 
A partir de esta base inicial, se han seleccionado los casos informados por los 
clientes que se encuentran en las fases de preproducción y producción. En este 
contexto, los clientes en producción se refieren a proyectos ya entregados, pero que 
ocasionalmente pueden reportar deficiencias en funcionalidades previamente 
proporcionadas por el departamento de Tecnologías de la Información (TI). Por otro 
lado, los clientes en preproducción son aquellos cuyos proyectos son nuevos y en 
proceso de pruebas, identificándose problemas a medida que se evalúan las 
funcionalidades entregadas por TI. 
Resultado de este proceso, se han identificado 58 casos que cumplen con las 
características mencionadas anteriormente. Estos casos se observan en la Tabla 1. 
Casos reportados en el ambiente de producción y preproducción de los 
desarrollos entregados por TI. 
 
 
 
 
 
16 
Tabla 1. Casos reportados en el ambiente de producción y preproducción 
de los desarrollos entregados por TI. 
Cliente 
 
Ambiente 
Nro. de casos escalados por problemas 
en desarrollos entregados por TI 
CLIENTE A Producción 9 
CLIENTE B Producción 2 
CLIENTE C Preproducción 7 
CLIENTE D Preproducción 5 
CLIENTE E Preproducción 17 
CLIENTE F Producción 18 
TOTAL 58 
Fuente: Elaboración Propia 
 
En la tabla anterior, se puede apreciar el recuento total de tickets reportados por 
cada uno de los clientes que se encuentran en las fases de producción y 
preproducción. Estos tickets corresponden al desarrollo proporcionado por el área 
de Tecnologías de la Información (TI). Dentro de estos datos, se han tomado en 
cuenta únicamente los casos que surgieron debido a una gestión deficiente del 
análisis funcional. Como resultado de este proceso de filtrado, se obtuvo lo 
mostrado en la Tabla 2. Casos reportados al encontrar un defecto debido a un 
requerimiento funcional. 
 
Tabla 2. Casos reportados al encontrar un defecto debido a un 
requerimiento funcional. 
Responsabilidad Cliente 
Ambiente Cuenta de Nro. 
Caso 
GODOWORKS ANALISTA FUNCIONAL CLIENTE A Producción 1 
GODOWORKS ANALISTA FUNCIONAL CLIENTE F Producción 8 
TOTAL 9 
Fuente: Elaboración Propia 
 
La tabla previa ilustra que de los 58 casos reportados durante los últimos 3 meses 
debido a incidencias identificadas en el entorno de Producción y Pre-Producción de 
desarrollos proporcionados por el área de Tecnologías de la Información (TI), 9 
eventos, representando el 15,51% de los casos, se originaron debido a una gestión 
inadecuada del analista funcional, esto calcula como se muestra en la Figura 1. 
Cálculo del porcentaje de incidencias originadas por el analista funcional. 
17 
 
Figura 1. Cálculo del porcentaje de incidencias originadas por el analista 
funcional. 
 
Fuente: Elaboración Propia 
 
En la Figura 1. Cálculo del porcentaje de incidencias originadas por el analista 
funcional, se encontró que un 15,51% de las incidencias podrían haberse evitado 
desde el principio, durante la fase de levantamiento de requerimientos. Como 
resultado fue necesario alterar el alcance del requerimiento funcional para 
adaptarse a las necesidades de los clientes o a posibles eventos que inicialmente 
no se habían considerado. En consecuencia, se requiere devolver el requerimiento 
funcional a la etapa de análisis de requerimientos y ajustar su alcance. 
Un deficiente levantamiento de requerimientos aumenta los costos del proyecto 
debido a las correcciones necesarias. Cada ajuste puede llevar, en ocasiones, a un 
impacto en términos de horas invertidas para llevar a cabo las modificaciones 
requeridas, costos financieros, recursos humanos necesarios para implementar los 
cambios y en el alcance general del proyecto. Estos efectos varían según la etapa 
del ciclo de vida del software, lo que puede generar desviaciones mayores o 
menores en componentes clave de la gestión de proyectos como tiempo, costos y 
alcance. Esto a su vez puede requerir ajustes en otros aspectos para mantener el 
equilibrio del proyecto. 
Se ha observado que corregir un error de requerimiento identificado en una etapa 
avanzada del ciclo de vida del software implica un esfuerzo que va del 50% al 82% 
del total del equipo de desarrollo para abordarlo5. 
Norris & Rigby presentan la siguientedefinición: “La captura y el análisis de los 
requerimientos del sistema es una de las fases más importantes para que el 
 
5 C. Rodríguez, “GUÍA PARA LA MEJORA EN EL LEVANTAMIENTO DE REQUERIMIENTOS DE 
SOFTWARE EN UNA PYME DE LOGÍSTICA DE TRANSPORTE,” BOGOTA, 2021. Accessed: Nov. 
12, 2022. [Online]. Available: https://repository.ucatolica.edu.co/bitstream/10983/27048/1/GUIA 
PARA LA MEJORA EN EL LEVANTAMIENTO DE REQUERIMIENTOS DE SOFTWARE EN UNA 
PYME DE LOGISTICA DE TRANSPORTE.pdf 
18 
proyecto tenga éxito.”6. Esto se debe a que es la columna vertebral del proyecto, ya 
que permite delimitar el comportamiento de este. 
Con la implementación de esta propuesta se busca optimizar el proceso de 
levantamiento de requerimientos en la empresa GoDoWorks, puesto que, al 
demostrar a los clientes que se posee no solo un equipo capacitado para programar 
los requerimientos funcionales, sino que además existe el personal capacitado para 
levantar los requerimientos funcionales de forma adecuada, se ofrece un servicio 
con mayor seguridad a los clientes y una mayor madurez en el manejo de 
estándares de calidad. 
 
2.1 IMPACTO ORGANIZACIONAL 
Una comunicación efectiva entre el equipo de desarrollo y los usuarios finales 
conduce a la formulación de requerimientos funcionales claros y precisos. Cuando 
se establecen requerimientos funcionales de manera adecuada, se logra una 
parametrización nítida de los criterios que el software debe cumplir. Esto, a su vez, 
posibilita la identificación y corrección de errores antes de la liberación del software, 
elevando tanto la calidad del producto como la satisfacción del usuario final. 
Además, la correcta definición de los requerimientos funcionales disminuye la 
probabilidad de que se realicen cambios en los requisitos, lo que resulta en una 
mayor eficiencia en el trabajo de los desarrolladores. La reducción de la complejidad 
en los requerimientos facilita su comprensión y ejecución, contribuyendo a una 
mayor productividad en el proceso de desarrollo. 
La eficiencia operativa que se lograría al implementar esta optimización en el 
proceso de levantamiento de requerimientos se evaluará mediante KPIs (Key 
Performance Indicators), que son indicadores clave o medidas de rendimiento de 
los procesos. 
Entre estos se pueden citar: 
• Tiempo de ciclo: El tiempo que transcurre desde que se inicia un proceso 
hasta que se completa, la cual se calcula como lo muestra la Figura 2. 
Cálculo del KPI de tiempo de ciclo. 
 
 
 
 
 
 
 
6 E. L. S.A, Ed., Ingenieria de Software Explicada / Software Engineering Explained, 1st ed. Mexico, 
1994. 
19 
 
Figura 2. Cálculo del KPI de tiempo de ciclo. 
 
Fuente: ¿Qué es el Tiempo de Ciclo? | Kanban Tool 
 
La Figura 2. Cálculo del KPI de tiempo de ciclo. Es una métrica que 
permite calcular el KPI del tiempo de ciclo, el cuál es una diferencia entre la 
fecha de terminación y la fecha de inicio del proceso, el número 1 es un 
adicional que corrige el problema del tiempo de ciclo de “cero días” para 
aquellos ítems que fueron terminados el mismo día que se empezó a trabajar 
en ellos. 
 
• Tasa de producción: La cantidad de unidades producidas por unidad de 
tiempo, la cual se calcula como lo muestra la Figura 3. Cálculo del KPI de 
tiempo de producción. 
 
Figura 3. Cálculo del KPI de tiempo de producción. 
 
 
 
Fuente: Cómo calcular las tasas de producción | Geniolandia 
 
La Figura 3. Cálculo del KPI de tiempo de producción es una métrica que 
permite calcula el KPI de tiempo de producción, en donde se debe sumar la 
cantidad de unidades producidas, posteriormente se divide en el periodo de 
tiempo requerido para realizar un corte y evaluar el tiempo total que se ha 
invertido durante la producción de esas unidades. 
 
 
• Tasa de defectos: La cantidad de productos defectuosos o errores en el 
proceso de producción con respecto al número de unidades monitoreadas, 
Tiempo de ciclo = 
Fecha de 
Terminación 
Fecha de 
Inicio 
(+1) 
Tasa de Producción = RQ1 + RQ2 + … + RQn 
Tiempo invertido 
https://kanbantool.com/es/guia-kanban/tiempo-de-ciclo#:~:text=Esta%20m%C3%A9trica%20ayuda%20a%20los%20equipos%20a%20determinar,%C2%BFCu%C3%A1l%20es%20la%20importancia%20del%20tiempo%20de%20ciclo%3F
https://www.geniolandia.com/13075407/como-calcular-las-tasas-de-produccion
20 
la cual se calcula como lo muestra la Figura 4. Cálculo del KPI de tasa de 
defectos. 
 
Figura 4. Cálculo del KPI de tasa de defectos. 
 
Fuente: Cómo Calcular una Tasa de Defectos (consejosytrucos.net) 
 
La Figura 4. Cálculo del KPI de tasa de defectos. Es una métrica que 
permite calcula el KPI de la tasa de defectos, en donde se debe dividir las 
unidades que se han encontrado con defectos sobre la muestra que se tomó 
para la muestra. 
 
• Utilización de recursos: La cantidad de tiempo que se utiliza cada recurso 
en el proceso de producción, la cual se calcula como lo muestra la Figura 5. 
Cálculo del KPI de utilización de recursos. 
 
Figura 5. Cálculo del KPI de utilización de recursos 
 
Fuente: Cómo dar seguimiento a la tasa de utilización e impulsar la 
rentabilidad del equipo [2022] • Asana 
 
Tasa de defectos = 
Unidades defectuosas 
Número de unidades de prueba 
(CR + GG + MU) 
(THD * TFO) 
Tasa de utilización = 
CR = Costo de Recursos. 
GG = Gastos Generales. 
MU = Margen De Utilidad. 
THD = Total de Horas Disponibles. 
TFO = Tarifa de Facturación Óptima. 
https://www.consejosytrucos.net/noticias-87876/como-calcular-una-tasa-de-defectos/#:~:text=Para%20calcular%20la%20tasa%20de%20defectos%2C%20se%20divide,dividido%20por%20el%20n%C3%BAmero%20de%20unidades%20de%20prueba.
https://asana.com/es/resources/utilization-rate
https://asana.com/es/resources/utilization-rate
21 
La Figura 5. Cálculo del KPI de utilización de recursos. Es una métrica 
que permite calcular el KPI de la tasa de utilización, en donde busca 
determinar el margen de utilización ideal de la capacidad organizativa de una 
compañía según los costos de sus recursos, los gastos generales, el margen 
de utilidad, el total de horas disponibles y la tarifa de facturación. 
 
• Costo de producción: El costo total de producción por unidad de producto 
se calcula como lo muestra la Figura 6. Cálculo del KPI de costo de 
producción. 
 
 
 
 
 
Figura 6. Cálculo del KPI de costo de producción 
 
Fuente: ¿Cómo calcular los costos de producción? | Gestionar Fácil 
(gestionar-facil.com) 
La figura anterior muestra cómo se calcula el KPI del costo de un producto, 
en donde se suma cada uno de los componentes necesario para calcular el 
costo, en donde se interviene la materia prima, la mano de obra y el costo 
indirecto de fabricación. 
 
• Costo de inactividad: La cantidad de tiempo en que el proceso está inactivo 
debido a fallas en la maquinaria, retrasos en el suministro de materiales, etc. 
Esta métrica se calcula por medio de la Figura 7. Cálculo del KPI de costo 
de inactividad. 
 
 
 
 
 
Costo de 
producción 
Materia 
prima 
 Mano de 
Obra directa 
Costo 
Indirecto de 
fabricación 
= 
+ + 
https://www.gestionar-facil.com/como-calcular-los-costos-de-produccion/
https://www.gestionar-facil.com/como-calcular-los-costos-de-produccion/
22 
Figura 7. Cálculo del KPI de costo de inactividad 
 
Fuente: Cálculo del coste del tiempo de inactividad | Atlassian 
 
La Figura 7. Cálculo del KPI de costo de inactividad, es una métrica que 
permite calcular los costos crecientes de un proceso inactivo, el cuál puede 
calcularse en términos de minutos, horas e incluso días, en donde solo es 
necesario realizar una conversión de la variable Minutos del tiempo de 
inactividad y de coste por minuto y términos de horas o en días.
Costo de 
inactividad 
Minutos del 
Tiempo de inactividad 
= * 
Coste 
Por minuto 
https://www.atlassian.com/es/incident-management/kpis/cost-of-downtime
23 
3. PLANTEAMIENTO DEL PROBLEMA 
 
3.1 CONTEXTUALIZACIÓN DE LA EMPRESA 
GoDoWorks es una empresavanguardista especializada en la implementación de 
soluciones tecnológicas para la gestión de movilidad, recursos humanos y activos. 
Su sede central está ubicada en Uruguay, y ha establecido su presencia en 
Colombia desde 2017. A lo largo de su trayectoria operativa, ha obtenido un amplio 
reconocimiento en la región como una destacada creadora de soluciones flexibles 
basadas en software de geolocalización. 
Las empresas clientes de GoDoWorks emplean sus herramientas para transformar 
sus procesos de recopilación de datos, que previamente se realizaban en papel. 
Asimismo, aprovechan la herramienta para realizar georreferenciación de los 
trabajadores que se encuentran en terreno, de los puntos de interés (lugares físicos 
donde se deben llevar a cabo tareas) y de los activos utilizados (equipos 
desplegados por una empresa para cumplir una función específica). Esto tiene como 
objetivo generar un historial de las actividades realizadas. En este historial, se 
puede acceder a detalles como el operario que ejecutó la tarea, el activo que se 
inspeccionó, el tipo de tarea llevada a cabo, el cliente al que se prestó el servicio y 
la documentación recopilada durante la ejecución de la tarea. 
La herramienta de GoDoWorks posee varias versiones enfocadas a una línea 
diferente de negocio, como en el caso de la vertical SERVICES, TRADE, SALES, 
HEALTH y FLEET. Los únicos utilizados en Colombia son SERVICES y TRADE, los 
cuales se explicarán a continuación. 
 
3.1.1 GoDoWork SERVICES. 
Es el buque insignia de GoDoWorks, dado que es la herramienta principal en donde 
las otras verticales como el TRADE son agregadas como un módulo extra. 
SERVICES. Es una herramienta que posee la característica de trabajar con 
georreferenciación de operarios, bienes (equipos desplegados por una compañía 
para realizar una función específica), y puntos de interés (lugares donde se deben 
realizar trabajos) como se mencionó anteriormente. Posee el propósito de gestionar 
las actividades del día a día de los operarios, además de permitir procesos 
transparentes entre operarios y clientes a la hora de realizar y documentar trámites. 
 
 
 
24 
3.1.2 GoDoWork TRADE. 
Es un módulo que se habilita dentro de la herramienta de GoDoWorks SERVICES 
y transforma su funcionamiento de forma radical, convirtiéndolo en GoDoWorks 
TRADE. Es una herramienta creada por GoDoWorks para el trade marketing. 
Permite crear un clúster de clientes los cuales se pueden subdividir por marcas, 
estas marcas se pueden dividir en puntos de interés y cada punto de interés puede 
estar manejando unos productos en específico. De esta forma permite identificar de 
qué forma se está posicionando estratégicamente la mercancía en los diferentes 
puntos de venta. Esto con el fin de generar medidas para volver más atractivo un 
producto ante la competencia. 
Por otro lado, permite recabar información en campo sobre los productos que vende 
un cliente o la competencia, permitiendo registrar qué tipo de promociones se están 
implementando para un producto específico de la competencia, qué tipo de precios 
manejan cada producto y generar tareas para generar contramedidas para los casos 
en donde se estén perdiendo potenciales clientes. 
 
3.2 MODELO DE CICLO DE VIDA DEL SOFTWARE IMPLEMENTADO EN 
GODOWORKS 
Los 3 (tres) modelos de ciclos de vida de software más conocidos son: Modelo en 
cascada, modelo evolutivo y modelo de componentes reutilizables, los cuales serán 
abordados más a profundidad en el marco conceptual. Se determinó que en la 
empresa GoDoWorks utilizan un modelo hibrido de dos fases, las cuales son: 
• Modelo evolutivo (Desarrollo Iterativo). 
• Modelo de componentes reutilizables. 
Esto se debe a que el software ofrecido por GoDoWorks ya se cuenta de antemano 
con varios módulos construidos y que dependiendo de las necesidades del cliente 
se van habilitando por medio de un ACL (Access Control List), haciendo que se 
comporte como un modelo evolutivo de tipo desarrollo Interativo, ya que posee un 
esqueleto completo del sistema al principio y con el paso del tiempo se va 
agregando otros módulos como se muestra en la Figura 8. Desactivación y 
Activación de un ACL. 
 
25 
Figura 8. Desactivación y Activación de un ACL 
 
Fuente: Elaboración Propia 
La Figura 8. Desactivación y Activación de un ACL, es el método por el cual se 
activa dentro de una cuenta un permiso que permite que se acceda a varias 
funcionalidades de la herramienta, que en un inicio se encontraban deshabilitadas, 
pero que ya estaban disponibles dentro de la herramienta. 
Por otro lado, se comporta también como un modelo de componentes 
reutilizables, ya que, dependiendo del área de negocio del cliente, si requiere una 
funcionalidad que otro cliente posee, se puede migrar esa funcionalidad al cliente 
que lo solicita como se muestra en la Figura 9. Migración de un componente de 
una cuenta a otra 
Figura 9. Migración de un componente de una cuenta a otra 
 
Fuente: Elaboración Propia 
Módulo 
de 
Bienes 
Módulo 
de 
clientes 
Módulo de 
legalización 
Módulo de 
Trade 
Marketing 
ACL de Trade Marketing 
Desactivado 
Módulo 
de 
Bienes 
Módulo de 
legalización 
Módulo de 
Trade 
Marketing 
Módulo 
de 
clientes 
ACL de Trade Marketing 
Activado 
Cuenta: 700 
Módulo 
de 
Bienes 
Módulo 
de 
clientes 
Módulo de 
legalización 
Migrando 
Módulo de 
autenticación 
con registro 
facial 
Cuenta: 258 
Módulo 
de 
Bienes 
Módulo de 
legalización 
Módulo 
de 
clientes 
En proceso de 
migración … 
26 
Como se muestra en la Figura 9. Migración de un componente de una cuenta a 
otra, se está migrando una funcionalidad que un cliente está solicitando en la cuenta 
258, el cual posee otro cliente en la cuenta 700. Esta funcionalidad permite que el 
ingreso a la plataforma se realice por medio de la autenticación por registro facial. 
De esta forma solo es necesario generar el análisis de requerimiento para identificar 
si esta funcionalidad que se encuentra en la cuenta 700 no es necesario realizar 
cambios o si se adapta en su totalidad a la necesidad del cliente de la cuenta 258. 
 
3.3 FORMULACIÓN DEL PROBLEMA 
En la actualidad, las empresas están en la búsqueda de software que se adapte 
precisamente a sus necesidades de mercado, con un enfoque en la confiabilidad, 
estabilidad, fiabilidad y calidad. Sin embargo, el mercado se ha vuelto altamente 
competitivo en términos de soluciones que ofrecen las mismas características que 
las proporcionadas por GoDoWorks, lo que impulsa a las empresas desarrolladoras 
a innovar de manera continua. En respuesta a esto, GoDoWorks aspira a presentar 
al mercado una herramienta aún más completa y de mayor calidad en cuanto al 
software. 
Es por ello que la empresa busca la capacidad de adaptarse a las necesidades de 
sus clientes, principalmente a través de un proceso llamado levantamiento de 
requerimientos. Este proceso está fundamentado en el modelo de ciclo de vida del 
software que se adopta. No obstante, es importante destacar que el proceso de 
levantamiento de requerimientos presenta ciertas debilidades que, si no se abordan 
adecuadamente, pueden eventualmente dar lugar al fracaso de un proyecto durante 
su implementación. 
 
• Mala definición de requerimientos: No es claro y preciso lo que se 
pretende hacer con el requerimiento funcional. 
• El cliente no tiene claridad sobre lo que necesitan: El cliente desconoce 
algunos detalles vitales sobre sus procesos internos que pueden llegar a 
repercutir en sus procesos internos. 
• La comunicación con los clientes es lenta: El cliente contesta las dudas 
sobre algunos detalles de los requerimientos en periodos de tiempo no 
óptimo. 
• No se comprende claramente el alcance del sistema: El límite o extensión 
de lo que se está haciendo o se pretende hacer no se encuentra bien 
delimitado. 
• No son respetados los tiempos: Los tiempos de entrega de los desarrollos 
supera la fecha tentativa planteadacon anterioridad. 
27 
• Falta de comunicación: No se logra establecer una serie de reuniones con 
los clientes para solventar dudas sobre algunos detalles de los 
requerimientos. 
• Requerimientos mal gestionados: Son los requerimientos que no se han 
definido correctamente, no se han documentado adecuadamente, no se han 
comunicado de forma clara a los interesados en el proyecto, posee 
ambigüedades el requerimiento y posee cambios frecuentes. 
• Alcance no realista: Los objetivos, documentos o actividades que se 
pretenden realizar de un proyecto no son alcanzables dentro de un plazo, 
presupuesto o no se cuenta con los recursos disponibles para llevar a cabo 
el proyecto. 
 
De la lista anterior, algunos factores van ligados al proceso de levantamiento de 
requerimientos (Mala definición de requerimientos, los clientes no tienen claridad 
sobre lo que necesitan, la comunicación con los clientes es lenta, falta de 
comunicación, requerimientos mal gestionados y alcance no realista). Si alguno de 
los factores mencionados anteriormente se evidencia, el alcance del proyecto se 
afectará de forma negativa junto con su cronograma y presupuesto. 
Por lo tanto, el levantamiento requerimientos se convierte en la base fundamental 
de un proyecto de desarrollo. Johnson en su libro Based on CHAOS 2020: Beyond 
Infinity Overview menciona lo siguiente “el 20% de los proyectos de software no 
logra el éxito, el 50% es reorientado y solo el 30% logra sus objetivos”7. 
De esta forma, la empresa aplica de manera general buenas prácticas durante el 
ciclo de vida de un software. Pero, algunas de sus fases se realizan de manera 
irregular, encontrándose casos donde se pierde información de levantamientos 
funcionales ya realizados, se adapta el código de un proyecto a otro diferente más 
de una vez, generando posteriores fallos y, por último, confusión sobre lo que 
requiere el cliente y contradicciones en algunos procesos, entre otros. 
Un caso real de mala reutilización de requerimientos sin un debido análisis es el 
desastre del cohete Ariane-5 de 1996, caso el cuál Pfleeger en su libro “Ingeniería 
de software. Teoría y práctica 1ra edición” profundiza más este caso: “El desastre 
del cohete Ariane-5, fue provocado por la reutilización de una sección de código del 
Ariane-4. Nuseibeh (1997) analiza el problema desde el punto de vista de la 
reutilización de los requerimientos. Esto es, muchos ingenieros de software sienten 
que pueden obtener grandes beneficios reutilizando las especificaciones de 
requerimientos, (y también el diseño, el código y los casos de prueba relacionados) 
de sistemas anteriormente desarrollados. Las especificaciones candidatas son 
identificadas contemplando los requerimientos de funcionalidad o de 
comportamiento que son iguales o similares, haciendo después las modificaciones 
donde fueran necesarias. En el caso del Ariane - 4, el sistema inercial de referencia 
 
7 J. Jim, Based on CHAOS 2020: Beyond Infinity Overview. 2020 
28 
(SRI) realizaba la mayoría de las funciones que necesitaba el Ariane-5. Sin 
embargo, Nuseibeh señala que, aunque la funcionalidad que se necesitaba era 
similar a la del Ariane-4, había aspectos de Ariane-5 que eran significativamente 
diferentes. En particular la funcionalidad del módulo SRI que continuaba después 
del lanzamiento no se necesitaba para el Ariane-5. Es así como, si la validación de 
los requerimientos se hubiese realizado correctamente, los analistas habrían 
descubierto que las funciones activas después del lanzamiento no podían rastrearse 
hasta un requerimiento en la especificación o en la definición del Ariane-5. Es decir 
que la validación de los requerimientos podría haber jugado un papel crucial en la 
prevención de la destrucción del cohete.”8. 
El caso anterior es un ejemplo claro de lo que ocurre cuando se reciclan los 
requerimientos funcionales de un proyecto a otro sin un debido análisis para 
comprender su impacto, generando que se pierda demasiado tiempo en desarrollo, 
realizando un efecto dominó, culminando en que se pierda confianza en la 
herramienta. Por lo tanto, se llega a la siguiente pregunta: 
 
3.4 PREGUNTA PROBLEMA 
¿Es posible reducir, de manera importante, la cantidad de inconformidades que 
actualmente se presentan por parte de los clientes de la empresa GoDoWorks 
durante la fase de implementación y pruebas, a partir del ajuste del proceso 
establecido para el levantamiento de requerimientos funcionales? 
 
 
 
8 S. L. Pfleeger, Ingenieria de Software teoría y práctica. Buenos Aires, 2002 
29 
4. OBJETIVOS 
 
4.1 OBJETIVO GENERAL 
Reducir la cantidad de inconformidades generadas por los clientes de la empresa 
GoDoWorks durante la fase de implementación y pruebas, para evitar un reproceso 
de actividades, aumento en los tiempos de entrega y pérdida de imagen en el 
mercado. 
 
4.2 OBJETIVOS ESPECÍFICOS 
Documentar el proceso actual que se usa para llevar a cabo el levantamiento de 
requerimientos funcionales, y poder establecer una línea base que permita medir la 
eficiencia obtenida a partir de los ajustes propuestos. 
 
Caracterizar las actividades donde se está presentando un insuficiente 
entendimiento de las necesidades de los clientes durante el levantamiento de 
requerimientos. 
 
Construir una propuesta para ajustar el proceso de levantamiento de requerimientos 
funcionales, buscando reducir las inconformidades que expresan los clientes de la 
compañía durante las fases de implementación y pruebas. 
 
Desarrollar un piloto controlado utilizando el proceso modificado para el 
levantamiento de requerimientos, y poder obtener evidencias contrastables con la 
línea base establecida. 
 
30 
5. MARCO CONCEPTUAL 
 
Para brindar una mayor contextualización del proyecto se abordarán algunos 
conceptos importantes. 
El ciclo de vida del software es una estructura conceptual que proporciona una guía 
para la planificación, el diseño, la construcción y la entrega de un software, como lo 
muestra la Figura 10. Ciclo de vida del software Un modelo de desarrollo de 
software establece una serie de faces, actividades y tareas que deben ser seguidas 
para asegurar que el software se construya de manera eficiente y eficaz9. 
Figura 10. Ciclo de vida del software 
 
 
 
 
 
 
 
 
 
 
 
 
Fuente: Elaboración Propia 
 
Como se muestra en la Figura 10. Ciclo de vida del software, el modelo de 
desarrollo de un software comienza con el análisis de requerimientos, que se 
encarga de determinar el objetivo del software e identificación de los requisitos de 
 
9 M. DE Desarrollo De Software and E. Gabriel Pacienzia, “FACULTAD DE QUÍMICA E INGENIERIA 
‘FRAY ROGELIO BACON’ PONTIFICIA UNIVERSIDAD CATÓLICA ARGENTINA SANTA MARIA 
DE LOS BUENOS AIRES Cátedra Seminario de Sistemas,” PONTIFICIA UNIVERSIDAD CATÓLICA 
ARGENTINA SANTA MARIA DE LOS BUENOS AIRES , 2015. Accessed: Feb. 22, 2023. [Online]. 
Available: https://repositorio.uca.edu.ar/bitstream/123456789/522/1/metodologias-desarrollo-
software.pdf 
Mantenimiento 
Análisis de Requerimientos 
Diseño 
Implementación 
Verificación 
31 
usuario y las necesidades del sistema. En la fase de diseño se especifican los 
componentes e interacciones del software. En la fase de implementación se 
construye el código fuente y se construye el software siguiendo el diseño 
previamente definido. En la fase de verificación se valida que el software cumpla 
con los requisitos de usuario en distintas condiciones y situaciones. Finalmente, en 
la fase de Mantenimiento se realizan las correcciones y mejoras necesarias para 
garantizar que el software funcione correctamente. 
El ciclo de vida de un software se puede categorizar en tres modelos no definitivos 
para el desarrollo del software. Ya que son conceptualizaciones de los modelos que 
se pueden utilizar para desarrollar software, como lo son: 
• El modelo en cascada: Es un modelo que se aconseja para proyectos que 
sean poco probables que vayan a cambiar durantela fase de desarrollo, dado 
que permite monitorizar el avance del proyecto a partir de la documentación 
que se va generando, se divide en un conjunto de faces las cuales respetan 
un orden de forma ascendente a descendente. Cada fase debe generar un 
documento que debe ser aprobado para continuar con la siguiente fase, sus 
faces son: Requisitos, diseño, implementación, verificación y mantenimiento 
como se muestra en la Figura 11. Modelo en cascada. Es el modelo más 
seguro en comparación al evolutivo y al de componentes, pero solo es 
recomendable utilizarlo cuando se comprenda bien los requerimientos10. 
 
10 DIGITAL TALENT AGENCY, “MODELO WATERFALL O EN CASCADA,” in Modelo de Gestión de 
Proyectos | Digital Talent Agency, 2018. Accessed: Feb. 26, 2023. [Online]. Available: 
https://www.dtagency.tech/cursos/metodologias_gestion_proyectos/tema_1-ModeloWaterfall.pdf 
32 
Figura 11. Modelo en cascada 
Fuente: Elaboración Propia 
 
 
La Figura 11. Modelo en cascada muestra cuál es el orden que sigue este 
modelo, en donde por cada fase se debe generar un documento o entregable 
completo que permite brindar una mejor claridad de los procesos realizados 
entre cada una de las fases. Una vez se llega a la fase de mantenimiento se 
empieza a validar los diferentes errores encontrados en las fases anteriores 
con el propósito de mejorar la implantación de un sistema. 
 
• El modelo evolutivo: Es un modelo interactivo que se caracteriza por 
generar una versión inicial, la cual se comparte con el cliente para recibir sus 
comentarios y por medio de constantes entregables con los cuales se va 
refinando el software. Posee la ventaja de satisfacer en un tiempo óptimo las 
necesidades del cliente, pero posee la desventaja que al realizar entregas 
regulares no se documente de forma óptima cada entregable, haciendo que 
en el proceso evolutivo sea casi nulo la documentación del software hasta el 
final11, este modelo se divide en dos modelos diferentes como se muestra en 
la Figura 12. Tipos de modelos evolutivo. 
 
11 M. DE Desarrollo De Software and E. Gabriel Pacienzia, “FACULTAD DE QUÍMICA E INGENIERIA 
‘FRAY ROGELIO BACON’ PONTIFICIA UNIVERSIDAD CATÓLICA ARGENTINA SANTA MARIA 
DE LOS BUENOS AIRES Cátedra Seminario de Sistemas,” PONTIFICIA UNIVERSIDAD CATÓLICA 
Requisitos 
Diseño 
Implementación 
Verificación 
Mantenimiento 
33 
 
Figura 12. Tipos de modelos evolutivos 
 
Fuente: Elaboración Propia 
 
 
 
Como se muestra en la Figura 12. Tipos de modelos evolutivo el modelo 
evolutivo se puede utilizar de dos formas: 
 
Incremental, en donde se entregan partes pequeñas del software totalmente 
funcionales y se va integrando uno a uno con el paso del tiempo. 
 
Iterativo, Se entrega el esqueleto completo del sistema al principio y con el 
paso del tiempo se va agregando los módulos. 
 
• Modelo de componentes reutilizables: Se basa en una metodología en 
donde se pretende desarrollar software con características modulares, 
independientes y reutilizables. Posee el propósito de reutilizar el código en 
vez de volverlo a desarrollar, de esta forma se identifican proyectos 
anteriores con funcionalidades similares que un proyecto actual requiera. 
 
ARGENTINA SANTA MARIA DE LOS BUENOS AIRES , 2015. Accessed: Feb. 26, 2023. [Online]. 
Available: https://repositorio.uca.edu.ar/bitstream/123456789/522/1/metodologias-desarrollo-
software.pdf 
MODELO INCREMENTAL 
MODELO INTERATIVO 
34 
Finalmente, si es necesario, se realizarán adaptaciones con el propósito de 
adecuarlos a las necesidades del cliente para validarlos con el cliente12, 
como se muestra en la Figura 13. Modelo de componentes reutilizables. 
Figura 13. Modelo de componentes reutilizables 
 
Fuente: Elaboración Propia 
 
En la figura anterior se muestra el proceso que se debe llevar a cabo para el modelo 
de componentes reutilizables, en donde es necesario la entrada de una 
especificación de requerimientos para pasar a un análisis de componentes para 
validar que otras funcionalidades anteriores se logra adecuar de mejor forma al 
nuevo proyecto. De esta forma al generar un nuevo requerimiento se pasa al área 
de diseño el cual le da una estructura al requerimiento, después de esto se le 
entrega el requerimiento al área de desarrollo para programar el nuevo 
requerimiento y finalmente se pasa al área de validación del sistema cuando se 
empieza a validar si la nueva funcionalidad se adaptó según lo especificado en el 
levantamiento funcional. 
Los modelos mencionados anteriormente se deben implementar dependiendo de la 
naturaleza del proyecto de software, además es necesario tener en cuenta las 
 
12 I. Crnkovic, S. Larsson, and M. Chaudron, “Component-based development process and 
component lifecycle,” in 27th International Conference on Information Technology Interfaces, 2005., 
pp. 591–596. doi: 10.1109/ITI.2005.1491195. 
Especificación de 
requerimientos 
Análisis de 
componentes 
Modificación de 
requerimientos 
Diseño del sistema 
con reutilización 
Desarrollo e 
integración 
Validación del 
sistema 
35 
ventajas y desventajas de cada modelo como lo muestra la Tabla 3. Ventajas y 
Desventajas de los modelos de ciclo de vida del software. 
 
Tabla 3. Ventajas y Desventajas de los modelos de ciclo de vida del 
software. 
Modelos de ciclo 
de vida de un 
Software 
Ventajas Desventajas 
Modelo en cascada • Usa una estructura 
clara. 
• Fácil de entender. 
• Documentación 
exhaustiva. 
• Pruebas bien definidas. 
• Falta de flexibilidad para 
adaptarse a cambios. 
• Dificultad para volver a 
etapas anteriores. 
• Retrasa las pruebas hasta 
después de la finalización. 
Modelo evolutivo • Es adaptable a las 
modificaciones. 
• Permite mejoras 
graduales. 
• Es retroalimentado 
constantemente. 
• Reducen el riesgo en 
las fases de 
levantamiento de 
requerimientos, diseño 
y desarrollo. 
• La documentación es 
escasa. 
• Los cambios constantes 
convierten a un desarrollo 
en una tarea cada vez 
más difícil y costosa. 
Modelo de 
componentes 
reutilizables 
• Ahorra tiempo y 
recursos. 
• Facilita el 
mantenimiento. 
• Reduce los costos y los 
riesgos. 
• Posee la dificultad de 
encontrar componentes 
de software adecuados 
para su reutilización. 
Fuente: Elaboración Propia 
La tabla anterior muestra las ventajas y desventajas de los ciclos de vida de los 
modelos cascada, evolutivo y de componentes reutilizables. 
Una parte fundamental al momento de llevar a cabo un levantamiento funcional es 
la planificación y el proceso de gestión de los requisitos, tiene como objetivo facilitar 
la comprensión de cómo se llevará a cabo la recepción, análisis, documentación y 
gestión de todos los requisitos en un proyecto. Este proceso inicia desde la 
recopilación de la información de alto nivel hasta la recolección de requisitos más 
detallados a lo largo del ciclo de vida del proyecto. Es importante definir: una 
descripción general del proyecto, el proceso de recolección de requisitos, las 
36 
funciones y responsabilidades de los miembros del equipo, las herramientas 
necesarias y el seguimiento de los requisitos 13. 
El término requerimiento funcional será abordado por partes. Un “Requerimiento” 
según el diccionario Larousse (2012) se define como “Acción y efecto de requerir o 
requerirse”14. Por otro lado, “Funcional” es definido por el diccionario Larousse 
(2012) como “Relativo a las funciones orgánicas, matemáticas o conceptuales, y 
especialmente a las vitales”15. Estas definiciones juntas pasan a convertirse en un 
método para delimitar las funcionalidades que debe realizar un software, esto a 
partir de la identificación de lo que un usuario puede hacer con el sistema. Los 
requerimientos funcionales buscan dar solución a la necesidad de un cliente, en 
donde si un requerimiento es ambiguo o no es bien detallado, el analista funcional 
debe interpretar este requerimiento bajo su propio criterio y volverlo más 
coherente16. 
Por otro lado, los requerimientosno funcionales describen una restricción que limita 
a los usuarios en el sistema, en donde no describe lo que debe hacer el sistema, en 
cambio, determina como debe comportarse el sistema, además de describir las 
propiedades generales del mismo. También conocidos como atributos de calidad17. 
 
La calidad de software está dada por la medida en la que un programa o sistema 
debe cumplir con los requisitos, expectativas y necesidades de los usuarios y las 
partes interesadas, también conocidas como stakeholders. Para lograr este 
cometido se debe cumplir con unos procesos y prácticas de desarrollo de software 
efectivos, como el control de calidad, la gestión de requisitos, la gestión de 
proyectos, la prueba de software, la documentación y el mantenimiento del software. 
De esta forma, la calidad de software es medible y varía de un sistema a otro, en 
donde no es lo mismo un software que solo es necesario ejecutarlo una vez a un 
software que debe ser utilizado por alrededor de 10 años o más 18. Existen varios 
modelos de calidad de software los cuales se deben implementar según la 
necesidad de un proyecto
 
13 IBM, “¿Qué es la gestión de requisitos? | IBM.” https://www.ibm.com/mx-es/topics/what-is-
requirements-management (accessed Apr. 23, 2023). 
14 Larousse (Firm), “Requerimiento,” Larousse (Firm). Larousse, p. 880, 2012. 
15 Larousse (Firm), “Funcional,” Larousse (Firm). Larousse, p. 468, 2012. 
16 P. Caro, “Capítulo 3 DEFINICIÓN REQUERIMIENTOS - Metodología Gestión de Requerimientos,” 
Apr. 24, 2012. https://sites.google.com/site/metodologiareq/capitulo-iii (accessed Oct. 09, 2022). 
17 altextsoft, “Functional and Non-functional Requirements: Specification and Types 
| AltexSoft.” https://www.altexsoft.com/blog/business/functional-and-non-
functional-requirements-specification-and-types/ (accessed Oct. 30, 2022). 
 
18 M. Callejas-Cuervo, A. C. Alarcón-Aldana, and A. María Álvarez-Carreño, “Modelos de calidad del 
software, un estado del arte*,” vol. 13, no. 1, 2017, doi: 10.18041/entramado.2017v13n1.25125 
37 
6. MARCO TEÓRICO 
 
6.1 INGENIERÍA DE REQUERIMIENTOS 
Dentro de la Ingeniería de Software, la ingeniería de requerimientos es una parte 
fundamental, debido a que permite un mejor entendimiento sobre la pregunta ¿Qué 
debe hacer un software?, de esta forma este rol se encarga de procesar las 
declaraciones de lo que el sistema debe hacer o las características que debe tener 
para satisfacer las necesidades de los usuarios y cumplir con los objetivos del 
proyecto. La ingeniería de requerimientos es una parte crítica del ciclo de vida del 
desarrollo de software, ya que debe adaptarse a las necesidades del producto, 
proceso, del proyecto y de las personas que hacen el trabajo19. 
Cabe destacar que para detallar las características del sistema se deben describir 
con claridad y sin ambigüedades las necesidades de los usuarios o clientes. l. Por 
lo general, el concepto de ingeniería de requerimientos se aborda desde dos puntos 
de vista, desde a fuera hacia adentro, en donde se debe identificar los principales 
actores y como ellos interactúan con el software. El segundo método es teniendo 
en cuenta el modelo de flujo del cliente, en donde solo el software va a intervenir 
cuando es necesario. Pero sin importar el punto de vista desde donde se mire se 
conseguirá el mismo resultado20. 
La ingeniería de requisitos o también conocida como ingeniería de requerimientos, 
permite generar escenarios de uso, delimitar las funciones y las peculiaridades, y 
se identifican las delimitaciones del proyecto, de esta forma se convierte en un 
mecanismo que permite evaluar las necesidades del cliente, además de distinguir 
la solución sin ambigüedades, evaluar la viabilidad, negociar una solución 
razonable, determinar la particularidad y autenticar los requisitos funcionales a 
medida que se transforma en un sistema funcional21. Durante esta elaboración 
influyen siete tareas, las cuales pueden realizarse en paralelo: 
 
 
19 P. Roger, Ingeniería del software un enfoque práctico, Séptima ed. Mc Graw Hill, 2010. Accessed: 
Oct. 09, 2022. [Online]. Available: http://www.javier8a.com/itc/bd1/ld-
Ingenieria.de.software.enfoque.practico.7ed.Pressman.PDF 
20 C. Rica Arias Chaves, “La ingeniería de requerimientos y su importancia en el desarrollo de 
proyectos de software,” vol. 6, no. 10, pp. 1–13, Jun. 2005, Accessed: Nov. 06, 2022. [Online]. 
Available: http://www.redalyc.org/articulo.oa?id=66612870011 
21 J. Reyes, “La ingeniería de requisitos en el desarrollo de aplicaciones informáticas,” Rev. Cuba. 
Informática Medica, pp. 1–15, Dec. 2020, Accessed: Nov. 06, 2022. [Online]. Available: https://web-
p-ebscohost-com.ucatolica.basesdedatosezproxy.com/ehost/detail/detail?vid=0&sid=871f1674-
b922-4a0d-95b2-
136e45843333%40redis&bdata=Jmxhbmc9ZXMmc2l0ZT1laG9zdC1saXZl#db=fua&AN=14786402
5 
38 
6.1.1 Analizar la concepción del sistema. 
Se comprende la necesidad del negocio y partiendo desde este punto se logra 
identificar la naturaleza de la solución y el equipo a cargo de la solución. 
 
6.1.2 Indagar cuál debe ser el propósito del software. 
Esta actividad busca identificar cuáles son las necesidades del cliente o cuál es el 
propósito del software. Es importante determinar un límite claro en las capacidades 
del sistema, esto se debe a que solicitudes innecesarias crearan inconsistencias 
que alteraran el alcance de un proyecto. Por otro lado, es importante tener presente 
que en algunas oportunidades los clientes no están completamente seguros de lo 
necesitan. Además, poseen problemas para comunicar sus necesidades al 
ingeniero de requerimientos, omiten información que consideran que es obvia. 
Finalmente, es necesario destacar que cada requerimiento posee la particularidad 
de cambiar con el tiempo para adaptarse a las nuevas necesidades22. 
6.1.3 Recrear posibles escenarios. 
Es el resultado de la concepción y la indagación. Se deben contemplar posibles 
escenarios dentro del flujo de negocio del cliente, esto con el propósito de exponerlo 
posteriormente a los clientes y determinar si estos acontecimientos pueden llegar a 
ocurrir y en caso contrario de no ser así delimitarlos23. 
 
6.1.4 Negociar con el cliente. 
Se necesita negociar cuando el cliente o el usuario solicite ampliar las capacidades 
del sistema, argumentando “Es un proceso vital para nuestro modelo de negocio”. 
Se hace necesaria una reunión con el cliente en dónde es importante no abordar 
ese requerimiento como algo difícil de llevar a cabo, sino que pregunta si 
verdaderamente es necesario o en su defecto se aborda el requerimiento desde un 
 
22 C. Caballero, “EFECTIVIDAD METODOLÓGICA PARA EL LEVANTAMIENTO DE 
REQUERIMIENTOS DE UNA APLICACIÓN WEB QUE PERMITA REALIZAR EL PROCESO DE 
PLANEACIÓN DE LA ACCIÓN PEDAGÓGICA,” UNIVERSIDAD AUTONÓMA DE BUCARAMANGA 
EN CONVENIO CON UNIVERSITAT OBERTA DE CATALUNYA, Bogotá, 2017. Accessed: Nov. 13, 
2022. [Online]. Available: 
https://repository.unab.edu.co/bitstream/handle/20.500.12749/3419/2017_Tesis_Lopez_Caballero_
Cesar_Augusto.pdf?sequence=1 
23 J. Francisco and A. Holgado, “Ingeniería de Requisitos.” Salamanca, Feb. 20, 2018. Accessed: 
Nov. 06, 2022. [Online]. Available: https://repositorio.grial.eu/bitstream/grial/1143/1/IS_I Tema 4 - 
Ingenieria de Requisitos.pdf 
39 
punto de vista diferente que permita su implementación haciendo que sea necesario 
levantar nuevos requerimientos23. 
 
6.1.5 Especificar el funcionamiento. 
Comprende la utilización de diferentes tipos de documentos en los que se puede 
encontrar diagramas de casos de uso, documentos escritos, utilización de modelos 
matemáticos específicos, un escenario de uso, un prototipo o una combinación de 
todos estos. Esto permite argumentar cada especificación. Cabe destacar que la 
forma como se aborde la construcción de la especificación varía dependiendo de su 
tamaño. Para un sistema pequeño se requerirá especialmente solo los escenarios 
de uso, peropara un sistema grande o complejo se necesita la utilización de 
lenguaje natural, y modelos gráficos, los cuales permiten contextualizar y orientar 
cómo se desarrolla el flujo de negocio del cliente24. 
 
6.1.6 Validar el funcionamiento de los requerimientos. 
Radica en revisar los requisitos funcionales entre el equipo de desarrollo, el cliente, 
usuarios y otros participantes. Esto con el fin de analizar cómo se mueve el flujo de 
negocio del cliente, y comprobar que cada requerimiento haya sido interpretado de 
forma debida25. 
 
6.1.7 Administrar los requerimientos. 
Es un mecanismo de control que nace de la necesidad de moderar el crecimiento 
de los requerimientos. Este concepto se divide en tres partes. La primera parte trata 
sobre el almacenamiento de requerimientos, que es la práctica de almacenar los 
datos en un lugar seguro y que sea accesible a los diferentes miembros del equipo. 
La segunda parte trata sobre la administración del cambio, que es el proceso de 
adaptarse a las nuevas necesidades de un cliente. Por último, la administración del 
 
24 I. Sommerville, “Capitulo 6 Ingeniería de Requerimientos,” Ing. Requerimientos, pp. 2–14, Aug. 
2015. 
25 A. Ramírez Fernández Tutora, “CLASIFICACIONES DE TIPOS DE REQUISITOS PARA LA 
MEJORA DEL PROCESO DE DESARROLLO DEL SOFTWARE,” Universidad Carlos III de Madrid, 
Madrid, 2012. Accessed: Nov. 06, 2022. [Online]. Available: 
https://core.ac.uk/download/30046163.pdf 
40 
seguimiento. En esta fase se buscan identificar requerimientos relacionados 
utilizando técnicas de filtrado utilizando el lenguaje natural26. 
 
6.2 REQUERIMIENTOS 
Un requerimiento es una necesidad solicitada por parte de los interesados en el 
proyecto. Todo requerimiento busca conseguir un resultado específico. Estos son 
los que definen las funcionalidades que el sistema debe desempeñar. Además, 
describen los valores de las entradas que el sistema solicita para obtener como 
resultado las salidas27. 
 
6.2.1 Requerimientos Funcionales. 
Son las funcionalidades que los desarrolladores del sistema deben brindar para 
satisfacer las necesidades de las partes interesadas. Estos son los que definen las 
características o funciones del sistema, por tanto, deben ser claros tanto para el 
equipo de desarrollo como para las partes interesadas17. 
 
6.2.2 Requerimientos no Funcionales. 
Son las características que determinan las propiedades de un software, como su 
comportamiento o funcionamiento. Van ligadas a los requerimientos funcionales, 
porque mientras que un requerimiento funcional indica lo que realiza un software, 
un requerimiento no funcional indica el cómo lo hará17. 
 
6.3 CARACTERÍSTICAS DE LOS REQUERIMIENTOS 
Los requerimientos funcionales les permiten a los desarrolladores entender lo que 
el cliente necesita del sistema, y también muestran a los desarrolladores la 
funcionalidad y capacidades que tendrá el sistema; Le permiten al l equipo de 
prueba determinar qué simulaciones ejecutar para convencer a clientes de que el 
sistema entregado es exactamente lo que necesitan. Para hacer esto, los requisitos 
deben cumplir con ciertas características para que sean comprensibles y cumplan 
 
26 M. Briseño, “Fundamentos de ingeniería de Requerimientos,” 2015. Accessed: Nov. 06, 2022. 
[Online]. Available: 
http://ing.ens.uabc.mx/docencia/apuntes/computacion/requerimientos[12147].pdf 
27 S. R. Santana, R. L. Antonelli, and P. J. Thomas, “Proceso de validación de requerimientos de 
software,” 2022, Accessed: Nov. 12, 2022. [Online]. Available: 
http://sedici.unlp.edu.ar/handle/10915/144125 
41 
con la tarea de ayudar a los desarrolladores a construir el sistema correctamente. 
Una “característica” es definida por el diccionario Larousse como “Lo que constituye 
el carácter distintivo o la particularidad de alguien o de lago”28. Los requerimientos 
deben poseer las siguientes características como se muestra en la Tabla 4. 
Característica de los requerimientos. En donde hace referencia a la información 
que se debe tener en cuenta al momento de considerar un requerimiento. 
 
 
 
28 Larousse (Firm), “Característica,” Larousse (Firm). Larousse, p. 201, 2012. 
42 
Tabla 4. Característica de los requerimientos 
Característica Descripción 
Necesario Se debe consultar con el cliente si verdaderamente es 
necesario un requerimiento, debido a que en el mejor de los 
casos no sea necesario y todo se deba a un capricho del 
cliente. 
Completo El conjunto de requisitos se considera completo, cunado uno 
de los requisitos describe todos los estados posibles, 
transiciones de estado, entradas, salidas y restricciones. 
Consistente Un requerimiento no se debe contradecir con otro 
requerimiento. 
Correcto Tanto el cliente como el desarrollador deben revisar los 
requerimientos para asegurar que no posean errores. 
Realistas Cada requerimiento debe ser revisado para garantizar de 
forma anticipada que sean posibles. 
Factible El requisito debe ser totalmente alcanzable y dentro del 
presupuesto, el cronograma y otras limitaciones. Si existen 
dudas sobre su factibilidad, es necesario realizar 
investigaciones y realizar pruebas de concepto para 
determinar su complejidad y factibilidad. En caso de que no 
ser factible, se debe reconsiderar el requisito. 
Modificable Se debe garantizar que cualquier cambio puede realizarse de 
manera, fácil, completa y consistente. 
Priorizado Los requerimientos deben ser categorizados con el objetivo 
de determinar el grado de necesidad de este Crítico, Alto, 
Medio o Bajo. 
Verificable Se deben preparar pruebas que demuestren que se han 
cumplido los requerimientos. 
Rastreable Se debe organizar cada función del sistema con el propósito 
que se pueda rastrear cada función con su respectivo 
requerimiento. 
Claro Un requerimiento debe ser conciso, esto con el propósito de 
ser fácil de leer y comprender, y la redacción debe ser simple 
y comprensible para quienes se referirán a él en el futuro. 
Fuente: Elaboración Propia 
 
La Tabla 4. Característica de los requerimientos, muestra las características que 
debe cumplir los requerimientos funcionales para determinar si es o no es viable el 
requerimiento. De esta forma se valida el alcance que debe tener un requerimiento. 
Es necesario validar esto, ya que, si un proyecto desde un inicio no es factible por 
alguna limitación técnica, se debe buscar una forma para desarrollar el 
43 
requerimiento o tomar la decisión de aceptar que no se posee la capacidad de llevar 
a cabo el requerimiento. 
 
6.4 IMPORTANCIA DE SELECCIONAR UNA BUENA TÉCNICA DE 
LEVANTAMIENTO DE REQUERIMIENTOS 
Una técnica es un método en donde se documenta una serie de pasos que van de 
la mano con unas reglas para su uso y criterios para verificar su corrección, en 
donde por lo general aplica un conjunto de procedimientos físicos o intelectuales a 
una tarea específica, basados en conocimientos científicos o artísticos, para lograr 
un resultado específico29. La “técnica” es definida por la RAE (Real Academia 
Española) como “Perteneciente o relativo a las aplicaciones de las ciencias y las 
artes”30. 
Existen diferentes métodos para el levantamiento de requerimientos, en donde 
varias de estas metodologías ya existen y tienen el propósito de asistir a los 
analistas funcionales a entender el flujo de trabajo del cliente, como la utilización de 
Mockups, diagramas de casos de uso, entrevistas, entre otros. 
 
6.5 TÉCNICAS DE RECOPILACIÓN DE REQUERIMIENTOS 
Existen muchos métodos y técnicas para la recopilación de requerimientos, todos 
con el objetivo común de ayudar a los analistas a comprender sus necesidades. 
Aunque algunos analistas creen que solo es necesario una metodología o método 
es aplicable a todas las situaciones, una metodología o método puede no ser 
suficiente para todas las condiciones31. 
De esta forma encontramos los siguientes métodos para recopilar información para 
levantamiento de requerimientos: 
6.5.1 Prototipo. 
Los prototipos