1st International iStar Teaching Workshop (iStarT 2015) iStar Instruction in Mixed Student Cohort Environments Eric-Oluf Svee, Jelena Zdravkovic Stockholm University, Department of Computer and Systems Sciences, Box 7003, SE-16407 Kista, Sweden {eric-sve, jelenaz}@dsv.su.se Abstract A problem-oriented, social modeling framework, iStar provides the possibility to capture intentions of stakeholders in an early phase of a require- ments engineering process, in contrast to more system-oriented techniques such as UML. In addition to its ability to work with multiple levels of abstraction, the richness of iStar notation makes it as an important framework to instruct students from a wide variety of degree programs and technical backgrounds in requirements engineering. In this paper we present examples used to instruct various cohorts found through teaching six years of bachelor’s and master’s level requirements engineering courses: approximately 1200 students. Experi- ences from both group projects and course examinations are presented, as well as used to discuss lessons learned. Keywords: Requirements Engineering, Social Modeling, iStar 1 Introduction A course on the topic of Requirements Engineering at the Department for Computer and Systems Sciences was first developed and presented at the master level in 2008 by Jelena Zdravkovic. During the first years the course was given at both Stockholm University [1] and KTH [2] when the department was a joint administrative and edu- cation unit of the two universities. In 2010 a strategic decision was taken to orient KTH towards software engineering, and Stockholm University to systems analysis. Based on this, the latter university took over complete management for the course. Since its beginning, the course has attracted a remarkable number of students, 70- 100 in each of its variants. Therefore, Stockholm University decided to, from 2009, include a bachelor-level course on the same topic. Hence the curriculum of the origi- nal course has been changed and split to accommodate to a) the second year of the Bachelor level studies at the department and serving several degree programs, under the name “Requirements Engineering” (KRAV) and presented in Swedish, and b) as a mandatory course in the Master’s of System Sciences, as well as an elective course for the other master’s programs at the department. This course was named “Advanced Requirements Engineering” (REQ) with English as the language of instruction. At the present time, REQ continues to attract 70-100 students, while 100-150 attend KRAV. Both courses are structured with a theoretical component, which is supported by a project where students practice the RE process on a problem example while develop- ing their results in an RE software tool, and completed by a written exam. 19 Both courses cover the topic of Goal-Oriented Requirements Engineering. The top- ic is motivated by a need to explicitly consider stakeholders’ intentions during the requirements engineering process, and to make use of goal models for documenting such intentions. In the courses’ early days, goal modeling was presented to students through AND/OR goal decomposition, while later the BMM [3] and iStar [4] model- ing languages were included in the curriculum for the GORE part; in KRAV, the knowledge of the BMM technique has been the only mandatory requirement so far, while for the REQ course, both languages are included as mandatory topics. In this paper the aim is to, in a concise way, report our experiences in teaching, practicing, and examining the iStar goal modeling technique to these cohorts of stu- dents. The paper is organized as following: in §2 a general breakdown of the courses’ populations is provided. §3 is organized to present the three main aspects of the course: teaching (§3.1), project (§3.2), and examination (§3.3). §4 concludes the study and provides directions of further work. 2 Course population Two courses are offered, one at the Bachelor’s level (KRAV), and another at the Mas- ter’s (REQ). A population breakdown is provided in Tables 1 and 2. Table 1. Bachelor’s Degree Programs, by year, with cohort population Bachelor’s of Arts in... 2014 2013 2012 Interaction Design 33 44 44 Economics and Informatics 37 49 46 Computer and Systems Sciences 23 18 16 Undeclared 54 58 60 Table 2. Master’s Degree Programs, by year, with cohort population Master’s of Arts in... 2014 2013 2012 Business Management/Information Systems 25 19 16 Strategic IT Management 4 18 4 Computer and Systems Sciences 32 18 30 The course sizes are consistent over time, ranging from with 216 in 2012, 224 in 2013, and 208 in 2014. Participant population sizes within each degree program have also been consistent, although a quadrupling in Master’s in Strategic IT Management in 2013 was the result of a temporary change in the program’s requirements. 2.1 Differences in degree cohorts The largest difference between the Bachelor’s and Master’s courses is the IT focus of the constituting degree programs. The three degrees represented within the Mas- ter’s—Business Management/Information Systems (BMIT), Strategic IT Management 20 (STIM) and Computer and Systems Sciences (CSS)—are directed towards infor- mation systems, whereas the three degrees represented within the Bachelor’s— Computer and Systems Sciences (CSS), Economics and Informatics (INFO) and In- teraction Design (ID)—have diverse foci. Indeed, although all students are enrolled in the Department of Computer and Systems Science, and therefore some assumptions can be made about their general degree, fully 40% of each Bachelor’s cohort falls outside the three degrees in yet more diverse areas (e.g., Game Design, Medical In- formatics). A common requirement for all students in the Department’s Bachelor’s programs is an introductory course to object-oriented programming that has an exten- sive modeling component. Figure 1 shows a composite of the Bachelor’s degree cohorts between 2012-2014. The percentages of each degree cohort are also shown in the legend. Fig. 1. Composite of Bachelor’s degree cohorts, 2012-2014 3 Experiences 3.1 Curriculum and Teaching In both KRAV and REQ courses, the Requirements Engineering (RE) topic is intro- duced to the students as playing a fundamental role within the systems development process. In REQ, the GORE topic is included in Learning Goal 4 (“Explain advanced procedures, methods, and concepts for performing RE.”) relating to advanced meth- ods and concepts for RE, as well as in Learning Goal 5 (“Create requirements ac- cording to the RE process using an IT tool for RE.”) concerning the practice of the RE process using IBM Rational Requisite Pro tool. The course books in use are [5] and [6]. In the instructional component of GORE, REQ students are, in addition to the fun- damentals of goal orientation for RE (such as definitions of the main concepts, AND/OR de-composition, goal dependencies), introduced detail to two modeling languages, i.e. BMM [3] and iStar [4]. Both are presented for the use of capturing business/organizational goals of stakeholders, which can be further refined to the level of system-related goals, either functional or non-functional. Since the iStar technique is considered more comprehensive than BMM both in its scope and notation, the first is lectured twice as long during the teaching part (i.e. 3-4 21 hours of instruction), and it is easily observed during individual supervision times that the iStar technique requires significantly more learning to understand the technique and drawing its models than the same task done in BMM. As for the teaching material, both iStar and BMM are easily accessible to students. As for iStar, a fine summary is available in one of the course books [6], while the main material is provided through i* Wiki portal [4]. Regarding the learning activities and possibilities, in addition to scheduled direct supervision times, the course relies on an electronic course portal to disseminate all course information and materials, while also providing online communication (dis- cussion and questions) either between the teacher and students, or student-to-student. It is also easy possible to upload, share, and discuss good examples of iStar models. 3.2 Project In the course project, two two-person groups work jointly on two predefined case scenarios. One group plays the stakeholder role for one case, and the requirements engineer role for the case of the partner group. Each group uses IBM Requisite Pro to create a requirements specification for their partner group’s scenario. Students can choose how to model their requirements, although for the Bachelor’s students, iStar is offered as a bonus lecture rather than as a part of the course. Typical- ly better students choose iStar as a higher “knowledge challenge”. Many students in the Interaction Design (ID) program show initial interest in learning iStar but ulti- mately choose not to use it in their projects. The estimated iStar adoption on the pro- jects is 5%, almost exclusively from ID students (historically the largest group attend- ing the bonus lecture on iStar). RequisitePro does not natively support iStar, and hence the students use MS Visio and attach the .vsd to the Requisite Pro project. Overall this works fine, although the students do have problem navigating the iStar wiki [4] and over time, we have decid- ed to simply provide the stencil directly via the course portal. 3.3 Examination The written exam includes a short, half-page description of an imaginary business case (such as “catering”) followed by a number of questions where some refer to the use of the case. As for the question about GORE and iStar in particular, it may in- clude the following sub-questions: 1. Compare the qualities of iStar and BMM in a table, where the two techniques will be the rows, and the columns you will create upon what you find as important characteristics of goal modeling. 2. Using the iStar technique, draw SDM and SRM models which will realize the fol- lowing business goal for the Catering case: "The catering company should provide flexible* service to customers" *think about “flexible” as able to easily respond to different needs and desires of customers. From the obtained SRM model, elicit new 22 stakeholder requirements for the Web-based system of the company, or map to ex- isting ones. As for the first sub-question, a majority of students easily observe the main differ- ences in the notation between the two techniques. For example, that iStar includes resources, dependencies, soft-goals, while BMM supports influencers. Some answers include higher-level conclusions on the differences, such as in Figure 2: Fig. 2. An example of the answer to sub-question 1, from a student exam As for the model drawing, given limited time—the exam lasts for 4 hours, and con- sists of 6 questions, each including 3 sub-questions—almost all students answering the GORE question succeed to draw a SRM model for the required goal. One example is shown in Figure 3: Fig. 3. An example of the iStar model for sub-question 2. In the examination of the model we find as the most important a correct understand- ing of the iStar notation and its capabilities: capturing multi-actor perspective, de- 23 pendencies, and resources, with goals and tasks seeming to be the simplest for identi- fication. Alternately we often observe difficulties for students are: - A correct understanding of SDM, i.e. that it solely focuses on an external per- spective of the included actors, i.e. on their dependencies; in other words stu- dents do not correctly understand a complementary relationship between SDM and SRM models. - An understanding to whom in a multi-actor environment to set focus in model- ing; i.e. often students “over-model” the customer/actor (i.e. non-system relat- ed one) filling it with a number of tasks, instead of, through the use of depend- ency links, set focus on the system actor (often represented by students as “company”). - A correct use of directions of dependency links (for tasks, resources, and goals). 4 Conclusions In this paper we have reported the experiences of using iStar within requirements engineering courses taught at a Swedish university to approximately 1200 students. Overall experiences lead us to conclude that iStar is understandable but fails to gain traction among the students. In particular, students with little modeling background within the Interaction Design program have shown resistance to iStar, contradicting our hypothesis that they would be receptive to it due to its visual nature. Regarding future work, developing mechanisms to share experiences with other teachers is important, and the iStarT workshop is a good first step. It would also be interesting to study the motivations behind the resistance of less technical and more design oriented people to using iStar, with many instead choosing methods such as BMM. One issue for future discussion is which tool can be the most appropriate to cover both iStar modeling as its further relation to requirements, as well as requirements elicitation, analysis, etc. References 1. REQ Course at Stockholm University: https://wiki.dsv.su.se/valbara/REQ 2. IV2032 Requirements Engineering, a 7.5 credits course on Systems Science http://www.kth.se/student/kurser/kurs/IV2032?l=en 3. Business Motivation Model, http://www.omg.org/spec/BMM/, last accessed 2015-Apr-15. 4. i* Wiki, http://istar.rwth-aachen.de/tiki-view_articles.php, last accessed 2015-Apr-15. 5. Sommerville, I., & Kotonya, G. (1998). Requirements engineering: processes and tech- niques. John Wiley & Sons, Inc. 6. Pohl, K. (2010). Requirements engineering: fundamentals, principles, and techniques. Springer Publishing Company, Incorporated. 24