=Paper=
{{Paper
|id=Vol-1370/paper_4
|storemode=property
|title=iStar Instruction in Mixed Student Cohort Environments
|pdfUrl=https://ceur-ws.org/Vol-1370/paper_4.pdf
|volume=Vol-1370
|dblpUrl=https://dblp.org/rec/conf/caise/SveeZ15a
}}
==iStar Instruction in Mixed Student Cohort Environments==
https://ceur-ws.org/Vol-1370/paper_4.pdf
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