Sei sulla pagina 1di 4

Session T2C

AN ACTIVE/ COLLABORATIVE APPROACH IN TEACHING REQUIREMENTS ENGINEERING

Daniela Rosc h

Abstract- The requirements engineering (RE) course

is a component of the curriculum for the Masters in Software Engineering (MSSE) program, at Monmouth

It has been the first software

University.

engineering

programin New Jersey and one of the first

nation. The RE course introduc esstudents to the process, methods and tools specific to this area, and the corresp ondingsoftware quality issues. The course is offer edin a lecture and lab format. To 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

an the

requirements do aments, or 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 RE ourse and my experience related to

their standard

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

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 1999the 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 softw are processes.We assume that students en tering the RE course ha veas bac kgroundan introductory course in softw are engineering, or an adequate professional experience. While the introductory course teac hes

1999 a

Monmouth Univ ersity,Department of Soft w areand Electrical Engineering, West Long Branch, NJ 07764, droscaOmonmouth.edu

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

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 ve 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 softw are requirements, implied by 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 pro 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.

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.

This paper is organized as follows:

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

October 18-21, 2000 Kansas City, MO

30th ASEE/IEEE Frontiers in Education Conference

T2C-9

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 vea life of their o wn that needs to be managed throughout the life- cycle of the system. The textbook used ([5]) organizes the material very

w ell, but needs to be supplemertedwith 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 by 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

for a system indicated by instructor. The purpose of this project is to make students understand the problem, articulate the differences betwen the old and new system, and exercisethe “use cases” method for eliciting requirements. The second project is assigned after the structural analysis has been covered by 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.

coveredby lectures, and

consists of the OCD

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

,I

-

IEEE

Session T24

ACTIVE/COLLABORATIVELEARNING

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

How everjf a member of a team has some bac kground on the particular method they are learning, that person is supposed to 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 object- orien teddesign class and are familiar with the object- orien ted modeling. When learning the elicitation techniques, students havethe opportunity to practice them using a role pia ying approach. For 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 by 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 face- to-face interaction that occur in the interviews with multiple stak eholders. Students are very pleased with these exercises, because they feel that they really have 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 eholdersare not willing to cooperate. When the students learn methods for object-oriented analysis, they form teams of 3 people, each student in the

team w ork.

October 18-21, 2000 Kansas City, MO

30th ASEE/IEEE Frontiers in Education Conference

T2C-10

I ISSUES

Overview

Elicitation

Analysis

Specification V alidation and Management

TABLE I Lecture topics

I Tonics RE process, functional, non-functional requirements Brainstorming, JAD, interviews,questionnaires,ethnographic studies ~

TJRP ran~n

--- -- --

1

Viewpoints

Structural Analysis (DFD, SADT(IDEFO), ER) Object-oriented Analysis (UML) SRS document, IEEE/military standards Reviews,prototyping,testing,

traceabilit y,change managemert

TABLE I1 firther learning experience

Assignment #

Topics

Session T2C

1

Viewpoints Identification of viewpoirts, identification of viewpoirt attributes, inheritance relationships among viewpoints, event-diagrams

2

DFD hierarchical represen tation of information data dictionaries

3

IDEFO hierarchical represen tation of information

4

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

0-7803-6424-4/00/$10.00 (32000 IEEE

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 yw 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

30th ASEE/IEEE Frontiers in Education Conference

T2C-11

CONCLUSIONS

One of the goals of this course is to dev elopstudents’ skills at all fiv e levels of the Bloom taxonomy [3].

comprehension lev el

w e make sure that the students have 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

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. For 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.

Specifically, at the kno wledgeand

capable of modeling a system, suc h that it meets

REFERENCES

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

classroom.

Workshop - Frontiers in Education Conference -

FIE’99.

The Practical Guide to Business Process

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

[2]

C.

Feldmann.

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

Session T2

October 18-21, 2000 Kansas City, MO

30th ASEE/IEEE Frontiers in Education Conference

T2C-12