1. Introduction

2. Research Design

3. UX Journey: Architecture and Design

3.1. Usage Contexts, user, and Use Cases

3.1.1. Usage Contexts

User experience and user requirements are two different approaches in software development with an intersection in some areas. User experience covers all aspects of how the experiences and uses software, while user requirements cover the user's needs and expectations of the software. Integration of user experience and user requirements in software development aims to develop software with the characteristics followings easy use, features that suit user needs, and an attractive appearance or work environment in accordance with the user habits. The integration of the two different approaches increases the quality of using the software.

In developer productivity, integration of user experience and user requirements escalates developer productivity in developing software by focusing software development on features that meet the user's needs and expectations. In addition, developers reduce production time and effort by developing features that do not match the user's needs and are not required. That integration improves efficiency in software development by identifying and addressing problems that may arise during the development process. This improvement saves developer time and effort in developing software.

The usage context of integration of user experience and user requirements in UX Journey contributes increase developer productivity and self-efficacy in developing software by focusing development on features that match the user needs, as well as increasing efficiency in overcoming problems that arise during the development process. This will make developers feel more confident and confident in their ability to develop quality software.

3.1.1. User

UX Journey is designed to be adopted by students, academics, researchers, and the industry to increase individual skills in analyzing user needs for software requirements. UX Journey is a framework that integrates activities in user experience and user requirements to explore user needs with user experience characteristics. From the perspective of student users, UX Journey can be used as a learning path to understand the implementation of user experience in exploring user needs. Moreover, students grasp the quality of requirements explored from the perspective of attributes in user experience and attributes in software development such as usability, maintainability, etc. From an academic perspective, UX Journey can be used as a learning block in determining the material to be conveyed to students when compiling the curriculum. In addition, UX Journey bridges the gap between academia and industry. From a researcher's perspective, UX Journey is an effective method for exploring user requirements with the user experience quality attribute. Moreover, UX Journey can be used for practical as well as theoretical research. From an industrial perspective, the UX journey can be used to conduct product research or develop products with limited resources. In addition, this method ensures that the quality delivers to the user match user expectations since it involves the user in every activity. The advantages of UX Journey are designed for solo software developers to increase developer productivity and self-efficacy. However, UX Journey is suitable for teams on a small scale for efficiency in the use of resources.

3.1.1. Construct

UX Journey is an adaptation of several design thinking approaches that reliably proven in previous studies. In the last two decades, design thinking has increased to gain wider popularity in substantial fields and is considered an exciting robust paradigm for taking over a problem multidisciplinary [19]. In addition, design thinking has been recognized as a broad approach to solving socially ambiguous design problems [20]. An early definition of design thinking by Cross et al. [21,22] describes design thinking as the study of the cognitive processes embodied in the act of design, as well as something inherent in human cognition [22]. According to Dunne and Martin [23], design thinking is the way designers think and apply their mental processes to design objects, services, or systems, which differ from the end result of elegant and usable products.

The design has a broad cognition, more than specified in the field of software development, practically all aspects of various disciplines have design concepts. Design is defined as a conceptualization of process (action), creation (artifact, product, system, or service), planning, intention, etc. Referring to the more general standard, IEEE 610.12-90 [24], design is defined as a process for exploring the architecture, components, interfaces, and other characteristics of a system or component and the results of that process.

Research conducted by Brown [25] explains that design thinking is a user-centered design innovation approach. In addition, design thinking takes a sensitive approach to the user. Design thinking is also widely recognized as a designer's method of matching user needs with what approach is technologically feasible and what can be changed by business strategy so that it is feasible to add value to customers and capture market opportunities. The research conducted by Brown provides a broader perspective on the design thinking method, where in this research design thinking is used to view design perspectives from several different points of view. The first concept is design thinking to be an approach used to create new viable solution situations without leaving value from customers or improving solutions to meet customer needs with added value. The second concept uses design thinking to become an approach to design. This is a consensus among developers because thinking about design is an integral part of planning or design. This strong background inspires ideas on how designers develop design processes with a creative mind toward design solutions and find new opportunities. Figure 1. is an approach to Design Thinking expressed by Brown [25].

