-To improve requirements engineering education and training, experience reports serve as guidance on how courses can be taught and which methods and approaches work with specific types of audiences. One problem when teaching undergraduate audiences is often a lack in motivation for the course because of misconceptions about requirements engineering as well as simple work overload by the curricula or other imposing constraints with regard to the students' time budget. A way to overcome this motivational problem and to make students want to actively contribute to a requirements engineering class project is to let them perform a case study on a socially relevant system in collaboration with an industrial partner. This paper provides an experience report of such an in-class project on an online-learning platform for civic engagement in cooperation with the Story of Stuff Project. We provide the structure of the course as well as the assignments, excerpts from the students' results, and observations made throughout the course, all of which may serve as input for other instructors.
Index Terms—requirements engineering; requirements education; environmental sustainability; civic engagement;
Requirements Engineering (RE) as a discipline provides the foundation to making successful software systems by eliciting the appropriate information from the relevant stakeholders and by offering the methodological means to analyze and document the findings such that they can be incorporated throughout design and implementation.
In the undergraduate course on RE at the University of California, Irvine, we want to integrate the theory in class with as much real-world experience as the classroom constraints allow for. Therefore, we integrate case studies and examples from ongoing software system development and collaborate with industry and/or non-profit partners to give the students an impression of RE in practice.
Web content has become an increasingly common way of
disseminating important information to people and engaging
them in social causes [
With the majority of our students being interested and
responsible citizens (as emerging data suggests that Millennials
are interested in doing more purpose-driven work or just being
“socially-conscious” [
Contribution and Outline: This paper reports on experiences gathered with using the Citizen Muscle Boot Camp (CMB), an online learning program currently under development at the Story of Stuff Project for environmental activism, as student project in a requirements engineering course for undergraduate students at the University of California, Irvine. 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 to work toward social change on sustainability issues. After introducing the project, we present the course details, how the students performed the assignments, and the observations from their results.
The undergraduate course in RE at the University of California, Irvine, has been taught by a number of different lecturers with each slightly adapting the style and focus to personal preferences and current research and practice. In the spring quarter of 2014, it was taught by the first author of this paper.
One of the definitions for RE that is used in the course
is the one by Nuseibeh and Easterbrook [
The major learning goals that arise from this view and shall be incorporated in the course are the following: 1) Knowledge areas: RE terminology RE contents, RE principles and methods for eliciting, analyzing, specifying, validating, verifying requirements, and quality assurance 2) Competencies and skills: analysis, abstraction, phrasing, communication, sensitivity for customers, method competencies
The course occurs over 10 weeks, with two lectures per week. Student evaluation is performed by a mid-term and final exam as well as a number of team assignments. The assignments are designed to add up to a complete requirements specification, with students working in a team distributing the work and synthesizing and consolidating individual parts as well as taking responsibility for quality assurance.
The course is mandatory for undergraduate students from three different major subjects, namely Informatics, Computer Science, and Business and Information Management. Due to the fact that it is a required course, there are many students each year who have to participate, and this made for a large course of 106 enrolled students.
All have had programming experience in their prior coursework, while some have had more extensive experience in software development either in their own projects or in internships.
The lectures were structured along an outline that followed the paradigm of artifact-oriented requirements engineering, i.e. that used the artifact model presented in Sec. II-D as a backbone to elicit and analyze requirements and to organize the other tasks involved with requirements management. Each lecture was 80 minutes long and the lecture slides were available online beforehand.
Preparation materials for the case study were provided in
the form of background information on the Story of Stuff
Project as introduced in Sec. III-A and Sec. III-B as well as
some general background on Massive Open Online Courses
(MOOCs) [
In winter 2014, we introduced AMDiRE [
The Artifact Model for Domain-independent Requirements
Engineering (AMDiRE) [
In the field of sustainability education, Karlin et al. [
In RE education, Zowghi and Paryani [
Penzenstadler et al. [
Story of Stuff started as a film project in 2007 designed to tell the story of “stuff (i.e. consumer goods) from its creation, through its sale and use, and eventually to its disposal” in a catchy and engaging manner. The single film, with an initial viewership goal of 50,000 views, quickly exceeded this goal and sparked the launch of The Story of Stuff Project as a 501(c)3 nonprofit organization. The Story of Stuff Project has since created 8 additional films and has also translated into other mediums, including television (interstitials for PBS), print (Story of Stuff book), online (website, social media, podcast), and curricula (K-12 and religious groups). Their combined films have been translated into 39 languages and seen by over 40 million people and counting. This viewership has also translated into an active online community of nearly a half million people. The initial goal of the Story of Stuff Project was to create and provide media resources to environmental activists and educators as well as to the general public. A community of potential activists formed around the organization, who started to want to become more actively engaged in the issues discussed in the films.
To address this need for positive citizen engagement through 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 designed to provide Story of Stuff Project community members 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 community to help members learn, engage, connect, and act on 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 the program focuses on a unique skill: 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 4) Focus: getting strategic about how to accomplish your goals 5) Push: figuring out which tactics you’ll need to employ to effect change 6) Practice: putting your learning into action.
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 were enrolled in the CMB and received an email with a link to a 2-3 minute video lesson, accompanied by additional resources (e.g., framing, tips, readings) to get them practicing their change-making skills and a homework activity to put their new skills into practice. The CMB is designed so that each weekly module can be completed in 1-2 hours per week, and it was chosen as study system for the students to complete their assignments and develop a requirements specification.
This section provides the assignments for the students as well as the evaluation criteria that were used to grade the submissions. The students were divided into 26 teams of four to five students. They were free to choose their teams within the first week of the quarter and the students who had not found teams by then were assigned to one. Each team was serving as customer for one of the other teams, and as a developer for a different team. The timeline of the assignments is depicted in Table I. We used a reduced version of the AMDiRE artifact model as depicted in Fig. 1. 1) Business Case Analysis and Stakeholder Model: For this assignment, the students had to perform an elicitation meeting with their team’s customer group to discuss the case study problem in their role as part of the development team. After the elicitation meeting where they discuss with the customer their understanding and vision of the Story of Stuff Citizen Muscle Boot Camp Online Course, the team develops a business case analysis and a stakeholder model, both as described and discussed in the lecture.
Evaluation criteria:
Business Case Analysis [40 points]: – Is the analysis structured well? – Does it contain executive summary, problem statement, analysis, solution options, project description, cost-benefit analysis, risks and recommendations? – Is each of these elements described in sufficient detail? – Is the information consistent throughout the document? Stakeholder Model: [40 points] – Have all major stakeholder groups been considered? – Have they been analyzed and described to an adequate degree of detail? – Are the relationships between the stakeholders clear? – Is it clear which stakeholder has which knowledge, skills, priority, and responsibilities? 2) Goal Model and System Vision: For this assignment, the students had to ensure that they captured the critical goals from their elicitation meeting with the customer. If this is not the case yet, they have to further communicate with them and elicit more goals. On that basis, the team develops a goal model and a system vision, both as described and discussed in the lecture. They had to make sure that the goal models contain at least three to four levels of subgoals for more than half of the goals3 and that appropriate notations are used (goal categories, labeled relations, AND/OR alternatives). The task was not only to submit the diagram but also a textual explanation of how they did it and why they did it this way. This also gives them a chance to report on encountered challenges.
For the system vision, the scoping (system boundary) is important, as well as other systems in the context and the involved stakeholders. It was important to keep the intention of a system vision in mind: It shall communicate the idea of the project to all stakeholders in a way they can agree on and that is easily understandable without technical knowledge.
Evaluation criteria:
Goal Model [40 points] – Is the goal model well structured? – Does it contain at least five business goals, five usage goals and five system goals?4 – Are they broken down and refined into subgoals where possible? – Is each of these elements related sufficiently to the other goals and are all notations used? System Vision: [40 points] – Is a clear system boundary / scope visible? – Is the vision described and illustrated to an adequate degree of detail? – Is it clear which systems are in the operational and business context? – Is it clear which stakeholders are involved? 3) Domain Model and Usage Model: For this assignment, the students use the input from the earlier content items (business case analysis, stakeholder model, goal model, system vision) including the feedback they received on those to develop a domain model and a usage model, both as described and discussed in the lecture. It was encouraged to make sure that the domain model contains the important concepts of the domain — business objects, real world objects, and events that transpire — in form of classes (at least seven), attributes (at least two per class), and associations with roles and multiplicities. Furthermore, it was again requested to not only submit the diagram but also a textual explanation of 3To ensure that students practice refinement.
4The number is defined arbitrarily, but students kept asking “how much
was enough”.
how they accomplished the task. For the usage model, they
were asked to provide an overview diagram of all use cases,
plus a detailed version of at least one use case, including
the full information from the template in the lecture slides.
The detailed version of one use case includes one scenario
— first described according to the Cockburn template [
Domain Model [40 points] – Is the domain model well structured? – Does it contain at least 7 classes and 2 meaningful attributes per class? – Are all classes connected by associations with roles and multiplicities? – Is the domain model complete w.r.t. the criteria discussed in class? Does it provide all important concepts? Usage Model: [40 points] – Is a use case overview diagram provided that is well structured and includes all important use cases? – Are all use cases that are important for the system depicted in that diagram? – Is a complete and correct description of one exemplary scenario provided for one central use case in either a UML activity diagram or a message sequence chart? – Is a complete and correct description provided for one central use case in a table (according to the Cockburn template)? 4) Non-functional requirements: For this assignment, the students again had to use input from the earlier content items (goal model, domain model, usage model) including the received feedback to develop a small set of non-functional requirements. This should be provided in the form of two examples of each of the following categories: process requirements, deployment requirements, system constraints, and quality requirements. These requirements shall be refinements of the earlier elicited goals, so they were asked to name the goals as rationale.
Evaluation criteria for non-functional requirements [80 points]:
Is the template filled out completely and correctly for process requirements? . . . for deployment requirements? . . . for system constraints? . . . for quality requirements? 5) Function hierarchy: For this assignment, the students again had to use the input from the earlier content items (usage model and scenarios). On that basis, the team develops 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 (precedes/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 assignments in one document) and receive the one from their development team. 2) The team writes up a review of the specification of their development team according to the following IEEE830 criteria: completeness, consistency, unambiguity, correctness, structuredness, traceability, changeability, understandability
Evaluation Review [80 points]: Is there a rating and rationale for the rating for the above criteria, namely Completeness, Consistency, Unambiguity, Correctness, Structuredness, Traceability, Changeability, and Understandability?
IV. RESULTS & OBSERVATIONS
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 illustrative examples of good solutions (not all from the same team) and a discussion of observations made throughout the course and while reviewing the results.
Fig. 2. Business Case Outline for the SoS CMB requirements engineering, but very much in the day-to-day practice of business analysts who also perform requirements engineering.
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 nonprofit 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 into researching some background statistics on the web thatWe consTidehr ethes sttaakkeheohldoerlsd ine ar pmowoerd/inetelreisnt mFatirgix .to3 assiesssa thseiir mpoptelnetialy toe itnflsueunfcfie cthiee pnrotjelyct. The would back up their data in the business case. goal eis xtot eunndserisvtaendr wehpor wees (eans tthaet siooluntioon fprothvideerm) anadj oourr csliteantk (eash tohel dcoenrtesnt oprfovtihdeer) sChoMuldB consider
The challenge of finding sufficient background information system. Students often neglected representing the relations 15 is not so much related to learning the actual techniques of between stakeholders, as for example in Fig. 3, where there 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.
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 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 antigoals, 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.
Major challenges were to distinguish between business, usage, and system goals and to identify relations between the goals.
Figure 5 is a pictorial representation of the system vision of the CMB that all stakeholders (in this case, customer team and 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 consider all categories of stakeholders and to determine influences between them.
We decFidiegd. th6e .clasDseos mby afirisnt lisMtingo edaechl cfoomrpotnhenet oSf toheS coCursMe wBebpage.
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 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 usage model. Thus, our diagram contains terminology and relations that had already been The ssttatuedd. Ween atdsdede fnurtcheor duesncrtipetiornes dof emacha onbjeyct’sc rhelaatiolnlsehinp wgiteh esacihn otchelru ind oridner gto but not clarify how the objects interacted and why each attribute is necessary for the object. limited to: having consistent terms between the domain model
The classes are associated with each other when they have direct interaction with each and proethveri. oFour esxampdleo, tcheu gammee bnoatrds conotairns mmanyo codureselss t;hat sdtuedetnetsr cman tiankei bny g whether interacting directly with both the game board and the courses. There is only one game board, classeswhwich eisr seharend beyc eveesrys satudreynt anod reveary rcobuirster. aEarcyh c;ourasen cdontaifins ga utyprei onf “gmedoia”u. Wte if an use the term “media” because the instructors may develop a course via images or video. attributBeecausae ist is puncertaino anfd vtahgue asc too wrhricehc mtedicumla ans isns.tructor cehoyoserse tos uosel, vweed the terw art e Th minolovdgiedyeemose da nthda pt ohsasvibinlyg pai cntaumrees atonod. aWs leisn kdi iinds nsoutf fpicuiet nteht efomr iamsp tlhyein agt ttrhibaut tae ciooft uahr s“eC owuilrl sceo”n, tbaeinc aaut sleema wstemates issue by discu g th model w their tea and comtchoinurks iet sw. iAll lbseo ,m oourre s yosrgteamni zceadle tnod haar vwei lla i nscelpuadrea teev eqnutesr ya ninds tdeaatde so, fs hoa wvien ga sits boeclioantegd u tnhdeemr twhiethused in ing to a consensus as to which terms to be the model. As for the classes, they decided which ones should become classes and which ones should remain attributes while creating the diagram.
MOOC usage model overview
The domain model in Fig. 6 is a class diagram that lists the Cockburn outline fFoirgc.r7e.atiUngseanCaacsceouOnvteornvitehwe MfoOrOtChe SoS CMB most important business (real-world) objects that have to be represented in the system. The classes and attributes needed to not only follow what was written in the business case and the goal model, but also had to be consistent with the usage model. The classes are associated with each other when they have direct interaction with each other.
UseF Ciagseure 7 and FigurCerea8te dane apciccoutntexcerpts of the usage model, Greoapl rine sCeonntteixnt g differentUspera ctrheastes an account on tuhes eMrOOcCan interact with
of how a Sthcoepewebsite. In the actSitvoriyt oyf Sdtuifaf Mgarsasmive O(Fpeing O.n8lin)e, Cthouerseuser is placed Linevetlhe middle as a waPyrimtaory sTyasmkbolize their role in determining Pwrehcoentdhietiornsor not data wou●ldUsbeer hatsr aacncsemss tiot tae cdombpuettewr ceonennecttehd eto sthyestem
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
The system vision was Faiggr.e5e.d Suypsotenm byV iaslilo sntafokrehthoeldSeorSs iCnM oBrder to define the functionality and 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. and the account database. The students also considered the failure condition, in which an account is not created. Including these two end conditions is necessary to demonstrate the destruction of data upon failure.
The most challenging aspect of designing activity diagrams was determining when and where data flow occurs, as the students had difficulty in defining the interaction between the system and the accounts database.
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, deployment requirements, and system constraints.
The students reported slight difficulty in eliciting nonfunctional 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 determine 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.
The functional hierarchy in Fig. 10 decomposes the userperceived 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 requires 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 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 subfunction to most of the other functions, so there were many arrows pointing to that function and many boxes surrounding it. As a result, they chose to make the “signin to account” function “activate” all the other functions, which solved the problem and made the diagram much easier to read.
Early design decisions like this were the most discussed point about function hierarchies and show where RE and design have to be integrated or may overlap.
In the peer review, students tended to be very generous to their developer teams. They commented on a few minor mistakes or how the specifications could have been extended, but in general they were satisfied with the work of their peers. Most of the teams had gone through the effort of reworking their specifications after the initial feedback from the teaching assistants, so those efforts apparently had paid off, as the specifications had improved considerably.
The teams presented excerpts of their solutions within five minute presentations during the last two sessions of the course before the final exam. At this stage of their curriculum, the students do have experience in presenting in front of a large
This functional hierFaricgh.y1 0di.agFraumn c rteiolinesH hieearvairlcyh oyn foourr tUhesaSgoe SMCodMelB 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”, audience, but their pre“sSeignnt-aint itoo naccsokunilt”ls, “Mvoanriiteodr pecrsoonnasli dpreorgarebslsy”., “Diuspsluaya lthlye vicdoeom ppagoes”e, d“Coomfmfernite onnd as viwdeho”o, therefore had established “Display assignments”, “Display calendar of events”, “Share pictures from events”, and “Display pictures While some teams madoef aann eveefnfto”.r Atltl oof mtheaske efunthcteioirns pcroentsaeinn staubtifounnctioncs oanmd msoumne ihcaavtei oexnterhnaalb inittser,fawcehs isluech nasew teams first had to get to engaging, others only “p<uPtictuinre cthhoesenm>”i nanidm “u<mAccoreunqtu inirfoerdmaetifofno>r”t. Thek dneopewndeenacciehs boetthweeerna enacdh fifunncdtiocno amndmon denominators. to deliver an acceptablesubsfuunmctmiona rayre. dPepriecsteedn btya tairoronwss lkaiblellsed awrieth o“rfequires”, “activates”, and “precedes”.
C. Solution Space critical importance to successful customer communication and should therefore be part of anWRe Efaccedo murasney .problems during the creation of thTis hdeiagdraems.i gWnhilsep waec leistueds eoudt ebaych tfuhnectisotnu,dents was rather limited we tended to think too broadly and in general terms abocuot mthep MarOeOdC,t oinstweahd aotf thwe islplecaifcict ureaqlulyirembeentsimplemented. Were the V. DISCUSSIOthNat AweNreD reLquEeSstSedO bNyS ouLr EclAienRtsN. EFoDr example, we initsiatullyd epuntt “sensriomll pinltyo cnouortsesi”n taes roenset oefd theenough or not knowledgeable functions of this MOOC. However, we later realized thaetn tohius gish n?ot what our clients wanted since they
Or were the re-documenting what they saw elsewhere A. Overall Quality of Rweasnuteldts all the users to participate in one big course on the same game board. We also had an issue with
The range of solutiondesteermxitneinngd sthef rsuobmfunbctaiodnst oof cgeortoaidn ,paarsentw fuenlcltions and figuring out whether “activates,” “precedesT,”his depends partially on without considering other options? as from little effort toor “requires” was more suitable for describing how certtahine ifurnecxtiopnesr iinetnercaect,ed with eacho onthetrh ieni trhecreativity and motivation for but also major effort that was put into the hierarchy. Another problem that we encountered was mcaokimngi nthge fuunpctwioniathl hineerawrchiyd deiaagsraimn ltohoiks clceoanurse. development of the specanifid creaatdiaobnle.. The user was required to go through the “sigHn- ianv tion agcccouhnot”s efunncatiopnr obebfloerem bedinogm alaloiwnetdhat would likely increase
The grades in the midt-ot uesrem thea nredst tohf ethefi fnuanlcteioxnas min twhee MreOOavCe sryasgteem. It mwaost tihvea stuibofnun(cstieone toS meco.st IoIfI t-hBe )o,thwere were interested in how much
for a RE course, not mfunucctihonsd, isfof tehreeren wceerew maasny parerorcwes ipvoeindtinfgr otom that fusnucstitoani nanadb milaitnyy bsohxoews seudrrouupndiinngt iht.e Airs rae rsesuulltts,. The answer is: only in
other years (comparisonwe acshospee troc meaivkee dtheb “ysignte-ianc toh ianccgouanst”s fiusntactniotn) “activate” all the other functions, whMicho sdoelvle,di fouart all. Some even reduced it
System Vision and Goal
or from earlier teachingperoxbpleemri aenndc meabdey thteh deiafigrrasmt amuutchh oerasaietr toot rheeadr. 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
program [
RE.
There is a strong correlation between the students level of experience and the quality of the work that they produced on the project. Students who had experience in software development projects and even worked in industry managed their teams in a very effective way and provided medium to high quality specifications. On the downside, they often strongly focussed on the technical aspects of the system (solution-orientation) and neglected stakeholder communication (problem-orientation).
There was a perceivable difference between the groups that were self-selecting and the groups that were assigned in terms of the work they produced. Teams who had self-selected were
This section sums up the lessons learned of the experience report at hand.
Reduce Number of Assignments: Effort estimation in student projects is hard, but as first-timers every artifact takes more time to elaborate and team work requires a lot of discussion if done properly. The conclusion is to ask for less artifacts when the course has only 10 weeks—it was too much stuff to deal with in such a short time—and to probably cut out function hierarchies because they are strongly design-oriented.
Real Stakeholders Motivate: While the students liked having
a “real system” to work on, they would have preferred to
talk to a real person involved in the project as opposed to
having to rely on documents, online research, and future
users. Consequently, for the next iteration of the course, we
will again put a real stakeholder in class (compare to the
BMW DriveNow case study [
Choice of Problem Domain: There are challenges when motivating the pragmatic topic of RE with a project that is, itself, motivated by what might be perceived as an ethical choice. Does the ethical choice resonate with the students (positive motivator), is it ignored (neutral, but not achieving your personal goal to enlighten them), or does it annoy them? When looked at from a software system perspective, RE is about the content to be represented in the system, not the system purpose. The question of whether or not the content of the project enhances or detracts from the mechanics of the course material is hard to answer without back-up by significant empirical data. It was perceived that the students were enjoying the topic of the problem domain but there might have been students who were negatively motivated by the topic without providing feedback on that. Next time we will include a question on this in the course evaluation survey.
Value-based Design: Sustainability is not a concern that visibly showed up in the solutions other than in the goal model and system vision. Environmental sustainability was used as example for a value that could be supported in valuebased design. While it was not the intention of the course to promote any political agenda, this was a value that students would generally be willing to accept and that was a little easier to grasp than a value like “fun”. The fact that the value was not made very explicit in the solutions shows that for practicing any kind of value-based design, this needs to be put into an exercise more explicitly, for example by making different teams design for different values and comparing the differences amongst their solutions.
This paper reported on the experiences with using an online course, the Citizen Muscle Boot Camp, under development at the Story of Stuff Project, as study system for the assignments in an undergraduate RE course at the University of California, Irvine. The Story of Stuff Project used the results as additional input for the actual development of the CMB. The major lessons learned are that artifact-oriented RE works well to structure assignments, but also needs to be restricted to the given time frame of the course, that real-world systems do motivate students, but even stronger motivation and commitment to developing a good requirements specification can be achieved by inviting real stakeholders, and that the choice of the problem domain might influence students’ motivation. There are a few follow-up questions to be explored in future work, for example, whether value-based design should be included as a concept when teaching requirements engineering, and how significantly the choice of problem domain affects the motivation of the students in such a course. For the next iterations of the course at UCI, we will try to allow the students to perform interviews with real stakeholders for a system under consideration in practice.
Acknowledgements: This work is supported by the DFG EnviroSiSE project under grant number PE2044/1-1.