Digital Home: A Case Study Approach

to Teaching Software Engineering

Concepts
Salamah Salamah1, Massood Tawhidnejad2, and Thomas Hilburn2
1
Department of Computer Science, The University of Texas at El Paso, El Paso, Texas, U.S.A.
and 2Department of Electrical, Compute, Software, and Systems Engineering, Embry Riddle
Aeronautical University, Daytona Beach, Florida, U.S.A

ABSTRACT
While many software engineering (SE) and computer science (CS) textbooks make use of case studies to
introduce difference concepts and methods, the case studies introduced by these texts focus on a specific
life-development phase or a particular topic within software engineering object oriented design and
implementation or requirements analysis and specification. Moreover, these case studies usually do not
come with instructor guidelines on how to adopt the introduced material to the instructor’s teaching style
or to the particular level of the class or students in the class. The DigitalHome Case Study aims at
addressing these shortcomings by providing a comprehensive set of artifacts associated with the full
software development life-cycle. The project provides an extensive set of case study modules with
exercises for teaching different topics in software engineering and computer science, as well as guidance
for instructors on how to use these case modules. In this chapter, we motivate the use of the case study
approach in teaching SE and CS concepts. We provide a description of the DigitalHome case study and
the associated artifacts and case modules. We also report on our use of the developed material

INTRODUCTION
Case studies were first used in the Harvard Law School in 1871 (Tomey 2003) and since then much study
and research have been done on the effectiveness of the use of case studies in teaching and learning
(Davis & Wilcock 2013, Fritz, Grupe & Joelle 2000, Herreid 1994). Case studies have been particularly
effective in teaching professional practice and have been widely used in such fields as business, law, and
medicine. The main advantage of using case studies in the classroom is that they allow the instructor to
create a realistic environment and context for the study of real problems in an academic setting. A case
study is based on actual events and documents, or at least pseudo-real events and documents. The case
study typically describes a problem, using a scenario format providing the context and summarizing key
issues and events related to the problem. The scenario is usually supplemented with background material
(setting, personalities, sequence of events, and problems and conflicts), artifacts, and data, which is
relevant to the situation depicted to help immerse the audience in the real-world situation to be discussed,
studied, or analyzed.
While case studies can be effective when used in a prescriptive, teacher-centered teaching environment,
they are most effective when used in an active, student-centered approach, where the session instructor
acts as a facilitator or coach. Case studies are of special value in problem-based learning, concentrating on
the development of problem-solving skills, self-directed learning, and teaming skills. The State University
of New York in Buffalo website (SUNY-Buffalo Website) provides examples of excellent case studies in
science and engineering.
The use of case studies in education has shown great success in medicine, law, and business. However,
this teaching style has seen little use in computing education. For example, currently, the SUNY-Buffalo
web site contains over 350 case studies in science and engineering, but only five of these are concerned
with some aspect of computing. We suspect that one of the principal reasons for this lack of usage of case
study-based teaching is the shortage of sufficient material for this purpose. Many software engineering
and computer science textbooks use case studies to illustrate concepts and techniques including an Airline
Reservation System and a Household Alarm System (Lethbridge &Laganière 2001), Fireworks Factory
(Metsker 2006), Picadilly Television and Ariane-5 (Pfleeger 2005), and SafeHome (Pressman 2007) these
case studies often lack the following:
 Realistic artifacts (often space does not allow providing a complete requirements or design
document),
 Completeness (covers only a portion of the life-cycle, and not an end-to-end), with a focus on
design and implementation,
 Ability to decouple from the text and apply in ways not intended by the author,
 Techniques for integration into course activities or into the curriculum as a whole,
 A scenario format that would motivate students to get engaged in problem identification and
solution, and
 Guidance to the instructor on how to use the case study to teach a course topic or concept.

In previous work (Hiburn & Towhidnejad 2007, Hilburn, Towhidnejad, & Salamah 2008) we introduced
the DigitalHome case study as a way to address these shortcomings by providing a complete set of
artifacts associated with software development as well as providing case modules (mini-case studies
addressing different aspects of the DigitalHome project) that can be used by faculty in teaching different
subjects in a computing curriculum. In this chapter, we provide a detailed description of the DigitalHome
case study material developed so far. In addition, we highlight our experiences in using the case study
material in different software engineering courses at our institutions.