To be able to understand the context of how developers can think about design, the concept of design itself needs to be brought to the fundamental aspects that can explain how each aspect can be interrelated and interact. Design activity is visible as a unified process aimed at producing design object specifications. Think critically about a design by considering the attention to several aspects. The first is the environment in which the objects of that design will exist. In this case, it will determine where the design will be used, in this aspect it can be proof that a design is something that has unique characteristics and environments. The second is the goal that is ascribed to the object in the design. The purpose of thinking about or organizing the design starts from the problems that exist in the user. The third is the desired structural and behavioral properties of the design object (requirements). The third aspect of this design relates to user requirements and the expectations that users embed in requirements. The fourth aspect is the collection of component types (primitives). The fifth aspect is the constraints that might limit acceptable solutions.

In addition, design objects are the result of designs such as artifacts, products, systems, or services as well as software products whether it is a collection of lines of code, database queries, and algorithms embedded in a product. Broadly speaking the design concept is shown in Figure 2. Where the form of the design itself is an artifact in a certain context, in Figure 2 it is shown as a Domain. Where the user requirements influence each other from the design concept.

In a design, developers shall think holistically because a system depends on and interact with other systems. In this research, we use the term system, it can represent general terms for example business processes, work environments, and software. As shown in Figure 2 that a design is in the application domain. Furthermore, a design should satisfy the design requirements of an application domain originating from the external environment as shown in Figure 2. Consider a holistic view of design is necessary to perform the user goals. The interrelationships between designs and the external environment influence user needs and expectations.

Design aspects as represented earlier have unique characteristics with regard to users, stakeholders, and different environments. Developers should focus on acquiring a deeper understanding while consistently accommodating the entire external environment holistically. In general, design thinking has accommodated this problem by focusing on several areas. The first area is empathy, in this area the developer considers at the context of the user needs and expectations holistically from the perspective of various and multiple users. The second area is integrative thinking. Hence, the developer should present creative thinking from all aspects both within the scope of the application domain and the external environment. The third area is experimentalism, to be able to determine which solution to choose as a potential solution, developers are competent to explore situations in creative ways for novel solutions. The fourth area is optimism, in the high level of thinking creatively, a developer is required to be optimistic about the solution that has been chosen and be capable to maintain it as a solution to the problem. The last area is collaboration, where developers can collaborate with interdisciplinary stakeholders for innovative solutions.

Representing a design in a project requires in-depth analysis to obtain a model that is relevant to user problems. Model or framework in design thinking is a couple of various activities to solve design problems. The approach used to represent in-depth analysis problems is the Divergent-Convergent Inquiry-based Design Thinking Model (DCIDT) which was introduced by Eris [27]. This model (shown in Figure 3) describes design thinking as two cognitive approaches related to fundamental modalities, divergent and convergent thinking.

The DCIDT model sequentially transforms user requirements into design specifications according to user needs and expectations. Transformation of user requirements to design solutions through a collection of questions, which is in divergent thinking and convergent thinking. A detailed explanation of the DCITD start with changing the design requirements through Generative Design Questions (GDQ) into a series of design concepts. The shifting process is carried out by answering several questions converted into a design concept. Additionally, the GDQ is used to create, synthesize, and extend several potential design concepts. The basic knowledge of the GDQ as exposed by Eris [27] contains various questions that are used to explore design concepts from design requirements. Furthermore, the design concept that has been obtained (C1…Cn) is converted into design potential and design specifications through a series of questions in Deep Reasoning Questions (DRQ). DRQ in the DCIDT model is to analyze, evaluate, and validate design concepts (Cs) to make design decisions or potential designs that are feasible according to the user's design needs and expectations, classification of the DRQ and GDQ questions as shown in Table 1.

Developers consider a problem broadly and holistically to be able to accomplish the design requirements and expectations of users. Design thinking is described as a non-linear and repetitive activity. In this research, the process of design thinking is grouped into four main activities, consisting of empathy, problem framing, ideas and visualization, and experiments [29,30,31,32,33,34,35]. A more detailed explanation of each of these groups is as follows:

