Requirement Engineering and the Role of Design Thinking
Anas Husaria
1,2
and Sergio Guerreiro
1,2
1
Instituto Superior Técnico, University of Lisbon, Av. Rovisco Pais 1, 1049-001 Lisbon, Portugal
2
INESC-ID, Rua Alves Redol 9, 1000-029 Lisbon, Portugal
Keywords: Design Thinking, Software Development, Requirement Engineering, UX, Agile, HCI.
Abstract: Recently, interest in the use of Design Thinking (DT) has been on the rise as a field to study related to Human-
Computer Interaction (HCI). Companies today are seeking innovation and user-centricity in the software
development projects regardless of the field they are in. Companies like IBM and SAP among others have
taken steps forward to innovate their software development processes using Design Thinking, by creating
academies and innovation labs. DT is used as a method to improve the User Experience (UX) while interacting
with a computer software. Requirement Engineering (RE) is a process of defining, documenting and
maintaining requirements in the system design and software engineering process, while RE takes on the initial
phase in software engineering. This position paper reviews the practices of RE as well as how DT could have
a role to mitigate the challenges that RE could have.
1 INTRODUCTION
Human-Centred Design is heavily used today in the
field of software engineering, as a method to promote
a better User Experience (UX) and a better
engagement of users with the developed software
which ultimately would benefit both the business and
the end users (Hehn et al. 2019). DT has the potential
to add value to the current RE process by tackling the
challenges it has, which would ultimately improve the
perceived UX of the developed software. In order to
ensure the quality of the provided UX in the field of
Human-Computer Interaction (HCI) usability was
always one important measure (Mekler and Hornbæk
2019). In addition to that, Design Thinking (DT) is
being considered as one of the most influential
method to solve complex problems and provide
usable solutions (Hehn and Uebernickel 2018). Uber
and Airbnb among other software-based companies
have used DT to innovate their service model and to
develop a usable software that is solving real life
problems (Geogy and Dharani 2016; Liedtka 2018).
Although Requirement Engineering has been
heavily researched the need to innovate in this field is
relevant due to the evolving environment of software
developments. By introducing the iterative work style
(e.g. Scrum and Kanban) Agile Methods have
increased the flexibility in software development
(Inayat, Moraes, et al. 2015). Nevertheless, DT has
the potential to support in solving complex problems
and mitigating the risks that current processes are
having. This paper has analysed articles and research
publications which reviewed Requirement
Engineering and studied the applications of Design
Thinking (DT) on current software development
problems.
The paper starts with reviewing the requirement
engineering literature, particularly by comparing
traditional and agile requirement engineering
methods. Afterward, the paper describes the usage of
DT in RE, particularly analyse the challenges of agile
requirement engineering which DT has a potential to
solve. Then, the paper explains how DT is applied in
an intensive software development project. Finally,
the paper analyses the benefits of using DT up front
in a software project by taking a case study from the
industry as an example where DT was applied up
front at a large organization. In the conclusion
section, the paper summarizes the findings and
suggests future research questions in field.
2 REQUIREMENT
ENGINEERING REVIEW
Requirement Engineering (RE) focuses on the
comprehensive understanding of stakeholder (i.e.,
customers, users, etc.) requirements and the
documentation of these requirements to make them
Husaria, A. and Guerreiro, S.
Requirement Engineering and the Role of Design Thinking.
DOI: 10.5220/0009489303530359
In Proceedings of the 22nd Inter national Conference on Enterprise Information Systems (ICEIS 2020) - Volume 2, pages 353-359
ISBN: 978-989-758-423-7
Copyright
c
2020 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
353
available for a structured software engineering
process (Batool et al. 2013). Additionally, RE
supports the process of identifying, modelling,
documenting and communicating both the
requirements and the context of a system (Heikkila et
al. 2015). While RE has matured to become an
essential activity in the field of software engineering,
the software product quality is widely based on the
quality of the development process used to build it
(Takeuchi and Ikujiro 1986). Therefore, it is
significant to keep improving the process with the
aim to enhance the quality of the final software
product.
2.1 Traditional Requirement
Engineering Process in Comparison
to Agile Requirement Engineering
In order to have a better understanding of RE, this
paper provides a review for the two main approaches
used in research for RE.
2.1.1 Traditional Requirement Engineering
Process
Requirement Engineering (RE) could be looked at
from three dimensions: the specification dimension,
the representation dimensions and the agreement
dimension. Studying RE using this framework, would
support in creating a better understanding of RE, by
classifying the different approaches (Pohl 1993). The
waterfall life cycle model, which emerged in 1970s,
has sat the bases for the term “traditional
requirements engineering” (Batool et al. 2013). The
model suggested that the approach to develop a
system can be done via a sequential order of progress
(Batool et al. 2013). The sequential phases of RE in
waterfall are requirements definition, system and
software design, implementation and unit testing,
integration and system testing, and finally operation
and maintenance (Batool et al. 2013).
Requirement Definition
During the requirements definition stage, several
processes for collecting requirements which meet the
needs of the users are involved (Takeuchi and Ikujiro
1986). The requirements definition stage starts with
elicitation where the stakeholders set the margins and
scope of both the requirements and the system using
techniques such as, interviews, brainstorming,
prototypes and use cases (Pohl 1993). The
discovering of requirements from other sources also
happen during the requirement elicitation phase
(Heikkila et al. 2015). For diving deeper in some of
the most important techniques for requirements
elicitation the paper has summarized some of them.
Interviews: Interviewing is an approach for
discovering facts and opinions held by potential users
or stakeholder of the software to be developed as well
as the chance to clear up misunderstandings (Kotonya
and Sommerville 1998). There are two different
types of interview styles, one is closed, in which the
requirement engineer would have pre-defined set of
questions. While the other one is an open interview,
where the requirement engineer goes to discuss with
stakeholders with an open-ended way what they need
to have in the system (Kotonya and Sommerville
1998). The benefit of interviews on one hand, is to
make developers aware with a lot of contextual
information. On the other hand, interviews pitfall is
that it is difficult to contemplate the large amount of
qualitive data acquired, while meeting different
stakeholder could lead to providing conflicting
information (Kotonya and Sommerville 1998).
Use cases: the objective of using use case is to
describe system-user interactions, in a way that would
explain the user need out of the system (Kotonya and
Sommerville 1998; Paetsch and Maurer 2003). A use
case examines a flow of interaction between an
external actor and a system. The functional
requirement of the system could be represented in use
cases at an early stage of the software development
process (Kotonya and Sommerville 1998).
Observation and social analysis: in the
observational methods, the requirement engineer
would be involved in viewing users doing their work
and take notes to build up knowledge about their
reality. It is a useful method for learning about
currently executed tasks and processes (Kotonya and
Sommerville 1998).
Focus Groups: in this technique a group of four to
nine users from several backgrounds and with
multidisciplinary skills discuss in a free form the
features of software prototype. Focus groups help to
understand user needs and viewpoints as well as what
is of high priority to them (Macaulay 1996).
Brainstorming: is a method to promote creative
solutions for an examined problem. Brainstorming
includes two stages, one is the ideas generation,
where ideas should not be criticized, and the second
is idea selection or evaluation where the team decides
on what is the most feasible idea to implement
(Heikkila et al. 2015).
Prototyping: prototypes of software systems are
usually used to support in the elicitation and
validation of the software. A prototype of system is
often done in an early stage of the development
process, to help collecting more information about the
ICEIS 2020 - 22nd International Conference on Enterprise Information Systems
354
expectations of users from the system (Heikkila et al.
2015). Usually the requirement engineer would select
one or some of these methods to use in requirement
definition stage depending on what fit the project.
Requirements Analysis
Then next step in requirement definition stage, is
analysis and negotiation. In this stage a deeper
understanding and a logical breakdown of the
business through clarifying sessions can be acquired
while confirming that the elicited requirements are
comprehensive, viable, prioritized and consistent
(Batool et al. 2013; Pohl 1993).
Requirements Documentation
The next step is the requirement documentation or
specification, where the requirements are
documented in a written form and used for stating
functional and non- functional requirements (Batool
et al. 2013; Pohl 1993). The purpose of requirements
documentation is to communicate requirements
between stakeholders and developers (Heikkila et al.
2015).
Requirements Validation
The validation or verification activity contains
checking if the requirements statements are coherent
and if they match the user needs using test cases or
prototypes (Pohl 1993). The main goal of
requirements validation is to make sure that the
documented requirements are providing an
acceptable description of the system to be developed.
Requirement documents, organizational standards,
and organizational knowledge are used as inputs for
the validation process (Heikkila et al. 2015).
Requirements Management
At the end of the development process, the
requirement management stage is initiate. This
activity focuses on keeping a track of changes in the
requirements and ensuring that alterations are made
to meet business needs and stakeholder’s requirement
(Heikkila et al. 2015; Northrop and Clements 2012).
2.1.2 Agile Requirement Engineering
Since the mid-80s, there was an on-going discussion
on how to improve the current processes of
Requirement Engineering. The sequential phases
approach to product development is not fit because it
does not provide enough flexibility (Schön,
Thomaschewski, and Escalona 2017). Since that time,
new models and experimentations to improve the
current process were proposed and developed
(Schwaber 2004). There have been already few agile
methodologies developed, such as Extreme
Programming (Beck 1999), Feature-Driven
Development (Palmer and Felsing 2001), Kanban ((J.
Anderson 2010) and Scrum (Schön, Thomaschewski,
and Escalona 2017). In the meantime, the Agile
Manifesto was created by the leaders of these
methodologies after they have joined forces in 2001
(Hohl et al. 2018). The Agile Manifesto has provided
principles to follow when developing a software in
order to optimize the process and enable team’s
collaboration (Schön, Escalona, and Thomaschewski
2015). The main values of the Agile Manifesto are:
Working software over comprehensive
documentation
Customer collaboration are over contract
negotiation
Responding to changeover sticking to the
plan
Individuates and interactions are over
processes and tools
One of the Agile Manifesto principles states
“changes in requirement are welcome, even late in the
development”, which proposes that RE would be a
continuous process throughout the lifecycle of the
system (Inayat, Moraes, et al. 2015). The most
common agile software method is scrum (e.g. of the
scrum framework depicted in Figure. 1 (Armitage,
Cordova, and Siegel 2017) which focuses on having
frequent deliverables in small iterations of work that
keep the process dynamic.
The requirements are initially defined by the
client, while they are listed in a backlog. Then every
two weeks they are discussed with the team in order
to have them fully comprehended and prioritized then
moved into the next sprint backlog (Schwaber and
Sutherland 2017).
Although the agile values would improve the
flexibility of Requirement Engineering in the
software development process nevertheless, recent
researches were indicating project failure rates on the
rise, even for the projects that are using agile
processes (Inayat, Moraes, et al. 2015). The reason
behind that is that, the agile new method of working
has brought a challenge and an unclarity to the
execution of Requirement Engineering processes
(Inayat, Moraes, et al. 2015).
Requirement Engineering and the Role of Design Thinking
355
Figure 1: Scrum Framework.
3 DESIGN THINKING IN
REQUIREMENT
ENGINEERING
In the field of software development, Requirement
Engineering (RE) has been always used to support the
understanding of complex business problems and for
the elicitation of user needs in volatile world where
user needs are unclear, and several parties are
involved in a project. Although agile frameworks
have contributed a lot to the field of software
development making the work organized (Heikkila et
al. 2015). However, Design Thinking is providing a
more structured method to solve these complex
problems. Design Thinking (DT) is defined as an
innovative human-centred method to integrate the
human requirement (desirability), the technological
capabilities (feasibility) and the business requirement
to be profitable (viability) (Brown 2008). DT is using
interdisciplinary teams, focusing on human needs,
fast prototyping and an ongoing cycle of learning
iteration to gain empathy at an early stage of the
software development process (Armitage, Cordova,
and Siegel 2017; Kolko 2015)
3.1 Challenges of Agile Requirement
Engineering that DT has the
Potential to Solve
While the complicated part in any system design is
what to build, the goal is to find the “sweet spot” or
which is a point that gives the right amount of
requirement information which keeps the right
amount of ambiguity for the development team to
discover along the process (Wahono 2003). DT Role
in RE can be investigated by case study (Hehn and
Uebernickel 2018). DT has the potential for a positive
impact on some of the current RE practices (Hehn and
Uebernickel 2018). During their research several
challenges related RE in agile set-ups have been
identified. Some of which are discussed below in
addition to the role of DT to positively impacting each
challenge. Some of the found challenges are
discussed below.
Issues with customers or users, the difficult
access to and contacting with directly with customers
slows the process of clarifying requirements down
(Heikkila et al. 2015; Inayat, Salim, et al. 2015). DT
provides a solution regarding customer or user
availability that normal RE methods face, since DT is
a process-oriented method, the user interviews can be
planned upfront, which will support overcoming this
challenge (Hehn and Uebernickel 2018).
Non-functional requirements are neglected, user
stories are usually focused on software features, but
non-functional requirements such as security and
usability are not well covered (Inayat, Salim, et al.
2015). Although DT neglects most of non-functional
requirement as well, however, it enforces heavily the
importance of eliciting usability requirements (Hehn
and Uebernickel 2018).
Additionally, majority of the knowledge often
stays tacit as agile practices rely on highly skilled
people 2+20. However, DT supports the distribution
of knowledge throughout the team (Hehn and
Uebernickel 2018). Additionally, the involvement of
interdisciplinary teams assists in enriching different
ICEIS 2020 - 22nd International Conference on Enterprise Information Systems
356
viewpoint which would enhance the whole team
understanding of the user needs (Hehn and
Uebernickel 2018).
Inaccurate effort estimates of time and cost
happens due to the agile project characterizes
(Heikkila et al. 2015; Inayat, Salim, et al. 2015). DT
approach by focusing upfront on the user needs and
the problem space, would provide a clear scope and
product vision by elaborating well defined problem
statement at an early stage (Hehn and Uebernickel
2018). This would serve as a mitigation to problems
such as imprecise effort estimation and usage of the
inappropriate technology (Hehn and Uebernickel
2018).
3.1.1 Design Thinking in Intensive Software
Development Project
To have deep comprehension of DT for RE as socio-
technological activity (Hehn and Uebernickel 2018)
adopted a quantitative approach and applied it to a
case study. Current RE practices in software
development projects can be enhanced by applying
DT and vice versa (Hehn and Uebernickel 2018). DT
is proven to be a supportive approach in turning
complex problems into well-defined ones that then
would be easily approached by the known RE
activities (Mekler and Hornbæk 2019). However, an
effective integration between both DT and RE would
leverage a synergetic relationship (Hehn et al. 2019;
Hehn and Uebernickel 2018). Software Development
can be a great ground for DT applications. Therefore,
DT would enable innovation and creativity by
iterative re-framing of the problem and solution
space, making sure the best User Experience (UX) is
provided (Hehn and Uebernickel 2018).
4 BENEFITS OF USING DESIGN
THINKING UP FRONT IN A
SOFTWARE DEVELOPMENT
PROJECT
In a large organization, using design thinking method
early on in software projects could have a positive
influence on the success of the project. To verify that,
we have investigated a medium size project in a large
organization, the project initial phase involved the
following:
The goal of the project is to create a new
financial analysis tool that.
Around 20 people in the project were
involved.
To implement that, a design thinking facilitators team
have joined the project for one-week time to run a
design thinking workshop in order to come up with a
clear problem statement. The design thinking
workshop went through the whole process of design
thinking, starting with empathy, where the team have
run several interviews and done shadowing for
current users. Next step, the joint team have defined
a well-stated problem statement. After that, an
ideation workshop took place where it was possible
to obtain several ideas to solve the defined problem
statement. The team have used the how-might we
method to inspire creativity during the solution
generation phase. As a next step, the team have
decided on the best solution to prototype and
provided a digital mock-up for the users to test. The
user testing stage took place afterward and brought
several learnings for the team to reiterate the
prototype until the users have accepted the prototype.
The prototype and testing results have been
submitted to the project management to decide on
investment and implementation. Based on the
positive results of the testing stage and the impact
perceived if the new solution was implemented, the
project management have decided to invest in
implementing this new solution.
The software project is currently running, and
we are still monitoring the results of our investigation
on using design thinking up front in a new software
project. However, monitoring this case study have led
us to identify few preliminary results. We have
categorized these results in three parts which are the
main aspects of design thinking. The aspects are
Human Desirability, Technological Feasibility and
Business Viability.
The results are described according their respective
category in Table 1.
Table 1: Identified Benefits of Using Design Thinking Up
Front in Software Project.
Human
Desirability
User adoption rates of the first release of
the software have been seen be above
average in comparisons to other projects.
Technological
Feasibility
The choice of the appropriate technology
to support the selected solution came
after, which saved the company the effort
of investing in several technologies before
deciding solution.
Business
Viability
As the project implementation and user
adoption are in parallel going up and
forward. The business has noticed lower
running costs in this project in comparison
to similar ones at the same department
that did not use design thinking up front.
Requirement Engineering and the Role of Design Thinking
357
The above results in Table 1 are still preliminary,
and we are still monitoring this project by running
interviews with the project team to understand the
effect of using design thinking up front on the full life
cycle of the software development project. However,
the current results show a positive potential for design
thinking role as requirement engineering method.
5 CONCLUSIONS
Requirement Engineering usually faces the difficulty
of discovering and meeting the unarticulated and
changing needs of various stakeholder (Hehn et al.
2019). Current RE practices in software development
projects can be enhanced by applying DT and vice
versa (Hehn and Uebernickel 2018). As DT has the
potential of solving some challenges of Agile RE. As
a result, a better development process would lead to
better built product and ultimately improved UX.
Thus, integrating Design Thinking in current
Requirement Engineering studies a potential to
improve the outcome of development process.
Additionally, the case study we are running shows a
positive impact for the role of DT in software
development project. Future research is
recommended on special case studies where design
thinking is applied for mature software product in
large companies.
ACKNOWLEDGEMENT
This work was supported by national funds through
Fundação para a Ciência e a Tecnologia (FCT) with
reference UIDB/50021/2020 and by the European
Commission program H2020 under the grant
agreement 822404 (project QualiChain).
REFERENCES
Armitage, A., Andrew, C., Rebecca, S., 2017. “Design-
Thinking: The Answer to the Impasse between
Innovation and Regulation.” UC Hastings Research
Paper 250: 2636. https://ssrn.com/abstract=3024176.
Batool, A., Motla, Y., Hamid, B., Asghar, S., Riaz, M.,
Mukhtar, M., Ahmed, M., 2013. “Comparative Study of
Traditional Requirement Engineering and Agile
Requirement Engineering.” In 2013 15th International
Conference on Advanced Communications Technology
(ICACT), , 100614.
Beck, K,. 1999. Extreme Programming Explained:
Embrace Change. USA: Addison-Wesley Longman
Publishing Co., Inc.
Brown, T., 2008. “Design Thinking.” Harvard Business
Review 86(6): 8492. www.hbr.org.
Geogy, M., and Andhe, D., 2016. “A Scrutiny of the
Software Requirement Engineering Process.” Procedia
Technology 25: 40510.
https://www.sciencedirect.com/science/article/pii/S221
2017316304728 (January 6, 2020).
Hehn, J., Mendez, D., Uebernickel, F., Brenner, W., Broy,
M., 2019. “On Integrating Design Thinking for a
Human-Centered Requirements Engineering.”
https://arxiv.org/abs/1908.07223: 15.
Hehn, J., Uebernickel, F., 2018. “The Use of Design
Thinking for Requirements Engineering - An Ongoing
Case Study in the Field of Innovative Software-
Intensive Systems.” 26th IEEE International
Requirements Engineering Conference (RE’18)
August.
https://www.alexandria.unisg.ch/publications/254658.
Heikkila, V., Damian, D., Lassenius, C., Paasivaara, M.,
2015. “A Mapping Study on Requirements Engineering
in Agile Software Development.” Proceedings - 41st
Euromicro Conference on Software Engineering and
Advanced Applications, SEAA 2015: 199207.
Hohl, P., Klünder, J., van Bennekum, A., Lockard, R.,
Gifford, J., Münch, J., Stupperich, M., Schneider, K.,
2018. “Back to the Future: Origins and Directions of the
‘Agile Manifesto’ – Views of the Originators.” Journal
of Software Engineering Research and Development
6(15).
Inayat, I., Salim, S., Marczak, S., Daneva, M.,
Shamshirband, S., 2015. “A Systematic Literature
Review on Agile Requirements Engineering Practices
and Challenges.” Computers in Human Behavior 51:
91529.
https://www.sciencedirect.com/science/article/pii/S074
756321400569X?via%3Dihub (January 29, 2020).
Inayat, I., Moraes, L., Daneva, M., Salim, S., 2015. “A
Reflection on Agile Requirements Engineering:
Solutions Brought and Challenges Posed.” In 1st
International Workshop on Requirements Engineering
in Agile Development (READ), Association for
Computing Machinery (ACM), 6167.
Anderson, J, D., 2010. Kanban: Successful Evolutionary
Change for Your Technology Business. Blue Hole
Press.
Kolko, J., 2015. “Design Thinking Comes of Age.”
Harvard Business Review (September): 6671.
Kotonya, G., Sommerville, I., 1998. Requirements
Engineering: Processes and Techniques.
Liedtka, J., 2018. “Why Design Thinking Works.” Harvard
Business Review 2018(September-October).
Macaulay, L, A., 1996. Requirements Engineering.
Springer-Verlag London.
Mekler, E, D., and Hornbæk, K., 2019. “A Framework for
the Experience of Meaning in Human-Computer
Interaction.” Conference on Human Factors in
ICEIS 2020 - 22nd International Conference on Enterprise Information Systems
358
Computing Systems - Proceedings (CHI 2019): 115.
https://doi.org/10.1145/3290605.3300455.
Northrop Linda M., and Clements Paul C., 2012. “A
Framework for Software Product Line Practice,
Version 5.0.” Software Engineering Institute: 258.
https://resources.sei.cmu.edu/library/asset-
view.cfm?assetID=495357.
Paetsch, F., Maurer, F., 2003. “Requirements Engineering
and Agile Software Development.” : 1–6.
Palmer, S, R., Felsing, M., 2001. A Practical Guide to
Feature-Driven Development. 1st ed. Pearson
Education.
Pohl, K., 1993. “The Three Dimensions of Requirements
Engineering BT - Advanced Information Systems
Engineering.” In eds. Colette Rolland, François Bodart,
and Corine Cauvet. Berlin, Heidelberg: Springer Berlin
Heidelberg, 27592.
Schön, E., Escalona, M., Thomaschewski, J., 2015. “Agile
Values and Their Implementation in Practice.”
International Journal of Interactive Multimedia and
Artificial Intelligence 3(5): 6166.
http://www.ijimai.org/journal/sites/default/files/files/2
015/11/ijimai20153_5_8_pdf_59735.pdf.
Schön, E., Thomaschewski, J., Escalona, M., 2017. “Agile
Requirements Engineering: A Systematic Literature
Review.” Computer Standards & Interfaces 49: 7991.
https://www.sciencedirect.com/science/article/pii/S092
0548916300708 (January 6, 2020).
Schwaber, K., 2004. Agile Project Management With
Scrum. USA: Microsoft Press.
Schwaber, K., Sutherland, J., 2017. Scrum.Org and
ScrumInc The Scrum Guide: The Definitive The Rules
of the Game.
http://www.scrumguides.org/docs/scrumguide/v1/Scru
m-Guide-US.pdf.
Takeuchi, H., Ikujiro, N., 1986. “The New New Product
Development Game.” Harvard Business Review 64:
137146.
Wahono, R., 2003. “Analyzing Requirements Engineering
Problems.” In IECI Japan Workshop, , 5558.
Requirement Engineering and the Role of Design Thinking
359