Design Thinking para adquirir requerimientos de
software
1st Ignacio Álvarez Barrantes
Ingenierı́a en Computación
Tecnológico de Costa Rica
nacho.alvarez2001@estudiantec.com
Abstract—El proceso de adquirir requerimientos de software
es de vital importancia para conseguir un buen producto, sin
embargo recolectar estos requerimientos supone un reto al tratar
con los usuarios. El Design Thinking, al estar centrado en una
visión antropocéntrica, proporciona técnicas para empatizar con
el usuario. Por lo tanto, en este artı́culo se presentará qué es
Design Thinking y sus caracterı́sticas principales. Además, se
mencionan los procesos de empatizar, idear, prototipar, testear y
cuáles técnicas son utilizadas en estos procesos. De esta manera,
se logra relacionar cómo se pueden aplicar las técnicas de
empatización para utilizarlas como una herramienta al adquirir
los requerimientos de software.
Palabras clave— Design Thinking, Procesos de Design Thin-
king, Requerimientos de software, Herramientas de adquisión de
requerimientos
I. I NTRODUCCI ÓN
En el vasto campo de la programación y la ingenierı́a de
requerimientos, a lo largo del tiempo, han surgido diversas
corrientes de pensamiento e ideales en cuanto a cuál es el
mejor método para llegar a comprender a los usuarios finales,
cuáles son los intereses y necesidades que poseen, debido a
que en ocasiones el proceso de recolección de requerimientos
presenta el reto de llegar al entendimiento entre lo que quiere
el usuario y lo que entienden los desarrolladores.
En el documento a continuación se explorará una de es-
tas corrientes de pensamiento, “Desing Thinking”. ¿Cómo
funciona? ¿Cuáles son sus principales caracterı́sticas? ¿Cómo
aplicar su metodologı́a? y ¿Cuáles son las técnicas utilizadas
para lograr el “Design Thinking”? son parte de las preguntas
importantes de responder para poder comprender esta corriente
de pensamiento y cómo aplicarla a la ingenierı́a de requeri-
mientos.
Con el desarrollo de estas preguntas se logra encontrar
la aplicación que se les puede otorgar a las técnicas del
“Design Thinking”, en el área de requerimientos de software
especı́ficamente en la adquisición de estos, ya que el “Design
Thinking” al tomar un enfoque de resolución de problemas
enfocada al usuario ayudará en el proceso de adquisión de
1
2nd Kevin Fallas Alvarado
Ingenierı́a en Computación
Tecnológico de Costa Rica
kf.ma@estudiantec.cr
requerimientos ya que estas técnicas facilitan la comunicación
entre grupos y ayuda a la comprensión del conocimiento.
II. D ESIGN T HINKING
El término “Desing Thinking” se refiere a uno de
los métodos empleados hoy en dı́a para generar ideas
innovadoras, las cuales centran su eficacia en entender y
dar una solución a las necesidades reales de los usuarios
involucrados.
II-A. Origen
El origen de dicho concepto proviene de la forma en la cual
los diseñadores de producto trabajan y buscan soluciones. De
ahı́ su nombre, el cual al traducirlo del inglés de forma literal
dice “Pensamiento de Diseño” para referirse al “pensamiento
del diseñador” [1].
Este concepto fue desarrollado de forma teórica en primera
instancia por la Universidad de Stanfford en California a
principios de los años 70s [1], pero su primera aparición bajo
el concepto “Desing Thinking” en sı́ fue impulsado por una
compañı́a consultora de diseño llamada IDEO, la cual a dı́a
de hoy es su principal precursora.
II-B. ¿Quiénes lo utilizan?
Al ser un método generador de ideas innovadoras no existe
un “área” especı́fica única en la que este estilo de pensamiento
pueda ser aplicado, el “Desing Thinking” “Es una disciplina
que usa la sensibilidad y métodos de los diseñadores para
hacer coincidir las necesidades de las personas con lo que es
tecnológicamente factible y con lo que una estrategia viable de
negocios puede convertir en valor para el cliente, ası́ como en
una gran oportunidad para el mercado”(Brown, T. TED Talk,
Julio del 2009) [18].
 Con esto Tim nos quiere dar a entender que el “pensamiento