• Empathy (divergent phase): Empathy is an ordinary activity that is often used in user experience activities, particularly in design thinking. In addition, empathy is an activity that is used to understand, observe, and find user problems and more closely with design users. In conducting empathy, developers carry out two main activities, consisting of primary exploration by eliciting design requirements problems directly to users. In addition, empathy is used to find out the user’s emotions and expectations of a product. The next activity is to carry out secondary exploration, by collecting data on standard operational procedures in organizations, statistical data, scientific and popular literature, and solutions that are already available in the market.
• Problem defining (divergent and convergent): activities that intersect with the two phases of design thinking. Activities in this category have been narrowed down to several design solutions. This activity can be grouped into two main sub-activities. The first is a review activity of the solutions generated in the empathy section. The developer will review some primary and secondary data to be classified based on proximity and possible problem solutions. Review activity is categorized as a divergent phase because it has not yet led to a solution provided to the user. The second is an activity to frame the results of the classification at the review stage so that they can be grouped together with potential solutions.
• Idea and visualization (divergent phase): visualization is a common activity in representing a design, including the user experience. Idea and visualization are included in the divergent phase category because in this activity there is no solution that has emerged as a design solution. This activity is classified into two activities, the idea is to be able to collaborate with users to bring inspiration from the design problems they face. The second activity is visualization. In general, in this activity, the developer will create a low-fidelity or high-fidelity display. Furthermore, the visualization generated by the developer becomes a prototype for the technical specification of a potential solution.
• Testing and iteration (divergent and convergent phase): this is an activity to explore user problems and test the potential solutions that have been obtained. This activity can be divided into three parts. The first activity is to test the usability of a potential solution from a predefined design. This activity will determine whether the potential solution meets the design requirements and expectations of the users. The second activity is evaluation and improvement. Is an iterative activity to get a potential solution that is ready to be developed into a product. All design requirements and expectations from users have been fulfilled at this stage of the activity. The third activity is the delivery of potential solutions. The results of the potential solutions that have been developed are sent to the development team to implement in a product that is ready to compete in the market and provide solutions to organizations.

Table 2. Divergent and convergent phases compared with the previous study.

Table 2. Divergent and convergent phases compared with the previous study.

3.2. UX Models Provided by UX Journey

All models principally accommodate divergent and convergent phases in each of their model activities. In addition, the sequence of the phases is relatively the same starting with a divergent phase and ending with a convergent phase. Besides that, in general, there will be overlapping of the two phases: divergent, convergent, divergent, and convergent so that in some phases there will be overlap. Table 3 is several models and processes that exist in these activities.

To shape the construct of the UX Journey, consider several previous models that are tailored to the goals of the UX Journey, which focus on increasing self-efficacy to competence in understanding the intent of the user, or proficiency in actively capturing market potential with creative product solutions. In the model presented by Brown, constructs design thinking through three activities, consisting of inspiration, ideation, and implementation where each activity is supported by sub-activities as an orderly and directed stage. Inspiration activities motivate developers to explore context with an empathetic and user-centered approach to identify design problems and explore potential design idea opportunities. The results of the identification and observation implement into the ideation process by generating and testing ideas into potential solutions. The last stage is to carry out implementation to realize a feasible solution for the potential idea.

Most of the design thinking models are influenced by the mental aspects of the users. These aspects include cognition, affection, and conation. Moreover, paying attention to the emotional aspect of the user has become an important consensus in the design [36]. The process of paying attention to the emotions of the user leads to empathy as a design solution to the problem at hand. This inspires developers to create design solutions according to user needs and expectations [37,38]. Moreover, design thinking is considered as a complex design activity from a cognitive, motivational, and emotional process of developers and users [26,39].

The various models have common characteristics, and consist of holistic contextual exploration, idea creation, and evaluation of solutions and the realization of solutions generated in the context of potential design ideas. In this case, the nature of the design thinking process based on the purpose of the model awakens the natural potential to reframe it into new solutions or improve solutions from the model with ideas that are better suited to goals centered on individual innovation for contextual problems.

