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 education 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 original 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 developing their results in an RE software tool, and completed by a written exam.
1st International iStar Teaching Workshop (iStarT 2015)
Both courses cover the topic of Goal-Oriented Requirements Engineering. The topic 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] modeling 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 students.
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.
Two courses are offered, one at the Bachelor's level (KRAV), and another at the Master's (REQ). A population breakdown is provided in Tables 1 and 2.
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 Master's-Business Management/Information Systems (BMIT), Strategic IT Management 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.
In both KRAV and REQ courses, the Requirements Engineering (RE) topic is introduced 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 methods and concepts for RE, as well as in Learning Goal 5 ("Create requirements according 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 fundamentals 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 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 (discussion 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.
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. Typically better students choose iStar as a higher "knowledge challenge". Many students in the Interaction Design (ID) program show initial interest in learning iStar but ultimately choose not to use it in their projects. The estimated iStar adoption on the projects is 5%, almost exclusively from ID students (historically the largest group attending 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 decided to simply provide the stencil directly via the course portal.
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 include 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 following 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 stakeholder requirements for the Web-based system of the company, or map to existing ones. As for the first sub-question, a majority of students easily observe the main differences 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: As for the model drawing, given limited time-the exam lasts for 4 hours, and consists 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: In the examination of the model we find as the most important a correct understanding of the iStar notation and its capabilities: capturing multi-actor perspective, de-pendencies, and resources, with goals and tasks seeming to be the simplest for identification. Alternately we often observe difficulties for students are:
-A correct understanding of SDM, i.e. that it solely focuses on an external perspective of the included actors, i.e. on their dependencies; in other words students 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 modeling; i.e. often students "over-model" the customer/actor (i.e. non-system related one) filling it with a number of tasks, instead of, through the use of dependency 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).
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.