del diseñador” puede ser aplicado a cualquier ámbito mientras
cumpla con una trı́ada:
Que sea tecnológicamente factible
Que posea una estrategia de negocio viable
Que provenga de necesidades reales de las personas.
Figura 1. Trı́ada base del “Desing Thinking” [16]
III. C ARACTER ÍSTICAS
La metodologı́a del “Desing Thinking” hace uso de iteracio-
nes para ası́ encontrar nuevas perspectivas que aplicar de forma
estratégica a las soluciones. Las iteraciones se caracterizan por:
III-A. La generación de prototipos
Ya que una de las principales caracterı́sticas del pensamiento
de diseñador es el hecho de que toda idea debe ser validada
antes de asumirse como correcta [1]. Por lo que este método
hace uso de prototipos para ası́ poder validar la solución con
el usuario final y poder hacer las correcciones necesarias en
caso de ser requeridas.
Figura 2. Herramienta de prototipado Figma
III-B. La creatividad
En el ámbito de diseño, se hace constante uso de la
imaginación y la creatividad para la resolución de problemas
especı́ficos. Al aplicar este tipo de razonamiento a otros
campos, es imperativo el uso de la creatividad para encontrar
2
nuevas formas de resolver los problemas planteados, este
método tiende a incentivar a pensar ”fuera de la caja” [1].
III-C. Usuario y Contexto
El método “Desing Thinking” se basa fundamentalmente en
¿Quién es el usuario? y ¿Cuál es su contexto? para ası́ poder
generar empatı́a comprender su situación y poder articular una
solución que satisfaga las necesidades del usuario [16].
III-D. Empatı́a
Para el “Desing Thinking” es imperativo que se tenga
empatı́a con el usuario y final y cuál es el problema a resolver
para el mismo [16].
III-E. Experimental
Una de las principales caracterı́sticas del pensamiento de
diseñador es el hecho de que la articulación de una solución
no se obtiene al primer prototipo entregado, sino, que se
suelen experimentar diversas ramas de soluciones posibles y
por medio de prototipos se determina cuales son las que en
realidad son soluciones factibles [1].
IV. M ETODOLOG ÍA EN D ESIGN T HINKING
El modelo “Desing Thinking” consta de 5 partes esenciales
para llegar al desarrollo de una solución empatizar, definición,
ideación, prototipado, testeo. Estos procesos permitirán afinar
el contenido poco a poco hasta desembocar en una solución
[16]. En la siguiente imagen podemos apreciar cada una de
estas etapas además de una breve explicación de las mismas:
Figura 3. Metodologı́a del Design Thinking [16]
IV-A. Empatizar
El proceso comienza con una profunda compresión de
las necesidades de los usuarios implicados en la solución
desarrollada y su entorno. Es necesario que el desarrollador
sea capaz de ponerse en los zapatos de los usuarios para ası́
poder generar soluciones consecuentes [16].
IV-B. Definir
Al concluir con la etapa de empatizar y recolección de
información es necesario depurar los datos y quedarse con los
datos que en realidad aportan valor a la solución. Es necesario
definir los subproblemas en esta etapa para ası́ poder identificar
las soluciones clave [1].
IV-C. Idear
Esta etapa tiene como fin generar la mayor cantidad de
opciones posibles, en esta etapa se favorece el pensamiento
expansivo [16].
IV-D. Prototipo
En esta etapa las ideas planteadas en etapas anteriores se
vuelven realidad, dichos conceptos se materializan por medio
del uso de prototipos para ası́ convertir las ideas en algo
palpable que pueda ser comprendido con mayor facilidad [16].
IV-E. Testeo
En esta etapa el prototipo creado es evaluado por los
usuarios finales, esta fase es crucial ya que permitirá identificar
errores de concepto además aportar mejoras significativas. Esta
etapa permitirá que la idea evolucione y sea transformada hasta
convertirse en la solución que se desea alcanzar [2].
V. T ÉCNICAS EN D ESIGN T HINKING
Las técnicas utilizadas en Design Thinking permiten que las
distintas etapas o procesos de la metodologı́a sean llevados a
cabo con éxito. A continuación se presentarán las técnicas más
comunes según el proceso en el que se encuentre.
Dentro del proceso de empatizar podemos encontrar las
siguientes técnicas:
1. Storytelling: Los storytelling es una manera de narrar
una historia con la intención de transmitir ideas de una
manera simple. En contextos de desarrollo de software
o organizacionales una historia puede entenderse como
una descripción detallada de las interacciones y los com-
portamientos pasados de empleados y gerentes que se
comunican informalmente dentro o entre organizaciones
[19]. Este tipo de comunicación que es más interactiva,
entretenida, empática, logra generar que se preste más
atención a lo que se intenta comunicar [19].
2. Grupos de discusión: Los grupos de discusión o también
conocidos como “Focus Group” logran identificar y
comprender opiniones, percepciones, hábitos o necesida-
des sociales e individuales, mediante sesiones grupales
de 6 a 10 individuos que son dirigidos por un moderador
que planteará los temas que se quieren desarrollar. Esta
manera de comunicación e interacción permite empatizar
3
más con las personas, ya que se genera un ámbiente de
comprensión y mayor compromiso [5].
Las siguientes herramientas ayudan al proceso de definir y
reconocer la información que es relevante para lograr identi-
ficar las mejores soluciones.
1. Árbol de Problemas: El árbol de problemas se utiliza
para identificar la causa y consecuencias del problema.
En la representación del árbol se encuentran las causas
como las raı́ces del árbol, el tronco es el problema
principal, las ramas significan problemas secundarios y
en las hojas se colocan las conseucencias [11].
2. Curvas de Valor: las Curvas de valor o también cono-
cidas como “Strategy Canvas”, se pueden utilizar para
crear y diseñar propuestas nuevas basándose en las
estrategias que la competencia utiliza. La curva define
el valor de la estrategia de la competencia [4].
3. Mapa de Contexto: Esta herramienta ayuda a que las
personas o el equipo de trabajo que están definiendo la
información relevante entiendan el contexto que están
inmersos, logrando identificar los factores que están
involucrados en el problema [15].
Para idear podemos utilizar alguna de las siguientes técnicas
ya que permiten generar ideas de una buena manera.
1. Lluvia de ideas: Con la lluvia de ideas o brainstorming
se busca obtener el pensamiento colectivo, ya que permi-
te que los integrantes propongan ideas de manera grupal
escuchando las ideas de todos los participantes y luego
anotando las ideas que surgen [3].
2. Cardsorting: Esta etapa puede ser realizada después de
la lluvia de ideas, porque es un método de clasificación
de contenidos, en los cuales los participantes relacionan
los conceptos que encuentran similares [13].
3. Mapa de oferta: Pretende representar de manera visual
las caracterı́sticas y funcionalidades de un producto, se
identifica los elementos que generan diferencias entre
productos similares [13].
Dentro de las técnicas para prototipar se puede utilizar algunas
de las siguientes:
1. Mockup: Es una herramienta que se utiliza para reflejar
los elementos que se logran identificar en las etapas
anteriores, comunican la estructura y la funcionalidad
del producto final [9].
2. Prototipo: Es una representación de alta fiabilidad del
producto final, en el cual se puede interactuar con este
 en contraste con los Mockups. El protopipo ayuda para
