Objective and Contribution
This thesis explores a very novel topic on the synergy between Design Thinking (DT) and Requirements Engineering (RE), a new area that has not been systematically investigated yet and little is known how such an integration could be realized. It aims at merging the strongly diverging human-oriented perspective of Design Thinking with the technically-driven perspective of Requirements Engineering and thereby, analyze possible gaps and synergies between them resulting in a holistic perspective towards the development of a more customer-oriented solution.
Study Design
The following is the roadmap to the study design (click to view high-resolution image)-
Research Questions
RQ1: What contributions have been made over the years in the field of Design Thinking?
RQ2: What is the state of reported evidence in the software engineering community regarding works on Requirements Engineering combining some aspects and characteristics of Design Thinking?
RQ3: What are the principles and methods that govern these two fields and what are the similarities and differences based on these principles and methods between DT and RE?
Three-Staged Study Design
-
Stage 1: We extracted, understood and analyzed, through the process of literature review, the current state-of-the-art on Design Thinking using specific search strings and keywords. This basically provided us a better understanding of the subject and helped us in finding out a detailed overview on Design Thinking, its history and present scenario. We then built a taxonomy of DT principles, methods and artefacts. This spanned the first Research Question, RQ1.
-
Stage 2: Covering the second research question, we did another systematic literature review for Requirements Engineering, keeping a focus on the Design Thinking perspective. This provided us with ample data about works that are based on Requirements Engineering and also works that made an effort in using some characteristics of Design Thinking.
-
Stage 3: Based on the idea and knowledge gained from the first two stages, we built a taxonomy of methods and artefacts on both Design Thinking and Requirements Engineering. A comparison of the taxonomies on DT and RE
helped us find common aspects between the two. Furthermore, We expanded our study towards other related contributions and then tried to find a synergy between Design Thinking and Requirements Engineering.
Search Strings
Design Thinking:
"design thinking" AND ("theory" OR "process" OR "practice" OR "method" OR "approach" OR "knowledge" OR "challenges" OR "contribution" OR "activities" OR "ideation" OR "innovation" OR "technology")
Requirements Engineering:
-
"requirements" AND "engineering" AND "human"
-
"requirements" AND "engineering" AND ("human" OR "user" OR "people" OR "ethnographic") AND ("observe" OR "need" OR "prototype")
-
"requirements" AND "engineering" AND ("mockup" OR "poster" OR "persona" OR "role playing" OR "feedback" OR "questionnaire" OR "interview" OR "personal experience")
Result
Design Thinking:
RQ 1.1: What is the state of available contributions till date and the type of research in the field of Design Thinking?
RQ 1.2: How have the research topics evolved over time?
RQ 1.3: What are the principles and methods proposed for Design Thinking?
Based on the data collection and classification, we figured out the possible principles, methods and artifacts that are relevant for Design Thinking post which, we built a taxonomy for Design Thinking. It provided a structured overview of goals, methods and artifacts of DT and provided us better knowledge in understanding where Design Thinking stands. This taxonomy is majorly divided into two phases, the problem-space and the solution-space which are again further sub-divided into methods, goals and artifacts. (Click to view the high-resolution image)
Requirements Engineering:
RQ 2.1: What related contributions have been made and how have they evolved in Requirements Engineering, considering some concepts of Design Thinking in scope?
Query string 1: "requirements" AND "engineering" AND "human"
Query string 2: "requirements" AND "engineering" AND ("human" OR "user" OR "people" OR "ethnographic") AND ("observe" OR "need" OR "prototype")
Query string 3: "requirements" AND "engineering" AND ("mockup" OR "poster" OR "persona" OR "role playing" OR "feedback" OR "questionnaire" OR "interview" OR "personal experience")
Taxonomy on Requirements Engineering, by taking some aspects of Design Thinking into consideration (click to view the high-resolution image) -
Synthesis and Discussion
Overlaps and Differences
-
Both DT and RE tries to achieve the same goal through different approaches by taking into account what the prospective end users want and thereby, develop products that will successfully run in the market.
-
The strength of RE is in its ability to maximize profit with constraints in cost and time. It works best when projects have fixed timelines and budget and unavailable end users, a common problem that large corporations deal with often. DT can provide no help in such circumstances.
-
DT can help solve wicked problems where the problem space is ill-defined. But, RE is more solution-focused. It does not take into consideration the adequacy of the problem itself and proceeds with a clearly-defined problem space.
-
While RE helps find solutions to problems, DT focuses more on finding problems worth solving.
-
RE has a more straightforward, predictable approach to problem-solving. DT involves more unpredictable actors, people.
-
Requirements keep changing. Re-framing the problem statement repeatedly is imperative. The solution itself can give rise to further questions and an entirely new problem set. DT takes this into consideration with a more realistic approach by incorporating feedback loops while RE focuses on seamless transition of problem space to solution space.
-
Primary RE suffer from the issue of retrieving clear and concrete requirements from the stakeholders. Requirements are either ambiguous,
incomplete, inconsistent or out-of-date, mainly because of communication difficulties, lack of knowledge and misunderstandings. This is exactly where DT comes to help because it focuses more on finding the needs of the user before coming up with a solution to it thereby, bridging such gaps. -
DT creates low-resolution prototypes which are quickly and repeatedly tested with the user to validate its efficiency and usability while the prototypes in RE are more well-defined, more technically-detailed and efficiently coded, resulting in a first-version model of the final system.
-
Unlike RE, DT identifies issues early, fails before investing time and money on development, quickly re-defines the prototypes to accommodate changing needs, resulting in more error-free, viable and sustainable solutions.
Synergy
Design Thinking and Requirements Engineering can go hand in hand if their individual advantages are explored and merged. Having said that, we should also take a look at the bigger picture. Requirements Engineering is the first phase in traditional software development process, the Waterfall model, to be precise. Because of all the disadvantages of traditional software development, Agile methodology came as a promising solution, as an antidote to Waterfall development. However, although Agile introduced more flexibility to the software development process and provided comparatively more effective ways of problem-solving, it still couldn't guarantee if it was solving the right problems. Hence, we need Design Thinking.
Engineering can form the last step of Design Thinking process through which manufacturing takes place and the new product, which is based on the innovative ideas generated in the Design Thinking process, is brought to the market. There is a lot of focus on Design Thinking as a creative process generating new ideas but, innovation can create actual value only with the execution of those ideas. If one can’t bridge the gap between a creative idea and an idea that could be executed in the market, then that idea is worth nothing. If Design Thinking is not properly integrated with software development, they can potentially prevent great ideas from becoming real products.
In order to do so, various information and working results that are captured by multiple analog and digital artifacts, along with their contexts, design rationales and other related details need to be handed over to the engineers who have to realize the results. Engineers should be well-informed for making effective decisions about realization of work results and identifying trade-offs between desirability and feasibility. However, this handover or knowledge transfer becomes hard because they are often not systematically captured and documented. Design thinkers typically present only the final ideas or the innovative product and not the journey of how they arrived at it. Such presentations only convey features instead of underlying requirements or design constraints.
One of the main factors enabling the transition from ideas to products is effective connection between the two, with every bit of information being transferred without any loss of data. So, ideally there should be sufficient transparency of Design Thinking activities, which means developers should be aware of not just the final idea but they should also be able to understand how the ideas emerged during the Design Thinking process. All these challenges can be met by putting strong regulations on Design Thinking activities. Creating reporting systems, output formats or some tools to capture or record every steps. This can essentially be done using Scrum’s sprint planning sessions to DT activities that can ensure increased transparency and structure
of Design Thinking activities.
As a broader picture, Design Thinking can help ’tame’ wicked problems and Requirements Engineering can then materialize the tamed problem into actual high-end products in the market through traditional Engineering approaches. Such a synergy can significantly boost software development processes and such a synergy, is not impossible.
Limitations and Future Scope
The limitation of our work is that the results of the literature reviews are primarily based on the query strings developed, the complexity of the query strings and the ability of the databases to process complex search strings. A complex and lengthy search string might provide a more precise result set but, smaller and simpler search queries might be easier to process by certain databases. However, small search queries encompass a bigger and less precise result set and might result in unwanted overlaps. We considered publications until a certain number of hits and it is not possible to justify using any metric whether that consideration was adequate or sufficient. This again depends on how detailed the inclusion and exclusion criteria is.
As a future scope, we would aim to delve deeper into the field and explore possible options of undergoing a case study or further strengthen our premise through experiments in a real-world setting, thereby validating our proposition further.