The framing of a model emphasizes the process of identification and reflection through appreciation, action, and re-appreciation [26,40]. Framing in design solutions is used to find a model that fits the purpose of the model to explore contextually. In addition, framing is an approach to capture, analyze, and create knowledge from new perspectives. A study conducted by Adikari et al. [26,32] revealed that the framing process is an activity that provides new potential for more specific problems from different realities. There are three ways to frame the process. The first realign the existing frame into a new perspective. This means that the existing model is rearranged from the components in the model. The second shifts the perspective of the model into a new domain usually used to represent an idea for different or interdisciplinary knowledge. The third is to draw some connections from the activity in the model and conclude that it is a new or the same activity in a different context.

Design solutions are products of user problems or creative ideas from the results of research on market needs. Sometimes, users of the design are not established at the beginning of exploration or observation, but the solution is an initial product that is used to test the market acceptance of a product. Successful design solutions focus on three important elements that reinforce each other at the outset, consist of insight, observation, and empathy [25]. Insight and observation, the existence of a design solution that leads to products and services, and empathy are design challenges to bring up creative design thinking that reflects the emotional aspects and experiences of all users in context. In UX Journey, these three elements are framed in the discover element, which is the first activity in the proposed model.

Elements of interpretation, ideas, experiments, and prototypes are activities that are used by developers to find and provide potential design solutions that are used to solve problems. Moreover, in this activity, is possible for developers to explore creative design ideas from various holistic perspectives. Design solutions are realized in the form of product design prototypes that can be used for market exploration or provide an overview of the solutions provided. In UX Journey, these elements are framed in explore element, which is the second activity that the main function to explore existing design problems.

Testing is a general activity that is always used to convince developers that the design solutions created to meet the needs and expectations of users, or in the form of products and services testing can be used to determine market acceptance of the proposed product or service. In the UX Journey, it is a mandatory activity that becomes a consensus to know that design solutions are useful and quality guaranteed.

The elements of refining, reflecting, and evolution of potential design solutions are useful for developing solutions if discrepancies occur or changes are found that may occur during solutions exploration. In addition, this element is to prepare the results of the tests carried out to find out whether the solution is feasible to continue into a product. In UX Journey, this element is framed as a listening element. It is the last activity before a new or continued cycle of the UX Journey model.

Figure 4. Purposed UX model with UX Journey.

Figure 4. Purposed UX model with UX Journey.

3.3. Functional Description

The functional description of the UX Journey is shown in Figure X. It was developed from robust fundamentals to describe the need to improve individual socio-technical skills in industry and academic challenges.

UX Journey is designed specifically for the personal in solo or small development teams to integrate activities in user experience and user requirements to satisfy user needs and expectations with the experience characteristics. Moreover, UX Journey is a combination of psychomotor and cognitive aspects for the developer to increase self-efficacy. The functionality of the UX Journey is formed from four main structures based on the design thinking model. The constructs of the UX Journey are discovering, exploring, testing, and listening.

Figure 5. UX Journey functional description.

Figure 5. UX Journey functional description.

The activities of the UX Journey begin with finding existing design requirements. In this context, design requirements are obtained from users or organizations as well as research on a product that will compete in the market. The process of finding design requirements is carried out through a series of activities. The developer should explore various possible solutions and start testing to obtain solutions that match their needs and expectations. In the last stage, the developer will organize listening, activities to obtain an overview of the potential solutions, and whether the solutions are appropriate and can be continued to become specifications of the design.

3.4. Architecture

The functional model in Figure 5 is converted into a detailed technical architecture as shown in Figure 6. There are four main components in UX Journey, consist of discover, explore, test, and listen. Each main activity shows a sub-activity, which implements the user experience method that provides a coherent set of quality elicitation methods. Detailed sub-activity on the UX Journey technical architecture is shown in Figure 6 as follows:

