Design Thinking for Requirements Engineering

Overview of DT for RE. Source: Hehn and Mendez 2022, fig. 11.
Overview of DT for RE. Source: Hehn and Mendez 2022, fig. 11.

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?
    Problems with requirements engineering. Source: Hehn and Mendez 2022, fig. 1.
    Problems with requirements engineering. Source: Hehn and Mendez 2022, fig. 1.

    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?
    Differing key layouts of telephone (left) and calculator (right) in Nokia C01 Plus with Android Go 11. Source: Devopedia 2024.
    Differing key layouts of telephone (left) and calculator (right) in Nokia C01 Plus with Android Go 11. Source: Devopedia 2024.

    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?
    Results from a survey showing the pros and cons of DT for RE. Source: Pereira et al. 2021.
    Results from a survey showing the pros and cons of DT for RE. Source: Pereira et al. 2021.

    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?
    Combined artifact model of DT and RE. Source: Hehn and Mendez 2022, fig. 9.
    Combined artifact model of DT and RE. Source: Hehn and Mendez 2022, fig. 9.

    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?
    Three modes of using DT with Scrum. Source: Adapted from Vetterli et al. 2013b.
    Three modes of using DT with Scrum. Source: Adapted from Vetterli et al. 2013b.

    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?
    A selection of tools for DT in RE. Source: Parizi et al. 2020.
    A selection of tools for DT in RE. Source: Parizi et al. 2020.

    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
A requirements analysis session involving users. Source: Sutcliffe 1997, fig. 1.
A requirements analysis session involving users. Source: Sutcliffe 1997, fig. 1.

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
A framework that integrates design thinking with Scrum. Source: Alhazmi and Huang 2020, fig. 5.
A framework that integrates design thinking with Scrum. Source: Alhazmi and Huang 2020, fig. 5.

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.

References

  1. Alhazmi, A., and S. Huang. 2020. "Integrating Design Thinking into Scrum Framework in the Context of Requirements Engineering Management." CSSE '20: Proceedings of the 3rd International Conference on Computer Science and Software Engineering, pp. 33-45, May. doi: 10.1145/3403746.3403902. Accessed 2024-01-03.
  2. Bertelli, F. 2024. "A brief history of the numeric keypad." DOC. Accessed 2024-01-03.
  3. Canedo, E.D., A.T.S. Calazans, G.R.S. Silva, P.H.T. Costa, R.P. de Mesquita, and E.T.S. Masson. 2022. "Creativity and Design Thinking as Facilitators in Requirements Elicitation." International Journal of Software Engineering and Knowledge Engineering, vol. 32, no. 10, pp. 1527-1558. Accessed 2024-01-05.
  4. Carell, A., K. Lauenroth, and D. Platz. 2018. "Using Design Thinking for Requirements Engineering in the Context of Digitalization and Digital Transformation: A Motivation and an Experience Report." In: Gruhn, V. and R. Striemer (eds), The Essence of Software Engineering, Springer. Accessed 2024-01-03.
  5. HPI. 2024. "History." School of Design Thinking, HPI. Accessed 2024-01-03.
  6. Hehn, J. and D. Mendez. 2022. "Combining Design Thinking and Software Requirements Engineering to Create Human-Centered Software-Intensive Systems." In: Hehn, J., D. Mendez, W. Brenner, and M. Broy (eds), Design Thinking for Software Engineering. Progress in IS. Springer, Cham. doi: 10.1007/978-3-030-90594-1_2. Accessed 2024-01-03.
  7. Hehn, J. and F. Uebernickel. 2018a. "Towards an Understanding of the Role of Design Thinking for Requirements Elicitation - Findings from a Multiple-Case Study." Proceedings AMCIS, New Orleans, August 16-18. Accessed 2024-01-03.
  8. Hehn, J. and F. Uebernickel. 2018b. "The Use of Design Thinking for Requirements Engineering: An Ongoing Case Study in the Field of Innovative Software-Intensive Systems." IEEE 26th International Requirements Engineering Conference (RE), Banff, AB, Canada, pp. 400-405. doi: 10.1109/RE.2018.00-18. Accessed 2024-01-03.
  9. Hehn, J., D. Mendez, F. Uebernickel, W. Brenner and M. Broy. 2020. "On Integrating Design Thinking for Human-Centered Requirements Engineering." IEEE Software, vol. 37, no. 2, pp. 25-31, March-April. doi: 10.1109/MS.2019.2957715. Accessed 2024-01-03.
  10. Hehn, J., D. Mendez, W. Brenner and M. Broy (eds). 2022. "Design Thinking for Software Engineering." Springer Cham. Accessed 2024-01-03.
  11. Holzmann, G. J., D. A. Peled, and M. H. Redberg. 1997. "Design tools for requirements engineering." Bell Labs Technical Journal, vol. 2, no. 1, pp. 86-95, Winter. doi: 10.1002/bltj.2034. Accessed 2024-01-03.
  12. Husaria, A. and S. Guerreiro. 2020. "Requirement Engineering and the Role of Design Thinking." Proceedings of the 22nd International Conference on Enterprise Information Systems (ICEIS 2020) - Volume 2, SCITEPRESS, pp. 353-359. doi: 10.5220/0009489303530359. Accessed 2024-01-03.
  13. Lindberg, T., C. Meinel, and R. Wagner. 2011. "Design Thinking: A Fruitful Concept for IT Development?" In: Meinel, C., L. Leifer, and H. Plattner (eds). Design Thinking. Understanding Innovation. Springer, Berlin, Heidelberg. doi: 10.1007/978-3-642-13757-0_1. Accessed 2024-01-03.
  14. Martins, H.F., A.C. de Oliveira Junior, E.D. Canedo, R.A.D. Kosloski, R.A. Paldês, and E.C. Oliveira. 2019. "Design Thinking: Challenges for Software Requirements Elicitation." Information, vol. 10, no. 12: 371. doi: 10.3390/info10120371. Accessed 2024-01-03.
  15. Parizi, R., M.M. da Silva, I. Couto, K. Trindade, M. Plautz, S. Marczak, T. Conte, and H. Candello. 2020. "Design Thinking in Software Requirements: What Techniques to Use? A Proposal for a Recommendation Tool." CIbSE, Curitiba, Brasil, November 9-13. Accessed 2024-01-03.
  16. Pereira, L., R. Parizi, M. Prestes, S. Marczak, and T. Conte. 2021. "Towards an understanding of benefits and challenges in the use of design thinking in requirements engineering." SAC '21: Proceedings of the 36th Annual ACM Symposium on Applied Computing, pp. 1338–1345, March. doi: 10.1145/3412841.3442008. Accessed 2024-01-03.
  17. Soledade, M., R. Freitas, S. Peres, M. Fantinato, R. Steinbeck, and U. Araújo. 2013. "Experimenting with Design Thinking in Requirements Refinement for a Learning Management System." Proceedings of the 9th Brazilian Symposium on Information Systems, pp. 182-193, May 23-24. Accessed 2024-01-03.
  18. Sutcliffe, A. 1997. "A technique combination approach to requirements engineering." Proceedings of ISRE '97: 3rd IEEE International Symposium on Requirements Engineering, Annapolis, MD, USA, pp. 65-74. doi: 10.1109/ISRE.1997.566843. Accessed 2024-01-03.
  19. Sutcliffe, A.G. 2024. "Requirements Engineering." Chapter 13 in: The Encyclopedia of Human-Computer Interaction, 2nd edition, Interaction Design Foundation. Accessed 2024-01-03.
  20. Vetterli, C., W. Brenner, F. Uebernickel, and C. Petrie. 2013a. "From Palaces to Yurts: Why Requirements Engineering Needs Design Thinking." IEEE Internet Computing, vol. 17, no. 2, pp. 91-94, March-April. doi: 10.1109/MIC.2013.32. Accessed 2024-01-03.
  21. Vetterli, C., F. Uebernickel, W. Brenner, F. Häger, T. Kowark, J. Krüger, J. Müller, H. Plattner, B. Stortz, and V. Sikkha. 2013b."Jumpstarting Scrum with Design Thinking." Whitepaper, v1.1, University of St. Gallen for Business Administration, Economics, Law and Social Sciences (HSG), June 26. Accessed 2024-01-03.