validar la experiencia del usuario con el producto final
sin tener que desarrollar todo el producto para que el
usuario lo pruebe [14].

Por último, se el testeo se puede llevar a cabo mediante las

siguientes técnicas para facilitar este proceso o bien realizarlo
de manera más efectiva.

1. Testeo de Prototipo: Esta herramienta consiste en presen-

tar el prototipo al usuario, para determinar si la solución
propuesta se adapta a las necesidades apropiadamente
[13].
2. Prueba de usabilidad: En esta actividad se les proponen
a los usuarios que realicen una serie de tareas con los
prototipos, para identificar como es la experiencia con
la interacción de la solución [6].
VI. R EQUERIMIENTOS DE SOFTWARE
Los requerimientos de software se pueden entender como
una especificación de lo que debe ser implementado en un
sistema. Incluyen las descripciones de lo que el sistema de
software debe hacer o las caracterı́sticas que debe poseer [12].
Figura 4. Subdisciplinas de la Ingenierı́a de Requerimientos [12]
VI-A. Procesos
Para llevar a cabo la administración de los requerimientos
es necesario seguir los procesos de Adquisición o educción,
analizar y negociar, especificar y documentar, validar [12].
Estos hitos se realizan de manera no lineal, ya que entre estas
etapas se complementan mutuamente.
En las etapas del análisis o validación se pueden encontrar
errores o mal entendidos y debido a esto es necesario volver a
adquirir las necesidades o bien a reescribir la especificación de
los requerimientos. Cada uno de estos procesos del desarrollo
de los requerimientos tienen las siguientes intenciones como
lo menciona Wiegers y Beatty [12]:

Adquisición o educción: Identificar las roles y usuarios,

A grandes rasgos, abarca los requerimientos de negocio, los
comprender las tareas y metas, encontrar las necesidades
requerimientos de usuario y los requerimientos funcionales.
existentes y cuales son las expectativas.
Los requerimientos de negocios son aquellos que describen
el porqué la organización o empresa necesita implementar el
Análisis: Se pretende analizar la información recolectada
sistema. Los requerimientos de usuario describen las tareas y
para encontrar los requerimientos funcionales, no funcio-
operaciones que los empleados o los que interactúan con el sis-
nales, prioridades, identificar las expectaciones entre los
tema ejecutarán en sus labores. Por último, los requerimientos
requerimientos.
funcionales están dirigidos a especificar los comportamientos
que el software deberá poseer para cumplir con las necesidades
Documentación: En esta etapa se utiliza para representar
[12].
y almacenar los requerimientos hallados para que de esta
manera sean persistentes, rastreables y manejables.
Gracias a los requerimientos de software es posible man-
tener un acuerdo detallado con los clientes e interesados del Validación: En esta etapa se confirma que los requeri-
sistema a implementar con el fin de definir los lı́mites del siste- mientos documentados sean aceptados por los clientes,
ma y reducir las brechas de expectación entre el producto final usuarios o interesados en el producto.
y el producto esperado. Asimismo, los requerimientos ayudan
a que los desarrolladores comprendan mejor las caracterı́sticas
y comportamientos del sistema. VII. D ESIGN T HINKING Y LA ADQUISI ÓN DE LOS
REQUERIMIENTOS
El desarrollo de los requerimientos de software es una
subdisciplina de la ingenierı́a de requerimientos, la cual se El Design Thinking y el desarrollo de los requerimientos
crea con el desarrollo de los requerimientos y la gestión de presentan intersecciones entre sus procesos como lo presentan
los requerimientos como se puede observar en la siguiente Jennifer Hehn et al. en su gráfico del estudio “On Integrating
figura. Desing Thinking for a Human-centered Requirements Engi-
neering” [10], el cual se puede apreciar en la figura 5 donde