• Discover, there are three activities that establish in discover that also have an intersection with Explore activity. SWOT Analysis is a sub-activity that is used as a feasibility study to identify the project eligibility, Competitor Analysis is used to gather information from the competitor that exists in the market, and Hypothesis predefined scope and goals for the project.
• Explore, is the main activity with lots of sub-activity. Identify behavioral variables, Prepare and Select Questions, Index Cards, Map Interviews, Findings, Significant Behavior Patterns, Expand Description and Variable, Synthesize Characteristics and Relevant Goal, Check for Redundancy and Completeness, Wireframing, Sitemap, User Scenario, Persona, Customer Journey, Prototype
• Test, Testing is an activity in the UX Journey that is useful for ensuring that the design solution meets the needs and expectations of users.
• Listen, although this activity is basically placed outside the design solution process, listen has an important assignment to provide an overview of the response from the market when the product is released. Moreover, to find out how the product can be developed to the next versions it is necessary to get user feedback.

Figure 5. UX Journey architecture.

Figure 5. UX Journey architecture.

3.5. Technical Feasibility

A review of the UX Journey architecture characteristics indicates that the architecture is reliable, comprehensive, and useful for increasing developer self-efficacy. Moreover, developers can discover their abilities in exploring user needs, and at the same time, the socio-technical abilities of developers to know the needs and expectations of users can be improved. The next stage of the research is conducting a feasibility study. The purpose of a feasibility study is to observe, explore, and define the strengths and weaknesses of an existing or new process or method, including the possibilities that can be obtained from the process or method and the possible challenges in its implementation [41] objectively and rationally. In addition, the feasibility study is also used as a process of deciding from an evaluation whether a process or model is feasible to implement.

The process of conducting a feasibility study through several stages, according to Avison et al. [41] four stages must be passed to carry out a feasibility study, consisting of:

• The process of preparing a feasibility study activity. In this first stage, it will be determined how extensive the object of study will be measured.
• Define the problem. The second stage is to compare the requirements of the problems faced with the current situation.
• Choose the feasibility study option. Stages to determine the available alternatives and choose the solution used.
• Make a report of the feasibility study. Steps to represent the feasibility study in a document.

The ability of a feasibility study to identify and evaluate alternatives to propose a method or model increases the need for a feasibility study. Moreover, the feasibility study process can provide identification and alternative solutions to optimally implement in terms of what is practicable, feasible, and one that will address the relevant legal requirements [ssegawa]. The process of determining an optimal solution requires several element evaluations including the level of risk, costs, and benefits of alternatives based on several feasibility areas. From previous research, there has not been a general agreement on several domains where feasibility must be carried out. However, there is some convergence in the five general areas known as TELOS (technical, economic, legal, operational, and schedule). The following is a feasibility study analysis of the UX Journey using the TELOS approach.

3.5.1. Technical feasibility

Technical feasibility tests the possibility of implementing available technology or implementing new technology if needed. The results of the technical feasibility are used to answer several questions including whether the technology has a satisfactory effect, whether there is an increase in time, and whether there is an increase in performance that has been completed.

Table 4. The technical aspect of the UX Journey.

Table 4. The technical aspect of the UX Journey.

Technical Aspect	Selected existing model			Purposed
	IDEO	HPI	Double Diamond	UX Journey
User Focus	Observing and understanding the challenge and user contect	Understanding existing information, collecting insight about user needs	Searching for new opportunities, information, trends, and insight	Observing and understanding empathy, new opportunities, existing information, and insight.
Communication(Phase)	Ideation: sharing and making sense of collected data, feedback	Prototype: presenting the idea to potential user	Develop: using creative tools like brainstorming	Discover, explore, test, listen: user collaborative
Product improvement(Phase)	Implementation: refining business models	Test: iterative cycles, collective feedback every time	Deliver: final concept and launching	Listen: launching market analysis product, review user feedback.

The performance improvement of existing models has generally been fulfilled in the proposed UX Journey model, moreover that the proposed model is a model that is actually used to improve individual abilities. Different from other models, where the focus of other models is on the user or the creation of a product. For the UX Journey, apart from focusing on the needs and expectations of users, it is also used to increase the confidence of developers through socio-technical skills by collaborating a lot with users.

3.5.2. Economic feasibility

