# Design Thinking for Requirements Engineering

## Summary


**Design Thinking (DT)** comes from the design discipline. It explores both the problem space and the solution space. Its attributes include user needs, prototyping, feedback, iterations and multidisciplinary perspectives. **Requirements Engineering (RE)** comes from the engineering discipline. It too considers user needs but it's more technical and formal. Requirements are documented as formal specifications. 

Identifying requirements is a complex task and DT is good at tackling complex problems. DT and RE complement each other. In one model, DT is applied to elicit requirements that feed into RE. However, teams can switch between DT and RE as the situation demands. 

Research in DT for RE is still nascent and perhaps more so in practice. For example, can DT be applied to other software engineering (SE) tasks? How do DT principles map to SE principles? These are open research questions.

## Discussion

### Why do we need design thinking for requirements engineering?

In RE, the perspective is mainly **technical**. Even when engineers apply human-computer-interaction to create user interfaces/interactions, they may disappoint users. This is because they fail to see the user perspective. Users may not articulate their needs precisely. DT can bring out underlying needs. It's said that asking questions isn't enough to identify user needs. They must be tracked down. 

Engineers are guided by **analytical thinking**, both deductive and inductive logic. Design thinking is more open, collaborative and multidisciplinary. DT is better at creativity and innovation. DT helps RE with a better understanding of user and domain. The learning curve associated with DT gives engineers an appreciation of how and why each requirement has emerged. This aids them in implementation. 

RE emphasizes formal and elaborate **documentation**. This hinders quick feedback and short iterations. There have been cases of extensive documentation of poorly understood user needs, resulting in unusable code. 


### Hasn't Agile already solved the RE problem?

In the mid-80s, it was recognized that the traditional waterfall model isn't adequate. It considered user perspectives only at the start and the end of projects. Agile practices such as Extreme Programming, Feature-Driven Development, Kanban and Scrum were introduced. Agile emphasized working software over formal documentation, customer collaboration over contract negotiation. 

But RE in Agile has its limitations: minimal documentation of requirements, unclear requirements, neglect of non-functional requirements, tacit requirements, wrong prioritization. 

While Agile does prototyping, it uses the same materials as the final product. The prototype can then be iterated towards the final product. The focus is not on learning, which DT fosters. 

In Agile, user scenarios are inputs to modelling. In DT, scenarios are a tool towards creativity. Scenarios are related to personas to give narrative power. Modelling is less important in DT. 

Agile practices fall short in terms exploring the problem/solution space. Agile emphasizes incremental refinements on a chosen path. It's been said, 

> Agile is always looking to remove options from the table. Design thinking is always trying to keep options on the table as long as possible.


### Could you give an example of DT for RE?

Consider the figure above. The telephone layout makes sense but the calculator layout is in reverse. Calculators evolved partly from cash registers such as the Comptometer (1885). One probable explanation is that levers and rotating drums beneath the buttons implemented the *method of complements*. Technologically, it was easier to implement this in the reverse layout. Today's familiar 3x3 calculator layout first appeared in 1914, a David Sundstrand invention. 

The telephone's layout came about in the 1960s. Under the discipline of *human factors engineering*, engineers studied as many as 15 layouts and sought user feedback. The study revealed that users preferred left-to-right, top-to-bottom layout. Layouts 2x5 and 3x3+1 were equally efficient. AT&T adopted the latter, which became the standard for future pushbutton handsets. 

This example shows that telephone engineers considered user needs and used prototyping to test ideas. Interestingly, modern calculators continue to use the old layout even when the original technical constraints are gone. We may say that this too is user-centric since users are used to this layout. 


### What are the pros and cons of applying DT to RE?

It's been seen that DT promotes better perception of business requirements, better collaboration with colleagues and users, learning for all stakeholders, and delivering value. In the problem space, user needs are better understood. DT fosters creativity and problem reframing. DT achieves better understanding of usability and user experience. RE takes this forward towards design and architecture. 

Bringing a multidisciplinary team together is a challenge. Organizational culture may come in the way of open discussions. Not enough time is given. Calls or emails may interrupt people high in the hierarchy. There's a tendency to adopt familiar solutions without adequately understanding the problem. People may not engage simply because they don't see the value. While DT is strong on usability, it fails to capture other non-functional requirements such as security and performance. Since DT is unstructured (uses post-its and low-fidelity prototypes), tracing requirements is not easy. Requirements prioritization and effort estimation are hard to do. 


### What's a suitable model for DT in RE?

One proposed model structures the process in three layers: context layer (why the system is needed), requirements layer (what are the user-level requirements and features), and system layer (how the system will be realized). Each layer produces artefacts that feed into the next layer. At the context layer, we apply the DT process. At the requirements layer, detailed technical specifications are produced. 

