Session T2C

AN ACTIVE/ COLLABORATIVE APPROACH

IN TEACHING REQUIREMENTS ENGINEERING
Daniela Rosc h
Abstract- The requirements engineering ( R E ) course

is a component of the curriculum for the Masters in

Software Engineering (MSSE) program, at Monmouth
University. I t has been the first software engineering
programin New Jersey and one of the first an the
nation. The R E course introduc esstudents to the
process, methods and tools specific to this area, and
the corresp onding software quality issues. The course
is offer edin a lecture and lab format. T o reinfor ce
the conc epts learne d, students actively particip ate an
their learning as they play differ entroles for eliciting
requirements, collab oratively improve the quality of
their standard requirements do a m e n t s , o r shar e their
particular exp ertise with their teams when performing
obje ct-oriental analysis. This pap er describ es the cuiwnt
structur e of the R E ourse and my experience related t o
the active/collab orativeappr oaches in tuching at.

INTRODUCTION
The softw are engineering program at Monmouth
University was initiated in 1985, and was hosted by the
Department of Computer Science. In 1995 the Softw are
Engineering Department w as created,offering a master
of science degree in softw areengineering. In 1999 a
certificate in soft w are engineering program vas started,
and in Fall 2000 a new baccalaureate program in softw are
engineering will be launched. Since 1999 the softw are and
electrical engineering departments ha ve been merged.
The requirements engineering (RE) course is part of
the curriculum for the masters in soft w areengineering
(MSSE) program. The curriculum is composed of
a sequence of fiv e core courses, fiv e electiv es, and a
six-credit capstone course. Requirements engineering
is one of the five core courses, which include also
formal methods, design, verification and validation, and
soft w are processes.We assume that students en tering the
RE course ha veas bac kgroundan introductory course
in soft w are engineering, or an adequate professional
experience. While the introductory course teac hes
Monmouth Univ ersity,Department of Soft w areand Electrical
Engineering, West Long Branch, NJ 07764, droscaOmonmouth.edu

students basic RE methods, like structured analysis

or object-oriented analysis, the RE course pro vides
students an in depth exposure to these topics and many
others that ha venot been touc hedin the introductory
course. Also students ha v e the opportunig to apply their
kno wledge on case studies that require both analysis and
syn thesis skills, and produce tw ostandard documents:
the operational concept (OCD) document and the
softw are requiremeis specification (SRS) document.
The student population is very heterogeneous:
people with a computer science bac kground,or people
who are changing their careers; people with a
couple of years of experience in softw aredev elopmet,
managers of softw are teams, or fresh graduates of
a baccalaureate program. How ever, their common
characteristic is their position as users and not
pro duc ersof soft w are requirements, implied b y their
various professional occupations (designers, dev elopers,
or testers of softw are). Therefore, the RE course
introduces these students to the process, methods
and tools necessary to p r o duc ethe requirements of a
system. This course fosters an activ e/collaboratis
learning atmosphere that includes playing different roles
for eliciting requirements, collaboratively improving the
qualit y of their standard requirements documents, or
sharing their particular expertise with their teams when
performing object-oriented analysis.
This paper is organized as follows: Section 2 presents
the structure of the course, Section 3 describes the
activ e/collaboratis approaches to teac hing this course,
while the last section discusses lessons learned and ideas
for further improvements of the course.

COURSESTRUCTURE
The course is structured for a fourteen w eeksemester,
in a lecture and lab format. Classes meet once a w eek
for tw o hours and 45 minutes. This time is divided
betneen lecture and lab according to the topic of the
da y .The course objectives are to introduce the students
to the process of requirements engineering, and to the
methods and tools available for eliciting, analyzing,
specifying, validating and managing requirements. In

0-7803-6424-4/00/$10.00 @ZOO0 IEEE

October 18-21, 2000 Kansas City, MO
30th ASEE/IEEE Frontiers in Education Conference
T2C-9