Aims to evaluate whether there is an economic effect resulting from the proposed new technology compared to existing technology today. The reliability of technology will be measured based on the process carried out without knowing or prejudicing the results of the evaluation carried out. When conducting an economic feasibility evaluation, there are expected results. In general, there are two approaches used [drijaca]. The first approach is through measurable effects. The indicators of this approach are based on numbers or trends of something that can be measured such as the number of employees, cost reduction, output improvement, service improvement, etc. The second approach is effects that are impossible to measure, in this case in the form of risks, or problems that cannot be measured but can occur when activities are carried out.

The proposed UX Journey model has an advantage in the number of personnel. The UX Journey model was originally designed to be dedicated to individuals or solo, this was motivated by the need to increase individual abilities to be able to interact with users. Moreover, the UX Journey is designed to be executed within 16.3-25 hours from the start of the process to testing for the design solution.

3.5.3. Legislative feasibility

This aspect defines the legal requirements to introduce or implement new technology. Legal feasibility must provide answers to form the basis for carrying out a quality evaluation of the technology. The legal basis used in this research is shown in Table 5.

3.5.4. Operational feasibility

Operational feasibility aims to evaluate the implementation of new technology compared to the initial state within an organization. The result of this feasibility study is to identify whether the technology can be implemented within the organization. In this case, UX Journey is a model that is designed to be implemented for individuals. Therefore, in this feasibility study, the hierarchical structure associated with this model is the user and the developer. However, there is a possibility that this model will be used in academics (Figure 6 (a)), small teams, and individuals in training (Figure 6 (b) and (c)), therefore the organizational structure of the designer is used for the feasibility of this model.

Figure 6. Operational feasibility (a) academic structure (b) software engineer structure (c) designer structure [42].

Figure 6. Operational feasibility (a) academic structure (b) software engineer structure (c) designer structure [42].

3.5.5. Schedule feasibility

Evaluating the overall performance of a technology provides an idea of how the technology can be adapted to its current state. The feasibility schedule can indicate the requirements for implementing the technology.

Table 6. UX Journey schedule feasibility.

Table 6. UX Journey schedule feasibility.

Process	Time (minutes)		Activity	Document
	Min	Max		Name
Empathy & Define	30	60	SWOT Analysis	SWOT Analysis
	10	30	Prepare Questions
	10	30	Selected Questions	List Question
	30	60	Competitor Analysis	Competitor Analysis
	20	30	Hypotheses	Hypotheses
	20	30	Identify Behavioral Variables	Identify Behavioral Variables
	60	60	Persona	Persona
Ideate	20	30	Findings
	60	120	Index card/ Sticky notes	Index card/ Sticky notes
	30	30	Map Interview	Map Interview
	30	30	Significant Behaviour Patterns	Significant Behaviour Patterns
	30	30	Synthesize Characteristics and Relevant Goals	Synthesize Characteristics and Relevant Goals
	30	40	Check for Redundancy and Completeness	Check for Redundancy and Completeness
	30	30	Expand Description and Variable	Expand Description and Variable
	60	60	Customer Journey	Customer Journey
	120	240	Wireframing (Low Fidelity)	Wireframing (Low Fidelity)
Prototype	60	120	User Scenario	User Scenario
	30	30	Sitemap	Sitemap
	240	320	Mockup (High Fidelity)	File Mockup
Test	60	120	Testing	Testing
Total (minutes)	980	1500
Total (hours)	16,3	25

4. Academic and Industry Perception Study

5. Discussion

References

