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.