BACKGROUND
Engineering Case Studies
The Accreditation Board for Engineering and Technology (ABET) requires that all engineering programs
involve their students in “a major design experience based on the knowledge and skills acquired in earlier
course work and incorporating appropriate engineering standards and multiple realistic constraints”
(ABET 2013). Usually, students are grouped into teams to work on a semester or year-long senior
engineering development project. This experience is too often isolated from the rest of the curriculum and
does not form a real-world basis for the entire curriculum. Although, students may be exposed to elements
of engineering practice in their foundation engineering courses, they often arrive in their senior project
course with disjointed view of engineering practice and have an insufficient appreciation and
understanding of the complexity and multifaceted nature of real-world development environments. In
addition, students often lack sufficient team, analysis, and communication skills. Therefore, it is
imperative that engineering curricula introduce professional and real-world education throughout a
curriculum. Many programs now introduce small team-based engineering projects in the early part of the
curriculum. Case studies can be used to support and extend such experiences.
An excellent way to address the challenges of introducing real-world exposure through a curriculum is the
use of a robust lifecycle engineering case study – that is, a case that engages the student in the engineering
of a complex system throughout its “life”: system definition, preliminary and detailed design,
implementation, verification and validation, and operation and maintenance. The literature describes a
variety of ways that case studies can be used to support learning and research, sometimes referred to as
the “case method” (Friedman & Sage 2004, Herreid 1994, Davis & Wilcock 2013). Although as
mentioned above, case studies should be viewed as active learning tools; the case method can be mixed
and matched with other pedagogies such as lectures, guided discussions, and project work. Case studies
can be used to supply the background needed for specific problems and design projects; serve as subjects
for class discussions; or they can be used to motivate further study, and to identify and formulate research
problems.

DigitalHome, A Software Engineering Case Study

For several years the authors have been involved in a case study project that focuses on the development
of a DigitalHome (DH) system (Salamah, Towhidnejad, & Hilburn 2011). The DigitalHome Project,
when completed, will cover the complete life-cycle development of a software product (project
management, requirements analysis and specification, design, implementation, testing and maintenance).

The DH Project is based on a scenario about a real-world, but fictitious, company, HomeOwner, which is
the largest national retail chain serving the needs of home owners. HomeOwner, based on market and
technology research, decides to invest in the development of a “smart” house, the DigitalHome system.
The development team of the DH is a fictitious group of developers with diverse cultural as well as
technical backgrounds. The DH has following features:
 The DH system shall allow any web-ready computer, cell phone or similar device to control a
home's temperature, humidity, lights, security devices, and the state of small appliances.
 The communication center of the DH system shall be a personal home owner web page, through
which a user can monitor and control home devices and systems.
 The DigitalHome shall contain a master control device that connects to the home’s broadband
Internet connection, and uses wireless communication to send and receive communication
between the DH system and the home devices and systems.
 The DigitalHome shall be equipped with various environment sensors (temperature sensor,
humidity sensor, power sensor, contact sensor, etc.). Using wireless communication, sensor
values can be read and saved in the home database.
 The DH system shall include programmable devices (thermostats, humidistats, contact sensors,
and small appliance and lighting power switches), which allows a user to easily monitor and
control a home’s environmental characteristics from any location, using a web ready device.
 The DH system shall include a DH Planner, which provides a user with the capability to direct the
system to set various home parameters (temperature, humidity, and on/off appliance and lighting
status) for certain scheduled time periods.
 The interaction between the DH and the surrounding environment shall be simulated. Figures 1
and 2 below show the DH Planner GUI and the DH simulator

The Case Study Project focuses on developing a complete set of artifacts associated with software
development (e.g., Requirements Document, System Test Plan, …) as well as case modules (a “mini-case
studies”). These artifacts and case modules are related by being part of and derived from a single case, the
development of a single software product. Each case module relates to an artifact or activity involved in
the development of the product. In addition, each case module is framed as part of a product development
narrative, using a scenario format, which involves characters and incidents that would be part of an actual
software development project (e.g., formation of a software project team, interaction with upper
management, customer and user interviews, writing a use case description, formal inspection of a
software artifact, designing a class interface, a design walk-through, system testing, etc.).
The DigitalHome Case Study is intended to cover the complete life-cycle development of a software
product (project management, requirement analysis and specification, design, implementation, testing and
maintenance). The initial phase of the case study project, concentrated on building a foundation for full
development: research into case study teaching; identification of a case study problem; creation of a
scenario framework; description of a launch of the software development team; development of a
software development plan to be used as part of the case study; and development of several related case
modules.

Figure 1 DH Planner GUI

The initial phase of the case study project concentrated on building a foundation for full development:
research into case study teaching; identifying a case study problem; creating a scenario framework;
describing the launch of the software development team; fashioning a software development plan to guide
development of the DigitalHome System; establishing a development process; creation of a DigitalHome
need statement; analysis, modeling and specification of the DigitalHome requirements; development of a
system test plan; development of a software architecture; and specification of the system components.

We have developed a set of DH mini-case studies/modules which are designed to engage students in
active learning software engineering activities related to development of the DigitalHome System. With
this life-cycle engineering case study, we advocate a “Team Learning Format” (Herreid 1994). Our
approach involves the following activities:
 Students are assigned prior reading or other preparation.
 Instructor introduces the case, providing motivation and giving background.
 Instructor divides class into teams and if necessary, assigns roles. Students are usually asked to be
the role of one of the six members of the fictitious development team
  Teams work on a case module exercise: discussing problems/issues, answering questions and