Further Reading

  1. Martins, H.F., A.C. de Oliveira Junior, E.D. Canedo, R.A.D. Kosloski, R.A. Paldês, and E.C. Oliveira. 2019. "Design Thinking: Challenges for Software Requirements Elicitation." Information, vol. 10, no. 12: 371. doi: 10.3390/info10120371. Accessed 2024-01-03.
  2. Hehn, J. and F. Uebernickel. 2018a. "Towards an Understanding of the Role of Design Thinking for Requirements Elicitation - Findings from a Multiple-Case Study." Proceedings AMCIS, New Orleans, August 16-18. Accessed 2024-01-03.
  3. Hehn, J. and D. Mendez. 2022. "Combining Design Thinking and Software Requirements Engineering to Create Human-Centered Software-Intensive Systems." In: Hehn, J., D. Mendez, W. Brenner, and M. Broy (eds), Design Thinking for Software Engineering. Progress in IS. Springer, Cham. doi: 10.1007/978-3-030-90594-1_2. Accessed 2024-01-03.
  4. Lindberg, T., C. Meinel, and R. Wagner. 2011. "Design Thinking: A Fruitful Concept for IT Development?" In: Meinel, C., L. Leifer, and H. Plattner (eds). Design Thinking. Understanding Innovation. Springer, Berlin, Heidelberg. doi: 10.1007/978-3-642-13757-0_1. Accessed 2024-01-03.
  5. Vetterli, C., W. Brenner, F. Uebernickel, and C. Petrie. 2013a. "From Palaces to Yurts: Why Requirements Engineering Needs Design Thinking." IEEE Internet Computing, vol. 17, no. 2, pp. 91-94, March-April. doi: 10.1109/MIC.2013.32. Accessed 2024-01-03.

Article Stats

Author-wise Stats for Article Edits

Author
No. of Edits
No. of Chats
DevCoins
2
0
1254
1929
Words
0
Likes
14
Hits

Cite As

Devopedia. 2024. "Design Thinking for Requirements Engineering." Version 2, January 5. Accessed 2024-01-05. https://devopedia.org/design-thinking-for-requirements-engineering
Contributed by
1 author


Last updated on
2024-01-05 16:11:42