The Monopoly Game to Teach ERi*c - Intentional Requirements Engineering

Abstract

Intentional Requirements Engineering (The ERi*c - Engenharia de Requisitos Intencional) is a GORE method under evolution. After the first publication of ERi*c, in March/2008, the method has received several changes in order to mitigate the complexity of tasks and artifacts. ERi*c follows the i-star Framework and NFR Framework ideas and consequently deals with actors, goals, softgoals, tasks and resources. Although the most laborious parts of the method have been facilitated by three tools (LEL, AGFL and iStar Diagnoses, as well as OME, used in modelling), we realized that students in an undergraduate software engineering course needed an incentive in the introduction of the new concepts in order to improve their understanding of what intentionality means in the context of requirements for a software project. It was necessary to find a way to keep students motivated and at the same time to tame the new concepts and consequently help their understanding. In this context, we explore the idea of using a game based learning strategy (GBL) as the motivational factor. We decided to adapt the Monopoly game to help teaching the ERi*c method to be used as a motivational factor. This article shows how the concepts were prepared and what was included in the game to teach ERi*c to UERJ's undergraduate students.

Keywords

• Game Based Learning
• Requirements Engineering
• iStar
• ERi*c Method

-

have realized that students needed something attractive and easy to break the first impact of the new subject.

The idea of adapting “The Monopoly Game” to teach The ERi*c as well as iStar concepts seems a good approach for motivating the students and breaking the communication barrier of shifting from the usual function-oriented perspective to the goal oriented one. Early work performed by some of us [ 8 ] and in the context of requirements engineering [ 9 ] was an inspiration for the use of Monopoly as the main infrastructure to the “ERi*cOpoly” game. A first design decision for the game was to address the modeling concepts of the iStar and NFR [ 3 ] languages. The organization of this paper is as follows: Section 2 briefly describes the Intentional RE Method; Section 3 explains the concepts (called properties in the “ERi*cOpoly” game) of Intentional RE and iStar concepts which are covered in this part of the ERi*cOpoly and presents our proposal: the ERi*cOpoly game; Section 4 gives a research bibliographical retrospective; and finally Section 5 concludes and points out some future customization works and research issues.

2 Intentional RE Method

The method provides a set of procedures, organized as steps in order to guide the construction of iStar models. The steps use the following main RE activities: elicitation, modeling and analysis. Elicitation means understanding the contextual knowledge and discovering the software requirements. Modeling means describing requirements. Analysis means verifying and validating the produced models.

The first step “Elicit Actors’ Goals” captures goals pushing the elicitation towards intentionality. This step is composed of three stages: identify goals, separate them by actors, and organize goals in a “chronological order”. This step uses the Language Extended Lexicon (LEL) [ 4 ] as an anchor since LEL facilitates the comprehension of contextual terminology.

In the second step, “Identify SDsituations” we want to define implement situations of dependency called SDsituations – Strategic Dependency Situations [ 6 ]. An SDsituation can be characterized as part of the business unit. In order to do that, the requirements engineer identifies goals (and softgoals) arrangements that are connected.

In the third step, “Model Agent Goals” the requirements engineer builds diagrams, using a language similar to state charts that considers actors/agents, in order to represent chains of goals (and softgoals) relationships. The diagrams called “INTENTIONALITY PANELS” should be drawn in parts based in SDsituations, and they are a simpler view of iStar SR model.

In the fourth step, “Model Actors’ Goals Rationale” the RE team refines softgoals using Softgoal Interdependency Graphs (SIG) models and builds SD and SR models.

In the fifth step, “Specify SDsituations” the RE team describes SDsituations applying a Scenarios [ 5 ] based strategy. This step is supported by the tool software C&L1 which is a management tool for Lexicons and Scenarios. 1 C&L is an open source developed by the Requirements Engineering Group at PUC-Rio being available at http://pes.inf.puc-rio.br/cel/.

In the sixth step, “Analyse SD and SR Models” the RE team and the stakeholders analyse the models supported by a diagnoses process and create a report matching the discovered problems with impacted goals. The iStar Diagnoses [ 13 ] examines each of the models in every SDsituation in order to bring questions that challenge the model’s consistency and completeness.