4
cada proceso de la metodologı́a del “Design Thinking” es
aplicado en los procesos de la ingenirı́a de requerimientos
las cuales implican actividades para entender el contexto, los
requerimientos y el sistema.
Como el Desing Thinking es una manera de resolver pro-
blemas centrados en los humanos [16], se puede recurrir al
“tool-box” o técnicas del Design Thinking antes mencionadas,
para comprender mejor a los usuarios, clientes a la hora de
adquirir los requerimientos del proyecto en etapas tempranas
del desarrollo de los requerimientos.
Figura 5. Relación entre Ingenierı́a de requerimientos y Design Thinking [10]
5
Según Hugo Ferreira et al., el Design Thinking se ha
utilizado como técnica de adquisión de los requerimientos y
de inmersión en las áreas del proceso, lo que acerca al cliente
al equipo del proyecto de software y permite la creación de
mejores proyectos [8].
Además, el “Design Thinking” ayuda a reducir la brecha
de expectativas la cual incrementa en medida que el tiempo
y el desarrollo del proyecto transcurre si no se logra que
los clientes y los desarrolladores generen un compromiso
constante para comprenderse mejor entre sı́, como se muestra
en la siguiente figura.
Figura 6. Expectation gap [12]
VII-A. Técnicas para adquirir los requerimientos
La etapa de adquirir los requerimientos es de suma im-
portante en el desarrollo de los requerimientos ya que aquı́ se
identifica las verdaderas necesidades de los usuarios, se delimi-
ta el alcance y también se reduce la brecha de expectativas que
puede generarse en lo que el usuario esperaba y la entrega final
del producto. Con Desing thinking en la etapa de empatizar se
busca entender estar en los zapatos de los usuarios, entender lo
que piensa y lo que necesita. Para ello utilizan técnicas como
“Storytelling”, “Focus Groups”, las cuales se pueden aplicar
en la recolección de los requerimientos también.
Storytelling: Al ser una forma de comunicación inusual
y bastante atractiva supera a otras formas de comunicar
para lograr mejor aprendizaje, memorización y capacidad
de unir a diferentes comunidades [7].
Las historias se pueden utilizar para narrar de manera
detallada situaciones y tareas de la vida cotidiana, las
cuales permiten el entendimiento del contexto, las per-
sonas involucradas, sus intereses, necesidades para luego
identificar “User personas” o “Product Champions”. Se
debe tener en cuenta el fin de la actividad la cual es
la adquisición de requerimientos para evitar que ocurran
desvı́os del tema central.
 Focus Group o Grupos de discusión: En las sesiones