However, the process is not linear. We adopt DT whenever we need a better understanding of user needs or the business context. When we need a more technical view or feasibility analysis, we adopt RE. Both DT and RE are complementary tools that help us customize the process as the situation demands. 


### How can an organization adopt DT for RE?

DT can be combined with RE in three ways: 

    + **Upfront**: DT is applied before RE. DT is a guiding process. It's useful when there's high uncertainty about the problem or solution.
    + **Infused**: DT is applied to specific RE tasks to clarify those tasks. DT is a toolbox in RE.
    + **Integrated**: DT is a guiding mindset that's continuously applied to the entire RE process. Organizations may start with the infused approach and then move towards the integrated approach.Organizations prefer streamlined processes and quality gates. They have to meet deadlines and budgets. The exploratory and creative nature of DT is perceived as a risk. For these reasons, DT is better applied as a frontend technique rather than fully integrated into RE. DT can be selectively applied to fuzzy requirements. However, as a front-end technique, moving from concept to implementation is a challenge. For this reason, a fully integrated approach is better in the long term. 


### What techniques or tools are suited for DT in RE?

The figure shows a selection of tools as applied by DT for RE. User personas help bring out specific needs based on user preferences or behaviours. Prototypes help gather user feedback and refine those needs. User journeys help determine the steps the user will take to fulfil those needs. Service blueprints show interfaces and interactions through which users can realize their journeys. 

In fact, design thinking has many more tools that can be used in the phases of immersion, ideation and implementation. Any of these could be used for RE. Some of these are stakeholder mapping, desk research, framing/reframing, interviewing, observation, active listening, clustering, storytelling, brainstorming, brainwriting, role playing, sketching, and feedback capture grid. 

Beyond the tools, individuals must be **T-shaped**: able to look at problems horizontally (multidisciplinary and broad perspectives) and vertically (specialized and deep expertise). To support collaboration and open discussions, a DT team without a designated leader is preferred. The office environment should also support collaborative behaviours. 

## Milestones

1997

Holzmann et al. publish a paper titled *Design Tools for Requirements Engineering*. They note that many requirements can be captured in **Message Sequence Charts (MSCs)**. MSCs can be formally analyzed for causal structures and race conditions. POGA and TEMPLE are tools to analyze MSCs. However, the use of design tools doesn't equate to design thinking. Requirements engineering in this paper is still rooted in technical perspectives. Sutcliffe presents an alternate approach that uses prototypes, design rationales, and user scenarios: these are closer to design thinking. 

2000

This decade sees more awareness among engineers that **user perspective** is important. New roles are introduced: user-interface designer, interaction designer, and user-experience designer. User-centered design is about translating user needs into software design. User experience design has broader scope. However, these roles and practices don't promote shared understanding or collaboration within the team. Design thinking achieves these via a multidisciplinary approach. 

2011

Lindberg et al. at the Hasso Plattner Institut publish a paper titled *Design Thinking: A Fruitful Concept for IT Development?*. The paper considers all phases of software development and not just requirements engineering. They note that engineers apply analytical thinking and their perspective is mainly technical. This is where design thinking can help. It's relevant to note that the Hasso Plattner Institute of Design at Stanford University (d.school) was founded in 2003. 

Mar  
2013

Vetterli et al. explain that RE was a good approach to developing large enterprise software and backend systems. Increasingly app-driven products are coming out. These need faster iterations. Agile development came as a solution but addressed only functional requirements of users. To capture, non-functional requirements DT can help. DT offers methods to elicit user needs. DT is about iterating, learning and ultimately capturing user needs. They note that, "Unlike requirements engineering, design thinking aims to fail early in order to succeed sooner". 

May  
2013

Soledade et al. study the use of design thinking for a Learning Management System (LMS). They use mockups, interviews and feedback forms. Users, mediators and observers take part. They find that design thinking brought better alignment of proposals with user expectations. Design thinking led to refinement of functional and non-functional requirements. Another finding is that developers might invest lot of time and effort on some features that aren't necessarily noticed by users. 

2018

Hehn et al. publish a technical paper that combines design thinking and requirements engineering. Hehn's research leads to further papers and publication of the book *Design Thinking for Software Engineering* in 2022, with Hehn as one of its editors. 

May  
2020

In the context of Scrum, Alhazmi and Huang propose that any item entering the product backlog for the next sprint shall be derived from user stories. User stories are generated via design thinking. Change requests and bug reports shall go through the design thinking process before getting scheduled for the next sprint. 

2022

From a literature review and industry survey, it's found that as many as 86 creativity and DT techniques exist for eliciting requirements. Individuals are more familiar with DT techniques than creativity techniques. Most used DT techniques are interview, brainstorming, uses cases, activity analysis, user story, and rapid prototyping.