3 The ERi*cOpoly game (iStar’s SD and SR models and NFR)

The ERi*cOpoly explores iStar concepts [ 14 ], which are described using Table 1 to show how the elements (cards) are used in the game without the board. Each colored card has its value according to the value of the property (concept).

SET Red (M 3) Light green (M 2) Black (M 2) Yellow (M 3) Brown (M 1) Blue (M 1) Dark blue (M 4) Green (M 4) Orange (M 2) Purple (M 2)

Table 1 – The ERi*cOpoly - sets of concepts considered in Property Cards.

CONCEPT PROPERTY DESCRIPTION STANDARD #1 qoubjaelictty+atBtrEibu+teve+rb[oinbjepcatsosirvteasvkoiacse topic] sgoofatgloal STANDARD #2 vnearmbeinoifntfhineitoivbeje+ctobject traesskource goal “ascthaiteevse”of affairs that an actor plans to “the criteria for the condition being THE FOUR KINDS OF softgoal achieved is not sharply defined a priori DEPENDENCIES and is subject to interpretation” task “ssopmeectifhi einsg” a particular way of doing resource “an entity physical or informational” dependee the actor on who the depender depends ACTOR’S POSITIONS depender tdheepeancdteoer who is depended upon the dependum rTehlaetioobnjsehcitpacreonutnredswhich the dependency SD MODEL lninokde adcetpoerndency

positions bAetpwoeseitnioan riosleinatnedrmaendaiagteentin. abstraction SA MODEL (actors) roles tAherobleehiasviaonr oafbastsroaccitalcahcatroarc.terization of agents pAhnysaicgaelnmt anisifeastnatioancsto. r with concrete iStar IGnoteanl toiorineanlitteyd approach IsaSntnortedacntiaaetlifgoteincraapclitrtooyrcseisssadrrieesdtreibvsuiiegtwendedboaths bbeef oinreg STRATEGIC DEPENDENCY SR MODEL 1 SR MODEL 2

There is always a depender’s goal to be achieved Depender believes that dependee is able to carry on the commitment Dependee has a commitment with the depender SR model has softgoals contribution SR model has Task decomposition SR model has means-end strategic dependencies among actors a) b) c) a) b) c)

Softgoal-Softgoal Contribution Task-Softgoal Contribution Task Decomposition Task-Task Link Task-Resource Link Task-Goal Link

There are a total of 105 cards (106 in Monopoly) in the ERi*cOpoly Deal Deck of the following types: PROPERTY CARDS, ACTION CARDS, MONEY CARDS, PROPERTY WILDCARDS, and RENT CARDS. Only one card has been taken out from the original deck because there is one property less in The ERi*cOpoly.

There are 27 PROPERTY CARDS in the Deal Deck amongst which there are 10 different colored sets (see Table 1). Figure 1 shows images of sets of PROPERTY CARDS and shows examples of ACTION CARDS, PROPERTY WILDCARDS, RENT CARDS and MONEY CARDS.

There are a total of 20 MONEY CARDS in the ERi*cOpoly Deal Deck, M57 Money in total, which include: one M10m money card, two M5m money cards, three M4m money cards, three M3m money cards, five M2m money cards, and six M1m money cards.

There are a total of 34 ACTION CARDS in the ERi*cOpoly Deal Deck, which include: 2 Deal Breaker, 2 Double the rent, 3 Just Say No, 3 Sly Deal, 3 Force Deal, 3 Debt Collector, 3 It is My Birthday, 10 Pass Go, 3 House, and 2 Hotel.

There are a total of 11 PROPERTY WILCARDS in the ERi*cOpoly Deal Deck, 9 two color wildcards (2 Purple and Orange, 2 Red and Yellow, 1 Light Blue and Brown, 1 Light Blue and Black, 1 Light Green and Black, 1 Dark Blue and Green and 1 Green and Black) and 2 ten multi-color wildcards.