making decisions, and prepare report of their conclusions.
 Teams present their report to class and class discusses results.

Figure 2 DH Simulator

THE DIGITALHOME MATERIAL

The development of the DH cases study has consisted of writing scenarios, developing DH artifacts, case
modules and exercises. Thus far, Project Inception, Project Launch and Planning, and Requirements
Analysis and Specification have been completed. In this section we provide a sample case module and
exercise to better describe the content and directions for use of such modules. Table 1 shows a listing of
the currently available Case Study material. The case study material is available for download and use at:
http://www.softwarecasestudy.org/. Each case module consists of the following parts:
 Case module title: a descriptive title of the module and its intended use.
 Students’ prerequisite knowledge
 Learning objectives: a list of students’ abilities based on the completion of the case module
 Keywords
  Case study artifacts: a list of DH material to be used in the case module and the accompanying
exercise
 Case Study Participants: members of the fictitious team taking part in the case module and
exercise
 Scenario: a detailed description of the context of the real-world settings to be used in the case
module and exercise.
 Exercise: description of the exercise and deliverables of the students participating in the case
module. The students are also provided an exercise booklet separate from the case module, which
is intended for the use of the instructor only.
 Resource information: any other reading or helpful material outside the scope of the DH material
 Teaching notes: suggestions and alternatives on how to use the case module for teaching the
specific topic.
The following text is Software Requirements Specifications (SRS) case module. We also refer to this
module in later sections of this chapter.
Case Module : SRS Inspection
Prerequisite Knowledge: Understanding
of basic elements of a Fagan Software Inspection process.
Learning Objectives:
Upon completion of this module students will have increased ability to:
1. Appreciate and understand the roles and responsibilities of an inspection team
2. Work as a member of an Inspection Team.
3. Work more effectively as part of a team.
4. Assess the quality of a Software Requirements Specification (SRS).
5. Describe problems in specifying the requirements for a software product.
6. Explain the inspection process.
7. Describe the value of the Fagan inspection process.
8. Gain experience working with and generating inspection artifacts.
Keywords:
Customer Needs, Software Requirements Specification, Fagan Software Inspection
Case Study Artifacts:
1. DH Customer Need Statement
2. DH High Level Requirements Definition (HLRD)
3. DH Background Scenario
4. DH Team Biographical Sketches
5. DH SRS, Version 1.3
Inspection Package:
 Inspection Process Description
 SRS Checklist
 Defect Log
 Inspection Summary Report Form
Case Study Participants:
• The DH Team
• Jose Ortiz, Director, DigitalHomeOwner Division of HomeOwner, Inc.
Scenario:
In late August of 2010, HomeOwner Inc. (the largest national retail chain serving the needs
of home owners) established a new DigitalHomeOwner division that was set up to explore
the opportunities for equipping and serving “smart houses” (dwellings that integrate smart
technology into every aspect of home living). In August and September of 2010, the
Marketing Division of HomeOwner conducted a needs assessment for a DigitalHome
product that would provide the computer and communication infrastructure for managing
and controlling the “smart” devices into a home to best meet the needs and desires of
home owners. The Marketing Division produced two documents: the DH Customer Need
Statement and the DH High Level Requirements Definition (HLRD).

In early September 2010, a five person team was assembled for the project and started a “project launch”.
After project planning was completed the team began work on requirements analysis and specification.
The first version, 1.0, was completed in early October 2010 and versions 1.1 and 1.2 were completed by
late October.

In consultation with Jose Ortiz, the team has decided to carry out a formal Fagan inspection of the SRS,
version 1.2. Jose has agreed to act as a customer on the inspection team, Michel Jackson is the author,
Disha Chandra will be the moderator and other roles will be assigned in the overview meeting.
Exercise:
1. As preparation for the case method, ask each student to read the Case Study Artifacts listed
above.
2. Divide the class into a set of small teams (4-5 people). Each team takes on a role from
the DH Team or as Jose Ortiz and then follows the inspection process:
a. Planning: The inspection is planned by the moderator.
b. Overview meeting: The author describes the background of the work product, describes the
inspection process, and reviews the inspection forms.
c. Preparation: Each inspector examines the work product to identify possible defects.
d. Inspection meeting: During this meeting the reader reads through the work product,part by
part and the inspectors point out the defects for every part.
e. Rework: The author makes changes to the work product according to the actionplans from the
inspection meeting.
f. Follow-up: The changes by the author are checked to make sure everything is correct.
Resource Information:
 [Fagan,1976] Fagan, M.E., Design and Code inspections to reduce errors in program
