=Paper=
{{Paper
|id=Vol-3107/paper7
|storemode=property
|title=Transitioning from motivational goal models to user stories within user-centred software design
|pdfUrl=https://ceur-ws.org/Vol-3107/paper7.pdf
|volume=Vol-3107
|authors=Eduardo Oliveira,Varsha Maram,Leon Sterling
|dblpUrl=https://dblp.org/rec/conf/apsec/OliveiraMS21
}}
==Transitioning from motivational goal models to user stories within user-centred software design==
https://ceur-ws.org/Vol-3107/paper7.pdf
Transitioning from motivational goal models to user
stories within user-centred software design
Eduardo A. Oliveira Varsha Maram Leon Sterling
Computing and Information Systems Computing and Information Systems Centre for Design Innovation
University of Melbourne University of Melbourne Swinburne University of Technology
Melbourne, Australia Melbourne, Australia Melbourne, Australia
eduardo.oliveira@unimelb.edu.au v.maram@unimelb.edu.au lsterling@swin.edu.au
Abstract—Motivational goal modelling has evolved from agent- between software engineers and clients. The method has
oriented models to allow a shared understanding of a project the advantage of extending the high-level understanding as
by diverse stakeholders. Building a motivational model is in the conveyed by the motivational model with concrete artefacts.
spirit of user-centred design. Requirements artefacts such as user
stories and personas should be developed consistently with the As such, they are also consistent with user-centred software
model. This paper describes a method to generate user stories design.
from motivational models. The generated stories are checked by The remainder of the paper is organized as follows: Section
users and developers to ensure readabilty and clarity. The method 2 briefly discusses major challenges related to requirements
has been partially automated within an extension to an editing
engineering and the role of motivational models to support
tool.
Index Terms—model-based requirements, motivational mod- the creation of personas and user stories. Section 3 provides
elling, requirements engineering, engineering education a comprehensive example on how to generate user stories
from motivational models. Section 4 provides conclusions and
I. I NTRODUCTION highlights future work opportunities.
Motivational goal models are valuable for building a shared
understanding of a project. Agent-oriented goal models were II. BACKGROUND AND L ITERATURE R EVIEW
described in Sterling and Taveter [1] as a way of designing
and implementing agent-oriented systems, however, they did In the past few years, previous studies have identified
not focus on Requirements Engineering (RE) methods. Since that face-to-face communication, customer involvement and
then, the do/be/feel elicitation method [2] incorporated the use interaction are major challenges related to Requirements En-
of motivational goal models to RE. gineering (RE) as they often involve different stakeholders
The do/be/feel method produces several lists of project goals with different backgrounds [4]–[7]. Agile processes advocate
and stakeholders. The lists can be translated into motivational minimal documentation [8] in the form of user stories and dis-
goal models. These lists and models have been used exten- courage long and complex specification documents. Frequent
sively for teaching at the University of Melbourne and at face-to-face communication helps clients steer the project in
Swinburne University of Technology as they help students to an unexpected direction according to their own understanding
understand a problem or desired system that is accessible to of the project. The frequent meetings lead to informal com-
all stakeholders [1]. munication among stakeholders, which aids in the evolution of
The success of software products is highly dependent on the requirements. The frequency of communication depends on
validations performed on users’ goals. In this context, the the availability and willingness of team members. Customers
relationships between goal models, personas and user sto- may be accustomed to traditional methods and are unable to
ries are critical at early design phases [3]. Non-technical comprehend and trust agile methods. [6] discusses risks when
approaches like motivational goal models can be used to facil- customers’ IT groups and managers, for example, understand
itate communication and better overall understanding among requirements in different ways and how their inability to com-
stakeholders when combined appropriately. The hierarchical prehend agile methods can impact decision-making and project
diagram of the goals of a system at high abstraction levels execution. Without a common understanding of requirements,
has potential to improve communication between students and many degrees of formal separation between stakeholders can
industry partners during requirements elicitation and validation be created. The separation can lead to biased and incomplete
tasks. Motivational goal models have evolved and been used views that diminish transparency in eliciting, negotiating, and
extensively over the past 5 years in software engineering, validating requirements. A lack of ability to communicate
especially in RE. properly can compromise the whole development of a system.
In this paper, we extend the work of [1] and [2] and present There is an urgent need to ensure that requirements are
a method for semi-automatically generating user stories from appropriately defined, clarified and prioritised among different
motivational goal models to support requirements validation stakeholders [9].
Copyright © 2022 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
In this context, personas and user stories, typically struc- gineering [11], [19], there has been little work describing how
tured into epics, can be created as specifications of require- software engineering tools should be augmented to support
ments. An epic is a large user story that cannot be delivered as their creation, usage, and on-going maintenance. To date,
defined within a single iteration or is large enough that it can there has been little work or tools supporting the integration,
be split into smaller user stories [10]. A user story description consistency and validation between personas, user stories and
generally consists of, among other things, a statement. To be requirements engineering activities. According to [16], the
amenable to humans as well as to machines, a user story focus of software engineering tools has been to support the
statement should relate to both a persona and a goal [11]. A design and development of software, not user-centered design
persona is a description of an archetypical user of a software artifacts like personas or user stories. Therefore it is necessary
system, created based on research performed with potential for us to understand how personas and user stories can be
real users of a software system. A goal is an intended outcome integrated into software tools to ensure they help, rather than
of a persona interacting with a software system. A role is an hinder, software engineering practice.
abstraction of a persona. Personas provide the rationale for the Recently we have used motivational goal models to ef-
existence of user stories. The success of final software products fectively bridge requirements artifacts such as system goals,
is highly dependent on validations performed on users’ goals. personas and user stories during the requirements elicitation
The relationships between personas and goals are critical. and design phases of software engineering subjects at the
Personas and user stories facilitate communication and University of Melbourne. They improve communication be-
better overall understanding among stakeholders [9], [12], tween students and industry partners. To our knowledge, no
[13]. Both artefacts shift the concentration from written docu- motivational model tool has supported an automated extraction
mentation to communication. User stories are also believed to of user stories as part of their systems before. This paper
be capable of eradicating the challenge of constant updating contributes to the field by presenting a method for semi-
of requirements specification documents in traditional require- automatically generating user stories from motivational goal
ments engineering [14] by keeping team members updated. models to support readability and clarity in RE, and require-
User stories emphasise “user goals” and are generally vali- ments validation between software engineers and clients.
dated against created personas. The use of personas and user
stories briefly explain the user perception, focus on “what” III. M OTIVATIONAL M ODELS AND U SER S TORIES
is needed to be done, and support collaborative and iterative Motivational modelling emerged from agent-oriented goal
development. User stories are usefully structured into epics modelling to describe projects to non-technical stakeholders. It
which is a collection of related user stories. has been applied in diverse contexts, including space planning,
In recent years, interest in personas and in the use of brand development and strategic planning for an eCommerce
user stories has extended to the software engineering com- platform. The essence is developing a shared understanding
munities. Previous studies have identified and discussed the between diverse stakeholders in a user-centred manner. The
importance of personas and user stories in RE [13], [15]–[18]. general abstract nature of the models has been useful for
Surprisingly, however, despite several proposals for integrating software engineering students who sometimes struggle to get
personas and user stories methodologically with software en- a high-level view of a project.
Fig. 1. Greeting goal model
It is beyond the scope of the paper to discuss motivational user story is ’As a I want to so that ’.
modelling in detail. Rather this paper has a narrow scope Interpreting the roles as users gives an initial attempt to
of showing how to generate user stories from motivational generate user stories. We have extended the motivational
models. We illustrate the relationship between user stories modelling tool with an experimental feature that generates
and motivational models with two examples in which the user stories automatically. Applying the feature to the model
complexity of the models and relationships increase with each in Figure 1 results in five user stories as listed below.
example. 1) As a Greetee, Greeter or Evaluator, I want to be able to
We begin our discussion with a very simple ’low-level’ Notice
model taken from the book by Sterling and Taveter [1]. 2) As a Greetee, Greeter or Evaluator, I want to be able to
The example we choose is the ’Hello World’ of agents, an Identify
agent greeting. As this is a simple example, we believe it 3) As a Greetee, Greeter or Evaluator, I want to be able to
is easier for us to explain the links between the goal model Formulate
and user stories, without the need to provide additional details 4) As a Greetee, Greeter or Evaluator, I want to be able to
about the problem domain. A goal model for two agents Articulate
greeting is given in Section 4.6 of ’The Art of Agent-Oriented 5) As a Greetee, Greeter or Evaluator, I want to be able to
Modelling’ on p. 139. It is reproduced in Figure 1 with Evaluate
some slight modification of wording and the addition of an
The five user stories do not make complete sense as gen-
emotional goal. The model is a high level representation of a
erated by the tool. For instance, in this example, there should
greeting scenario. The greeter needs to greet the greetee by a
be a separate user story for each different role. Later in this
sequence of steps including noticing there is someone to be
paper that will not be the case. So user story 1 would be better
greeted in a timely manner, identifying the person accurately,
expanded to be three separate user stories. Here is possible
formulating an appropriate greeting, and articulating it. In the
wording.
spirit of quality control, there is an evaluator role to evaluate
the greeting. To briefly explain the notation, functional goals • As a Greeter, I want to be able to Notice the Greetee
are depicted in parallelograms, quality goals are depicted in • As a Greetee, I want to be able to be Noticed by the
clouds, emotional goals in hearts, and roles by stick figures. Greeter
This notation is used consistently throughout the paper. Note • As an Evaluator, I want to evaluate whether the Greeter
the diagram was re-drawn with our editor tool available at greets the Greetee appropriately
motivationalmodelling.com . It is an exercise for the reader to expand the other user
The idea for converting from motivational model to user stories.
stories is to consider the motivational model as a tree and We now consider quality and emotional goals. The func-
to generate a user story for each leaf. The basic form of a tional goal ’Notice’ has the quality goal ’Timely’ attached.
Fig. 2. Intruder handling goal model
An improved user story would be ’As a Greeter, I want to be • As an Intruder, I do not want to be Noticed by the
able to Notice the Greetee in a timely manner.’ User Manager
An improved version of the second user story might be ’As • As a Security Manager, I want to Identify the
a Greeter, I want to be able to Identify the Greetee accurately.’ Intruder
Note that the quality goal ’Accurate’ expressed as an adjective • As an Intruder, I do not want to be Identified
in the model reads better as an adverb ’Accurately’ in the user 2) Epic: Respond
story. In general, adjustments should be made to improve read- • As an Intruder, I do not want police to Respond
ability, and the translation process should be semi-automated • As a Security Manager, I want to Inform police
rather than automated completely. • As a Police, I want to be Informed
We now consider the intruder scenario discussed in Chapter • As a Security Manager, I want to Inform visitors
9 of ’The Art of Agent-Oriented Modelling.’ Consider Figure • As a Visitor, I want to be Informed
9.4 from the book modified slightly in Figure 2. • As a Scheduler, I want to be Informed
Note that the motivational model can be naturally divided • As a Security Manager, I want to Inform owner
into two subtrees. We introduce another translation principle. • As an Owner, I want to be Informed
Significant subtrees should be handled as separate epics. The
It is straightforward to add the quality and emotional goals.
name of the epic will typically be a node from the motivational
While simple, these two examples are indicative, we believe,
model. The experimental feature generates the following.
of how a model can be used to generate user stories. The user
1) Epic: Handle intruder stories will be followed through in design and implementation
• As a Security Manager or Intruder, I want to be able to make sure the requirements are met.
to Notice
• As a Security Manager or Intruder, I want to be able A. Software Project Example: A Goal Model for our Motiva-
to Identify tional Modelling Editor Tool
2) Epic: Respond We now consider a larger example which has emerged
• As a Security Manager, Intruder or Police, I want from our experience in using motivational modelling in our
to be able to Inform police teaching, research, and consulting activities. For reasons that
• As a Security Manager, Intruder, Visitor or Sched- are beyond the scope of the paper, we developed an initial
uler, I want to be able to Inform visitors motivational model of our overall activities around moti-
• As a Security Manager, Intruder or Owner, I want vational modelling. Part of the model was used to direct
to be able to Inform owner teams of University of Melbourne students who have been
maintaining and extending the motivational modelling editing
A better version separates the roles. Here is an updated
tool in software project subjects.
version with greatere detail about the scenario.
The overall model is presented in Figure 3. Rather than
1) Epic: Handle intruder explaining the model directly, we present user stories that
• As a Security Manager, I want to Notice the Intruder could be derived from the model. Note that the effort to think
Fig. 3. Motivational Model goal model
about user stories related to the model improved the model, ∗ As a Student, Intern or Software engineer, I want
which has been through several iterations, as is expected. to be able to extend the MM tool
The model has three subtrees which will be the three major ∗ As a Student, Intern or Software engineer, I want
epics: Promote, Research and Improve MM Editor tool. We to be able to test by system testing
discuss each epic in turn. Promote is the simplest epic, contain- ∗ As a Student, Intern or Software engineer, I want
ing two user stories, one concerning demonstration to industry, to be able to test by regression testing
and one concerning demonstration to academia. Promotional ∗ As a Student, Intern or Software engineer, I want
activities to industry are a little different than promotional to be able to maintain by corrective maintenance
activities to academia, so it makes sense to separate the user ∗ As a Student, Intern or Software engineer, I want
stories. Further, the reporting on the promotional activities will to be able to maintain by perfective maintenance
be different. Ensuring that the user stories would be simple and
direct affected how the motivational model was built. IV. C ONCLUSIONS
We next briefly discuss the Research epic. We have gener- We have described a method to generate user stories from
ated three user stories in this epic. The user stories correspond motivational models. The generated stories are checked by
to conducting surveys about the use of motivational modelling, users and developers to ensure readability and clarity. Such
conducting interviews with students, staff and other users, and checking retains the feeling of user centred development. The
analysing the data from the surveys and interviews. Again it method discussed in this paper has been partially automated
was helpful to think about a simple form for the model and within an extension to the motivational modelling editing tool.
the user stories. Future extensions being considered include the integration
The third epic concerns the motivational modelling tool that of a motivational modelling editing tool with Canvas LMS.
is being used extensively for workshops and consulting, and Users will also be able to upload personas, user stories and
also being used for internships and student projects at the epics (text) to the tool, which will convert them into a goal
University of Melbourne. The tool is also being maintained model. Future studies should focus on further examining the
at work.motivationalmodelling.com outside the university sec- impact of user stories generated from goal models on require-
tor. There are five user stories as to the software covering ments quality and on communication between stakeholders.
respectively: overall extension of the tool, regression testing,
overall system testing, corrective maintenance (i.e. fixing bugs) ACKNOWLEDGEMENTS
and perfective maintenance, namely improving features. An
The authors would like to thank the teaching staff and
example of the latter is automatic sizing of nodes to fit the
students doing the Software Engineering subjects at the Uni-
text in the goals. An example of a tool extension is the ability
versity of Melbourne who have contributed to the ideas of the
to colour nodes. Both of those examples have been developed
paper. The work also acknowledges discussions with members
in student projects, and are in the process of being more
of the Future Self and Design Living Lab at Swinburne
consistently tested and deployed.
University of Technology. The work was partially supported
A list of the user stories discussed is given here. Note
by ARC Discovery grant DP200102955, ‘Maturing design-led
that these user stories are suitable to be placed on a Kanban
innovation processes with motivational models’.
board for agile development. In fact they have been. Clearly
these user stories are reasonably abstract, but they provide a R EFERENCES
high level overview of the work being done by the various
[1] L. Sterling and K. Taveter, The art of agent-oriented modeling. MIT
people involved with motivational modelling including the Press, 2009.
authors. As reasonably abstract, they capture the flavour of [2] A. Lopez-Lorca, R. Burrows, and L. Sterling, “Teaching motivational
user centred development. They clearly can be refined further models in agile requirements engineering,” in Proceedings of the Re-
quirements in Education and Training workshop at RE’18, 2018.
as developments occur.
[3] E. Oliveira and L. Sterling, “Motivational models for validating agile
• User Stories about Motivational Modelling requirements in software engineering subjects,” in Proceedings of the
19th International Conference on Software Engineering Research and
– Epic: Promote Practice, SERP’21, July 26-29, 2021, Las Vegas, Nevada, USA, 2021.
∗ As Owner, I want to be able to demonstrate to [4] E.-M. Schön, J. Thomaschewski, and M. J. Escalona, “Agile require-
industry ments engineering: A systematic literature review,” Computer Standards
& Interfaces, vol. 49, pp. 79–91, 2017.
∗ As Owner, I want to be able to demonstrate to [5] I. Inayat, S. S. Salim, S. Marczak, M. Daneva, and S. Shamshirband, “A
academia systematic literature review on agile requirements engineering practices
and challenges,” Computers in human behavior, vol. 51, pp. 915–929,
– Epic: Research 2015.
∗ As a Researcher, I want to be able to collect data [6] J. M. Bhat, M. Gupta, and S. N. Murthy, “Overcoming requirements
engineering challenges: Lessons from offshore outsourcing,” IEEE soft-
by survey ware, vol. 23, no. 5, pp. 38–44, 2006.
∗ As a Researcher, I want to be able to collect data [7] E. A. Oliveira, “i-collaboration 3.0: um framework de apoio ao de-
by interview senvolvimento de ambientes distribuı́dos de aprendizagem sensı́veis ao
contexto,” 2013.
∗ As a Researcher, I want to be able to analyze data
[8] L. Cao and B. Ramesh, “Agile requirements engineering practices: An
– Epic: Improve MMTool empirical study,” IEEE software, vol. 25, no. 1, pp. 60–67, 2008.
[9] M. Daneva, E. Van Der Veen, C. Amrit, S. Ghaisas, K. Sikkel, R. Kumar,
N. Ajmeri, U. Ramteerthkar, and R. Wieringa, “Agile requirements
prioritization in large-scale outsourced system projects: An empirical
study,” Journal of systems and software, vol. 86, no. 5, pp. 1333–1353,
2013.
[10] M. Cohn, User stories applied: For agile software development.
Addison-Wesley Professional, 2004.
[11] P. Kamthan, “Using personas to support the goals in user stories,” in
2015 12th International Conference on Information Technology-New
Generations. IEEE, 2015, pp. 770–770.
[12] J. K. Blomkvist, J. Persson, and J. Åberg, “Communication through
boundary objects in distributed agile teams,” in Proceedings of the 33rd
Annual ACM Conference on Human Factors in Computing Systems,
2015, pp. 1875–1884.
[13] T. Tenso, A. H. Norta, H. Rootsi, K. Taveter, and I. Vorontsova,
“Enhancing requirements engineering in agile methodologies by agent-
oriented goal models: Two empirical case studies,” in 2017 IEEE 25th
International Requirements Engineering Conference Workshops (REW).
IEEE, 2017, pp. 268–275.
[14] E. Bjarnason, K. Wnuk, and B. Regnell, “A case study on benefits and
side-effects of agile practices in large-scale requirements engineering,”
in proceedings of the 1st workshop on agile requirements engineering,
2011, pp. 1–5.
[15] A. Dittmar and P. Forbrig, “Integrating personas and use case models,”
in IFIP Conference on Human-Computer Interaction. Springer, 2019,
pp. 666–686.
[16] S. Faily and J. Lyle, “Guidelines for integrating personas into software
engineering tools,” in Proceedings of the 5th ACM SIGCHI symposium
on Engineering interactive computing systems, 2013, pp. 69–74.
[17] L. Schneidewind, S. Hörold, C. Mayas, H. Krömker, S. Falke, and
T. Pucklitsch, “How personas support requirements engineering,” in
2012 First International Workshop on Usability and Accessibility Fo-
cused Requirements Engineering (UsARE). IEEE, 2012, pp. 1–5.
[18] B. Ferreira, W. Silva, E. Oliveira, and T. Conte, “Designing personas
with empathy map.” in SEKE, vol. 152, 2015.
[19] J. W. Castro, S. T. Acuña, and N. Juristo, “Integrating the personas
technique into the requirements analysis activity,” in 2008 Mexican
International Conference on Computer Science. IEEE, 2008, pp. 104–
112.