Session T24
addition, quality criteria are discussed in the context of
validating and testing the requirements. A related goal
of the course is to sho w the students that there is no
silv er bullet method for capturing the requiremerts of
a project. Instead, a spectrum of methods should be
applied, according to the specifics of the system. Another
important message is that requirements ha v e a life of
their o wn that needs to be managed throughout the lifecycle of the system.
The textbook used ([5]) organizes the material very
w ell, but needs to be supplemerted with other books and
papers for a more in depth coverage. Some of the books
used as supplements are [9]- a collection of papers in the
RE area, [SI - a practical guide on RE, [SI - a fun to
read and easy to understand book on use cases, [4] an excellent description of UML, and [2] - a practical
introduction to IDEFO.
The topics discussed in this course are shownin
T able I. W CO wr a wide palette of elicitation techniques,
follo w ed b y structural and object-oriented analysis
methods, and the specification of the requirements in
the SRS document. F ormal specification languages and
techniques are not cwered because they are discussed in
depth in the formal methods course.
The concepts presented in lectures are reinforced
during labs, in four assignments, and in tw oprojects.
The assignments for the course are presented in Table 11.
The first project is assigned after the elicitation phase
has been coveredby lectures, and consists of the OCD
for a system indicated b y instructor. The purpose of
this project is to make students understand the problem,
articulate the differences betwen the old and new
system, and exercise the use cases method for eliciting
requirements. The second project is assigned after the
structural analysis has been covered b y lectures, and
consists of the SRS for the same system as in project one.
This project is intended as an exercise for the analytical
and synthesis skills of the students in order to determine
the requirements of the system, and model the system by
applying the most appropriate modeling techniques. The
qualit y of the requiremeds produced is judged according
to ho w w ell they meet the user needs and the qualit y
criteria imposed on requirements documents. The SRS is
dev eloped according to the military standards, whih are
thorough and contain v aluable information (traceabilig,
for example) which has not made its way into the IEEE
standards yet. Students find it helpful to receive sample
documents for eac h of the projects. So far, the projects
assigned have been the introduction of on-line monitoring
in a hospital, and the introduction of a bank ATM.

ACTIVE/COLLABORATIVE
LEARNING
As stated in the activ e/collaborativ learning (A CL)
literature ([l],[7]) the characteristic elements of A CL
are: positive interdependence, individual accountabilit y ,
group processing, social skills, and face-to-face
interaction. These elements are practiced in the RE
class in several situations that are described next. First,
during the RE lab, students w ork in teams of 2-3 people
and every one is expected to be prepared to answr when
ask ed for communicating the result of the team w ork.
How everjf a member of a team has some bac kground
on the particular method they are learning, that person
is supposed t o be the leader of the team. This happens
sometimes when students ha ve tak en a class on databases
in their undergraduate curriculum, and are familiar
therefore with semantic modeling and entity-relationship
(ER) diagrams, or if students ha vetak en an objectorien teddesign class and are familiar with the objectorien ted modeling.
When learning the elicitation techniques, students
h a v e t h e opportunity to practice them using a role
pia ying approach. F o r example, when practicing the
brainstorming technique, they form teams of 4-5 people,
where eac h participant has a specific role: the user(s),
the customer, the requirements engineer, or the softw are
engineer. Students are given the description of the
Customer Statement of Needs and their particular role
description to study at home and come up with a
list of possible requirements according to their specific
role. In class, the idea generation phase is mediated
b y the requirements analyst who keeps the meeting
focused and tries to obtain as comprehensive a list
of requirements as possible, for the time alloted (30
minutes). In the consolidation phase (30 minutes),
the requirements analyst is going over the previously
generated list of requirements and together with the
other members of the team organize the requirements
according to their desirability and priorit y. During
this exercise students practice and begin to appreciate
the positiv einterdependence, social skills and the faceto-face interaction that occur in the interviews with
multiple stak eholders. Students are very pleased with
these exercises, because they feel that they really h a v e
the opportunity to think about the questions they need
to ask in order to clarify some ambiguously stated
requirements, and learn to deal with difficult situations,
like for example, when the stak eholders are not willing
to cooperate.
When the students learn methods for object-oriented
analysis, they form teams of 3 people, each student in the

0-7803-6424-4/00/$10.00 @-Z O O 0 IEEE

October 18-21, 2000 Kansas City, MO
30th ASEE/IEEE Frontiers in Education Conference
,

T2C-10

Session T2C
TABLE I Lecture topics

I Tonics
1
RE process, functional, non-functional requirements
Brainstorming, JAD, interviews,questionnaires,ethnographic studies
TJRP
- -- r--a n--~ n
Viewpoints
Analysis
Structural Analysis (DFD, SADT(IDEFO), ER)
Object-oriented Analysis (UML)
SRS document, IEEE/military standards
Specification
V alidation and Reviews,prototyping,testing,
Management
traceabilit y,change managemert

I ISSUES

Overview
Elicitation

TABLE I1 firther learning experience

Assignment
1

Topics
Viewpoints
Identification of viewpoirts, identification of viewpoirt attributes,
inheritance relationships among viewpoints, event-diagrams
DFD
hierarchical represen tation of information
data dictionaries
IDEFO
hierarchical represen tation of information
00 Analysis
class diagrams
sequence diagrams
state diagrams

team being responsible for a specific type of modeling:

capturing the class diagram, the sequence diagram or
state diagram. Each group receives a use case that has
to be analyzed and modeled. After all use cases are
modeled, each exp ertis teaming up with his homologues
from the other teams to come up with the model of the
whole system, from their specific perspective. This way
students are capable of solving more complex problems
and have the c Lance to explain and bring argumeb for
their o wn models to their peers.
Another example of cooperation is the production
of the SRS document. Each student is responsible for
coming up with a complete SRS for a system indicated by
the instructor. An SRS standard and a sample document
are discussed in class previously to the assignment of this
project. Students are all0 w ed to apply apmethods they
find appropriate to come up with the requirements of the
suggested system. Since this project is assigned at about
the middle of the semester, the techniques learned in
class are only those subsumed by the structured analysis.
Students ha ve four weks to prepare the SRS. By the time
they turn in the SRS, students w ould ha velearned in
class tec hniques and criteria for requiremerts validation.
Therefore, each student is paired up with another

colleague who will validate his SRS document. Both

versions of the SRS, the original one, and the annotated
one are turned in to the professor for grading. Students
ha vethe opportunity to incorporate the feedback from
the professor and their peers and improve the quality of
their SRS documents, which will receive the final grade
for that project.
This approach was induced by the observation that
when the SRS w as just another assignment, students
treated it with less importance, and delivered documents
of lesser quality. Also, the type of information captured
in the SRS had to be drastically restricted due to a
limited amount of time for preparing it. A similar
feedback came also from our outcomes assessment
of the capstone course, which sho w edthat students
w ere not sufficiently prepared to deliv er good qualit y
SRS documents. After introducing this collaborative
technique, a visible increase of the SRS qualit y w as
noticed, as opposed to the situation when the teacher
w as the only person who examined the projects.

October 18-21, 2000 Kansas City, MO

0-7803-6424-4/00/$10.00 (32000 IEEE
30th ASEE/IEEE Frontiers in Education Conference

T2C-11

Session T2
CONCLUSIONS
One of the goals of this course is t o dev elopstudents
skills at all fiv e levels of the Bloom taxonomy [3].
Specifically, at the kno wledgeand comprehension lev el
w e make sure that the students h a v e the necessary
kno wledgeand essen tial concepts of qualit ycriteria for
requirements, that w ould enable them to successfully
apply this kno wledge, using either CASE tools or
manually . A t the analysis lev el, w e observe ho w w ell
the students are capable of determining the requirements
that a system must satisfy, by performing different types
of stak eholders iierviews, or other elicitation techniques.
A t the sylthesis lev el, w e obsemhow well the students
are capable of modeling a system, suc h that it meets
stak eholders needs. Also, the qualit y of their SRS
documents is monitored. Finally, at the evaluation level
w e are looking at deeloping skills that enable students
to successfully review standard documents specific to
requirements engineering.
The validit yof this course structure remains to be
seen a year from now, when the first students who have
tak en the class in this format will ha vecompleted the
capstone course. F o r the near future, w eare planning
the in troduction of one of the commercial tools arailable
for requirements engineering, specifically, either DOORS
(Quality Systems & Soft w areltd.) or RequisitePRo
(Rational Soft w arecorp.), as a support tool for the
course assignments.

REFERENCES
[I] Activ e/collaborativ e learning and teaming in the college
[2]

[3]
[4]
[5]
[6]

[7]

[8]
[9]

classroom. Workshop - Frontiers in Education Conference FIE99.

C. Feldmann. The Practical Guide to Business Process
R eengine ering using IDEFO Dorset House Publishing, 1998.
G. Ford. Adaptation of the Bloom taxonomy to software
engineering. Technical Report 90-TR-3, SEI, 1990.
M. Fowler and K. Scott. UML Distilled: Applying the
Standar d Obje ct M O delling L angunqkidison Wesley, 1997.
G. Kotonia and I. Sommerville. R equirements Enginering Processes and T echniquesJohn Wiley & Sons, 1998.
G. Sc hneider and J . Wiher. Applying Use Cases: A Practical
Guide. Addison Wesley, 1998.
K. A. Smith. Cooperative learning: Effectiv eteam w oruor
engineering classrooms. In Proceedings of the Frontiers in
Educ ation Confeence IEEE Computer Press, 1995.
I. Sommerville and P. Sawy er. R equirements Enginering - A
Go d Practice Guide. John Wiley & Sons, 1997.
R. Thayer and M. Dorfman. Softwar e R equirements IEEE
Computer Press, 1999.

October 18-21, 2000 Kansas City, MO

0-7803-6424-4/00/$10.00 @2000 IEEE
30th ASEE/IEEE Frontiers in Education Conference

T2C-12