A problem-oriented, social modeling framework, iStar provides the possibility to capture intentions of stakeholders in an early phase of a requirements 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. Experiences from both group projects and course examinations are presented, as well as used to discuss lessons learned.
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 [
Since its beginning, the course has attracted a remarkable number of students, 70100 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.
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 [
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. 2
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. 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. 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 (STIM) and Computer and Systems Sciences (CSS)—are directed towards information systems, whereas the three degrees represented within the Bachelor’s— Computer and Systems Sciences (CSS), Economics and Informatics (INFO) and Interaction 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 Informatics). A common requirement for all students in the Department’s Bachelor’s programs is an introductory course to object-oriented programming that has an extensive 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.
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 [
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 [
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 [
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. 3.2
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 [
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, dependencies, 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). 4
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.