There are a total of 13 RENT CARDS in the ERi*cOpoly Deal Deck, 11 two color Rent cards (2 Purple and Orange Rent cards, 2 Black and Light Green Rent cards, 3 Green and Dark Blue Rent cards, 2 Brown and Light Blue Rent cards, and 2 Red and Yellow Rent cards) and 2 ten color wild Rent cards.

The aim of the game is to be the first player to collect (and lay out) three full sets of different colored properties (iStar intentionality concepts). The major rule, differently from the original Monopoly, is: “The player must describe, using his own words, the meaning of each concept”.

Below we describe the basic rules to start the game and the essential rules. Basic Start Rules:

GET READY: Shuffle all the cards and deal 5 to each player. The youngest player starts to play and it continues clockwise.

PLAY on your turn: (1) Take 2 cards from the draw pile. (2) Lay out 3 cards from your hand. Put them face-up in front of you in any combination of the following ways: (a) Put money or actions cards into your bank pile (the value of an action card, when used as money, is shown in the corner). (b) Lay a property card, displaced faceup in front of you, never in your back. (c) Play an action card (a card with a red ring). Follow the instructions on the card and play into the center. TIP: Always keep a wellstocked bank. You never know when you will have to pay out! (3) Ending your turn: If you have more than 7 cards on your hand, at the end of your turn, discard the extras cards, so you are back down to 7. If you have no cards left, pick up 5 (not 2) from the center of the pile at the start of your next turn.

ESSENTIAL RULES: (i) Never put cards back into your hand. (ii) Paying other players: (a) DO NOT PAY WITH CARD FROM YOUR HAND; you can only pay using the cards you have laid in front of you. (b) CHANGE IS NOT GIVEN; i.e. if the rent is M2m and you only have M5m, you get nothing back. (c) IF YOU DON’T HAVE ENOUGH MONEY IN YOUR BANK, pay with your properties. (d) IF YOU DO NOT HAVE PROPERTIES OR MONEY IN FRONT OF YOU, leave the game. (iii) Wildcards: Wildcards act as properties cards of that color. If you acquire the property you need, you can replace the wildcard and re-use it elsewhere.

For the subject, pupils can improve their style and the game becomes interesting because they can use several strategies and so the repetition of the game was not considered boring. An example of a possible strategy would be “Try to avoid creating full sets for as long as possible unless you have at least one Just Say No card”. Even with a Just Say No card, your full set is not 100% safe.

4 Bibliographical Retrospective

A systematic review of computer and serious games shows that computer games can be considered a motivation impact for learning environment [ 10 ]. In the literature of GBL specific for Software Engineering [ 11 ] we can find reports that games can simulate situations and problems that happen all the time in real business projects and also to bring entertainment in a learning environment that facilitates students to acquire knowledge from a subject.

The board game named RE-O-Poly [ 9 ] introduces and reinforces RE good practices in general and the board is composed by RE activities (Elicitation, Analysis and Validation, Documentation, and Change Management). The game is a board game arranged as in the game Monopoly, but the four sides of the board were modified to reflect an RE context. Like Monopoly, a player moves by the roll of the dice. There is a circuit around the board which represents one pass through a typical RE process for three types of projects: a basic, average and complex. The player with the highest Stakeholder Satisfaction Points (scored for the project) and with the correct challenges tabulated wins the game.

5 Conclusions

This experience of teaching iStar demonstrated that most pupils enjoyed the very first game prototype and got acquainted with the concepts in two rounds playing.

We are just finishing the redesign of the game, and after that, we are planning an experiment using the game with UERJ undergraduate students. At first, we are going to use Master’s students to test the game and refine the ERi*cOpoly interface. The undergraduate students will use the ERi*cOpoly with different strategies. The objective is to validate the game and give an idea if the game helps the student to understand ERi*c. One of the design features we are really beating on is the cast of concepts as properties; at least they should be memorized quickly. One important objective of this research is based primarily on the point that iStar is an excellent approach to deal with intentionality, but iStar is not easy to learn.

It is important to say that this research problem should apply a PDCA technic for improving the teaching process and we agree with “map and track the effectiveness of the game as a training tool with other real world RE applications objective” [ 9 ].