de focus group ayudan a descubrir los atributos de los
usuarios, las preferencias, sus necesidades. Se llevan a
cabo con usuarios que comparten las mismas actividades
para que generen ideas de los posibles requerimientos
de manera interactiva [12]. Esta técnica permite construir
experiencias y encontrar el valor de sus prácticas o tareas
de forma natural entorno a los objetivos principales que
se quieren obtener con los grupos de discusión.
VIII. C ONCLUSIONES Y R ECOMENDACIONES
Esta investigación evidencia qué técnicas del Design Thin-
king pueden ser aplicadas en el proceso de la adquisión de los
requerimientos. Al estar enfocadas estas técnicas a otorgar un
mejor contexto enfocado a los usuarios permiten centralizarse
en obtener la mejor comprensión de las necesidades, contexto,
y deseos de los usuarios.
Lo cual representa una gran ventaja a la hora de recolectar
los requerimientos del proyecto, ya que evitamos malas inter-
pretaciones, conversaciones ineficientes y a su vez logramos
reducir la temida brecha de expectación entre el producto final
y lo que deseaba el usuario, logrando un mejor producto o
proyecto.
Es necesario considerar que estas técnicas de “Design
Thinking” son herramientas bastantes útiles a la hora de
comprender a los usuarios, por lo cual es necesario practicar
estas técnicas en distintos contextos para identificar cual es la
técnica más adecuada para ejecutar determinado proceso y de
esta manera lograr un buen uso de la esta.
IX. AGRADECIMIENTOS
Agradecemos al Instituto Tecnológico de Costa Rica por
las acciones tomadas que permitieron la continuidad de la
enseñanza incluso en los tiempos de adversidad que está
generando la pandemia del COVID-19. También agradecemos
a la escuela de computación por facilitar el material necesario
para el desarrollo de proyectos e investigaciones similares en
caso de ser necesario. Y por velar la calidad de la carrera y sus
profesores, asegurando ası́ que estén a la altura de los estánda-
res de calidad del mercado actual. Por último, agradecemos
a nuestro profesor Mario Chacón, del curso Desarrollo del
software, por motivarnos y brindarnos un espacio en su curso
para realizar la investigación además de acompañarnos en el
proceso de aprendizaje de temas importantes relacionados con
el Diseño de Software.
X. R EFERENCIAS
[1] A. Efeoglu, C. Møller, M. Sérié, and H. Boer. “Design thinking:
characteristics and promises.” CINet, September 2014, pp. 244-
248.
[2] C. L. Owen, “Design thinking: Notes on its nature and use”,
Design Research Quarterly, Vol. 2, No. 1, pp. 16-27. 2007.
[3] Design Thinking Comunidad Online. ¿Qué es el
Brainstorming? y ¿Por qué deberı́a de utilizar el
método de brainstorming para mis proyectos? [Online].
Disponible en: https://www.designthinking.services/
herramientas-design-thinking/brainstorming/
[4] Design Thinking en Español (s.f.). Curvas de valor [On-
line]. Disponible en: https://www.designthinking.es/inicio/
herramienta.php?id=75&fase=empatiza
[5] Design Thinking en Español (s.f.). Grupos de
discusión o ”focus groups”[Online]. Disponible en:
https://www.designthinking.es/inicio/herramienta.php?id=
55&fase=empatiza
[6] Design Thinking en Español (s.f.). Prueba de usabilidad
[Online]. Disponible en: https://www.designthinking.es/inicio/
herramienta.php?id=28&fase=testea
[7] F. R. Ciriello, A. Richter, and G. Schwabe, “When prototyping
meets storytelling: practices and malpractices in innovating
software firms”, 2017 IEEE/ACM 39th International Conferen-
ce on Software Engineering: Software Engineering in Practice
Track (ICSE-SEIP). IEEE, 2017.
[8] H. F. Martins, A. C. de Oliveira Junior, E. D. Canedo, R.
A. Dias Kosloski, R. Á. Paldês, and E. C. Oliveira, “Design
thinking: Challenges for software requirements elicitation,”
Information 2019, vol. 10, p. 371, doi:10.3390/info10120371.
[9] Invision. Mockup. [Online]. Disponible en: https://www.
invisionapp.com/design-defined/mockup/
[10] J. Hehn, D. Mendez, F. Uebernickel, W. Brenner, and M.
Broy, “On Integrating Design Thinking for Human-Centered
Requirements Engineering.”, IEEE Software, 2019, vol. 37, no
2, p. 25-31.
[11] J. Huertas. (s.f)“Qué es y cómo hacer un Árbol de Problemas”
Tutorial 4” [Online]. Disponible en: https://www.youtube.com/
watch?v=HH25PxFOWp4
[12] K. Wiegers and J. Beatty, Software Requirements ed.3. Wa-
shington: Microsoft Press, 2013. ISBN: 978-0-73567966-5
[13] M. Castillo, A. Alvarez, and R. Cabana, “Design thinking:
como guiar a estudiantes, emprendedores y empresarios en su
aplicación”, Ingenierı́a Industrial, ISSN 1815-5936, Vol. 35,
No. 3, septiembre-diciembre, p. 301-311, 2014.
[14] R. Mkrtchyan. (2018, Jun 26) “Wireframe, Mockup, Prototype:
What is What?” [Online]. Disponible en: https://uxplanet.org/
wireframe-mockup-prototype-what-is-what-8cf2966e5a8b
[15] SocialUD (s.f.). Mapa contextual [Online]. Disponible en: http:
//toolkit.designthinking-socialup.eu/es/mapa-contextual
[16] T. Brown, “Change by design: How design thinking transforms
organizations and inspires innovation”, New York: Harper
Business, 2009.
[17] T. Brown, and J. Wyatt, “Design thinking for social innovation”
Stanford Social Innovation Review, Vol. 8, No. 1, pp. 30-35,
2010.
[18] TED. (Septiembre 30, 2009). Tim Brown urge a los diseñadores
a pensar en grande [Video]. YouTube. https://www.youtube.
com/watch?v=UAinLaT42xY&t=18s
[19] W. Swap, D. Leonard, and L. A. Mimi Shields, “Using mento-
ring and storytelling to transfer knowledge in the workplace,”
J. Manag. Inf. Syst., 18-1, pp. 95–114, 2001.