development, 1976, IBM Systems Journal, Vol. 15, No 3, Page 182-211.
(http://www.mfagan.com/ibmfagan.pdf)
 [Fagan, 1986] Fagan, M.E., Advances in Software Inspections, July 1986, IEEE Transactions on
Software Engineering, Vol. SE-12, No. 7, Page 744-751. (http://www.mfagan.com/aisi1986.pdf)
 [Humphrey 2000] Humphrey, Watts S., Introduction to the Team Software Process, Addison-
Wesley, 2000.
Teaching Notes:
 This case module could be used in different level courses (from a software level introductory
course in software engineering to an upper level or graduate course in requirements engineering
or quality assurance.).
 Since an appropriate inspection rate is 2-3 text pages per hour, it would best not to assign the
entire SRS to each inspector, but rather some subset – e.g., 6-9 pages per inspector.
 Assuming an adequate student preparation for the exercise, allowing students about four hours
each for the exercise should be sufficient: assuming three hours for preparation and inspection,
and one hour for the inspection meeting.
 It would be beneficial to follow the exercise with a twenty to thirty minute discussion concerning
the student team results. Some key points to include in the discussion are the
following:
  Discuss how closely the inspection process was followed: How well did the team conduct
each phase? How well did students carry out their assigned inspection role (i.e., moderator,
author, inspector)?
 What was the quality of the inspection outline (NOTE: it is very helpful if the instructor
completes the product inspection, and compare the students outcome to the instructor
outcome)
 How well was time managed?
 Address any personal conflict or egoistic attitude displayed.
 Student team members should be cautioned about a few things:
 Leave their ego outside of the meeting room
 Their job is to identify defects, not fix them.
 The SRS is a Requirement document and not a Design specification; so inspect
appropriately and check that design elements have not been introduced by the author or as a
result of inspection. This does not include design constraints specified by the customer.
 Come prepared to the inspection meeting – students need to spend appropriate effort during
their individual inspections.
 It is critical that students understand the data they need to collect (time and defect data), how
to use the forms provided, and the importance being careful and accurate in collecting and
recording data. If students do not properly collect and record inspection data it will be
difficult to assess the effectiveness of the inspection.
 If the course involves actual student development teams, this exercise could provide a good team
building experience: it could be carried out near beginning of a course; it does not require deep
technical knowledge; and everyone can participate.
 If the time and the size of the class permit, the course instructor could take on the role of Jose
Ortiz.
 If the class is divided to multiple teams, if possible, it is best to have each team conduct their
inspection in a separate room, thus eliminating distracting noise generated by other teams.
 It would be best to hold the inspection meeting in class, since it would allow the instructor to
observe this part of the inspection process. For a class of 20 or more, it would be good to have
two instructors observe the inspection meeting.
 A typical team size to accommodate all roles would be 4-5 members, with a maximum of 8 in
order to accommodate a productive inspection meeting.
 It would be best if all team members are inspectors. The author and moderator could inspect but
not include their inspection data in the meeting discussion.
The case module above is intended for the use by the course instructor only. Each case module is
accompanied by an exercise that is handed to the students for completion by the end of the session. The
Software Requirements Inspection exercise follows:
Requirements Inspection Exercise
Scenario
In early September of 2010, HomeOwner Inc. (the largest national retail chain serving the needs of home
owners) established a new DigitalHomeOwner division that was set up to explore the opportunities for
equipping and serving “smart houses” (dwellings that integrate smart technology into every aspect of
home living). In September and October of 2010, the Marketing Division of HomeOwner conducted a
needs assessment for a DigitalHome product that would provide the computer and communication
infrastructure for managing and controlling the “smart” devices into a home to best meet the needs and
desires of home owners. The Marketing Division produced two documents: the DH Customer Need
Statement and the DH High Level Requirements Definition (HLRD).

In early September 2010, a five person team was assembled for the project and started a “project launch”.
After project planning was completed the team began work on requirements analysis and specification.
The first version, 1.0, was completed in early October 2010 and versions 1.1 and 1.2 were completed by
late October.

In consultation with Jose Ortiz, the team has decided to carry out a formal Fagan inspection of the SRS,
version 1.2. Jose has agreed to act as a customer on the inspection team, Michel Jackson is the author,
Disha Chandra will be the moderator and other roles will be assigned in the overview meeting.

Learning Objectives:
Upon completion of this exercise students will have increased ability to:
 Appreciate and understand the roles and responsibilities of an inspection team
 Work as a member of an Inspection Team.
 Work more effectively as part of a team.
 Assess the quality of a Software Requirements Specification (SRS).
 Describe problems in specifying the requirements for a software product.
 Explain the inspection process.
 Describe the value of the Fagan inspection process.
 Gain experience working with and generating inspection artifacts.

Reading Assignment
Read the below Case Study Artifacts:
 DH Customer Need Statement
 DH High Level Requirements Definition (HLRD)
 DH Background Scenario
 DH Team Bios
 DH Launch Scenario

Inspection Package
 Inspection Process Description
 SRS Checklist
 Defect Log
 Inspection Summary Report Form

Exercise Description
1. As preparation for this exercise, read the Case Study Artifacts listed above, except for the DH
SRS. The DH SRS will be reviewed as part of the inspection process in part 3 below.
2. You will be assigned to a small development team (like the DH team).
3. Your team is to take on the role of the DH Team and prepare for the inspection of a Software
Requirements Specification.
a. First, review the inspection package materials (list above).
b. Then follow the Inspection Process and any special instructions from your teacher.
4. Notes:
a. Inspectors should take care to closely review their assigned portion of the
SRS. A review rate of 2-3 pages per hour is reasonable.
b. Each team member must be conscientious about recording all the time spent
during the inspection process.
c. The Rework and Follow-Up phases of the Inspection Process are not part of
this exercise. Also, the part of the Exit Criteria “Software work product has
been revised, removing identified defects” does not apply in this exercise.
For the exercise above, the students are handed an exercise booklet package to complete by the end of the
session. The complete forms can be found at www.Softwarecasestudy.org. The complete list of available
material is displayed in Table 1 below.
Table 1. Current DigitalHome Case Study Material
DigitalHome Item Software Development Phase
Beginning Scenario Pre Project
DigitalHome Development Team Bios Pre Project
Development Strategy Pre Project
Customer Need Statement Pre Project
Case Module: Assessing Customer Needs Pre Project
Exercise: Assessing Customer Needs Pre Project
High Level Requirements Definition Pre Project
Launch Script Launch
Launch Scenario Launch
Conceptual Design Launch
Context Diagram Launch
Development Process Launch
Case Module: Software Process Launch
Exercise: Software Process Launch
Artifact: SRS 1.2 Requirements Analysis
Artifact: SRS 1.3 Requirements Analysis
Use Case Model Requirements Analysis
Case Module: SRS Inspection Requirements Analysis
Inspection Process Requirements Analysis
Inspection Defect Log Requirements Analysis
SRS Checklist Requirements Analysis
Inspection Summary Report Requirements Analysis
Exercise: Requirements Inspection Requirements Analysis
Case Module: Unit Testing Testing
Exercise: Unit Testing Testing
Case Module: Operational Profile Operation and Maintenance
Exercise: Creating an Operational Profile Operation and Maintenance
Case Module: Software Team Problems Others
Exercise: Software Team Problems Others
USE OF THE CASE STUDY MATERIAL
Over the past four years, the case study material has been used in multiple courses in computer science
and software engineering at multiple institutions such as Embry Riddle Aeronautical University (ERAU),
the University of Texas at El Paso (UTEP), and Milwaukee School of Engineering (MSE). This included
the use of developed artifacts as well as case modules. Table 2 shows the complete listing of the case
study material that has been used in computer science and/or software engineering courses at Embry
Riddle Aeronautical University. In the table, courses in bold letters are computer science courses while
the rest are software engineering ones. The rest of the section sheds highlight on and provides results of
the use of the Inspection Case Module and Exercise in multiple courses across ERAU and UTEP.
Table 2. Use of the DigitalHome Case Study Material
DigitalHome Case Study Item Course Description
DH Beginning Scenario Introduction to Software Engineering
Software Quality Assurance
Software Reliability
DH Team Bios Introduction to Software Engineering
Software Reliability
Dh Customer Need Statement Introduction to Software Engineering
Software Quality Assurance
Software Reliability
DH High Level Requirements Definition Introduction to Software Engineering
Software Quality Assurance
Computer Modeling and Simulation
Software Reliability
DH SRS Version 1.3 Introduction to Software Engineering
Software Analysis and Design
Software Quality Assurance
Files and Database systems
Computer Graphics
Software Reliability
Case Module: Software Inspection Introduction to Software Engineering
Software Quality Assurance
Software Reliability
Case Module: Operational Profile Software Reliability
Case Module: Software Team Problems Introduction to Software Engineering
DH Simulator Document Computer Modeling and Simulation
Case Module: Unit Testing Software V&V
DH Simulator Design Document Computer Modeling and Simulation
DH Simulator Detailed Design and Code Computer Modeling and Simulation

The Software Requirements Inspection Case Module

It is now well understood and accepted that software quality is a major influence on software cost and
schedule, and on the ultimate success of a software product. Experience through the years has shown that
quality cannot be an afterthought, but must be “engineered” into the product throughout the software
lifecycle. Although the use of proven techniques and tools for project planning, requirements engineering,
design, and construction can significantly reduce the injection of defects, human error and lack of
capability play a significant role in the defect density of development artifacts. The most influential factor
in addressing quality, cost, and schedule issues is the early removal of defects; removing defects in the
early phases of development can reduce the time and cost of defect removal by 10 to 100 fold, as
compared to removal in test or in the field (Fagan 1976, Fagan 1986).

One of the most effective, proven techniques for defect removal is software inspection. In (Fagan 1976),
Fagan states that software inspections at IBM have “enabled higher predictability than other means, and
the use of inspections has improved productivity and product quality”. (Parnas & Lawford 2003) assert
that “In addition to finding errors in code and related software documents, inspection can also help to
determine if coding style guidelines are followed, comments in the code are relevant and of appropriate
length, naming conventions are clear and consistent, the code can be easily maintained, etc.”. Although
Fagan inspection techniques are used widely in industry, there are still many in the commercial and
academic computing communities who do not understand their value, misuse the technique, or are
unaware of the technique.

An early effort of the DigitalHome case study was the analysis and specification of the software
requirements for the system, which resulted in a Digital Home Software Requirements Specification
(SRS). In addition to the specification of the functional requirements, the SRS includes a description of
user characteristics, development constraints, the performance environment, and nonfunctional
requirements specifying performance, reliability, and safety and security requirements. The SRS also
includes a use case model. As part of the development of the requirements specification, the team
developed a case module for inspection of the SRS (shown in previous section of this chapter). The
learning objectives for the inspection case module go beyond assessing the quality of the SRS, but are
intended to address critical software engineering education goals: appreciating and understanding the
problems in specifying requirements; learning to work as part of a team; and using and following an
inspection process. Although the SRS artifact is the chief focus of the inspection, the others (such as the
background scenario and need statement) provide the setting and context to create a realistic environment
for professional and effective software inspection exercise. The inspection package provides the sort of
forms and tools used in a mature inspection process and help guide the students not only in performing an
effective inspection, but in understanding how a best practice works.

Use of the Inspection Case Module in Class

The SRS Inspection Case Module (and variations of it) has been used in a variety of courses and
workshops: a sophomore-level introductory course in software engineering; an undergraduate course in
software quality assurance; an undergraduate course in software requirements; a graduate course in
software architecture; a graduate course on Software V&V; a faculty workshop in software process; and a
short course in software reliability.

In fall 2009 and spring 2010 the SRS Inspection Case Module was used in three software engineering
classes (two sophomore level classes and one senior level class), in which nine inspection teams were
formed to carry out the module exercise. The inspections concentrated on the functional requirement
statements and used the Inspection Package described in Table 1: Inspection Process Description, SRS
Checklist, Defect Log, and Inspection Summary Report Form. The Report Form includes summary data
about the inspection. The inspection process and materials are based on the work of Fagan (Fagan 1976)
and Humphrey (Humphrey 2000).
Although all teams followed the inspection process, and collected and recorded inspection data, some
elements of the process were performed weakly and not all data was accurate or complete. Table 3 shows
the data for one team, which could be considered typical. In the comments section of Table 3 we compare
the team’s results with benchmark goals for inspection data (based on work by Humphrey 2000).
Although the defect removal rate and the overall inspection rate seem reasonable, the team identified only
10 major defects, while the DH project team had previously reviewed the SRS and identified over 20
major defects (many purposely seeded in the SRS). Two types of defects commonly missed were
compound statements containing multiple requirements, and the testability problems with some
requirements statements. One conclusion might be the inspection team was ineffective; however, we
viewed this more as an education exercise, not strictly a quality assurance activity. By engaging students
in a “close” reading of the SRS, we helped them to understand its meaning, to determine the degree to
which it addressed the customer need statement, to evaluate the correctness, clarity and precision of the
requirements statements, and to identify missing features. We should also note that the collection and
analysis of team inspection data provides the teacher with excellent information on how the inspection
was conducted and the degree to which the case module objectives were reached.

Table 3: SRS Inspection Team Data

Inspection Feature Team Data Comment
Requirements Size 7 Pages The team only reviewed a functional requirements section of the
SRS.
Major Defects Found 10 Correction of a major defect either changes the program source
code or would ultimately cause change in the program source
code.
Major Defects Missed 2 Total defects of 12 were estimated using the
“capture-recapture” method (Humphrey 2000)
Total Inspection Time 14.2 hours 9.2 hrs for preparation time and inspections time; one hr
inspection meeting (times 5 people).
Defect Removal Rate 0.7 def/hr A benchmark goal is 0.5 def/hr (Humphrey 2000)
Inspection Rate 0.49 pg/hr A benchmark goal is < 2 pg/hr (Humphrey 2000)

We believe this sort of “reading” is a critical, first step in helping students (or professionals) prepare for
requirements analysis and specification tasks. Anyone that has been an observer in a student inspection
meeting has seen the degree to which a structured inspection activity engages students in disciplined
reading and understanding of the inspection artifact: students discuss and debate the correctness,
understandability and completeness of artifact elements; they reach an understanding of what the artifact
should and should not contain; and they get a real sense of the meaning of “quality”. In (McMeekin,
Konsky, Change, & Cooper 2009) research was conducted on the utterances of students while engaged in
code inspection teams: the research demonstrated various levels of learning beyond simple knowledge of
the code content. This is a result similar to what we observed in the SRS inspections and that was
illustrated in the defect logs and the inspection summary reports.

While inspecting an SRS does not make one a requirements analyst, it is an important first step; and it
promotes the type of understanding of what requirements are, how difficult they are to get right, and their
importance. This sort of learning is essential to any student who aspires to be a professional software
developer. We believe that using case studies such as the inspection case module provides the perfect
setting and engaging exercise for students to gain better grasp of software engineering concepts.

The experiences of inspection teams also provided valuable input to the DH project team of how well the
SRS Inspection Case Module worked. In analysis of the overall inspection experience we did see ways in
which the case module could be improved. We reviewed all inspection forms to insure they were
understandable and convenient to use and we verified that we had included checks for compound
statements and requirement testability in the inspection checklist. This motivated several changes to the
module: revision of the inspection process and the SRS Checklist to improve clarity and completeness,
and addition of a comment in the Teaching Notes and Exercise Booklet about the need to emphasize the
importance of properly collecting and recording inspection data. We also think a requirements tutorial
offered before the use of the case module would be helpful, especially for beginning students. The tutorial
could include the following: the purpose and importance of an SRS; the typical structure and content of
an SRS; a description of the inspection process, data, and forms; and examples of well-written and poorly
written requirements.

SUMMARY AND FUTURE RESEARCH DIRECTIONS

The use of case study-base teaching has shown success in disciplines such as medicine and law.
The DigitalHome case study project’s goal is to enhance the use of case studies throughout a computing
curriculum. This is done through the development of case study material that can be tailored to multiple
courses and teaching techniques. The case study materials include case modules for teaching software
development topics such as requirements analysis, inspections, OO design and construction, and testing
among others. Case modules include teaching notes to guide instructors in teaching the target topic. Case
modules are also accompanied by class exercises that employ scenarios to simulate real world
environment and increase students’ interest in the topics.

Although there is still much work to be done to complete the DH case study, we hope the material
developed and our experiences with it provide insight into the value of such an approach. We believe the
content, organization, and spirit of the DigitalHome Case Study provides a model for the development of
other engineering life-cycle case studies. As a minimum, the DigitalHome can easily serve as a baseline
for case studies/modules for Computer Engineering, Electrical Engineering, and System Engineering.
Hopefully, this discussion will broaden the reach of this work into other fields of engineering with a goal
of building a community of collaborators that will contribute more significantly to the development of
case studies, artifacts, and exercises.
REFERENCES
Accreditation Board for Engineering and Technology (ABET) (2013) Criteria For Accrediting
Engineering Programs, 2012-2013 Accreditation Cycle, Engineering Accreditation Commission,
ABET Inc., October, 2012.

Davis, C. & Wilcock, E. (2013) Teaching materials using case studies. UK Centre for Materials
Education, http://www.materials.ac.uk/guides/casestudies.asp, accessed August 2013.

DigitalHome Case Study Project: www.softwarecasestudy.org, Accessed August 2013.

Fagan, M, E (1976). Design and code inspections to reduce errors in program development. IBM
Systems Journal, Vol 15, No 3, 1976, pp. 258-287, pp. 744-751.

Fagan, M, E. (1986). Advances in software inspections. IEEE Transactions in Software Engineering, Vol
12, No 7, July 1986.

Friedman, G., & Sage, A. (2004). Case studies of systems engineering and management in systems
acquisition. Systems Engineering, Vol. 7, No. 1, January 2004, pp. 84- 96.

Fritz H., Grupe, & Joelle K, J. (2000). Incremental cases. College Teaching, September 22, 2000, pp.
123-128.

Herreid, C, F. (1994). Case studies in science: A novel method of science education. Journal of College
Science Teaching, February 1994, pp. 221-229.

Hilburn, T., Towhidnejad, M. (2007). A Case for software engineering. Proceedings of the 20th
Conference on Software Engineering Education and Training, 2007

Hilburn, T., Towhidnejad, M., Salamah, S. (2008). The DigitalHome case study material. In the
proceedings of the 21st Conference on Software Engineering Education and Training. 2008

Humphrey, W. S. (2000). Introduction to the team software process. Addison-Wesley, 2000.

Lethbridge T, C., & Laganière, R. (2001). Object-Oriented software engineering: Practical software
development using UML and Java. Second Edition, McGraw Hill, 2001

McMeekin, D, A., Von Konsky, B, R., Chang, E., & Cooper, D, J, A. Evaluating software inspection
cognition levels using bloom’s taxonomy. In the Proceedings of the 22nd Conference on Software
Engineering Education and Training, Hyderabad, India, February 17 - 19, 2009, pp. 232-239

Metseker, S. (2006). Design patterns in Java. Second Eddition, Addison-Wesley Professional, 2006.

National Center for Case Study Teaching in Science, SUNY-Buffalo: National Center for Case Study
Teaching in Science: http://ublib.buffalo.edu/libraries/projects/cases/case.html , accessed August
2013.

Parnas, D, L. & Lawford, M. (2003). The role of inspection in software quality assurance. IEEE
Transactionson Software Engineering, Vol. 29, No. 8, August 2003, pp. 674-676.

Pfleeger, S, L. (2005). Software engineering. Pearson, 2005

Pressman, R, S. (2007). Software engineering: A practitioner’s approach. McGraw-Hill, 2007

Salamah, S., Towhidnejad, M., & Hilburn, T. (2011). Developing case modules for teaching software
engineering and computer science concepts. In the Proceedings of 2011 Frontiers in Education
Conference, October 2011.

Tomey, A, M., (2003). Learning with cases. Journal Of Continuing Education In Nursing, Vol 34, No 1,
January/February 2003.

ADDITIONAL READING SECTION

ACM/IEEE-CS Joint Task Force on Computing Curricula, Software Engineering 2004,Curriculum
Guidelines for Undergraduate Degree Programs in Software Engineering, August 2004.
(http://www.acm.org/education/curricula.html)

Bolinger, J., Herold, M., Ramnath, R., & Ramanathan, J. (2011). Connecting reality with theory - An
approach for creating integrative industry case studies in the software engineering curriculum. In
Proceedings of the Frontiers in Education (FIE), 2011.

Bolinger, J., Yackovich, K., Ramnath, R., Ramanathan, J., & Soundarajan, N. (2010). From student to
teacher: Transforming industry sponsored student projects into relevant, engaging, and practical
curricular materials. In Proceedings of the Transforming Engineering Education: Creating
Interdisciplinary Skills forComplex Global Environments, 2010 IEEE, pp. 1-21.

Bonwell, C. & Eison, J. (1991). Active learning: Creating excitement in the classroom AEHE-ERIC
HigherEducation Report No. 1, Washington, D.C,: Jossey-Bass, ISBN 1-87838-00-87, 1991.

Clarke, S., Thomas, R., & Adams, M. (2005). Developing case studies to enhance student learning. In
Proceedings of the 7th Australasian Conference on Computing Education - Volume 42,
Newcastle, New South Wales, Australia, pp. 101-108.

Corey, R. (1998). Case Method Teaching. Harvard Business School 9-581-058, Rev

Ellet, W. (2007). The case study handbook: how to read, discuss, and write persuasively about cases.
Harvard, Business School Press, 2007

Erskine, J. A., Leenders, M. R., Mauffette-Leenders, L. A., & Business, R. I. S. (1998). Teaching with
Cases. Richard Ivey School of Business, University of Western Ontario.

Fuller, A., Croll, P., & Limei, D. (2002). A new approach to teaching software risk management with case
studies. In Proceedings of the 15th Conference on Software Engineering Education and Training,
Covington,

Gerald M. Weinberg. (1971) The Psychology of Computer Programming. New York: Van Nostrand
Reinhold 1971.

Knuth, D, K. (1984). Literate programming. Computer, Vol 27, No 2 , May 1984, pp. 97-111.
Linn, M., & Clancy M. (1992). The case for case studies of programming problems. Communications of
 the ACM, v.35 n.3, p.121-132, March 1992

Ludi, S, S., & Collofello, J. (2001). An analysis of the gap between knowledge and skills learned in
academic software engineering course projects and those required in real projects. In the proceedings of
the 31st ASEE/IEEE Frontiers in Education Conference, October 2001.

Lutz, M., Hislop, G., Hilburn, T., McCracken, W, M., & Sebern, M. (2003). The SWENET project:
Bridging the gap from bodies of knowledge to curriculum development. In the proceedings of 2003
Frontiers in Education Conference, Bolder, CO, November 2003.

Parrish, A., Hale, D., Disxon, B., & Hale, J. (2000). A case study approach to teaching component based
software engineering. In the proceedings of the Thirteenth Conference on Software Engineering
Education and Training. 2000

Razali, R., Zainal, D, A, P., & Chitsaz, M. (2012). Developing industrial cases for teaching software
engineering – A lesson learned. Journal of Asian Social Science, Vol 8, No 16 (2012)

Sivan, A., Leung, R. W., Woon, C.-C., & Kember, D. (2000). An implementation of active learning and
its effect on the quality of student learning. Innovations in Education & Training International,
37(4), 381-389.

Varma, V., & Garg, K. (2005). Case studies: The potential teaching instruments for software engineering
education. In Proceedings of the 5th International Conference on Quality Software, Melbourne,
Australia, pp. 279-284.

Wohlin, C., & Regnell, B. (1999). Achieving industrial relevance in software engineering education. In
Proceedings of the 12th Conference on Software Engineering Education and Training New
Orleans, pp. 16-25.

KEY TERMS AND DEFINITIONS

Case Study: Realistic example used to illustrate a concept or technique. It involves the application of
knowledge and skills, by an individual or group, to the identification and solution of a problem associated
with a real-life situation

Case Module: A mini case study which focuses on a specific aspect of a larger case study. It includes a
realistic scenario, specific individual roles, team exercise, and instruction notes.
Software Inspection: A structured formal review of a software artifact by a team of software developers
(or students).