To support the use of ERi*cOpoly as a teaching tool we plan to implement a web software game supporting all feedbacks received from the first trials. We are also planning to bring the method part, the ERi*c itself, to be part of the game, but this will happen after the trials with the redesign of the actual version. Experiments will be conducted on the same way as performed by [ 12 ], comparing groups using the game and groups without game playing with respect to their learning performance, while replicating this experiment using the ERi*cOpoly game prototype.

References

1. Yu , E. Modelling Strategic Relationships for Process Reengineering . PhD Thesis , Graduate Department of Computer Science, University of Toronto, Toronto, Canada - 1995 .

2. Oliveira , A . Padua; Leite, Julio C. S. P. ; Cysneiros , L. M. ; “ERi*c Method - Intentional Requirements Engineering”; The XI Workshop on Requirements Engineering; Barcelona, Spain - July/ 2008 .

3. Chung , L. ; Nixon , B. ; Yu , E. ; Mylopoulos , J. ; Non-Functional Requirements in Software Engineering - Kluwer Academic Publishers 2000 - Massachusetts, USA.

4. Leite , Julio C. S. P. ; Franco, Ana P. M. A Client Strategy for Conceptual Model Acquisition , Proceedings of the International Symposium on Requirements Engineering , IEEE Computer Society Press, San Diego ( 1993 ), pp. 243 - 246 .

5. Leite , J.C.S.P. , Hadad , G. , Doorn , J. , Kaplan , G. A Scenario Construction Process - RE Journal : Vol. 5 , N. 1, Pags . 38 - 61 , ( 2000 ), Springer-Verlag London Limited.

6. Oliveira , A. Padua A. ; Cysneiros , L. M. ; “Defining Strategic Dependency Situations in Requirements Elicitation” The IX Workshop on Requirements Engineering; Rio de Janeiro, Brazil - July/ 2006 .

7. Pastor , Oscar; Estrada, Hugo; Martínez, Alicia; The strengths and weaknesses of the i* framework: an experimental evaluation . In: Social Modeling for Requirements Engineering. Cooperative Information Systems series. Eric Yu et al. (eds.) MIT Press, Cambridge ( 2011 ).

8. Monsalve , E. S. ; Werneck , V. ; Leite , J. ; Teaching software engineering with SimulES-W . In: Software Engineering Education and Training (CSEE&T) , 2011 , Honolulu. Proceedings of the 24th IEEE-CS Conference on Software Engineering Education and Training (CSEE&T) , 2011 . v. 24 .

9. R. Smith , O. Gotel. RE-O-Poly : A Customizable Game to Introduce and Reinforce Requirements Engineering Good Practices, The Michael L . Gargano, 7th Annual Research Day, Pace University, May 8th, 2009 (http://csis.pace.edu/~ctappert/srd2009/b4.pdf)

10. Connolly , T. , Boyle , E. , MacArthur , E., Hainey , T. & Boyle , J. ( 2012 ). A systematic literature review of empirical evidence on computer games and serious games . Computers & Education 59 ( 2 ).

11. Boyle , E. , Connolly , T.M , Hainey , T. , Hancock , F. & Boyle , J. ( 2012 ). Engagement in digital entertainment games: A systematic review . Computers in Human Behavior 28 ( 3 ), 771 - 780 .

12. Monsalve , E.S. ; Leite , J.C.S.P. ; Werneck , V.M.B. , Transparently Teaching in the Context of Gamebased Learning: the Case of SimulES-W, Joint SE Education and Training Track ICSE 2015 (The 37th International Conference on Software Engineering) , Florence, 2015 .

13. Oliveira , Padua A.; Leite , J. ; Cysneiros , L. , Lucena , C.; i* Diagnoses: A Quality Process for Building i * Models pp. 9 - 12 , CAiSE'08 Forum Proceedings of the Forum at the CAiSE'08 conference , p. 9 - 12

14. Oliveira , Padua A.; Leite , J. ; Cysneiros , L. ( 2010 ) Using i* Meta Modeling for Verifying i* Models . In: iStar 2010 4th International i* Workshop , Hammamet, Tunisia. CEUR - Workshop Proceedings . Aachen : rwth-aachen, 2010 . v. 586 . p. 76 - 80 .