Design Thinking for Requirements Engineering
5 likes1,613 views
This document provides an overview of a tutorial on Design Thinking for Requirements Engineering (DT4RE). The tutorial aims to introduce basic principles and methods of Design Thinking and discuss how it can be integrated with Requirements Engineering. It outlines different approaches to integrating Design Thinking and Requirements Engineering based on the complexity of the project from pure Design Thinking to fully integrated approaches. The tutorial also discusses open research challenges around principles, artifacts, project influences, methods adoption, and operationalization of Design Thinking and Requirements Engineering processes.
Design Thinking for Requirements Engineering
- 1. DT4RE: Design Thinking for RE 20.08.2018 Banff, Alberta, Canada Jennifer Hehn, Falk Uebernickel, Daniel Méndez
- 2. Jennifer Hehn www.iwi.unisg.ch Research areas ● Design Thinking and Requirements Engineering ● Design Science Research Daniel Méndez www.mendezfe.org Research areas ● Empirical software engineering w/ focus on: ○ Requirements Engineering ○ Software Process Models ○ Quality Management ● Interdisciplinary qualitative research Falk Uebernickel goo.gl/WmRyAu Research areas ● Design Thinking and Human-centered Design for Information Systems ● Industry 4.0 / Internet of Things ● InsurTech ● Qualitative research
- 3. This session is based on... ● Previous tutorials given on either Design Thinking or Requirements Engineering ● Experiences made in projects
- 4. This tutorial will be about... Scope ● Introduction into basic principles and methods for Design Thinking (DT) ● Sharing experiences and lessons learnt on using DT in context of RE ● Discuss synergies with RE and open research challenges Out of Scope ● Out of the box solutions ● Universally applicable “blueprint”
- 5. Ground rule Whenever you have questions / remarks, please don’t ask , but share them with the whole group.
- 6. Introduction - Who are you? Quick round... ● Who are you? ● What are your experiences in Design Thinking in the context of software development projects/processes?
- 7. What do you know? What is Design Thinking?
- 8. Same as with agile methods, there are different perspectives on Design Thinking
- 9. What is Design Thinking (not)? Design Thinking... ● … is a human-centered problem solving method that applies extensive user-research, rapid prototyping, iterative improvement cycles, and interdisciplinary team work In contrast, Requirements Engineering ● is a holistic discipline with various principles, approaches and even more methods
- 10. Two faces of the same medal? In Design Thinking, we often pretend that after building a high-resolution prototype, the rest is “just development”. In RE, we often pretend that requirements are somehow present and “just need to be elicited”.
- 11. Issues in scope of current debates When should we make use of Design Thinking? How can we make use of Design Thinking? How can we integrate Design Thinking and RE in a seamless manner?
- 12. Outline 1. Design Thinking in a Nutshell 2. Design Thinking for Requirements Engineering 3. Final discussion and closure
- 13. Outline 1. Design Thinking in a Nutshell 2. Design Thinking for Requirements Engineering 3. Final discussion and closure
- 16. Design Thinking is a problem solving approach that starts with the human Viability FeasibilityDesirability
- 17. Design Thinking is explorative and iterative
- 19. Interviewing and self-immersion in Kenya (Photographer: Falk Uebernickel) Needfinding Empathize.
- 20. In Needfinding we apply three methods Observe Ask Immerse
- 22. Pictures: project for an insurance company (2017)
- 26. Screen Flow
- 28. 28
- 29. The outcome of a Design Thinking project is one or more tested prototypes LOW RESOLUTION PROTOTYPE HIGH RESOLUTION PROTOTYPE Simple and easy to handle prototypes Quickly created Focus is on few features / critical functions Costs: low Complex simulations and prototypes of the future product, service or process and business model All important functions are implemented Costs: higher
- 33. People and Making are the heart of Design Thinking Principles
- 34. Picture: FIFA Project (DT@HSG 2012/13) See the human behind the user
- 35. Do not stop at your corporate doors Picture: DT@HSG (2016)
- 36. Making instead of over-thinking Picture: Stanford ME310 Loft
- 37. Experiment and prototype continuously (“kill your darlings”) Picture: DT@HSG Loft (St.Gallen 2013/14)
- 38. Enforcing Picture: DT@HSG (2013/14) Field testing even in early project phases (”fail forward”)
- 39. Picture: DT@HSG (2013) Shape your view with interdisciplinary teams
- 40. Design Thinking transforms wicked into ill- and well- defined problems
- 41. Outline 1. Design Thinking in a Nutshell 2. Design Thinking for Requirements Engineering 3. Final discussion and closure
- 42. Outline 1. Design Thinking in a Nutshell 2. Design Thinking for Requirements Engineering 3. Final discussion and closure
- 43. DT largely concentrates on identifying/empathising with the stakeholders and end-users, and understanding the domain and problem space to enable distilling needs and requirements. RE typically concentrates on subsequent requirements elicitation, analysis, and documentation Cross Comparison Source: Artefact-based Requirements Engineering: The AMDiRE Approach - https://arxiv.org/abs/1611.10024 Why? What? How? Context Specification Requirements Specification System Specification RE DT
- 44. DT largely concentrates on... ● … better understanding the problem space by identifying and empathising with stakeholders ● … providing a system vision by defining key (functional) features ● … the rationale for (“formal”) requirements RE largely concentrates on… ● … identifying, analysing/refining, and specifying/modelling requirements going beyond functional ones Cross Comparison Source: Artefact-based Requirements Engineering: The AMDiRE Approach - https://arxiv.org/abs/1611.10024
- 45. Source: Artefact-based Requirements Engineering: The AMDiRE Approach - https://arxiv.org/abs/1611.10024 Prototype Persona User journey User Test protocols Needs Opportunity Areas Stakeholder Map Platform Model Service Model Design Challenge Ideas Business model Human model Insights Exemplary DT Artefacts
- 46. Disclaimer … but many lessons learnt
- 47. Evolution of Design Thinking and RE Complexity* t Pure Design Thinking Infused Design Thinking Integrated Design Thinking Upfront Design Thinking * Note: one is not per-se “better” than the other; everything has its place
- 48. Evolution of Design Thinking and RE t Pure Design Thinking Infused Design Thinking Integrated Design Thinking Upfront Design Thinking * Note: one is not per-se “better” than the other; everything has its place Complexity*
- 50. ● Much like RE, DT shouldn’t suddenly stop ● DT is human-centric, but also team-driven ○ Team members (skills, motivation, participation) are crucial ○ Make explicit implicit assumptions (e.g. to avoid gold plating) ○ Beware dependencies to implicit knowledge ● Potentially working towards the void ○ No immediate counterpart and no institutionalised “hand-shake” → Software process model? Needs and team culture? ○ No continuity and potentially no champion ● No guaranteed operationalisation (and feasibility) of prototype Take-Aways
- 51. Evolution of Design Thinking and RE t Pure Design Thinking Infused Design Thinking Integrated Design Thinking Upfront Design Thinking * Note: one is not per-se “better” than the other; everything has its place Complexity*
- 52. ● German Software Company (SME) ● Problem Statement: Development of an offering for a new target group (private landlords) in real estate management ● Team: Requirements Engineer, Product Manager, IT-Architect, Designer, Hotline Support, Project Lead, Design Thinking Coach ● Design Thinking Project: 4 months Upfront Design Thinking DT RE
- 53. DT RE • 12 qualitative interviews • 1 quantitative questionnaire • 2 Personas • 4 prototypes • User story definition via project team • User stories and high resolution prototypes are handed over to implementation Upfront Design Thinking
- 54. ● What works: ○ Fostering a collaborative working environment ○ Fostering a failure tolerant culture through rapid prototyping and continuous experimentation ○ Broadly validated key features / user stories ● Open challenges: ○ Final deliverable via user stories and HighRes prototype ○ No further feedback cycles ○ Potential starvation of results with no implementation (or control over it) Take-Aways
- 55. Evolution of Design Thinking and RE t Pure Design Thinking Infused Design Thinking Integrated Design Thinking Upfront Design Thinking * Note: one is not per-se “better” than the other; everything has its place Complexity*
- 56. ● International Electronics group ● Headquarter in Germany,10.500 employees ● Needfinding and Prototyping Infusion Infused Design Thinking DT RE
- 57. ● What works: ○ Fostering a broader collaborative working environment ○ Integrating creative idea generation in context of a software development life cycle ● Open challenges: ○ No further development-critical artefacts, e.g. NFRs, technical constraints, or data models ○ Still no seamless and sustainable integration of DT methods into software development activities ○ Limited learning curve for reuse in further projects Take-Aways
- 58. Evolution of Design Thinking and RE t Pure Design Thinking Infused Design Thinking Integrated Design Thinking Upfront Design Thinking * Note: one is not per-se “better” than the other; everything has its place Currently in progress Complexity*
- 59. ● German Utility Company ● Problem statement: Development of an offering to boost photovoltaik sales ● Team: multidisciplinary ● Design Thinking process: 3 months ● Integrated approach: 12+ months Integrated Design Thinking approach DT RE
- 60. Design Thinking 3 months Final (non-tech.) prototype DT ● 10 expert interviews ● 22 interviews with possible users (homeowners and craftsmen) ● 40 insights collected ● 50 ideas generated ● 12 value propositions for both craftsmen and customers ● 3 Personas ● 12 low resolution prototypes tested with both stakeholder groups ● 1 final high resolution prototype (not yet tested) Full Design Thinking Approach Revised vision: Home Improvement Platform
- 61. Design Thinking 3 months DT@Scrum 12-x months Design Thinking Toolbox: User Testing & Prototyping; Product Owner Role is inhabited by Design Thinking Team SCRUM Sprint 0 SCRUM Sprint 1 SCRUM Sprint 2 .... SCRUM Sprint n Sprint backlog Sprint backlog Sprint backlog MVP1 Final (non-tech.) prototype DT ● 10 expert interviews ● 22 interviews with possible users (homeowners and craftsmen) ● 40 insights collected ● 50 ideas generated ● 12 value propositions for both craftsmen and customers ● 3 Personas ● 12 low resolution prototypes tested with both stakeholder groups ● 1 final high resolution prototype (not yet tested) E p i c s User stories Flow Charts Non-tech Prototype Full Design Thinking Approach Revised vision: Home Improvement Platform
- 62. ● What works: ○ DT as a structured, domain-agnostic approach to requirements elicitation ○ Extended arm into wicked problems and re-define actual problems and SW system context ○ Sufficiently correct and complete key features / user stories via continuous experimentation and testing of non-technical and technical prototypes ○ Clear roles and responsibilities ● Currently open challenges: ○ Difficulty in integrating further RE-specific artefacts, e.g. NFRs, technical constraints, or data models Take-Aways
- 63. How can we efficiently integrate DT and RE?
- 64. Reminder
- 65. Towards a pragmatic approach to human-centric RE DT RE Infused RE DT RE Fully integrated DT ? ● Coarse problems & goals ● Project characteristics DT RE Upfront DT
- 66. Open research challenges ● Principles: Which principles and approaches in DT can be found in more holistic human- centred software development approaches and how do they differ? ● Boundary objects: How can artefacts with similar purposes, but different forms, be integrated? General Challenges
- 67. Open research challenges ● How can problems be efficiently classified? ● What are typical project situations which influence the choice of a strategy? ● How do these situations and the class of systems influence the choice of a strategy and single methods? ● How can these situations be characterised and assessed in early stages of a project (with which confidence)? Project Influences
- 68. Open research challenges ● Which methods in DT can be found in / reused for other software engineering disciplines (e.g. HCI, TDD)? ● How do these methods differ? How can they be integrated? Method adoption
- 69. Open research challenges Interfaces ● How can artefacts, roles, and methods be seamlessly integrated? ● Which artefacts do overlap? Are shifts in roles and responsibilities necessary? ● How can milestones be efficiently defined? Operationalisation ● How can resulting processes be integrated (into the overall life cycle) - for instance SCRUM? ● How can resulting processes be tailored? Interface and Operationalisation
- 70. Outline 1. Design Thinking in a Nutshell 2. Design Thinking for Requirements Engineering 3. Final discussion and closure