1. Sommerville, I. Software engineering; Always learning; 10. ed., global ed.; Pearson: Boston Munich, 2016; ISBN 978-1-292-09613-1.
2. Pressman, R.S.; Maxim, B.R. Software engineering: a practitioner’s approach; Ninth edition.; McGraw-Hill Education: New York, NY, 2020; ISBN 978-1-260-54800-6.
3. Anwar, R.; Rehman, M.; Wang, K.S.; Hashmani, M.A.; Shamim, A. Investigation of Knowledge Sharing Behavior in Global Software Development Organizations Using Social Cognitive Theory. IEEE Access 2019, 7, 71286–71298. [CrossRef]
4. Almeida, F.; Simões, J.; Lopes, S. Exploring the Benefits of Combining DevOps and Agile. Future Internet 2022, 14. [CrossRef]
5. Caballero, L.; Moreno, A.M.; Seffah, A. How Agile Developers Integrate User-Centered Design into Their Processes: A Literature Review. Int. J. Softw. Eng. Knowl. Eng. 2016, 26, 1175–1201. [CrossRef]
6. Chanin, R.; Pompermaier, L.; Sales, A.; Prikladnicki, R. Collaborative Practices for Software Requirements Gathering in Software Startups. In Proceedings of the 2019 IEEE/ACM 12th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE); IEEE: Montreal, QC, Canada, 2019; pp. 31–32.
7. Sukaviriya, N.; Sinha, V.; Ramachandra, T.; Mani, S.; Stolze, M. User-centered design and business process modeling: Cross road in rapid prototyping tools; 11th IFIP TC 13 International Conference on Human-Computer Interaction, INTERACT 2007; Springer Verlag: Rio de Janeiro, 2007; Vol. 4662 LNCS; ISBN 03029743 (ISSN); 9783540747949 (ISBN).
8. Nelson, N.; Brindescu, C.; McKee, S.; Sarma, A.; Dig, D. The life-cycle of merge conflicts: processes, barriers, and strategies. Empir. Softw. Eng. 2019, 24, 2863–2906. [CrossRef]
9. Schön, E.-M.; Thomaschewski, J.; Escalona, M.J. Agile Requirements Engineering: A Systematic Literature Review. Comput. Stand. Interfaces 2017, 49, 79–91. [CrossRef]
10. Ahmadi Eftekhari, N.; Mani, S.; Bakhshi, J.; Mani, S. Project Manager Competencies for Dealing with Socio-Technical Complexity: A Grounded Theory Construction. Systems 2022, 10, 161. [CrossRef]
11. Bourimi, M.; Barth, T.; Haake, J.M.; Ueberschär, B.; Kesdogan, D. AFFINE for enforcing earlier consideration of NFRs and human factors when building socio-technical systems following agile methodologies; Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics); 2010; Vol. 6409 LNCS, p. 189.
12. Getto, G. Managing Experiences:: Utilizing User Experience Design (UX) as an Agile Methodology for Teaching Project Management. Int. J. Sociotechnology Knowl. Dev. 2015, 7, 1–14. [CrossRef]
13. Gräßler, I.; Pottebaum, J.; Oleff, C.; Preuß, D. HANDLING OF EXPLICIT UNCERTAINTY IN REQUIREMENTS CHANGE MANAGEMENT. Proc. Des. Soc. 2021, 1, 1687–1696. [CrossRef]
14. Almeida, F.; Espinheira, E. Adoption of Large-Scale Scrum Practices through the Use of Management 3.0. Informatics 2022, 9. [CrossRef]
15. Abdeen, W.; Chen, X.; Unterkalmsteiner, M. An approach for performance requirements verification and test environments generation. Requir. Eng. 2022. [CrossRef]
16. Yousaf, M.S.; Ali, S.; Nawaz, Q.; Afsar, S.; Mumtaz, I.; Rashid, N. Fagan Inspection: A Defects Finding Mechanism in Software Requirements Specification (SRS) Document. VFAST Trans. Softw. Eng. 2022, 10.
17. Hsu, T.-C.; Abelson, H.; Patton, E.; Chen, S.-C.; Chang, H.-N. Self-efficacy and behavior patterns of learners using a real-time collaboration system developed for group programming. Int. J. Comput.-Support. Collab. Learn. 2021, 16, 559–582. [CrossRef]
18. A. Issaee; R. Motschnig; O. Comber Pair- versus solo-programming of mini-games as a setting for learning to program: An Action Research approach. In Proceedings of the 2021 IEEE Frontiers in Education Conference (FIE); 2021; pp. 1–9.
19. Dorst, D.; Stewart, S.; Staudinger, I.; Paton, B.; Dong, D. Introduction. DTRS8 Proc. 8th Des. Think. Res. Symp. 2010.
20. Lindberg, T.; Gumienny, R.; Jobst, B.; Meinel, C. Is there a need for a design thinking process? Des. Think. Res. Symp. 2010, 243–254.
21. Cross, N.; Dorst, K.; Roozenburg, N. Research in Design Thinking. Res. Des. Think. 1992.
22. Cross, N. Des. Think. Underst. Des. Think Work 2011.
23. Dunne, D.; Martin, R. Design thinking and how it will change management education: An interview and discussion. Acad. Manag. Learn. Educ. 2006, 5, 512–523. [CrossRef]
24. IEEE standard glossary of software engineering terminology. IEEE Stand. Gloss. Softw. Eng. Terminol. 1990.
25. Brown, A.W. Personal software engineering project management process. Proc Int Conf Softw. Eng 1999, 669–670. [CrossRef]
26. Adikari, S.; McDonald, C.; Campbell, J. Reframed Contexts: Design Thinking for Agile User Experience Design. In Design, User Experience, and Usability. Design Philosophy, Methods, and Tools; Marcus, A., Ed.; Lecture Notes in Computer Science; Springer Berlin Heidelberg: Berlin, Heidelberg, 2013; Vol. 8012, pp. 3–12 ISBN 978-3-642-39228-3.
27. Eris, O. Insisting on truth at the expense of conceptualization: Can engineering portfolios help? Int. J. Eng. Educ. 2006, 22, 551–559.
28. Eris, Ö. ASKING GENERATIVE DESIGN QUESTIONS: A FUNDAMENTAL COGNITIVE MECHANISM IN DESIGN THINKING.
29. Carlgren, L. Identifying latent needs: towards a competence perspective on attractive quality creation. Total Qual. Manag. Bus. Excell. 2013, 24, 1347–1363. [CrossRef]
30. Carlgren, L.; Elmquist, M.; Rauth, I. Design Thinking: Exploring Values and Effects from an Innovation Capability Perspective. Des. J. 2014, 17, 403–423. [CrossRef]
31. Carlgren, L.; Rauth, I.; Elmquist, M. Framing Design Thinking: The Concept in Idea and Enactment: Creativity and Innovation Management. Creat. Innov. Manag. 2016, 25, 38–57. [CrossRef]
32. Carlgren, L.; Elmquist, M.; Rauth, I. The Challenges of Using Design Thinking in Industry - Experiences from Five Large Firms: THE CHALLENGES OF USING DT IN INDUSTRY CREATIVITY AND INNOVATION MANAGEMENT. Creat. Innov. Manag. 2016, 25, 344–362. [CrossRef]
33. Beckman, S.L.; Barry, M. Innovation as a Learning Process: Embedding Design Thinking. Calif. Manage. Rev. 2007, 50, 25–56. [CrossRef]
34. Liedtka, J. Perspective: Linking Design Thinking with Innovation Outcomes through Cognitive Bias Reduction: Design Thinking. J. Prod. Innov. Manag. 2015, 32, 925–938. [CrossRef]
35. Grönman, S.; Lindfors, E. The Process Models of Design Thinking. 2021.
36. McDonagh, D.; Denton, H.; Chapman, J. Design and emotion. J. Eng. Des. 2009, 20, 433–435. [CrossRef]
37. Alsanoosy, T.; Spichkova, M.; Harland, J. A framework for identifying cultural influences on requirements engineering activities.; 2020.
38. Kouprie, M.; Visser, F.S. A framework for empathy in design: Stepping into and out of the user’s life. J. Eng. Des. 2009, 20, 437–448. [CrossRef]
39. Badke Schaub, P.G.; Roozenburg, N.F.M.; Cardoso, C. Design thinking: A paradigm on its way from dilution to meaninglessness? Proc. 8th Des. Think. Res. Symp. 2010.
40. Schön, D.A. The reflective practitioner: How professionals think in action. Basic Books 1983.
41. Drljaca, D.P.; Latinovic, B. Using TELOS for the planning of the information system audit. IOP Conf. Ser. Mater. Sci. Eng. 2018, 294, 012022. [CrossRef]
42. CC2020 Task Force Computing Curricula 2020: Paradigms for Global Computing Education; ACM: New York, NY, USA, 2020; ISBN 978-1-4503-9059-0.