=Paper=
{{Paper
|id=Vol-1217/paper1
|storemode=property
|title=Using Non-Profit Partners to Engage Students in RE
|pdfUrl=https://ceur-ws.org/Vol-1217/paper1.pdf
|volume=Vol-1217
|dblpUrl=https://dblp.org/rec/conf/re/PenzenstadlerRKCCW14
}}
==Using Non-Profit Partners to Engage Students in RE==
https://ceur-ws.org/Vol-1217/paper1.pdf
Using Non-Profit Partners to Engage Students in RE
Birgit Penzenstadler, Debra Richardson Beth Karlin Allison Cook
School of Computer and Information Sciences School of Social Ecology Story of Stuff Project
University of California, Irvine, CA, USA University of California, Irvine, CA, USA Berkeley, CA, 94709, USA
bpenzens@uci.edu bkarlin@uci.edu allison@storyofstuff.org
David Callele Krzysztof Wnuk
Experience First Design Inc. Blekinge Institute of Technology
Saskatoon, Canada SE - 371 79, Karlskrona, Sweden
dcallele@experiencefirstdesign.com Krzysztof.Wnuk@bth.se
Abstract—To improve requirements engineering education and students to learn these techniques and to experiment with
training, experience reports serve as guidance on how courses can different ways of achieving a consensus among a variety of
be taught and which methods and approaches work with specific stakeholders from a non-engineering background.
types of audiences.
One problem when teaching undergraduate audiences is often With the majority of our students being interested and re-
a lack in motivation for the course because of misconceptions sponsible citizens (as emerging data suggests that Millennials
about requirements engineering as well as simple work overload are interested in doing more purpose-driven work or just being
by the curricula or other imposing constraints with regard to “socially-conscious” [5]), we predicted that using a case study
the students’ time budget. on empowering citizens would engage them more thoroughly
A way to overcome this motivational problem and to make
students want to actively contribute to a requirements engineer- with the responsibilities of requirements engineering.
ing class project is to let them perform a case study on a socially Contribution and Outline: This paper reports on expe-
relevant system in collaboration with an industrial partner. riences gathered with using the Citizen Muscle Boot Camp
This paper provides an experience report of such an in-class (CMB), an online learning program currently under develop-
project on an online-learning platform for civic engagement in ment at the Story of Stuff Project for environmental activism,
cooperation with the Story of Stuff Project. We provide the
structure of the course as well as the assignments, excerpts as student project in a requirements engineering course for
from the students’ results, and observations made throughout undergraduate students at the University of California, Irvine.
the course, all of which may serve as input for other instructors. The goal of the Boot Camp is to train a subset of the 500,000
members of the Story of Stuff community into citizen activists
Index Terms—requirements engineering; requirements educa- to work toward social change on sustainability issues. After
tion; environmental sustainability; civic engagement;
introducing the project, we present the course details, how the
I. I NTRO students performed the assignments, and the observations from
their results.
Requirements Engineering (RE) as a discipline provides the
foundation to making successful software systems by eliciting II. BACKGROUND
the appropriate information from the relevant stakeholders A. The RE Undergraduate Course at UCI
and by offering the methodological means to analyze and
document the findings such that they can be incorporated The undergraduate course in RE at the University of Califor-
throughout design and implementation. nia, Irvine, has been taught by a number of different lecturers
In the undergraduate course on RE at the University of with each slightly adapting the style and focus to personal
California, Irvine, we want to integrate the theory in class with preferences and current research and practice. In the spring
as much real-world experience as the classroom constraints quarter of 2014, it was taught by the first author of this paper.
allow for. Therefore, we integrate case studies and examples One of the definitions for RE that is used in the course
from ongoing software system development and collaborate is the one by Nuseibeh and Easterbrook [13]: Requirements
with industry and/or non-profit partners to give the students engineering is concerned with interpreting and understand-
an impression of RE in practice. ing stakeholder terminology, concepts, viewpoints and goals.
Web content has become an increasingly common way of Hence, RE must concern itself with an understanding of
disseminating important information to people and engaging beliefs of stakeholders (epistemology), the question of what
them in social causes [12]. The challenge of educating people is observable in the world (phenomenology), and the question
online in civic engagement, as developed by the Story of of what can be agreed on as objectively true (ontology). Such
Stuff Project1 , provides a well-suited example case study for issues become important whenever one wishes to talk about
validating requirements, especially where stakeholders may
1 http://www.storyofstuff.org have divergent goals and incompatible belief systems [13].
Furthermore, RE facilitates the process of consolidating dif- several artifact models, such as the one of Berenbach et
ferent stakeholders’ concerns and agreeing on a system vi- al. [4, ch. 2], who describe RE artifact modeling with the
sion [11]. key components to be a measurable reference model and
The major learning goals that arise from this view and shall respective process guidelines. To tackle the problem of a
be incorporated in the course are the following: blurry terminology and to foster the discussions about this
1) Knowledge areas: RE terminology RE contents, RE paradigm, Mendez et al. introduced a meta model for artifact-
principles and methods for eliciting, analyzing, spec- based RE [10]. This meta model defines the basic concepts of
ifying, validating, verifying requirements, and quality artifact-based RE, i.e. which elements are necessary to define
assurance an artifact (structure, content), or how an artifact relates to
2) Competencies and skills: analysis, abstraction, phrasing, further software process concepts like “method” or “role”.
communication, sensitivity for customers, method com- This supports the systematic creation of artifact-based RE
petencies approaches covering all elements of software processes, and
The course occurs over 10 weeks, with two lectures per thus the integration and customization of an artifact-based RE
week. Student evaluation is performed by a mid-term and as part of a software process.
final exam as well as a number of team assignments. The The Artifact Model for Domain-independent Requirements
assignments are designed to add up to a complete requirements Engineering (AMDiRE) [7], [2], developed on the basis of
specification, with students working in a team distributing the that meta model, served as framework for the lectures and
work and synthesizing and consolidating individual parts as structured the team project into weekly assignments.
well as taking responsibility for quality assurance. E. Related Work
B. Student Body In the field of sustainability education, Karlin et al. [8]
The course is mandatory for undergraduate students from report on a pilot study of the Guided Research Applied Sus-
three different major subjects, namely Informatics, Computer tainability Project (GRASP) model for sustainability education
Science, and Business and Information Management. Due to that provides students with a positive and engaging learning
the fact that it is a required course, there are many students experience.
each year who have to participate, and this made for a large In RE education, Zowghi and Paryani [16] used role playing
course of 106 enrolled students. to bring real world experiences into the classroom. Penzen-
All have had programming experience in their prior course- stadler and Callele [14] report on experiments with bringing a
work, while some have had more extensive experience in soft- stakeholder from mechanical engineering into class. Barnes
ware development either in their own projects or in internships. et al. [3] discuss how to foster an attitude of acceptance
in their students versus resistance and fear of the unknown
C. Lectures and Course Materials and unknowable in RE by including real-world examples and
The lectures were structured along an outline that followed experience in class.
the paradigm of artifact-oriented requirements engineering, Penzenstadler et al. [15] report on bringing stakeholders
i.e. that used the artifact model presented in Sec. II-D as a from industry into the classroom. In contrast, the course
backbone to elicit and analyze requirements and to organize described in the paper at hand did not include interviews with
the other tasks involved with requirements management. Each the stakeholders in class but instead information via documents
lecture was 80 minutes long and the lecture slides were and online research.
available online beforehand. III. S O S CMB P ROJECT
Preparation materials for the case study were provided in
the form of background information on the Story of Stuff This section describes the problem domain, the study sys-
Project as introduced in Sec. III-A and Sec. III-B as well as tem, and the student assignments.
some general background on Massive Open Online Courses A. Problem Domain: The Story of Stuff Project
(MOOCs) [9] with examples2 . Students were asked to famil-
iarize themselves with the Story of Stuff material as well as Story of Stuff started as a film project in 2007 designed to
with examples for MOOCs. tell the story of “stuff (i.e. consumer goods) from its creation,
through its sale and use, and eventually to its disposal” in a
D. Artifact-based RE with AMDiRE catchy and engaging manner. The single film, with an initial
In winter 2014, we introduced AMDiRE [7], an artifact- viewership goal of 50,000 views, quickly exceeded this goal
oriented approach to RE, in the course. The basic idea of and sparked the launch of The Story of Stuff Project as a
artifact orientation consists in defining a reference model of 501(c)3 nonprofit organization. The Story of Stuff Project has
all relevant artifacts and their dependencies while leaving open since created 8 additional films and has also translated into
the way of their creation. The focus thus lies on what to other mediums, including television (interstitials for PBS),
create rather than on how to create it. In RE, there exist print (Story of Stuff book), online (website, social media,
podcast), and curricula (K-12 and religious groups). Their
2 https://www.coursera.org/ combined films have been translated into 39 languages and
seen by over 40 million people and counting. This viewership TABLE I
has also translated into an active online community of nearly T IMELINE OF A SSIGNMENTS AND G RADING S CHEME
a half million people. The initial goal of the Story of Stuff Business Case (5%) Jan 27
Project was to create and provide media resources to envi- Stakeholder Model (5%) Jan 27
ronmental activists and educators as well as to the general Goal Model (5%) Feb 3
System Vision (5%) Feb 3
public. A community of potential activists formed around the Mid-term exam (20%) Feb 6
organization, who started to want to become more actively Domain Model (5%) Feb 10
engaged in the issues discussed in the films. Usage Model (5%) Feb 10
Non-functional requirements (5%) Feb 17
Functional hierarchies (5%) Feb 24
B. Study System: The Citizen Muscle Boot Camp Peer review (5%) Mar 3
Presentation of specification (5%) Mar 10
To address this need for positive citizen engagement through Final Exam (30%) Mar 20
education, The Story of Stuff Project created a new program
in 2013 called the Citizen Muscle Boot Camp. The Citizen
Muscle Boot Camp (CMB) is a six-week, online course de- Context Layer
signed to provide Story of Stuff Project community members Business Process Stakeholder Model
with the skills, motivation and peer support they need to act on
issues related to environmental sustainability. It was designed
in response to inquiries and requests from the Story of Stuff
Domain Model Goals &
community to help members learn, engage, connect, and act on Constraints
the issues raised in their films. The CMB guides participants
through a series of weekly trainings aimed at strengthening
their civic activism skills, or “citizen muscle”. Each week of
Requirements Layer
the program focuses on a unique skill: System Vision Quality Requirements
1) Purpose: discovering your change making style and goal
2) Talk: learning how to communicate effectively about
your issue
3) Grow: finding and developing a community of allies Usage Model Functional
4) Focus: getting strategic about how to accomplish your Hierarchy
goals
5) Push: figuring out which tactics you’ll need to employ
to effect change
6) Practice: putting your learning into action. Fig. 1. Reduced Version of AMDiRE for Course Assignments
For a first pilot of the course, members of the Story of
Stuff community were contacted via email and invited to
register for the CMB free of charge. Those who registered 1) Business Case Analysis and Stakeholder Model: For this
were enrolled in the CMB and received an email with a assignment, the students had to perform an elicitation meeting
link to a 2-3 minute video lesson, accompanied by additional with their team’s customer group to discuss the case study
resources (e.g., framing, tips, readings) to get them practicing problem in their role as part of the development team. After the
their change-making skills and a homework activity to put elicitation meeting where they discuss with the customer their
their new skills into practice. The CMB is designed so that understanding and vision of the Story of Stuff Citizen Muscle
each weekly module can be completed in 1-2 hours per week, Boot Camp Online Course, the team develops a business
and it was chosen as study system for the students to complete case analysis and a stakeholder model, both as described and
their assignments and develop a requirements specification. discussed in the lecture.
Evaluation criteria:
C. RE Course Assignments • Business Case Analysis [40 points]:
This section provides the assignments for the students as – Is the analysis structured well?
well as the evaluation criteria that were used to grade the – Does it contain executive summary, problem state-
submissions. The students were divided into 26 teams of four ment, analysis, solution options, project description,
to five students. They were free to choose their teams within cost-benefit analysis, risks and recommendations?
the first week of the quarter and the students who had not – Is each of these elements described in sufficient
found teams by then were assigned to one. Each team was detail?
serving as customer for one of the other teams, and as a – Is the information consistent throughout the docu-
developer for a different team. The timeline of the assignments ment?
is depicted in Table I. We used a reduced version of the • Stakeholder Model: [40 points]
AMDiRE artifact model as depicted in Fig. 1. – Have all major stakeholder groups been considered?
– Have they been analyzed and described to an ade- how they accomplished the task. For the usage model, they
quate degree of detail? were asked to provide an overview diagram of all use cases,
– Are the relationships between the stakeholders clear? plus a detailed version of at least one use case, including
– Is it clear which stakeholder has which knowledge, the full information from the template in the lecture slides.
skills, priority, and responsibilities? The detailed version of one use case includes one scenario
2) Goal Model and System Vision: For this assignment, the — first described according to the Cockburn template [6] (as
students had to ensure that they captured the critical goals from main success scenario with extensions and/or variations)—and
their elicitation meeting with the customer. If this is not the then choosing one diagram type (activity diagram or message
case yet, they have to further communicate with them and elicit sequence chart) to illustrate it. They were asked to provide a
more goals. On that basis, the team develops a goal model description of the rationale for the domain model and usage
and a system vision, both as described and discussed in the model, at least two paragraphs of how they did it and what
lecture. They had to make sure that the goal models contain at they found difficult or the most challenging aspect of it.
least three to four levels of subgoals for more than half of the • Domain Model [40 points]
goals3 and that appropriate notations are used (goal categories,
– Is the domain model well structured?
labeled relations, AND/OR alternatives). The task was not only
– Does it contain at least 7 classes and 2 meaningful
to submit the diagram but also a textual explanation of how
attributes per class?
they did it and why they did it this way. This also gives them
– Are all classes connected by associations with roles
a chance to report on encountered challenges.
and multiplicities?
For the system vision, the scoping (system boundary) is
– Is the domain model complete w.r.t. the criteria
important, as well as other systems in the context and the
discussed in class? Does it provide all important
involved stakeholders. It was important to keep the intention
concepts?
of a system vision in mind: It shall communicate the idea of
• Usage Model: [40 points]
the project to all stakeholders in a way they can agree on and
that is easily understandable without technical knowledge. – Is a use case overview diagram provided that is well
Evaluation criteria: structured and includes all important use cases?
• Goal Model [40 points] – Are all use cases that are important for the system
– Is the goal model well structured? depicted in that diagram?
– Does it contain at least five business goals, five usage – Is a complete and correct description of one ex-
goals and five system goals?4 emplary scenario provided for one central use case
– Are they broken down and refined into subgoals in either a UML activity diagram or a message
where possible? sequence chart?
– Is each of these elements related sufficiently to the – Is a complete and correct description provided for
other goals and are all notations used? one central use case in a table (according to the
Cockburn template)?
• System Vision: [40 points]
– Is a clear system boundary / scope visible? 4) Non-functional requirements: For this assignment, the
– Is the vision described and illustrated to an adequate students again had to use input from the earlier content
degree of detail? items (goal model, domain model, usage model) including the
– Is it clear which systems are in the operational and received feedback to develop a small set of non-functional
business context? requirements. This should be provided in the form of two
– Is it clear which stakeholders are involved? examples of each of the following categories: process re-
quirements, deployment requirements, system constraints, and
3) Domain Model and Usage Model: For this assignment,
quality requirements. These requirements shall be refinements
the students use the input from the earlier content items
of the earlier elicited goals, so they were asked to name the
(business case analysis, stakeholder model, goal model, system
goals as rationale.
vision) including the feedback they received on those to
Evaluation criteria for non-functional requirements [80
develop a domain model and a usage model, both as described
points]:
and discussed in the lecture. It was encouraged to make
sure that the domain model contains the important concepts • Is the template filled out completely and correctly for
of the domain — business objects, real world objects, and process requirements?
events that transpire — in form of classes (at least seven), • . . . for deployment requirements?
attributes (at least two per class), and associations with roles • . . . for system constraints?
and multiplicities. Furthermore, it was again requested to not • . . . for quality requirements?
only submit the diagram but also a textual explanation of 5) Function hierarchy: For this assignment, the students
3 To ensure that students practice refinement. again had to use the input from the earlier content items
4 The number is defined arbitrarily, but students kept asking “how much (usage model and scenarios). On that basis, the team develops
was enough”. a function hierarchy according to the example from the lecture,
structuring them into functions and subfunctions and adding
the respective relationships between them.
Evaluation criteria for the Function hierarchy [80 points]
• Are there at least ten functions in the function hierarchy?
• Does the structure of the hierarchy make sense?
• Are at least three of the possible types of relations (pre-
cedes/follows, requires, interrupts, activates/deactivates)
made explicit?
• Are all relations depicted that exist between the displayed
functions or are relations missing?
6) Quality Assurance in Peer Review: For this assignment,
students used the input provided by their development team,
meaning that:
1) They send their complete specification to their customer
in one PDF file (consolidated version of all your assign-
ments in one document) and receive the one from their
development team.
Fig. 2. Business Case Outline for the SoS CMB
2) The team writes up a review of the specification of their
development team according to the following IEEE-
830 criteria: completeness, consistency, unambiguity,
correctness, structuredness, traceability, changeability, requirements engineering, but very much in the day-to-day
understandability practice of business analysts who also perform requirements
Evaluation Review [80 points]: Is there a rating and ratio- engineering.
nale for the rating for the above criteria, namely Complete-
B. Stakeholder Model
ness, Consistency, Unambiguity, Correctness, Structuredness,
Traceability, Changeability, and Understandability?
IV. R ESULTS & O BSERVATIONS
All teams completed the assignments and handed in their
solutions. They also provided the rationale on how the results
were developed and which challenges had been encountered
while performing the assignment. This section provides illus-
trative examples of good solutions (not all from the same team)
and a discussion of observations made throughout the course
and while reviewing the results.
A. Business Case
Figure 2 is a screenshot of the rather elaborately designed
business case brochure one of the teams created. The hardest
part in the business case was that the system was for a non-
profit organization. This led some of the student teams to
inventing options for voluntary donations while taking the
online course, but made it hard to develop an actual business
case with convincing numbers apart from trying to keep the
costs low. The business case in Fig. 2 is a good, concise
solution. While the layout effort is quite impressive, that part
of the effort could have gone to something more directed to
the task at hand. Constraining the students to focus on content
over presentation seems to be useful in such an early and short
course. However, this is one of the three “fancy” examples out
Fig. 3. Stakeholder Model for the SoS CMB
of 26 solutions, so most of the students did stick to a simplerPower / Interest Model
presentation format. Apart from that, students put a lot of effortOverview
The stakeholder model in Fig. 3 is a simple yet sufficiently
into researching some background statistics on the web thatWe consider the stakeholders in a power/interest matrix to assess their potential to influence the project. The
goal is to understand who we (as the solution provider) and our client (as the content provider) should consider
would back up their data in the business case. extensive representation of the major stakeholders of the CMB
15
The challenge of finding sufficient background information system. Students often neglected representing the relations
is not so much related to learning the actual techniques of between stakeholders, as for example in Fig. 3, where there
Domain Model
are arrows to “hold together” the figure but no labels on the
arrows that would indicate the actual relation between the
stakeholders.
From the discussion on the solutions afterwards, the major
challenge was to infer relations if the checklists and examples
provided in class didn’t already include those relations.
C. Goal Model
The goal model in Fig. 4 depicts business goals (in red),
usage goals (in green), and system goals (in blue) and their
relations. The model is structured to support a goal hierarchy
with respect to the scope of the goal. Business goals are
more primary, relating to the actual purpose of creating the
system, so they are located toward the top of the diagram.
They are supported by usage goals which define the intent
Fig. 6. Domain Model for the SoS CMB
We decided the classes by first listing each component of the course webpage.
and function of the system and are thus supported by system Afterwards, we determined the attributes by writing out the details of each component. Classes
needed to denote objects. We created the final version of the classes by changing objects into
goals which demonstrate the characteristics of the system. The attributes if they described a class. The classes and attributes needed to not only follow what
was written in the business case and the goal model, but it also had to be consistent with the
model contains a multitude of antigoals, or constraints, as well usage model. Thus, our diagram contains terminology and relations that had already been
as obvious goals. Anything that is not marked with the double The students encountered many challenges including but not
stated. We added further descriptions of each object’s relationship with each other in order to
clarify how the objects interacted and why each attribute is necessary for the object.
minus sign is an uninhibiting subgoal of its parent goal. Each limited to: having consistent terms between the domain model
The classes are associated with each other when they have direct interaction with each
constraint is marked with a double minus sign (- -) meaning and previous documents or models; determining whether
other. For example, the game board contains many courses that students can take by
interacting directly with both the game board and the courses. There is only one game board,
it can inhibit the functionality or achievement of it’s parent classes which is shared by every student and every course. Each course contains a type of “media”. We
were necessary or arbitrary; and figuring out if an
use the term “media” because the instructors may develop a course via images or video.
goals. Double plus sign (++) means the subgoals lead up to attributeBecause it is uncertain and vague as to which medium an instructor chooses to use, we
was part of the correct class. They resolved the ter-
deemed that having a name and a link is sufficient for implying that a course will contain at least
their parent goal. minology issue by discussing the model with their teammates
videos and possibly pictures too. We did not put them as the attribute of a “Course”, because we
think it will be more organized to have a separate query instead of having it belong under the
Major challenges were to distinguish between business, and coming to a consensus as to which terms to be used in
courses. Also, our system calendar will include events and dates, so we associated them with
usage, and system goals and to identify relations between the the model. As for the classes, they decided which ones should
goals. become classes and which ones should remain attributes while
creating the diagram.
D. System Vision
Figure 5 is a pictorial representation of the system vision of Usage ModelModel
F. Usage
the CMB that all stakeholders (in this case, customer team and MOOC usage model overview
developer team members) agree on and that serves as common
reference point in discussions. The system vision was agreed
upon by all stakeholders (i.e., each developer team and the
respective customer team) in order to define the functionality
and characteristics of the Story of Stuff CMB. The vision
contains passive and active stakeholders centering around the
CMB and a business and operational context, separated by
a dotted line on the diagram. Most active stakeholders are
highlighted by colored fields. Community leaders and users
are among the active stakeholders, but they are not members
of the Story of Stuff organization. Each group is highlighted
according to the legend on the diagram. Passive stakeholders,
along with community leaders and users, are not highlighted
by any boundary.
The major challenge with the stakeholder model was to con-
sider all categories of stakeholders and to determine influences
between them.
E. Domain Model
Fig.creating
Cockburn outline for 7. UseanCase Overview
account for the SoS CMB
on the MOOC
The domain model in Fig. 6 is a class diagram that lists the
most important business (real-world) objects that have to be
Use Case Create an account
represented in the system. The classes and attributes needed Figure 7 and Figure 8 depict excerpts of the usage model,
Goal in Context
to not only follow what was written in the business case and representing differentUser creates an account on the MOOC
paths of how a user can interact with
Scope Story of Stuff Massive Open Online Course
the goal model, but also had to be consistent with the usage the website. In the activity diagram (Fig. 8), the user is placed
model. The classes are associated with each other when they Level
in the middle as a wayPrimary Task
to symbolize their role in determining
have direct interaction with each other. Preconditions
whether or not data would● User has access to a computer connected to the
be transmitted between the system
Internet
● User has a valid email address
● User knows how to navigate to the MOOC webpage
Success End Condition User creates an account for the MOOC
Failed End Condition User does not create an account
Goal Model
Fig. 4. Goal Model for the SoS CMB
The model above is structured to support a goal hierarchy with respect to the scope of the goal.
Business goals are more primary, relating to the actual purpose of creating the system, so they are
System Vision
located toward the top of the diagram. They are supported by usage goals which define the intent and
function of the system and are thus supported by system goals which demonstrate the characteristics of
the system.
The model contains a multitude of anti-goals, or constraints, as well as obvious goals. Anything
that is not marked with the double minus sign is an uninhibiting subgoal of its parent goal. Each constraint
is marked with a double minus sign (--) meaning it can inhibit the functionality or achievement of it’s
parent goals. Double plus sign (++) means the subgoals lead up to their parent goal.
Primary Goals
The primary goal of this project is to develop citizen muscles, or in other words to teach people
how to become more active in the community. The way to do that is to first create a massive open
The system vision was agreed upon by all stakeholders in order to define the functionality and
Fig. 5. System Vision for the SoS CMB
characteristics of the Story of Stuff massive open online course (MOOC). The vision contains passive
and active stakeholders centering around the MOOC and a business and operational context, separated
by a dotted line on the diagram. Most active stakeholders are highlighted by colored fields. Community
leaders and users are among the active stakeholders, but they are not members of the Story of Stuff
organization. Each group is highlighted according to the legend on the diagram. Passive stakeholders,
along with community leaders and users, are not highlighted by any boundary.
Activity Diagram for creating an account on the MOOC
The non-functional requirements in Fig. 9 provide examples
of a simple template specification form used to detail the
NFRs and their validation. The non-functional requirements
included quality requirements, process requirements, deploy-
ment requirements, and system constraints.
The students reported slight difficulty in eliciting non-
functional requirements, along with phrasing them in a way
that was coherent with the goals. They referred mostly to their
goal models, breaking down each element in order to deter-
mine some non-functional properties their client prescribed
for the system. The NFRs themselves were rather high-level
quality goals broken down to a level that could be applied
to the overall software system. The measurement (see Fig. 9,
4th attribute of every table) was often underspecified so that
testers would have to make assumptions about how exactly to
measure this satisfaction criterion.
H. Functional hierarchies
The functional hierarchy in Fig. 10 decomposes the user-
perceived functionality from a system point of view and
thereby facilitates the transition to design. While the students
listed out each function, they tended to think too broadly
and in general terms about the CMB, instead of the specific
requirements that were requested by the clients. They found
it difficult to determine the subfunctions of certain parent
functions and figuring out whether activates, precedes, or re-
quires was more suitable for describing how certain functions
interacted with each other in the hierarchy. Another problem
that they encountered was making the functional hierarchy
Fig. 8. Use Case Scenario as Activity Diagram for the SoS CMB diagram readable. The user was required to go through the
“signin to account” function before being allowed to use
the rest of the functions in the MOOC system. It was the
and the account database. The students also considered the subfunction to most of the other functions, so there were many
failure condition, in which an account is not created. Including arrows pointing to that function and many boxes surrounding
these two end conditions is necessary to demonstrate the it. As a result, they chose to make the “signin to account”
destruction of data upon failure. function “activate” all the other functions, which solved the
The most challenging aspect of designing activity diagrams problem and made the diagram much easier to read.
was determining when and where data flow occurs, as the Early design decisions like this were the most discussed
students had difficulty in defining the interaction between the point about function hierarchies and show where RE and
system and the accounts database. design have to be integrated or may overlap.
I. Peer Review
G. Non-functional requirements
1RQ)XQFWLRQDO5HTXLUHPHQWV In the peer review, students tended to be very generous
to their developer teams. They commented on a few minor
)) ,!"*201- 00 ,!"/"3&"4 "/3"/*201 )),4#,/1%""5-,/1,#! 1
1&,+ )" ,+1/& 21"01,4 /!01 &)&16$, )0 1&,+ )" )),40! 1 1, "4&1%!/ 4+ +! + )67"!
mistakes or how the specifications could have been extended,
1&0# 1&,+
/&1"/&,+
1"/ ,!"/"# 1,/&+$ 1&0# 1&,+
/&1"/&,+
"11&+$0"5-,/1 ,3"/ $" but in general they were satisfied with the work of their peers.
" 02/"*"+1 "/ "+1 $",# ,!"1% 1% 0 ""+/"# 1,/"! " 02/"*"+1 "/ "+1 $",#%,01&+$0"11&+$01% 1 /"0 3"!&+"5-,/1 Most of the teams had gone through the effort of reworking
&0( &1"* 602##"/2+&+1"+!"!!,4+1&*" &0( %"0&1"4,2)! "&*-,00& )"1,1/ +0#"/1, +,1%"/
%,01 their specifications after the initial feedback from the teaching
%"!"3"),-*"+11" **20120",-"+Ȓ0,2/ "
1,,)0
&1"*201 "2- ,+0&01"+1)6
assistants, so those efforts apparently had paid off, as the
1&,+ )" %"4" 0&1"0%,2)! "#2))6#2+ 1&,+&+$0,1% 120"/04&))
1&,+ )" %" -Ǿ" 061,/"-)& 1"#,/#212/"20"Ǿ
1/ +0- /"+ 6
+,1 "12/+"!,## 61%"&!" 1% 14" 0&1"&0 )4 60
!"#" 1&3"ǽ
specifications had improved considerably.
1&0# 1&,+ ))!"3"),-*"+11,,)0 /",-"+Ȓ0,2/ " 1&0# 1&,+ &1"2-1&*"*201 "$/" 1"/1% +ǞǞǽǞǞʢ
/&1"/&,+ /&1"/&,+
" 02/"*"+1 "3&"4,#!"3"),-*"+11,,) ,-6/&$%1)& "+0"0 " 02/"*"+1 +!,*)6-&+$&+$1%"0&1" +! ,2+1&+$-"/ "+1 $",#
J. Presentation of the Specification
/"0-,+0"0
&0( ,,)020"!4&)) ",#),4"/.2 )&161% +1%"6
*&$%1 ",1%"/4&0" &0( 0"/0* 6)" 3"1,,1%"/0 +!!&0*&00,2/4" 0&1" The teams presented excerpts of their solutions within five
0 !"0&/ )"), 1&,+#,/,+)&+""!2 1&,+ǽ
minute presentations during the last two sessions of the course
Fig. 9. NFRs for the SoS CMB
before the final exam. At this stage of their curriculum, the
students do have experience in presenting in front of a large
Fig. 10. Function Hierarchy for the SoS CMB
This functional hierarchy diagram relies heavily on our Usage Model of the Story of Stuff MOOC
system. It contains one root, titled “Story of Stuff MOOC”, and lists all the necessary functions. Based on
our client’s requirements, our system includes the following major functions: “Register for an account”,
“Sign-in to account”, “Monitor personal progress”, “Display the video page”, “Comment on a video”,
audience, but their presentation skills varied considerably. usually composed of friends who therefore had established
“Display assignments”, “Display calendar of events”, “Share pictures from events”, and “Display pictures
While some teams made an effort to make their presentation communication habits, while new teams first had to get to
of an event”. All of these functions contain subfunctions and some have external interfaces such as
engaging, others only “” and “”. The dependencies between each function and
put in the minimum required effort know each other and find common denominators.
to deliver an acceptablesubfunction are depicted by arrows labeled with “requires”, “activates”, and “precedes”.
summary. Presentation skills are of
C. Solution Space
critical importance to successful customer communication and
The design space used by the students was rather limited
should therefore be part of anWe faced many problems during the creation of this diagram. While we listed out each function,
RE course.
we tended to think too broadly and in general terms about the MOOC, instead of the specific requirements
compared to what will actually be implemented. Were the
V. D ISCUSSIONthat were requested by our clients. For example, we initially put “enroll into courses” as one of the
AND L ESSONS L EARNED students simply not interested enough or not knowledgeable
functions of this MOOC. However, we later realized that this is not what our clients wanted since they
A. Overall Quality of Results enough? Or were the re-documenting what they saw elsewhere
wanted all the users to participate in one big course on the same game board. We also had an issue with
without considering other options? This depends partially on
determining the subfunctions of certain parent functions and figuring out whether “activates,” “precedes,”
The range of solutions extends from bad to good, as well their experience, but also on their creativity and motivation for
or “requires” was more suitable for describing how certain functions interacted with each other in the
as from little effort to major effort that was put into the coming up with new ideas in this course.
hierarchy. Another problem that we encountered was making the functional hierarchy diagram look clean
development of the specification.
and readable. The user was required to go through the “sign-in to account” function before being allowed
Having chosen a problem domain that would likely increase
The grades in the mid-term and the final exam were average motivation (see Sec. III-B), we were interested in how much
to use the rest of the functions in the MOOC system. It was the subfunction to most of the other
for a RE course, not much difference was perceived from sustainability showed up in their results. The answer is: only in
functions, so there were many arrows pointing to that function and many boxes surrounding it. As a result,
other years (comparisonwe chose to make the “sign-in to account” function “activate” all the other functions, which solved our
as perceived by teaching assistant) System Vision and Goal Model, if at all. Some even reduced it
or from earlier teachingproblem and made the diagram much easier to read.
experience by the first author at other only to the economic sustainability of the business. It is hard
universities. However, this is not dependent on the teaching to determine whether this is due to the lack of familiarity
method but on the students’ population — badly designed with requirements techniques, due to lack of interest in the
course will generate failures but well designed courses may specific concern for the system under development, or due to
also generate failures if students are not motivated. a lack of knowledge of sustainability issues. Other disciplines
B. Team Dynamics that are also trying to incorporate questions on sustainability
into existing structures, like UC Santa Cruz’s engineering
There is a strong correlation between the students level of program [1] have reported a high motivation amongst students
experience and the quality of the work that they produced for sustainability causes, therefore we conclude that this is
on the project. Students who had experience in software mainly due to inexperience of how to factor such a value into
development projects and even worked in industry managed RE.
their teams in a very effective way and provided medium
to high quality specifications. On the downside, they often D. Lessons Learned
strongly focussed on the technical aspects of the system This section sums up the lessons learned of the experience
(solution-orientation) and neglected stakeholder communica- report at hand.
tion (problem-orientation). Reduce Number of Assignments: Effort estimation in student
There was a perceivable difference between the groups that projects is hard, but as first-timers every artifact takes more
were self-selecting and the groups that were assigned in terms time to elaborate and team work requires a lot of discussion if
of the work they produced. Teams who had self-selected were done properly. The conclusion is to ask for less artifacts when
the course has only 10 weeks—it was too much stuff to deal motivate students, but even stronger motivation and commit-
with in such a short time—and to probably cut out function ment to developing a good requirements specification can be
hierarchies because they are strongly design-oriented. achieved by inviting real stakeholders, and that the choice
Real Stakeholders Motivate: While the students liked having of the problem domain might influence students’ motivation.
a “real system” to work on, they would have preferred to There are a few follow-up questions to be explored in future
talk to a real person involved in the project as opposed to work, for example, whether value-based design should be
having to rely on documents, online research, and future included as a concept when teaching requirements engineering,
users. Consequently, for the next iteration of the course, we and how significantly the choice of problem domain affects
will again put a real stakeholder in class (compare to the the motivation of the students in such a course. For the next
BMW DriveNow case study [15]) for one or two interviews iterations of the course at UCI, we will try to allow the students
during elicitation and analysis, even if they are playing a to perform interviews with real stakeholders for a system under
role. According to our experience, a real person who is only consideration in practice.
available for that specific time, considerably increases the Acknowledgements: This work is supported by the DFG
motivation to understand the problem domain and system EnviroSiSE project under grant number PE2044/1-1.
under development.
R EFERENCES
Choice of Problem Domain: There are challenges when
[1] Patricia Allen and Martha Brown. Sustainable Agriculture at UC Santa
motivating the pragmatic topic of RE with a project that is, Cruz. http://casfs.ucsc.edu/about/History%20and%20News%20Archive/
itself, motivated by what might be perceived as an ethical sustainable-agriculture-at-ucsc.html, 2014.
choice. Does the ethical choice resonate with the students [2] D. Mendez Fernandez B. Penzenstadler, J. Eckhardt. Two replication
studies for evaluating artefact models in re: Results and lessons learnt.
(positive motivator), is it ignored (neutral, but not achieving In Proc. of the 3rd International Workshop on Replication in Empirical
your personal goal to enlighten them), or does it annoy them? Software Engineering Research (RESER ’13), IEEE, 2013. Baltimore,
When looked at from a software system perspective, RE is USA, 2013.
[3] R.J. Barnes, D.C. Gause, and E.C. Way. Teaching the unknown and the
about the content to be represented in the system, not the unknowable in requirements engineering education. In Requirements
system purpose. The question of whether or not the content Engineering Education and Training, 2008. REET ’08., pages 30–37,
of the project enhances or detracts from the mechanics of Sept 2008.
[4] B. Berenbach, D. Paulish, J. Kazmeier, and A. Rudorfer. Software &
the course material is hard to answer without back-up by Systems Requirements Engineering: In Practice. McGraw-Hill, Inc.,
significant empirical data. It was perceived that the students 2009.
were enjoying the topic of the problem domain but there might [5] Emily C Bianchi. Entering adulthood in a recession tempers later
narcissism. Psychological science, page 0956797614532818, 2014.
have been students who were negatively motivated by the topic [6] Alistair Cockburn. Writing effective use cases. Pearson Education, 2001.
without providing feedback on that. Next time we will include [7] Daniel Mendez Fernandez and Birgit Penzenstadler. Artefact-based
a question on this in the course evaluation survey. Requirements Engineering: The AMDiRE Approach. Requirements
Engineering, 2014.
Value-based Design: Sustainability is not a concern that [8] B. Karlin, N. Davis, and R. Matthew. GRASP: Testing an Integrated Ap-
visibly showed up in the solutions other than in the goal proach to Sustainability Education. Journal of Sustainability Education,
model and system vision. Environmental sustainability was Spring 2013(Experiential Education, Part One), 2013.
[9] Rita Kop. The challenges to connectivist learning on open online
used as example for a value that could be supported in value- networks: Learning experiences during a massive open online course.
based design. While it was not the intention of the course to The International Review of Research in Open and Distance Learning,
promote any political agenda, this was a value that students Special Issue-Connectivism: Design and Delivery of Social Networked
Learning, 12(3), 2011.
would generally be willing to accept and that was a little [10] D. Mendez Fernandez, B. Penzenstadler, M. Kuhrmann, and M. Broy.
easier to grasp than a value like “fun”. The fact that the value A Meta Model for Artefact-Orientation: Fundamentals and Lessons
was not made very explicit in the solutions shows that for Learned in Requirements Engineering. In D. Petriu, N. Rouquette, and
O. Haugen, editors, Proceedings of the 13th International Conference
practicing any kind of value-based design, this needs to be on Model Driven Engineering Languages and Systems (Models), volume
put into an exercise more explicitly, for example by making 6395, pages 183–197. Springer-Verlag Berlin Heidelberg, 2010.
different teams design for different values and comparing the [11] Andrew Monk and Steve Howard. Methods & tools: the rich picture: a
tool for reasoning about work context. interactions, 5(2):21–30, 1998.
differences amongst their solutions. [12] Norman H Nie and Lutz Erbring. Internet and society. Stanford Institute
for the Quantitative Study of Society, 2000.
[13] Bashar Nuseibeh and Steve Easterbrook. Requirements engineering: a
VI. C ONCLUSION & F UTURE W ORK roadmap. In Proceedings of the Conference on the Future of Software
Engineering, pages 35–46. ACM, 2000.
This paper reported on the experiences with using an online [14] Birgit Penzenstadler and David Callele. Prototyping re experiments
course, the Citizen Muscle Boot Camp, under development at in the classroom: An experience report. In Requirements Engineering
the Story of Stuff Project, as study system for the assignments Education and Training (REET), 2010 5th International Workshop on,
pages 7–16. IEEE, 2010.
in an undergraduate RE course at the University of California, [15] Birgit Penzenstadler, Martin Mahaux, and Patrick Heymans. Univer-
Irvine. The Story of Stuff Project used the results as additional sity Meets Industry: Calling in Real Stakeholders. In 26th IEEE-CS
input for the actual development of the CMB. The major Conference on Software Engineering Education and Training, 2013.
[16] Didar Zowghi and Suresh Paryani. Teaching requirements engineering
lessons learned are that artifact-oriented RE works well to through role playing: Lessons learnt. In Requirements Engineering
structure assignments, but also needs to be restricted to the Conference, 2003. Proceedings. 11th IEEE International, pages 233–
given time frame of the course, that real-world systems do 241. IEEE, 2003.