Preface

This Instructor’s Manual is designed to make teaching from the second

edition of Modern Systems Analysis and Design as convenient and rewarding
as possible. For each chapter in the textbook, this manual provides the
following:

Chapter Overview An overview of each chapter is provided in this section.

The intent is to provide you with a summary of the chapter’s contents.

Instructional Objectives This includes a list of instructional objectives to

help prioritize each chapter’s topics. Student learning objectives are included
at the beginning of each chapter in the textbook.

Classroom Ideas Discussion questions, classroom exercises and activities,

notes on alternative sequences of chapters, and references to recent articles
and other current literature form the basis for these teaching suggestions. We
also suggest points to emphasize with your students based on what we have
found most important or most difficult for our students. In many chapters we
suggest how much time to spend on different topics and what figures and
tables to highlight in class. Many of the Classroom Ideas have originated from
our students and from our years of teaching this material; we welcome
additional suggestions to include in future editions.

Answers to Review Questions The Review Questions in each chapter

range from simple definitions to in–depth discussion questions. The Review
Questions emphasize the key concepts and terms from the chapter, and
students should master these questions to gain a basic understanding of the
material. These questions (and the associated answers provided here) may
be used as examination questions and/or as a foundation for classroom
discussion. You may want to strongly encourage your students to use these
questions and the key terms in each chapter to study for examinations.

Answers to Problems and Exercises Each chapter contains Problems and

Exercises, ranging from simple matching exercises to problems requiring a
graphical or quantitative solution; many require the application of some
SA&D technique and notation. Especially in the sections of the textbook on
analysis and on logical and physical design, we have created many Problems
and Exercises that are small applications of the same skills needed in
systems development projects. The Problems and Exercises have been
carefully designed to cause students to deal with the central analysis and
design issues they must master. These problems may be used for homework
assignments, in–class exercises, and/or examination questions.

Guidelines for Using the Field Exercises One of the most unique
features of this textbook is the field exercises, which encourage students to
investigate the topics of the chapter beyond the concepts and skills taught in
the textbook. These Field Exercises usually require students to investigate
systems analysis and design practices in organizations and compare these
practices to the principles outlined in the textbook. Because there are no
closed–ended answers to these exercises, we provide directions you can give
students in their work on these exercises and guidelines for you as you
evaluate the thoroughness and quality of answers they submit. The Field
Exercises can be used as class discussion questions, given that students have
been asked to research them prior to class. Many of the Field Exercises could
be the basis for essays or short papers throughout the course.
In addition to this Instructor’s Manual, there are several other supplements to
support instructors who adopt the second edition of Modern Systems
Analysis and Design. A comprehensive Test Bank exists with approximately
80 multiple choice, matching, and short answer questions for each chapter.
This excellent teaching aid, developed by Lisa Miller of the University of
Central Oklahoma, covers all the key concepts, principles, and terms of
systems analysis and design. This test bank is available on disk in Adobe
Acrobat format. It is part of your supplements package.

There is also a Computerized Test Bank, which consists of the

aforementioned test bank put into a format that allows you to randomize test
questions, mix them with your own questions, and create other custom
options. The Computerized Test Bank is distributed separately from the
supplements package. Ask your sales representative for more details.

An original Video Tape with four different segments highlights important

systems development concepts and activities. This professionally produced,
scripted, and acted video (produced especially for Modern Systems Analysis
and Design by Electronic Data Systems) is divided into four segments: (1)
making the business case for an information system request, (2) organizing
and conducting a Joint Application Design (JAD) session, (3) the need for
systems development to be a repeatable, engineering-style discipline, and (4)
managing end-user expectations. Each segment is 10-18 minutes long,
including a summary by one of the textbook authors. A section called
Teaching Notes for EDS Video is provided in this Instructor’s Manual.
These notes suggest how to use the video segments to supplement different
chapters of the textbook and list some questions that can be given to
students before they view the tape and then used for discussion after
viewing. These video segments will be updated; please check our web site
(http://hepg.awl.com) for more information about the update.

One Sample Course Project Case Study included in this Instructor’s

Manual provides a unique way to engage your students in role playing in
simulated SA&D and systems development management situations; several
additional role-playing cases are available at our web site. These role-playing
cases are designed for teams of 3-4 students and have three roles to be
played by instructors or confederates. Each case includes the following: (1) a
short case background that students must study to prepare for the exercise
and (2) a script of plausible responses that role players can provide during
interviews or other inquiries for additional information from the student
teams. The suggested agenda for use of each role-playing case is to first
have student teams study the background document for several days and
prepare to conduct a 30-minute interview of the role players (the class
instructor can play all three roles) to gather additional information. One or
more interviews allow the students to practice their information-gathering
skills; the script provides answers to many of their questions, but the role
players will still need to create answers to unanticipated questions during the
interview. After the interviews, you can give the teams several days to a
week to prepare a recommendation to management that addresses the
central issues of the case. This presentation involves the outline of a systems
development project and a suggested direction for the system. The authors
have used these cases in special out-of-class projects and competitions, but
these role-playing cases can also be used instead of case studies or field
projects within an SA&D course.

Sample Syllabus A sample syllabus is provided in this instructor’s manual.

The intent of this syllabus is to provide suggestions in terms of chapter
presentation and sequencing. It is important to note that you will need to
adapt this syllabus for your particular course.

The authors gratefully ackowledge the support of our students (past and
present) who in so many ways have contributed to this Instructor’s Manual
and have continually suggested improvements to our teaching, which have
indirectly assisted us in preparing these materials. We would like to thank
Doug Hodson, Pamela Carter, Lisa Miller, and Len Jessup for their help in
preparing answers for the Review Questions, Problems and Exercises, and
Field Exercises. We would also like to thank Lisa Miller for her help in revising
this instructor’s manual.

For further information about the second edition of Modern Systems Analysis
and Design and its supplements and associated materials, please contact
your Addison Wesley Longman sales and marketing representative or visit our
web site.

Jeffrey Hoffer
Joey George
Joe Valacich
Sample Syllabus

Introduction

The second edition of Modern Systems Analysis and Design was designed to
be used with a single one–semester course, with a sequence of two quarter–
or semester–calendar courses, and as a companion text to Modern Database
Management, fifth edition (by McFadden, Hoffer, and Prescott, also from
Addison Wesley Longman Publishing) in a set of courses on systems analysis,
design, and implementation. However you use this text, it is not essential
that you cover all of the chapters. As with most SA&D texts, Modern Systems
Analysis and Design presents a wide range of aspects of systems analysis
and design. Most instructors find this to be too much for one course, and you
must choose to cut back on some book elements. The modular design of the
book should make this task of picking that subset of the text you want to use
both easy and effective.

Obviously, you have many choices to make in organizing a course on systems

analysis and design; for example, whether to require a term–long project, and
if so, whether it will be based on a case study or will be conducted in the
field; the relative weight given to examinations, exercises, projects, class
participation, and other possible grading elements; and how to make the
course fit into the IS curriculum. Rather than addressing these issues, which
cannot be done in the abstract, we suggest several possible weekly
sequences of topics and chapter readings that would be effective applications
of Modern Systems Analysis and Design. The design of the text facilitates
these alternative organizations, since the book is highly modular along the
traditional activities of a systems development project; there are several
optional elements (for example, the Broadway Entertainment Company case
study sections, which support courses of alternative lengths), and the book is
written to fit with the concepts, terminology, and appearance of the fifth
edition of Modern Database Management.
A Semester–Long Course Design

We assume a standard 15–week semester with a separate final examination

period. We will not consider whether the class meets once, twice, or three
times per week; rather, we present a weekly outline of topics and readings.
Within such a semester, there still would be variations due to the number of
exams, the number of supplemental topics and guest speakers you might
include, and whether class periods are needed for student team project
activities such as requirements collection interviews, structured walkthroughs
at project milestones, and prototype demonstrations. There is one mid–term
examination in the sample schedule and several weeks of project–related
activities to illustrate how such elements might be blended into the sequence
of topics.

In the following example we list the course’s behavioral objectives and

weekly class schedule. We show a possible outline which includes several of
the pedagogical elements mentioned above; however, you should be able to
easily modify this outline to suit the learning objectives and pedagogy you
desire.

Learning Objectives

The overall course objective is to give you the concepts and skills you need to
analyze and design information systems. The course concentrates on the
front–end of the systems development process; that is, the course only lightly
touches on the design and development of computer programs and their
testing and maintenance (although you will work through some elements of
the whole development process on your project).

Upon successful completion of the course, you are expected to be able to:

 Describe the major alternative methodologies used in developing

information systems and the considerations involved in choosing which
methodology to use.

 Produce the requisite systems documentation at each point in the

analysis and design of an information system, and to do so with clarity
and completeness.

 Analyze a business need for information and to develop an appropriate

strategy to solve the problem and provide the required information
service.

Prepare and use various information gathering techniques for eliciting

user information requirements and system expectations.
  Construct and interpret a variety of system description documents,
including physical and logical data flow diagrams, entity–relationship
diagrams, Structured English, structure charts, state–transition diagrams,
as well as screen, form, and report layouts.

 Communicate effectively, in both written and oral forms, systems

specifications, and to be persuasive in these presentations.

 Develop a personal plan for improving yourself to become a better

systems professional or user/manager of a system, by understanding
your own strengths and weaknesses and matching those with the critical
success factors of a modern business manager.

Weekly Schedule

Wee Topic Readings

k

1 Introduction to Course Preface

Systems Development Environment Chapter 1*
Succeeding as a Systems Analyst Chapter 2*

2 Managing the Information Systems Project Chapter 3

Automated Tools for Systems Development Chapter 4

3 Identifying and Selecting Systems Chapter 5*

Development Projects Chapter 6
Initiating and Planning Systems
Development

4 Determining System Requirements Chapter 7*

Project Interviews and Other Requirements

Process Modeling Chapter 8

5

6 Logic Modeling Chapter 9

7 Conceptual Data Modeling Chapter 10

8 Selecting a Design Strategy Chapter 11

Project Requirements Walkthrough

9 Mid–term Examination
Examination Review
Object-Oriented Analysis Chapter 12
10
Rapid Applications Development Chapter 13

11 Input and Output Design Chapter 14*

 Wee Topic Readings
k
Designing Interfaces and Dialogues Chapter 15

12 Logical Data Modeling Chapter 16

Physical File and Database Design Chapter 17*

13 Distributed System Design Chapter 19

14 System Implementation Chapter 20*

15 Final Project Presentations and

Demonstrations
* Read the part opener sections before this chapter.

Alternatives to this Outline

The above weekly schedule has some obvious assumptions, which if changed
would necessitate changing the organization of topics. First, this syllabus
assumes that only an overview is required for physical system design and
implementation, probably due to extensive coverage of these topics in prior
or subsequent courses. Additional coverage of these topics could be
accomplished by conducting the project activities during additional class
meetings or in private sessions with the instructor. Second, this syllabus does
not address system maintenance (either the design of systems to facilitate
maintenance—which is addressed in Chapter 18—or the management of
system maintenance—covered in Chapter 21. Again, project activities would
likely have to be eliminated to fit in this topic.

You may find that the timing of the mid–term examination is later than you
wish. We suggest that you design examinations to cover one or several whole
parts of the book, since the topics within each part are quite related. We have
conducted an examination after Chapter 6 and after Chapter 7, but it is not
advisable to hold an examination in the middle of covering Chapters 8–11.

This syllabus does not ask the students to read the Broadway Entertainment
Company cases. Although you could ask your students to read these sections
since most are short, the above schedule does not allow time for substantial
discussion of these cases. We believe that it is only when supplemented by
classroom discussion that these cases have the most value. One way to
include the cases would be to handle them via a newsgroup, GSS, or similar
electronic discussion forum. You could give participation credit to students
who post insightful ideas gleaned from the BEC cases. This approach would
still require your students to devote reading and thinking time to the cases,
but would not consume any classroom time.

We remind you that there are four video segments available to adopters of
the second edition of Modern Systems Analysis and Design; we encourage
you to include these tapes at appropriate points in the course. We do not
show when to use these tapes in the above schedule since they can be shown
at various times during the course. Please refer to the teaching notes on each
chapter and to the section on the video segments in this Instructor’s Manual.

If you have a sequence of two courses on SA&D, on either a quarter or

semester calendar, then it is possible to cover all of the text chapters and
BEC cases, and possibly include additional sessions for students to make oral
presentations associated with project deliverables. We encourage you to
include as many of these types of presentations as your schedule permits,
since critical feedback on oral presentation skills (and the peer pressure of
presenting to classmates) can be extremely valuable to your students as they
develop these important skills.

Contents

Teaching Notes for EDS Video..........................................................................1

Sample Syllabus............................................................................................... 7
Sample Course Project Case Study.................................................................11

Part I Foundations for Systems Development

1 The Systems Development Environment 25

2 Succeeding as a Systems Analyst 33
3 Managing the Information Systems Project 42
4 Automated Tools for Systems Development 58

Part II Making the Business Case

5 Identifying and Selecting Systems Development Projects 68

6 Initiating and Planning Systems Development Projects 78

Part III Analysis

7 Determining System Requirements 94

8 Structuring System Requirements: Process Modeling 103
9 Structuring System Requirements: Logic Modeling 126
10 Structuring System Requirements: Conceptual Data Modeling 145
11 Selecting the Best Alternative Design Strategy 164

Part IV Blending Analysis and Design

12 Object-Oriented Analysis 177

13 Rapid Applications Development 201
Part V Logical and Physical Design

14 Designing Forms and Reports 207

15 Designing Interfaces and Dialogues 217
16 Designing Databases: Logical Data Modeling 226
17 Designing Physical Files and Databases 239
18 Designing the Internals: Program and Process Design 251
19 Designing Distributed Systems 265

Part IV Implementation and Maintenance

20 System Implementation 274

21 Maintaining Information Systems 285

1
The Systems Development Environment
Chapter Overview
The purpose of this chapter is to introduce students to systems analysis and
design and the components of the systems development environment. The
chapter serves as an overview of systems analysis and design as well as an
overview of the book. The components of systems development to which
students are introduced include the data–oriented approach to systems
development, different roles within an organization that play some part in the
development process, different types of information systems, and the
traditional systems development life cycle. The text is intended primarily for
juniors taking a core course in the information systems major, although the
book can be adapted for a similar course at the junior college level or for a
two–course sequence on analysis and design. In teaching this material over
the past decade, our experience has been that many students are not
familiar with the systems development process, with its different
organizational components, or with how those components work together.
This chapter is intended to provide the general organizational context in
which systems development takes place.

Instructional Objectives
Specific student learning objectives are included at the beginning of the
chapter. From an instructor’s point of view, the objectives of this chapter are
to:

1. Define and discuss the modern approach to systems analysis and design,
with an emphasis on the combination of both process and data views of
systems.
2. Show how systems development in an organizational context involves
many different roles beyond those played by the systems analyst and
others in the information systems unit.

3. Illustrate how systems development extends to many different types of

information systems and not just transaction processing systems.

4. Introduce the traditional information systems development life cycle,

which serves as the basis for the organization of the material in this book,
starting with “Making the Business Case” in Part II and running through
“Implementation and Maintenance” in Part VI.

5. Show students that the life cycle is a flexible basis for systems analysis
and design and that it can support many different tools and techniques,
such as prototyping and JAD.

Classroom Ideas
1. Emphasize the differences between methodologies, techniques, and
tools. Such differences are not obviously to students; often they think of
methodologies just as a set of techniques and that techniques and tools
are synonymous.

2. Figures 1–1 and 1–2 and Table 1–1 summarize the points made here
about data–oriented and process–oriented systems development
approaches. The figures and table can be used in class to clarify the
differences in the two approaches and to emphasize the need to balance
data– and process–orientation.

3. In the text, we focus on various organizational roles and how they can
be involved in systems development. We also provide an organization
chart for a sample information systems unit (Figure 1–3). Students are
interested to know that not all organizations have such differentiated IS
units. This is a good point to illustrate different IS organizations with
different organization charts that show the relative importance of IS to an
organization and the different sizes IS units can assume. In our teaching,
we compare a bank, where IS reports to the chairman, to a city
government, where IS is several hierarchical units below the city
manager, to an organization where there is no IS unit at all. All three of
the organization charts used are from real organizations. Use whatever
organization charts you have available to illustrate these differences.

4. Discuss the history of IS units in organizations, from the days where IS

was a part of the accounting function, to when IS became an independent
unit, to when IS was becoming less centralized (and less relevant) in the
days of departmental IS shops, through end–user computing and
microcomputers, to the reemergence of strong IS units in the current
trend of networking and client/server.
 5. Give concrete examples during class discussion of the types of IS
mentioned here: transaction processing systems, management
information systems, decision support systems, and expert systems. Ask
students to talk about ISs they are familiar with.

6. When discussing different types of information systems, discuss the

differences between systems that support back room operations, such as
basic accounting functions, and systems that directly affect the bottom
line. Although it seems unlikely, many students are not aware of systems
like AMR’s SABRE and Baxter Healthcare’s ASAP. If students are aware of
such systems, they usually are not aware of how these systems provide
competitive advantage. Discussing different types of systems provides a
chance to talk about the differences between these two different
categories of systems.

7. When introducing the life cycle model we use, you may want to
introduce other life cycle models, from other textbook authors, or in other
forms, such as Boehm’s spiral model. This shows students that there is no
one standard life cycle model and that the model they will rely on when
they begin work as a systems analyst will likely differ from the life cycle
we use here. The point is to show them they can use our life cycle as an
archetype to understand other models, and they should understand there
is no one “correct” life cycle model. The life cycle represents activities
that must be done, and the phases are a way to introduce, in an
organized way, the methods, techniques, tools, and skills necessary for
success at systems analysis and design.

8. Give a brief overview of the activities and outputs from each of our
seven life cycle phases, based on your own experience or from your
reading of the rest of the book.

9. Although prototyping and Joint Application Design are covered in more

depth later in the book, you could provide a more in–depth introduction to
these techniques than we do in Chapter 1. Figure 1–9 is a good point of
departure for a discussion of prototyping and what it adds to structured
development techniques.

10. Participatory Design is only introduced in this chapter but can be

discussed in much more depth. A good starting place for exploring
Participatory Design is a special issue of Communications of the ACM,
published in June 1993. Several books are available on this topic, as well
as numerous web sites. Ask students to find more recent articles about
this topic.

11. CASE tools have an entire chapter, Chapter 4, devoted to them. Since
CASE tools are mentioned at the end of this chapter, you may want to
spend some time talking about CASE tools now.

12. Two video segments are available that can be used to supplement your
lecture on this chapter: “Joint Application Design” and “Application
 Engineering.” The JAD video segment is about 18 minutes long, and the
Application Engineering one is about 12 minutes long. Notes on using
these video segments are included in a separate section of this
Instructor’s Manual. See the Preface to this Instructor’s Manual for
information on how to obtain copies of these and other video segments
produced for use with the second edition of Modern Systems Analysis and
Design.

Answers to Review Questions

1. The systems development life cycle is the traditional methodology
used to develop, maintain, and replace information systems. Data are
raw facts about people, objects, and events in an organization. Data
flows are groups of data that move together through an information
system. Processing logic refers to the steps by which data are
transformed or moved and a description of the events that trigger the
occurrence of these steps. An object is a structure that encapsulates
(or packages) attributes and methods that operate on those attributes.
An object is an abstraction of a real–world thing, in which data and
processes are placed together to model the structure and behavior of
the real–world object. An object class is a logical grouping of objects
that have the same (or similar) attributes and behaviors (methods).
Inheritance is the property that occurs when entity types or object
classes are arranged in a hierarchy and each entity type or object class
assumes the attributes and methods of its ancestors (that is, those
higher up in the hierarchy). Inheritance allows new but related classes
to be derived from existing classes. Application software is computer
software designed to support organizational functions or processes.
Methodology can be defined as comprehensive, multiple–step
approaches to systems development that guide an analyst’s work and
influence the quality of the information system. A technique is the
particular process an analyst follows to help ensure that the analyst’s
work is complete, well–done, and understood by others on the project
team. Tools are computer programs that make it easier to use and
benefit from techniques and to faithfully follow the guidelines of the
overall development methodology.

2. Information systems analysis and design is the complex organizational

process through which computer–based information systems are
developed and maintained.

3. Traditionally, an information system’s design was based on what the

system was supposed to do. Each application had its own files and
data storage. The data had to match the specifications established in
each application, and each application was considered separately. The
data–oriented approach depicts the ideal organization of data,
independent of where and how data are used within a system. Some
people believe a data model is more permanent than a process model
since a data model reflects the inherent nature of the business instead
of the way the business operates, which is constantly changing.
4. IS managers (allocating resources; overseeing approved project);
Systems analysts (use analytical, technical, managerial, and
interpersonal skills in developing new systems; playing a key liaison
role between users and programmers); Programmers (converting
system specifications to code); End users (take a lead role in
determining what new systems should do and look like; in some cases,
developing applications themselves with the assistance of IS
professionals); Business managers (set IS development priorities; fund
projects; approve projects); Other professionals (includes database
administrators, telecommunications experts, human factors specialists,
and internal auditors—their responsibilities depend on their jobs).

5. The different types of information systems are transaction processing

systems, management information systems, decision support systems,
and expert systems. Transaction processing systems automate the
handling of data about business activities or transactions;
management information systems take the information generated by
transaction processing systems and convert it into aggregated forms
meaningful to managers; decision support systems are designed to
help organizational decision makers make decisions through providing
an interactive environment that uses data and models; expert systems
represent attempts to codify and manipulate knowledge rather than
information by mimicking experts in particular knowledge domains.

6. The seven phases of the systems development life cycle described in

this book are project identification and selection, project initiation and
planning, analysis, logical design, physical design, implementation, and
maintenance. Project identification and selection is the phase where an
organization’s total information system needs are identified, analyzed,
prioritized, and arranged. Project initiation and planning is the phase
where a potential IS project is explained and an argument for
continuing or not continuing the project is presented. Analysis is the
phase where the current system is studied and alternative replacement
systems are proposed. Logical design is the phase where all functional
features of the target system are described independent of
implementation concerns. Physical design is the phase where the
logical specifications are transformed into implementation–specific
specifications so system construction can occur. Implementation is the
phase where the code is written and tested, the system is installed,
and user training and support are planned and provided. Maintenance
is the phase where the system is systematically repaired and
improved.

7. Structured analysis and design were developed to help reduce

maintenance time and effort. Structured analysis and design make it
easier to go back to earlier phases in the life cycle when necessary,
such as when requirements change. Also, there is an emphasis on
partitioning or dividing a problem into smaller, more manageable units,
and on making a clear distinction between physical and logical design.
 8. Prototyping is an iterative process of systems development by which
requirements are converted to a working system, which is continually
revised through close work between an analyst and users.

9. JAD is a group process involving users and systems development staff

in which all parties discuss the needs for an information system and
reach a shared understanding. Participatory design is a systems
development approach that originated in northern Europe, in which
users and the improvement in their work lives is the central focus.

10. Object–oriented analysis and design is a set of systems development

methodologies and techniques based on objects rather than data or
processes.

11. In the early years of computing, analysis and design were considered
more of an art. However, with the growing importance of and
changing nature of information technology and its usage in the work
environment, work methods have evolved, making analysis and design
a disciplined process. Through the years, we have seen the systems
developer’s job move from that of a builder to an integrator. In the
1950s, the development effort concentrated on the processes the
software performed; emphasis was placed on automating existing
processes; all applications had to be developed in machine language or
assembly language and were developed from scratch. In the 1970s,
systems development came to be more disciplined as many people
worked to make it more like engineering. In the 1980s microcomputers
became key organizational tools, the software industry expanded
greatly, fourth-generation languages were used more and more to
write applications, and CASE tools were developed. Systems
integration is currently the focus of the systems development
environment.

12. Successful team characteristics include diversity in backgrounds, skills,

and goals; tolerance of diversity, uncertainty, and ambiguity; clear and
complete communication; trust; mutual respect and putting one’s own
views second to the team; and a reward structure that promotes
shared responsibility and accountability.

Answers to Problems and Exercises

1. e. maintenance d. design b. project
identification and selection
c. analysis f. project initiation and
planning a. implementation

2. It is useful to follow systems analysis methodologies and techniques and

to use systems analysis tools because they provide structure to the
process, and they have been tested and perfected by others. When
building complex systems, why not take all the help you can get? The
 bottom line is that this helps to ensure the quality and appropriateness
of the system being built. The quick and easy approach in building
systems may be easier, cheaper, and quicker in the short run, but it
almost always results in a poor system, which means that the system
will be sub–optimal, will require extra work to maintain and “fix,” and
in the long run will probably end up taking even more time and money
to make right. Following the “engineering” approach ensures that
systems analysis will be rigorous, structured, systematic, and will make
use of techniques such as prototyping.

3. For an ATM transaction, the data involved would include customer name,
customer account number, customer personal identification number,
customer account balance, transaction type, and transaction amount.
At this point, the student shouldn’t be expected to know the structure
or nomenclature of a data flow diagram or of processing logic. For the
ATM example, they should be able to explain that a customer’s name is
read from the account identification number on their ATM card. The
customer inputs their personal identification number by hand and, if
this number is matched with their account identification number, they
are granted access to begin an ATM transaction. They will either
request to inquire into the status of their account, withdraw money, or
deposit money. If, for example, they request to withdraw money, their
request will be matched with their available funds and the allowable
daily limit for that ATM machine. If acceptable, the cash will be
dispensed, their account will be debited, and a receipt will be provided.
Do not worry whether or not the student knows the technique or
nomenclature at this point. It is more important that the student can
analyze the transaction, break it down into its component parts and
pieces of data, and understand the process.

4. Both Joint Application Design and Participatory Design are development

processes designed to help build better systems by engaging the direct
participation of users. The primary difference between them lies in the
locus of control for systems development. With the JAD approach,
control of systems development typically still rests with the systems
staff. Indeed, the outputs from JAD sessions are commonly summarized
and handled by the systems staff after users have a chance to review
the transcripts. With the PD approach, control of systems development
is either shared by systems personnel and users or rests solely with the
users and their managers. With the movement toward end–user
development in the United States, we are moving more toward shared
control of systems and systems development. The benefits to the JAD
and PD approaches are that they are likely to result in better systems
and higher user commitment to the systems than would be the case if
these techniques were not used. Some of the barriers to these
approaches are that they require extra systems analyst skills and
knowledge, in the short run they add more time and expense to the
systems development process, and they require more time and effort
from already busy users and user managers.
5. The student project team should be of a size that is adequate for the task
at hand. The team member should also possess the necessary set of
skills and experience for the task at hand. It is important that there be
diversity of skills and abilities across team members, but it is also
helpful if the team members have some common interests and values
on which to build collegiality and trust. It is not necessary that there be
a clearly defined “leader” for the team (leadership can rotate by time
or phase), but there should be clearly defined roles and responsibilities
for each of the team members. There should also be a reward structure
(i.e., a grade) that promotes shared responsibility and accountability.
Finally, because their project is for a small business client, the team
members must act professionally and deliver a quality product on time.
Surprisingly, these steps do not necessarily change much for
organizing a project team within a professional consulting organization.
One difference might be that, because you would be concerned more
with the long–term professional growth of the team members, you
might make team member selections and project assignments which
take into account the long–term career development of each of the
team members.

6. Imagine that an analyst is helping to develop a system that will enable a

sales representative to access information about inventory levels in
real time rather than having to phone someone in production who then
physically checks inventory levels and calls the sales representative
back on the phone to answer the question. The analyst might begin by
asking the sales representative what kinds of information about
inventory he/she needs, including when and where he/she needs to
access this information. The analyst might then use a graphical,
object–oriented development tool, such as Microsoft Visual Basic, to
quickly build some sample interface displays that meet the sales
representative’s needs. The analyst would then have the sales
representative review these displays and give the analyst feedback.
The analyst could then modify the displays and, again, solicit feedback
from the sales representative. Given the ease of use of Visual Basic,
the analyst could even build the sample interface “on–the–fly” with the
sales representative present and helping to build the displays. The
sample interface could then be used to build the actual system, either
in Visual Basic or in some other development environment.

7. The role of the systems analyst in the SDLC is essentially the same as
that in prototyping. The primary difference is that in prototyping, the
analyst is simultaneously performing tasks from the analysis, logical
design, and physical design phases of the SDLC. In cases where all or
part of the prototype will be used for the actual system, then the
analyst is also performing tasks from the implementation phase of the
SDLC. In cases where the analyst builds the prototype with the direct,
real–time assistance of the users, then the analyst and users are
collaboratively completing several steps of the SDLC in one step.
8. The process–oriented approach is focused on the flow, use, and
transformation of data in an information system. The techniques and
notations developed out of this approach show the movement of data
from their sources, through intermediate processing steps, and on the
final destinations. The natural structure of data is, however, not
specified within the traditional process–oriented approach. The data–
oriented approach depicts the ideal organization of data, independent
of where and how data are used within a system. A data model is
constructed, which describes the kinds of data needed in systems and
the business relationships among the data. Both approaches are
necessary and are captured within the SDLC. The process–oriented
approach helps us to understand and improve how the organization
functions. This is particularly important to popular process
improvement techniques such as business process re–engineering. The
data–oriented approach helps us to understand, preserve, and protect
the organization’s data resource. This is critical to the current efforts in
organizations to provide for employees easy access to accurate data in
real time.

9. Since prototyping is a form of RAD, the students should recognize the

similarities between the two diagrams. While the names of the phases
differ, both diagrams have similar phases. Students should recognize
the definition of requirements, the iterative nature of both processes,
and the implementation of the final product.

10. Figure 1-5 illustrates the traditional, sequential ordering of the systems
development life cycle phases. Figure 1-8 illustrates a company-
specific systems development lifecycle. While the textbook does not
provide a detailed description of the Seer Technologies SDLC, the
following comparison can be used to facilitate discussion:

Seer Technologies Traditional SDLC

(Figure 1-8) (Figure 1-5)

Enterprise Definition Project Identification and Selection

Business Object Analysis Analysis
Protocycling Analysis and Design
Technical Construction Physical Design and
Implementation
Delivery Implementation

11. Students should be encouraged to review the section titled “Your Role
and Other Organizational Responsibilities in Systems Development.”
After reviewing this section, students will recognize that the level of
participation and leadership responsibilities will vary depending upon
the role and SDLC phase.

Guidelines for Using the Field Exercises

1. Expect that the organization charts presented by students will vary
greatly. It will be useful to draw on these differences to talk about the
various ways that the information systems function can, is, and should
be organized. Be sure to point out that the position of the highest
ranking systems employee within the overall organization chart has
important implications for the level of power this person has, the
knowledge this person will have of business strategy and direction, and
how effective this person can be.

2. Expect that the degree to which these roles are filled formally or
informally will vary greatly from organization to organization. Similarly,
the extent to which organizations use a team approach to systems
development will also vary. To some degree, however, the work of the
various systems personnel must be integrated, even when a team
approach is not used. Ask students to explain the organizational history
that led to these job roles. Have them find out how the performance of
each of these people are measured, especially in team settings.

3. It shouldn’t be too difficult for students to list the various “systems” for
an organization, perhaps for their university. These may include
standard computer–based information systems such as a transaction
processing system for recording point of purchase sales or for
registering for a course. They should also include systems that are not
computer–based, such as a physical filing system for receipts or for
transcripts. Push the students to place each of their “systems” in the
categories provided in the question. Are there any other system
categories not provided in this question? It will also be useful for the
students to determine the extent to which these systems are, or
should, interact with each other. This will enable the students to
determine whether or not the systems are well integrated (be sure that
the students have a clear idea on what it means for systems to be
integrated).

4. Urge the students to use their imagination here. They might imagine
elegant, costly systems that do not solve the right problem and, as a
result, are not used. Alternatively, they might imagine a system where
a database is kept redundantly in several different locations, or where
information is rekeyed into one part of the system while it already
exists in another format in another part of the system. They might
describe a system that is lost completely because there were no proper
backup and recovery procedures. The useful part of this exercise is that
no matter what disasters or problems they imagine, they have
probably already happened in one setting or another.

5. This is a useful exercise, particularly for beginning information systems

students, because it enables them to see how information systems are
used throughout the organization. Frequently, in smaller organizations
information systems development is more informal, and the various
information systems roles are played by one or a small number of
people. It is interesting to see how people in smaller organizations find
 creative ways to develop and implement technology on a limited
budget and with a limited information systems staff.

6. Journals are an effective teaching and learning tool. It is very

useful to collect these journals from time to time and provide direct
feedback to each student, commenting on their experiences and
answering their questions. You might also periodically have the
students share their journal comments and questions with the rest of
the class and use this as fuel for class discussions. Even if you don’t
have students share actual comments, you might have them talk about
sources of their comments, such as newspaper articles, conversations
with other faculty and students, advertisements, new topics they read
in this textbook, or comments made by a parent

2
Succeeding as a Systems Analyst

Chapter Overview
The purpose of this chapter is to present to students a rendition of the
systems analyst’s role in the system development process and in the
organization. We adopted this focus as we believe that many of the students
who major in information systems become systems analysts of one type or
another, whether they work for IS units in large corporations or as
consultants. Focusing on the systems analyst also allows us to list and
discuss the many diverse skills needed for systems development. The set of
skills we present here is certainly not universally recognized as the most
important, but we have done our best to represent a set of generic skills that
are important to successful systems development efforts.

Other than the introduction and summary, the chapter is divided into five
major sections. Four of these sections cover a basic systems analysis skill set:
analytical, technical, management, and interpersonal. The fifth major section
treats systems analysis as a profession. By far the longest of these five
sections is devoted to analytical skills, and most of that section is about
systems thinking. We have found that some level of systems thinking is very
helpful for sound analysis, which is why we have devoted so much space to it
here.

Chapter 2 also marks the students’ first exposure to our running case,
Hoosier Burger. Hoosier Burger is a fictional family–owned fast food
restaurant supposedly based in Bloomington, Indiana, home of one of our
three authors. The case is used here to illustrate how an organization can be
seen as a system and why the word system appears in the term information
system. A special icon in the margin shows where Hoosier Burger is used as
an illustration.

Instructional Objectives
Specific student learning objectives are included at the beginning of the
chapter. From an instructor’s point of view, the objectives of this chapter are
to:

1. Overview for students the different analytical skills that are important to
systems development, including problem identification, problem solving,
and systems thinking.

2. Discuss the many technical skills required of a systems analyst and why
analysts still need to have basic technical skills, even when systems are
developed using rapid prototyping and code generators.

3. Show how systems analysts use their skills in managing resources,

projects, risk, and change.

4. Emphasize the importance of interpersonal skills for a systems analyst, in

communicating, working with teams, facilitating groups, and managing
expectations.
5. Discuss whether systems analysis qualifies as a profession.
Classroom Ideas
1. In the text, we provide several examples of systems on several levels,
from a restaurant to a CD player to an information system. To make sure
students understand all of the many system concepts that we introduce
here, you may want to present still more examples in class or work
through an example from scratch on the board. Biological examples have
proven easy for students to grasp and useful as a foundation for other
examples. Be sure to build on whatever exposure to general systems
theory your students have had in prior courses.

2. You can use Figures 2–2 and 2–4 to define and illustrate each of the basic
components of a system.

3. We provide an introduction to problem finding and problem solving.

Depending on your course objectives, you could use this as a point of
departure for a more thorough examination of how managers find
problems and set about solving them.

4. Our section on technical skills is rather general and focuses as much on

how to stay current with changing technology as on the skills an analyst
needs. There is much more that could be said about the specific technical
skills an analyst needs, and this is a topic for a lively class discussion,
especially if you are teaching at the graduate level or if some of your
students are graduates with work experience. You might ask your
students to list the technical skills they expect employers will require of
them at graduation and then compare this to the technical skills required
of graduates two years ago. Ask students how they could predict the
skills needed in graduates, say, four years in advance (roughly what
those managing an IS curriculum must do).

5. The section on management skills serves primarily as a pointer to related

content in later chapters (project management in Chapter 3, risk
management in Chapter 6, change management in Chapter 20). Still, the
topics can be used as a basis for discussing why systems analysts, who
are after all developing information systems, should be required to have
general management skills.

6. Communication skills, and the need for them, are probably best
understood from experience and practice rather than from simply talking
about them. You can illustrate good and not–so–good communication
skills through short class exercises, such as the familiar “pass–the–word”
parlor game to show the importance of listening (i.e., the first person
whispers a message to second, who is supposed to relay the same
message to a third person, and so on until the end of the line, but the
message the last person states to the group is rarely even close to the
initial message) or by illustrating good and bad presentation formats to
show the importance of effective presentations (e.g., well–designed color
overheads vs. gray, crowded ones; monotone delivery vs. a more
 dramatic and interested tone; illustrative hand motions vs. hands held
stiffly at sides).

7. Figure 2–9 can be used in class as a point of departure for a discussion of

what group facilitation entails and how students would operationalize
each of the guidelines listed in the figure. Although students may have
practiced public speaking in business communication and speech classes,
it is likely that they have not practiced facilitating group discussions. You
might want to use some of the class time for such an exercise. Pick
current topics of interest to students (e.g., campus issues, career
opportunities) and have groups of different sizes (3–4 person groups, 10–
12 person groups) discuss these issues, with one student designated as
the facilitator. Keep the discussion time short so that you have time to
discuss afterwards how the facilitators handled their groups and how
group size mattered.

8. Is systems analysis a profession? Have students suggest why it is or it

isn’t, particularly with reference to other well–recognized professions.
Have them discuss what it means to have “standards of practice” and
their impact on whether a line of work is a profession. Codes of ethics
and career paths can also be a part of this discussion. Can a profession
exist without a widely–accepted body of knowledge and a certification
process to validate mastery of this knowledge? Are professionals more
loyal to their profession than to their employer? What similarities and
differences do your students see between systems analysts and readily
accepted professionals such as doctors, lawyers, and accountants? Who
is responsible for the continued development of a professional: the
individual or the employer? You can probably think of other provocative
questions to make this a lively discussion. Students might be able to find
some publications that propose definitions of a profession.

9. The ACM Code of Ethics, shown in Figure 2–10, can be a stepping stone
to an involved discussion of ethics in systems analysis. An effective way
to present ethics in the classroom is to provide students with scenarios
and ask them to record what they would do and why. Student responses,
along with the “correct” response, can serve as the basis for a very lively
discussion. Scenarios with ethical dilemmas in IS are currently available
from several different authors and publishers. Many provide guidelines for
using the scenarios as part of class discussions. Another excellent source
of scenarios, as well as an expanded perspective on ethical issues in
information systems development and use, is the December 1995 issue
of Communications of the ACM. Six articles in this issue deal with
computer ethics, and a seventh article addresses a framework for
teaching ethical computing. You can find many good ideas in this issue
for expanding class discussion on being an ethical systems developer.

10. You may want to use the video segment “Managing User Expectations” to
supplement this chapter. This video segment is about 12 minutes long.
Notes on using this video segment are included in a separate section of
the Instructor’s Manual. See the Preface to this Instructor’s Manual for
 information on how to obtain this and other video segments produced for
use with the second edition of Modern Systems Analysis and Design.

Answers to Review Questions

1. A system is an interrelated set of components, with an identifiable
boundary, working together for some purpose. An interface is the point of
contact where a system meets its environment or where subsystems
meet each other. A boundary is the line that marks the inside and
outside of a system and that sets off the system from its environment.
Purpose is the overall goal or function of a system. Modularity can be
defined as dividing a system up into chunks of a relatively uniform size or
modules.

2. Systems thinking involves identifying something as a system, visualizing

the system and translating it into abstract terms, and thinking about the
characteristics of the specific situation. Systems thinking is useful for
thinking about computer–based information systems because information
systems can be seen as subsystems in larger organizational systems,
taking input from, and returning output to, their organizational
environments.

3. Decomposition is the process of breaking down a system into its

component parts. Coupling is the extent to which subsystems are
dependent on each other. Cohesion is the extent to which a system or a
subsystem performs a single function.

4. Organizations are systems because they are made up of interrelated

components working together for a purpose. They take input from and
return output to their environments. Organizations can be redesigned
through a systems analysis and design process by which system
components are replaced while preserving interconnections between
components.

5. In problem identification, you must be able to compare the current

situation in an organization to the desired situation. Problem
identification involves measurement not decision making. Problem
solving is the process of finding one or more ways to reduce these
differences and then selecting one approach for implementation.

6. A systems analyst can determine if his or her technical skills are up–to–
date through reading trade publications, joining professional societies,
and attending classes and conferences.

7. Management skills needed by systems analysts include resource

management (effectively managing the organization’s resources,
including time, people, and money), project management (determining
the tasks and resources needed for a project and how they are related to
each other), risk management (identifying and minimizing risks), and
 change management (managing the transition from one state to
another).

8. Communication skills important for an analyst include clear and effective

interpersonal communication, whether written, verbal, or visual, from
writing reports to face–to–face conversations, to presentations in front of
groups. Listening is also an important aspect of personal communication.
Group facilitation skills (setting an agenda, leading discussions, involving
all parties in the discussion, summarizing ideas, keeping discussions on
the agenda, etc.) are also important.

9. Whether or not systems analysis is a profession is open to debate. The

debate typically centers around whether the following generally accepted
characteristics of a profession exist in the systems analysis field: college
curriculum guidelines, standards of practice, professional societies,
certification programs, and codes of ethics.

10. A code of ethics is a list of statements of intended conduct, emphasizing

personal responsibility, honesty, and relevant laws, which provides
guidelines for individual behavior in situations where the appropriate
ethical action may not be evident.

11. A logical system description portrays the purpose and function of the
system without tying the description to any specific physical
implementation. A physical system description of a system focuses on
how the system will be materially constructed.

12. The areas of organizational knowledge important for an analyst to know

include how work gets done in a particular organization, how internal
politics operate, the organization’s competitive and regulatory
environment, and the organization’s strategies and tactics.

13. An open system interacts freely with its environment, taking input and
returning output, whereas a closed system is cut off from its environment
and does not interact with it.

14. Resource management includes predicting resource usage (budgeting),

tracking and accounting for resource consumption, evaluating the quality
of resources used, securing resources from abusive use, relinquishing
resources when no longer needed, obsoleting resources when they can
no longer be useful, and learning how to use resources effectively.

15. Time constraints, limited number of internal personnel, and more

expertise are reasons for hiring an outside contractor.

16. High-performance team characteristics are summarized in Table 2-2. A

high-performance team is a successful team, yet takes the successful
team concept one step farther. With the high-performance team, one can
see the existence of a real team spirit. The team becomes its own entity.
A good analogy is that of a basketball team. A basketball team can be
 successful and not win a championship. However, most basketball teams
that win a championship have a synergy; each component (individual)
knows what is best for the team, and the good of the team is placed
before the needs of the individual (such as scoring more points).

Answers to Problems and Exercises

1. b closed system e components c environment
a open system d constraint

2. Students might describe inputs to a university or college as new

students, new faculty, new employees, supplies, or funding. Some
outputs include graduating or transferring students, faculty and other
employees who take jobs elsewhere, knowledge, or inventions. It will be
difficult, however, for students to define and agree on a boundary for a
university. Does the physical boundary of the campus serve as the logical
boundary for the organization? What if the school delivers outreach
education in the community, state, or region. What if the school delivers
technology–based distance education across the globe? How would you
classify a university–sponsored high–tech start–up business that is not
located on campus?

It should be easier for students to list the components of a university.

They typically have “business” functions, such as procurement, facilities
management, and accounting. In addition, they have academic colleges
and departments, and they have academic functions such as registration
and advising. Universities are usually organized along a functional
hierarchy much like traditional business organizations, with vertical
reporting relationships and interdisciplinary committees and task forces
for horizontal coordination. Nearly all universities are faced with
constraints on funding.

Many are also constrained by their state-granted mission. For example,

they may be defined by state law as having an exclusively teaching or a
research institution. Alternatively, state law may mandate from where
and what types of students may be admitted. The mission of most
universities includes providing education, conducting research, and/or
serving their communities. Universities interact with other universities,
community colleges and high schools, business organizations,
professional organizations, alumni, and many other external entities. The
interfaces with these external entities are sometimes formal and
sometimes informal. Some examples of formal interfaces include
research collaborations between professors and researchers in business
or “shadowing” programs where business faculty or students go into the
field and learn from a business executive.

3. At this point, the technical details of the figures drawn by the students
are not important. The students should at least draw general systems
diagrams as depicted in Figure 2-2 and Figure 2-4. It is important that the
 students are able to draw a diagram which depicts each of the car
subsystems and includes lines with arrows that show the inter–
relationships between these subsystems. Similarly, they should be able to
draw a diagram of a personal computer, label the subsystems, and show
the inter–relationships between these subsystems. One important
subsystem of a personal computer is the system board (also known as
the motherboard) which includes the processor, memory chips, support
chips, and buses. Other subsystems include the power supply, hard disk,
and input/output devices such as the monitor, keyboard, mouse, printer,
and speakers.

4. It will probably be easiest for students to look back through the section of
the chapter that outlines each of these skill sets. In the area of resource
management, students might list predicting resource usage, tracking and
accounting for resource consumption, evaluating the quality of resources
used, securing resources from abusive use, relinquishing resources when
no longer needed, obsoleting resources when they can no longer be
useful, and learning how to effectively use resources.

For project management students might list decomposing a project or

subproject into several independent tasks, determining who is
responsible for each task and how tasks relate to each other, motivating
people to work together on a project, and setting and achieving project
milestones.

For risk management students might list anticipating what might go

wrong in a project, minimizing the likelihood that those risks will actually
occur, and minimizing the damage that might result from risk.

For change management students might list planning for and managing
resistance to change and helping people to make a smooth transition
from an old system to a new system. Even if students do not yet have
supervisory experience, they have most likely developed and used these
skills in some way. For example, they probably used at least some subset
of the resource and project management skills to complete their course
work.

5. As with the previous question, even if students do not have work

experience, they should be able to draw on their experiences in classes,
clubs, or at home. For example, for working alone versus working with a
team, students can speak about completing class projects. For
interviewing, listening, writing, and presenting, students can speak about
working on a class project or they can reflect on the interpersonal skills
that they use every day. For managing expectations students can speak
about their relationships with friends, roommates, or family members.
This question involves a set of generic interpersonal skills that are
relevant for every aspect of life and are particularly important for work
settings. Students are wise to pursue jobs that allow them to capitalize on
their interpersonal strengths and strengthen their interpersonal
weaknesses. Some ways to improve interpersonal skills are to educate
 and train in interpersonal skills, model the behaviors of someone who
excels at these skills, and practice in those areas that are not up to par.

6. A systems analyst with no personal or professional ethics might copy and

use software illegally, not fulfill and/or abuse hardware and software
under contracts with another vendor, take data from others without
permission, use data in a way that does not respect the privacy of others,
build systems with little/or no concern for the quality of the system or
whether or not the system actually works correctly, take credit for work
that others have performed, blame his/her poor work or mistakes on
other people, or sabotage the work of other people. If his/her unethical
behavior is detected, this systems analyst would probably be fired and
his/her reputation would most likely be ruined.

Some of the consequences for the organization include: that the systems
that this person worked on are not likely to work well, the organizational
performance would suffer, and the reputation of the systems department
and/or of the organization might be tarnished. A code of ethics and
professional conduct can be used to directly curb the behavior of the
systems analyst described above. For example, the ACM code described
in the chapter calls for peer pressure for compliance. Indirectly, such a
code also helps a discipline to build and gain the respect of other
professionals in the organization, so that they can learn what to expect
and demand from an information systems professional. In addition,
because there are codified rules of conduct and an organized professional
society, those people with unethical behavior can be more easily
detected and either helped or urged out of the profession.

7. Universities usually have an information system for processing the

payment of tuition. The purpose of such systems is to accurately process
the payment of tuition in a timely manner. Such a system might have a
component for creating and issuing a billing statement to students each
semester, which would be one possible output for the system. Another
component of the system might create and issue a receipt upon payment
of tuition, which would be another possible output of the system. These
two system components are interrelated in that information about the
student (e.g., student name, identification number, and address, all
possible inputs of the system) is replicated from one statement to the
other. In addition, the amount that the student owes, which is found on
the billing statement, is also used in calculations for the receipt of
payment. Such a system might operate within the broader student fee
payment environment or within the entire student transactions and
records environment.

There is likely to be a boundary between this system and, say, course

registration. These two systems would have to interface, though, so that
continuing students who did not pay fees in a previous semester are not
allowed to register for courses in subsequent semesters. One potential
constraint on this system might be that it cannot be directly linked with
the course registration system. Data cannot be passed automatically
 from one system to the other because the two systems have been
implemented on incompatible hardware and software. Thus, people have
to check manually to see that a continuing student has paid fees in
previous semesters before allowing students to register for courses in
subsequent semesters.

8. In this chapter it was argued that the subsystems within a system should
be relatively uncoupled; that is, they should be as independent of each
other as possible. Similarly, the boundaries between systems should be
set such that the systems are relatively uncoupled. The systems should
be as independent of each other as possible. This way if one system fails,
other systems will not fail or have problems functioning. In addition, the
concept of subsystem cohesion applies to systems as well. Systems
should perform a single function. Some other more pragmatic criteria for
determining a system boundary include setting boundaries that are
commensurate with the resources available for building the system.
Some of the implications of setting too broad a boundary for a system are
that the system may become too complex and it may be difficult and
costly to build and maintain. If the system boundary is too narrow then it
may, in fact, be better to position the system as a sub–system of another
larger system.

9. Students should list their technical skills in all areas, including

programming languages, operating environments, database
management systems, networks, and application packages. As students
compare their skill set with those described in want ads, they should not
be discouraged if their skill set is not up to par. First, they should not
generalize that, because their skill set does not meet the demands of a
couple of want ads, they do not have skills that are valuable in the
marketplace. We cannot generalize from a couple of want ads to the
entire field. Second, the overall all set of possible technical skills is huge
and is ever changing. It is impossible to know everything. As was argued
in the chapter, life long learning is definitely necessary.

10. One way to approach this question is to have students compare and
contrast an “unsuccessful” team with a very “successful” team on which
they have worked. For the unsuccessful team, few, if any, of the high-
performance characteristics will apply. Students will point out that
bickering, lack of trust, and poor participation were evident in the
unsuccessful team. However, with the successful team most of the high-
performance characteristics were evident. Students will probably point
out how they respected, trusted, enjoyed, and felt good about their team
members.

11. The role of the contractor will vary depending on what he or she has been
hired to do. For instance, parts of the project may be contracted out or
the entire project may be contracted out, depending on the
organization’s needs. The IS managers will still be involved in resource
allocation and project approval. If the organization has outsourced IS
development to another company, then the systems development
 activities will be performed by the outsourcing company’s analysts and
programmers. If the project is contracted out, it is very important that the
work be supervised and that the work conform to prespecified guidelines.
As the text suggests a relationships manager will become necessary.

End users are still very necessary to the development process, whether
or not the system is developed in-house or contracted out. Business
managers will still set general requirements and constraints for
development projects.

Guidelines for Using the Field Exercises

1. Nearly all organizations are open systems, so it should be relatively easy
for students to come up with examples. It may be useful for students to
compare their answers and talk about the relative openness of the
organizations they have cited. Perhaps the students could plot their
organizations on a continuum from very closed systems on one end and
very open systems on the other end. This may be a useful vehicle for
comparing and understanding the relative openness of their
organizations. Similarly, the students are likely to benefit from comparing
their organizations in terms of decomposition, coupling, cohesion, and
modularity. Thinking about organizations in these ways helps us to better
understand how organizations operate and are structured. In addition,
applying these concepts to entities that we are familiar with
(organizations) helps us to understand how the concepts apply to
information systems.

2. It may be useful to have students work in small groups to choose a

problem and complete each of the problem solving steps listed in this
question. This would help to point out the benefits of having small groups
of people solve problems together. To stress this point even more, you
might give the class the same problem and have small groups compete
with individuals to solve the problem using the steps listed. You could
then point out the relative advantages and disadvantages of individuals
versus groups in problem solving. Alternatively, you may find that
students will choose more interesting problems if they are allowed to
work on them alone and are not required to share them with other
students. You might have students think of their own problem and
perform the problem solving steps alone. You could then ask students to
comment on the problem solving process while not requiring them to
divulge information about their problems.

3. This question is similar to the fourth question in the Problems and

Exercises section for this chapter. In fact, it may be useful to students to
have them answer that question along with this question. The students
can then compare their own skill sets with those of the managers they
choose. In addition, it will be useful for students to determine the extent
to which these skills contribute to the managers’ overall success. Have
 the students also explore what other skills, attributes, behaviors, and/or
factors contribute to the managers’ success.

4. Students are likely to be developing public speaking skills as they deliver

presentations in their classes. In addition, there may be a speech/debate
team at their school and there may be speech building seminars and
training available through the job placement office or other office on
campus. In the community there may be a club, such as “Toastmasters,”
dedicated to helping people build their public speaking skills. Practicing
public speaking will help improve technique and reduce nervousness.

5. Students should also realize that there will be hardware and

software used in the organization that will not be on the approved
technology list because the units are not allowed to buy this
technology on their own. For example, there may be some
mainframe hardware and corresponding software applications that
end–users do not purchase; the information systems staff may do
the purchasing and systems development. In these situations, while
the end–users do not buy or build their own technologies, the
systems analysts are still required to be competent in the use of
these technologies. In addition, some students are likely to find
organizations that do not have a firm approved technology list. If so,
it will be useful to have the students discuss what a systems analyst
should know under these conditions, as compared to what a
systems analyst should know in an organization with an approved
list. In addition, have the students explain which type of
organization they would rather work in as a systems analyst and
why.

3
Managing the Information Systems Project

Chapter Overview
The purpose of this chapter is to introduce students to the process of
managing an information systems project. Specifically, the chapter focuses
on the system analyst’s role in managing information systems projects
through the four phases in the life of all projects: initiation, planning,
execution, and close down. You (and your students) should think of this
chapter as a valuable reference throughout the systems development course
and use the material in this chapter to assist in guiding and evaluating
ongoing project activities. This chapter has been placed early in the book in
order to provide students with a better understanding of the totality of an
information systems project (e.g., it is not just building the system). You may
want to emphasize that the skills and knowledge gained from this chapter are
a critical foundation to the effective management of not only information
systems projects but all types of projects and activities.

Chapter 3 also introduces our second running case, Pine Valley Furniture.
Pine Valley Furniture provides a concrete example of a systems development
project. This project helps reinforce the analysis and design concepts
presented throughout the textbook. A detailed description of the Pine Valley
Furniture case can be found at the Modern Systems Analysis and Design web
site. The URL for this site is http://hepg.awl.com. The keyword is Hoffer.

Instructional Objectives
Specific student learning objectives are included at the beginning of the
chapter. From an instructor’s point of view, the objectives of this chapter are
to:

1. Explain the process of managing an information systems project.

2. Describe the skills required to be an effective project manager.

3. List and describe the skills and activities of a project manager during
project initiation, project planning, project execution, and project close
down.

4. Explain what is meant by critical path scheduling and describe the

process of creating Gantt and PERT charts.

5. Explain how commercial project management software packages can be

used to assist in representing and managing project schedules.

Classroom Ideas
1. This chapter introduces many different concepts and terms that are
central to the management of information systems projects. Review
Question 1, at the end of the chapter, may be important to discuss in
class to be sure that your students are understanding the material. Be
 sure that you ask your students to review the Key Terms listed at the end
of the chapter.

2. You may choose not to lecture from this chapter. Your students can read
the chapter much as they might read a supplemental, background
reading (this is especially true if your students have already been
exposed to project management concepts in another course). When
reading the chapter this way, you may want to ask each student to apply
the concepts of this chapter to a non–information systems activity (e.g.,
going on a date, vacation, etc.). For this activity, ask students to describe
initiation, planning, execution, and close down activities. Ask them to
create a “work breakdown” structure that includes precedence
relationships and time durations for each activity. Additionally, ask them
to construct Gantt and PERT charts for these activities. You can have
students do this as either an outside class activity or have them do this
during your class time. Within class, you can call on students to describe
their project and phases. Alternatively, you could make this a written
assignment to hand in to be graded or reviewed.

3. If you do lecture about this chapter, you might want to use the tables and
figures in the chapter to point out to the students the major project
management activities.

4. An alternative to lecturing on the chapter is to lecture from the Review

Questions, Problems and Exercises, and Field Exercises at the end of the
chapter. Selected questions can be posed to students to help focus a
discussion on project management concepts and techniques.

5. Depending on the background of your students, you should make sure

that they have the ability to construct Gantt and PERT charts. Working
through the problems presented in the text or in Problems and Exercises
2, 3, 4, 7, and 9 in class may be helpful to many students.

6. Another very effective in–class exercise for teaching this chapter is to ask
students who have been on systems development teams to compare
their experiences to the concepts presented in Chapter 3. This discussion
can be a good way to elaborate on alternative ways for managing
systems development projects, especially if systems were constructed
using different methodologies. Use this discussion to explore if these
student projects followed the discrete phases outlined in the chapter. Ask
them to describe the activities of the project manager. What was the
same? What was different?

7. If you have access to project management software, it is often engaging

for students to see a demonstration of how a systems development
project can be represented. Such a demonstration will not only teach
students project management techniques, but it also gives them greater
confidence to try project management software for themselves.
 8. If you have access to a practicing systems development project manager,
a useful activity is to invite him or her into your class to discuss how he
or she manages projects. Make sure that you ask this person about how
to manage all four phases of a project (even if this isn’t the terminology
he or she uses). Also, what tools are used? How do project members
communicate?

9. If you can obtain a copy of the project management guidelines for a local
systems development firm or consulting organization, show students how
extensive project management guidelines typically are. If you have
students working in systems development organizations, you might ask
several of them to bring to class their firm’s guidelines. If possible,
reproduce the table of contents of these manuals for all students and
have them compare the various guidelines to see what each organization
emphasizes and what is different.

10. You may wish to supplement your lecture on this chapter with the video
segment “Application Engineering.” This video is about 12 minutes long.
Notes on using this video segment are included in a separate section of
this Instructor’s Manual. See the Preface to this Instructor’s Manual for
information on how to obtain this and the other video segments produced
for use with the second edition of Modern Systems Analysis and Design.

Answers to Review Questions

1.Critical path scheduling is a scheduling technique where the order and
duration of a sequence of activities directly affect the completion date of a
project. A Gantt chart is a graphical representation of a project that shows
each task activity as a horizontal bar whose length is proportional to its
time for completion. PERT is a diagram that depicts project activities and
their interrelationships. Project close down is the final phase of the project
management process that focuses on bringing a project to an end. Project
execution is the third phase of the project management process where the
plans created in the prior phases (project initiation and planning) are put
into action. Project initiation is the first phase of the project management
process where activities are performed to assess the size, scope, and
complexity of the project and to establish procedures to support later
project activities. Project planning is the second phase of the project
management process that focuses on defining clear, discrete activities
and the work needed to complete each activity within a single project. A
project workbook is an online or hard copy repository for all project
correspondence, inputs, outputs, deliverables, procedures, and standards
that is used for performing project audits, orientation of new team
members, communication with management and customers, scoping
future projects, and for performing post-project reviews. Any person,
group of people, piece of equipment, or material used in accomplishing an
activity is a resource. Slack time is the amount of time that an activity can
be delayed without delaying the project. A baseline project plan is a
detailed plan that is developed during project planning and reflects the
 best estimate of the project’s tasks and resource requirements. The
baseline project plan is used to guide project execution activities and is
updated as new information becomes available. Earliest expected
completion time refers to the earliest time that an activity can be
completed. Latest expected completion time refers to the latest time that
an activity can be completed without delaying the project.

2. Critical path scheduling refers to project scheduling techniques that

sequence project activities based upon their duration and precedence in
order to minimize the completion date of a project. Gantt is a specific,
graphical technique for representing projects by showing each task
activity as a horizontal bar whose length is proportional to its time for
completion. PERT is a specific, graphical technique for representing
projects by depicting project activities and their interrelationships as a
network diagram. Slack time represents the amount of time that a single
activity within a project can be delayed without delaying the completion
date of the project.

A project is a planned undertaking of related activities to reach an

objective. Project management is a controlled process for initiating,
planning, executing, and closing down a project (i.e., the science of
managing a project). The project manager is the individual who is
responsible for managing the activities involved in completing a project.

Projects are managed through four distinct phases: initiation, planning,

execution, and close down. Project initiation refers to activities used to
assess the size, scope, and complexity of the project and to establish
procedures to support later project activities. Project planning focuses on
defining clear, discrete activities and the work needed to complete each
activity within a single project. Project execution focus on putting the
plans created in prior phases into action. Project close down focus on
bringing a project to an end.

A project workbook is a repository for all project documentation. Any

person, group of people, piece of equipment, or material used in
accomplishing an activity are resources. A work breakdown structure
refers to the process of dividing the project into manageable tasks and
logically ordering them to ensure a smooth evolution between tasks.
When developing a work breakdown structure, the project manager must
carefully consider his/her resources. The work breakdown structure is
stored in the project workbook.

3.Information system projects are undertaken for two primary reasons: to

take advantage of business opportunities or to solve business problems.
Taking advantage of an opportunity might occur by providing an
innovative service to customers through the creation of a new system.
Solving a business problem could occur by modifying the way in which an
existing system processes data so that more accurate or timely
information is provided to users.
4.The common skills and activities of a project manager are highlighted in
Table 3–1. Although a case could be made for virtually all project
management skills listed in the table, one skill—being an effective oral
and written communicator—is likely the most fundamental skill for a
project manager to master. Without effective communication skills, the
ability to successfully complete activities will be curtailed.

5.There are five major activities during project initiation; these include
establishing the project initiation team, establishing a relationship with the
customer, establishing a project initiation plan, establishing management
procedures, and establishing the project management environment and
project workbook. Establishing the project initiation team focuses on
organizing an initial core of project team members that assist in
accomplishing the project initiation activities. Establishing a relationship
with the customer focuses on building a cooperative and trusting
partnership with the customer. Establishing a project initiation plan
focuses on defining the necessary activities required to organize the
initiation team while they are working to define the scope of the project.
Establishing management procedures focuses on developing team
communication and reporting procedures, job assignments and roles,
project change procedures, and determining how project funding and
billing will be handled. Establishing the project management environment
and project workbook focuses on establishing the repository for all project
correspondence, inputs, outputs, deliverables, procedures, and standards
established by the project team.

6.The activities performed by the project manager during project planning

include describing project scope, alternatives, and feasibility; dividing the
project into manageable tasks; estimating resources and creating a
resource plan; developing a preliminary schedule; developing a
communication plan; determining project standards and procedures;
identifying and assessing risk; creating a preliminary budget; developing a
statement of work; and setting a baseline project plan.

The purpose of describing project scope, alternatives, and feasibility is

to develop an understanding of the content and complexity of the project
by gaining answers to and agreement on the following types of questions:
 What problem or opportunity does the project address?
 What are the quantifiable results to be achieved?
 What needs to be done?
 How will success be measured?
 How will we know when we are finished?

After defining the scope of the project, the next objective is to identify and
document general, alternative solutions for the current business problem
or opportunity and assess each for feasibility so that a choice can be
made as to which to consider during subsequent SDLC phases.
 The focus of dividing the project into manageable tasks is to divide the
entire project into manageable tasks and then logically order them to
ensure a smooth evolution between tasks.
Estimating resources and creating a resource plan focuses on estimating
resource requirements for each project activity and using this information
to create a project resource plan. Developing a preliminary schedule uses
information regarding tasks and resource availability to assign time
estimates to each activity in the work breakdown structure. This
assignment will allow for the creation of target starting and ending dates
for the project. Developing a communication plan outlines the
communication procedures between management, project team
members, and the customer. Determining project standards and
procedures specifies how various deliverables are produced and tested.
Identifying and assessing risk identifies sources of project risk and
estimates the consequences of those risks. Risks might arise from the use
of new technology, resistance to change, availability of critical resources,
competitive or regulatory actions, or team member inexperience with
technology or the business area.

The focus of creating a preliminary budget is to create a preliminary

budget that outlines the planned expenses and revenues associated with
your project. The focus of developing a statement of work is to create a
document that outlines all work that will be done and makes clear what
the project will deliver. The focus of setting a baseline project plan is to
develop an initial plan that reflects the best estimate of the project’s tasks
and resource requirements and is used to guide the next project phase,
execution.

7.The activities performed by the project manager during project execution

include executing the baseline project plan, monitoring project progress
against the baseline plan, managing changes to the baseline project plan,
maintaining the project workbook, and communicating the project status.

The focus of executing the baseline project plan is to oversee the

execution of the baseline plan (i.e., the execution of project activities,
acquire and assign resources, orient and train new team members, keep
the project on schedule, and assure the quality of project deliverables).
The focus of monitoring project process against the baseline plan is to
monitor the actual progress of the project against the baseline plan. If the
project gets ahead of (or behind) schedule, adjustments to resources,
activities, and budgets can be made. The focus of managing changes to
the baseline project plan is to evolve the baseline project plan as events
(e.g., a slipped completion date of an activity) occur. The focus of
maintaining the project workbook is to maintain the project workbook,
which contains project-related information. The focus of communicating
the project status is to inform all interested parties—systems developers,
managers, and customers—about the status of the project.

8.Table 3–4 summarizes project team communication methods. The table

rates each method in terms of formality and use—for informing, for
resolving issues, or for keeping permanent records. The following table
lists these communication methods and provides an example of the type
of information that might be shared among team members using each
method.
Team Communication Methods and
Corresponding Examples

Communication Examples
Methods

Project Workbook Official system documentation, such as data flow

diagrams or entity–relationship diagrams, interview
notes
Meetings Review project schedule
Seminars and Techniques and methods to be used in subsequent
Workshops project phases
Project Newsletters Introduce new team members, explain upcoming
project activities
Status Reports Project activity completions and issues
Specification Form designs, program structure charts
Documents
Minutes of Meetings Decisions made on alternative system designs
Bulletin Boards Project status, awards for team members
Memos Guidance to team members, personnel appraisals
Brown–Bag Lunches Information from trade shows attended by team
members, ideas about articles read on SA&D
Hallway Discussions Answers to questions, advice on how to deal with
problems

9.The activities performed by the project manager during project close down
are closing down the project, conducting post-project reviews, and closing
the customer contact. The focus closing down the project is to conclude
the project. The objective of conducting post-project reviews is to assess
the strengths and weaknesses of project deliverables, the processes used
to create them, and the project management process. The focus of closing
the customer contact is to ensure that all contractual terms of the project
have been met.

10.Critical path scheduling is a scheduling technique where the order and

duration of the sequence of project activities directly affect the completion
date of a project. Applicable project characteristics include:
 well–defined activities that have a clear beginning and end point.
 activities that can be worked on independently of other activities.
  activities that are ordered (or can be ordered).
 activities that when completed serve the purpose of the project.

11.The steps involved in making a Gantt chart are:

1. Identify each activity to be completed in the project.
2. Determine time estimates and calculate the expected completion time
for each activity.
3. Determine the sequence of the activities and precedence relationships
among all activities.
4. Construct the Gantt chart.

12.The steps involved in making a PERT chart are:

1. Identify each activity to be completed in the project.
2. Determine time estimates and calculate the expected completion time
for each activity.
3. Determine the sequence of the activities and precedence relationships
among all activities.
4. Construct the PERT chart.

13.Project planning typically occurs during the “Project Initiation and

Planning” phase of the SDLC. Project management occurs during all phase
of the SDLC, yet, different project management activities occur during
different SDLC phases.

14.Task sequence will depend on which tasks produce deliverables needed in

other tasks, when critical resources are available, constraints placed on
the project by the client, and the process outlined in the SDLC.

Answers to Problems and Exercises

1. d. project b. Baseline Project Plan f.. PERT Chart
e. Gantt Chart c. project workbook a. critical path

2. Each of the four phases of project management has its unique challenges.
Thus, students’ choices of which is most challenging should vary. Project
initiation, the first phase, involves team building, building relationships
with customers, defining the problem and project, and other challenging
tasks. Some students may (appropriately) argue that this first phase is
most important. If the first phase is conducted poorly, the project is likely
to be doomed to failure. Project planning, the second phase, is also
important because it can make or break the success of the project work
that follows. In addition, resource planning, scheduling, crafting a budget,
and other planning tasks are difficult. Good planning is also a challenge
because there is nearly always pressure to truncate or do away with
planning altogether. Many students are likely to choose project execution,
the third phase. This involves actually building the system, which is the
primary responsibility and often is the longest phase of project
management. Closing down the project, the fourth phase, is not likely to
be chosen by students as much as are other project phases. However, this
phase is equally challenging. The break up of the team is a difficult, often
 overlooked aspect of project management. In addition, there may be
assignment changes for team members and there are likely to be
performance appraisals of team member performance. These are difficult
and important personnel tasks that must be completed.

3. Sources of risk include difficulties in constructing the system (due to

unfamiliarity with the business area or new technologies), necessary
systems personnel leaving before the system is completed, competitor’s
response to the successful implementation of the system, failures of
vendors to supply promised technology, uncooperative users, and so on. It
is important that a manager identify the potential sources of risks,
describe the possible negative outcomes, determine the probabilities of
occurrence, and prepare contingency plans for those significant outcomes
with a high probability of occurrence.

4. There are several good project management software packages available

for the personal computer. Microsoft Project for Windows and Primavera
are two that are widely used. Information about project management
software can be obtained from a variety of sources, including the World
Wide Web, trade magazines, the library, marketing packets, and testing
services. The World Wide Web is an excellent source of information. As
part of your class activities or as a homework assignment, students can
search the web for relevant information about project management
software. If time permits, ask students to investigate public domain and
shareware products. How do these products compare with Microsoft
Project?

Students can call trade magazines directly and ask for the dates of issues
that contained reviews. Computer searches in the university library may
identify articles they can obtain through inter–library loan and duplicating
services. Alternatively, students can contact the vendors directly to
receive information about software. Vendors will often provide copies of
published reviews in their marketing packets. Software reviews are also
available from Auerbach Publishers and Datapro.

The advice to give to prospective buyers of project management software

is much like that of buyers of software generally. For example, it is
probably a good idea to advise someone to first determine what they need
and why they need it, and then see what packages best meet their needs
at an acceptable price. Obtaining the opinions of those who have used the
software for situations similar to your own is also very advisable. Chapter
11 provides additional information on evaluating vendors and software.

5. Information systems are very similar to other types of projects. Most large,
complex projects, whether they involve developing information systems or
not, share many characteristics. For example, they involve time and
resource constraints, managing people, breaking a project into sub–tasks
and determining the inter–relationships among the sub–tasks, and so on.
Information systems projects are different in that they tend to involve
technological change more often than do other types of projects. The
 project management software that the students reviewed is most likely to
be generic; that is, it can be used for a variety of projects, just as a word
processor or spreadsheet can be used for a variety of tasks in a variety of
organizations. Microsoft Project for Windows, for example, can be used for
nearly any project, regardless of whether or not it is a systems
development project.

6. Student answers will vary, but all should accept the opportunity to
become the manager of an information systems project if they believe
that they are ready. This is a great opportunity and is often the
springboard into higher managerial opportunities within the systems area.
Students should draw from the list of skills and activities of a project
manager listed in Table 3–1. In addition, students may list other skills,
abilities, and experiences that will make them a good project manager.
Students who believe that they would feel uncomfortable being a project
manager probably believe that they do not have enough experience.
Additional training and education will help, but often the best way to learn
how to manage is to do it. They might start out by supervising the
completion of relatively small projects or closely watching a mentor as he
or she manages a project.

7. Task Expected Time

A 7
B 8.67
C 3
D 5
E 6
F 5
G 4
H 4
I 5
J 6.83

8. The PERT chart provided below was created as a screen capture from
Microsoft Project. The students may use this or some other project
management software to produce their chart, may use a graphics
package, or draw the chart by hand. The important issue is that they
accurately express the relationships among the activities in this problem.
The earliest expected completion time is 27 weeks. The activities in the
boxes with the darker border are all on the critical path. These include
collect requirements, analyze processes, design processes, design reports,
test and document, and install. Changing Activity 6 from 1 week to 6
weeks doesn’t mean much. Activity 6 is off the critical path, as is Activity
8, its successor. There is enough slack time for Activities 6 and 8 so that
this change doesn’t affect the project completion time.

1
3 6 8
0
1 2 4 7 9
BOLD
shows
5
See table below to answer parts B and C.

Immediate Early Late Critical

Activit Tim Predecess Finish Finish Slack Path?
y e ors
1 2 -- 2 2 0 Yes
2 3 1 5 5 0 Yes
3 3 2 8 12 4 No
4 7 2 12 12 0 Yes
5 6 2 11 12 1 No
6 1 3, 4 13 17 4 No
7 5 4, 5 17 17 0 Yes
8 4 6, 7 21 25 4 No
9 8 7 25 25 0 Yes
10 2 8, 9 27 27 0 Yes

D. If activity 6 were changed, the critical path would not change.

However, it could be argued that Activity 6 joined the critical
path since it now has zero slack. Yet, it is not on a path. In other
words, since Activity 6 flows only into Activity 8, and Activity 8 is
not on the critical path, Activity 6 does not show up on the
critical path. (In our courses, we accept it as being a "critical
activity" -- due to the zero slack -- but not on the path. Try
analyzing this problem in a project management program like MS
Project, it too will not show Activity 6 on the critical path.) In
addition to no changes in the critical path, the early and late
finish times (and slack) are also changed in two activities as
shown below (all others are the same as the table above).
 Immediate Early Late Critical
Activit Tim Predecess Finish Finish Slack Path?
y e ors
6 1 3, 4 18 18 0 Yes / No
8 4 6, 7 22 25 4 No

9. The following Gantt chart was created as a screen capture from Microsoft
Project. The students may use this or some other project management
software to produce their chart, may even use a graphics package, or
draw the chart by hand. This chart reflects the change in Activity 6 from 1
week to 6 weeks. The activities with solid bars are on the critical path. The
Gantt chart for problem 8 is taken from MS Project with a June 12, 1998
start time.

10.The following PERT chart was created as a screen capture from Microsoft
Project. The newly added, week–long activity is labeled “feedback.” These
new time estimates have pushed the earliest expected completion time to
63 weeks. The activities in the boxes with darker border are all on the
critical path. These include collect requirements, analyze processes,
design processes, design reports, test and document, install, and
feedback.

Immediate Early Late Critical

Activit Tim Predecess Finish Finish Slack Path?
y e ors
1 4 -- 4 4 0 Yes
2 2 1 6 6 0 Yes
3 6 2 12 27 15 No
4 21 2 27 27 0 Yes
5 12 2 18 27 9 No
6 2 3, 4 29 42 13 No
7 15 4, 5 42 42 0 Yes
8 8 6, 7 50 58 8 No
9 16 7 58 58 0 Yes
10 4 8, 9 62 62 0 Yes
11 1 9,10 63 63 0 Yes
 1
3 6 8
01
1 2 4 7 9
1
BOLD
shows
5
critical
path

11. Be sure that students choose projects of sufficient complexity to make

it worthwhile to create Gantt and PERT charts. Encourage students to use
project management software to create their charts. Have students
compare their charts and, if possible, compare charts created using
different software projects. Have students discuss the comparative
strengths and weaknesses of these packages. Alternatively, compare
charts drawn using software with those drawn by hand. Have the students
discuss the comparative advantages and disadvantages. Emphasize the
typical power of any computer tool, which is the efficiency of making
changes to the data compared to manual methods.

12.Some of the difficulties are easier to deal with. For example, to change the
project plan to account for the delays, the students will simply adjust their
Gantt and PERT charts accordingly. Other difficulties, however, will be
much more problematic. For example, dealing with the boss is potentially
much more difficult. Frequent communication, accurate and full
assessments of the situation, requests for reasonable means to deal with
problems, and a history of being a good project manager are necessary to
gain compliance from the boss.

There are basically four problems. The reassigned team member and the
changes in due dates are beyond the control of the project manager.
However, the personality clashes among team members and the mistaken
completion estimate for one of the tasks are within the control of the
project manager, or at least these two problems, if unsolved, may reflect
poorly on the project manager. One prudent alternative would be to go to
the boss and explain to him/her the situation. The project manager should
also explain to the boss what he/she is doing to solve the two problems
that are within his/her control. If the boss absolutely cannot accept the
project past the original deadline, then additional resources will be needed
to complete the project on time. If additional resources will solve the
problem, and they are available, the project manager will have to provide
a fairly strong, convincing rationale for why these new resources should
be allocated to this project. The project manager might show, for example,
that the project cannot be completed on time unless the boss doubles the
programmers available for this project or takes some much needed
experts off other projects and assigns them to this project.
13.A suggested answer is provided below.

Immediate Critical
Activit Tim Predecess EF LF Slack Path?
y e ors
A 5 -- 5 5 0 Yes
B 3 A 8 9 1 No
C 4 A 9 9 0 Yes
D 6 C 15 15 0 Yes
E 4 B, C 13 16 3 No
F 1 D 16 16 0 Yes
G 5 D, E, F 21 21 0 Yes

Below is the Gantt chart from MS Project with the starting date set at June
12, 1998.

14.A PERT Chart for Problem 13 is provided below.

B E G
A
BOLDC D F
shows
critical
path
15. A suggested answer is provided below.

Immediate Early Late Critical

Activit Tim Predecess Finish Finish Slack Path?
y e ors
A 4 -- 4 4 0 Yes
B 5 A 9 31 22 No
C 6 A 10 17 7 No
D 7 A 11 11 0 Yes
E 6 A, D 17 17 0 Yes
F 5 C, E 22 22 0 Yes
G 4 D, E 21 22 1 No
H 3 E 20 26 6 No
I 4 F, G 26 26 0 Yes
J 5 H, I 31 31 0 Yes

B
A C F J
D H I
BOLD E G
shows
critical
path
16.Below is the Gantt chart from MS Project with the starting date set at June
12, 1998.

17.A suggested answer is provided below.

Immediate Early Late Critical

Activit Tim Predecess Finish Finish Slack Path?
y e ors
A 2 -- 2 2 0 Yes
B 3 A 5 5 0 Yes
C 4 B 9 9 0 Yes
D 5 C 14 14 0 Yes
E 4 C 13 14 1 No
F 3 D, E 17 17 0 Yes
G 4 F 21 21 0 Yes / No
H 6 F 23 23 0 Yes
I 5 G, H 28 28 0 Yes
J 2 G 23 28 5 No
K 4 I, J 32 32 0 Yes

Activity G could be argued to be on or off the critical path. In reality,

there are two kinds of slack -- the amount of time a task can slip before
it affects another task's dates or the project finish date. "Free slack" is
the amount of time a task can slip before it delays another task.
Whereas, "total slack" is the amount of time a task can slip before it
delays the project finish date. In this text, we have represented slack
as simply free slack. Thus, since Activity J's Early Start time is 21
(making G's Late Finish time 21), Activity G has zero Free Slack -- which
would support the argument that G is on the critical path. However,
since Activity J is not on the critical path (has 5 units of slack) and
Activity I (which is on the critical path) does not need to begin until
time 23, Activity G has 2 units of Total Slack (i.e., we could delay
activity 2 units before it would delay the completion of the project).
Please consider this when grading your students' answers and
explaining this problem.
 A
B D F H
C
BOLD
E G I K
shows J
critical
path

18.Student answers will vary. However, students will likely mention reviewing
degree requirements, visiting with advisors, comparing schedules with
friends (making sure they are in the same class), reviewing work
schedules, and course schedules. Encourage students to use a project
management software package to create their PERT and Gantt charts. Ask
them to discuss the advantages to using project management software
over constructing the charts by hand.

Guidelines for Using the Field Exercises

1.Students are likely to find a variety of answers for this question, so it will
be useful for students to compare their answers. Each of us is unique, as
are project managers, so the students are likely to find variations in the
skills and activities that project managers are responsible for, in the skills
and activities they find more challenging, in those they are better at, and
in those they prefer. Table 3–1 is a fairly complete list, so it will be
interesting to see if students can find managers who mention skills or
activities not listed in the table. You can use the information generated by
 the students in your lecture on project management the next time you
teach the course.

2.As with the previous question, students are likely to find a variety of
answers for this question. Thus, it will be useful for students to compare
their answers. While the project planning elements in Table 3–3 are fairly
complete, they are operationalized slightly differently within each
organization. Students are likely to find variations in the extent to which
these elements are part of each person’s planning process. Have the
students discuss why the barriers exist and what can be done to either do
away, exploit, or work around these barriers.

3.People have different communication strengths, weaknesses, and

preferences, and different forms of communication are emphasized in
different organizations. However, meetings, memos, and hallway
discussions occur in nearly all organizations. People are likely to have
distinct ideas about which types of communication are best for certain
situations. For example, people tend to use memos for more formal
communication. Similarly, people tend to use hallway discussions for more
informal and/or sensitive information.

4.This question parallels Field Exercise 2 in many ways. In fact, it may be

useful to have students answer Field Exercises 2 and 4 simultaneously
with the project manager they have chosen. While the project execution
elements in Table 3–5 are fairly complete, they are operationalized slightly
differently within each organization. Students are likely to find variations
in the extent to which these elements are part of each person’s work.
Have the students discuss why the barriers exist and what can be done to
either do away, exploit, or work around these barriers.

5.This is a fairly substantial question, but it should provide rich, useful

information for discussion in class. The key issue here is the similarities
and differences between information systems projects and projects that
do not involve systems. In particular, are different personal leadership
attributes required for systems projects versus non–systems projects. The
culture and general management style of an organization can affect
leadership attributes applied in each case. Many people argue that
leadership skills and attributes are generic and transcend most tasks and
jobs. However, the students may uncover some perceived differences
from their small data set they build from the self–reports of project
managers.

6.This can be a very useful exercise, especially if the students can observe
an information system project team building a real system. If not, it is still
useful for the students to conduct the same exercise using a class–based
student project team. Alternatively, the students might read something
like Tracy Kidder’s award winning book The Soul of a New Machine, which
is an account of an information systems project (new computer system
design) team in industry (Data General). This book is an excellent case
study of the sociology of teams and projects. Have the students compare
 their answers to see if a general set of project team do’s and don’ts
arises. Have the students also address the extent to which each of these
do’s and don’ts is generalizable to other project team settings.

4
Automating Development through CASE

Chapter Overview
The purpose of this chapter is to introduce students to the role of automated
tools in the design and development of information systems. Specifically, this
chapter overviews the evolution and use of automated tools in the systems
development process. The purpose of CASE is to make it much easier for an
organization to enact a single design philosophy across many projects,
systems, and people. Given this, the chapter first describes the evolution of
CASE usage in organizations, why organizations adopt CASE, and the impacts
of CASE on individuals within organizations. The chapter then outlines the
components of a comprehensive CASE environment and discusses how
specific CASE tools are related to each phase of the SDLC. The chapter
concludes with a brief examination of visual and emerging development
tools.

Instructional Objectives
Specific student learning objectives are included at the beginning of the
chapter. From an instructor’s point of view, the objectives of this chapter are
to:

1. Emphasize the tradeoffs when using CASE to support systems

development activities.

2. Describe organizational forces for and against the adoption of CASE.

3. List and describe the typical components of a comprehensive CASE

environment.

4. Describe the general functions of upper CASE, lower CASE, cross life cycle
CASE, and the CASE repository.

5. Describe the role of CASE and how it is used to support activities within
the SDLC.
6. Provide the conceptual background about CASE necessary to understand
the potential features of any CASE tool students might use in the course.

7. Describe the benefits of visual and other emerging development tools.

Classroom Ideas
1. This chapter introduces many different concepts and terms that are
central to understanding the role of CASE in organizations and in the
systems development process. Review Question 1, at the end of the
chapter, may be important to discuss in class to be sure that your
students are understanding the material. Be sure that you ask your
students to review the Key Terms listed at the end of the chapter.

2. You may choose not to lecture from this chapter. Your students can read
the chapter much as they might read a supplemental, background
reading (this is especially true if your students have already been
exposed to CASE in another course, through work experience, or in out–
of–class lab experiences). When reading the chapter this way, you may
want to ask your students to focus on the role of CASE within
organizations. Additionally, ask them to consider how they feel about
CASE. Do they like CASE (e.g., does CASE free them from performing
mundane tasks or does is constrain their creativity)? Within class, you
can call on students to describe their views, or you could make this a
written assignment to hand in. It is important that students understand
why CASE is still not a widely accepted technology. If possible, have
students utilize a CASE tool in class assignments or projects. From first–
hand use of a CASE tool, students can better appreciate the power,
discipline, investment, and coordination necessary to effectively use
CASE in an organization.

3. If you do lecture about this chapter, you can use the tables and figures in
the chapter to point out to students the major concepts brought out in
the chapter. There are many effective tables that summarize the main
points. See the Preface to this Instructor’s Manual on how to obtain
transparency masters for the tables and figures in the chapter.

4. An alternative to lecturing on the contents of the chapter is to lecture

from the Review Questions, Problems and Exercises, and Field Exercises
from the end of the chapter. Selected questions can be posed to students
to help focus a discussion on CASE concepts and usage.

5. Another very effective in–class exercise for teaching this chapter is to ask
students who have been on systems development teams to compare
their experiences to the concepts presented in Chapter 4. This discussion
can be a good way to elaborate on alternative ways for constructing
information systems. If some students have used CASE before, have
them describe their experiences from a systems design and development
standpoint and from an organizational standpoint. Have them discuss
 why CASE is or is not being deployed in the organizations with which they
are familiar.

6. If you have access to CASE software, it is often engaging for students to

see demonstrations of how CASE can be used to perform various systems
development activities. An effective example is to build a multi–leveled
data flow diagram or to rapidly prototype a user interface where students
help you select menu names, fonts, prompts, etc. Such demonstrations
will not only teach students about CASE, but it also gives them greater
confidence to use CASE for themselves. Several CASE tool vendors have
videos (with obvious marketing overtones) that demonstrate their
products.

7. If you have access to practicing systems analysts who use CASE, an

insightful activity is to invite them into your class to discuss how they use
CASE in their organization. Have them describe issues from both a
technical and organizational perspective.

8. If you can obtain copies of CASE product marketing materials, it is often

engaging for students to read about and contrast the system capabilities
of various tools and environments. Vendors will often gladly send you
multiple copies of product brochures, demonstration disks, and
videotapes that you could review during a class period. Alternatively, you
could place these product marketing materials on reserve in your library
and have students review and report back to you (in class or in writing)
what they have learned. Because CASE tools rapidly change, it is difficult
to keep these materials up–to–date, so you will want to request new
brochures and materials annually.

9. Students can be placed into groups of about three or four students. Each
group can be asked to research a particular CASE product. During a
subsequent class period, each group’s findings can be presented to the
class. After the presentations have been completed, ask the class to
compare and contrast the products.

Answers to Review Questions

1. CASE (Computer–aided software engineering) refers to software tools that
provide automated support for some portion of the systems development
process. Code generators are a type of CASE tool that enable the
automatic generation of program and database definition code directly
from the design documents, diagrams, screens, forms, windows, and
reports stored in the repository. Cross referencing is a feature performed
by a data dictionary that enables one description of a data item to be
stored and accessed by all individuals so that a single definition for a
data item is established and used. A data dictionary is the repository of
all data definitions for all organizational applications. I-CASE refers to an
automated systems development environment that provides numerous
tools to create diagrams, screens, forms, and reports; provides analysis,
 reporting, and code generation facilities; and seamlessly shares and
integrates data across and between tools. Information repository refers to
automated tools used to manage and control access to organizational
and application portfolio information as components within a
comprehensive repository. Lower-CASE tools are CASE tools designed to
support the implementation and maintenance phases of the systems
development life cycle.

Re-engineering refers to automated tools that read program source code

as input, perform an analysis of the programs data and logic, and then
automatically, or interactively with a systems analyst, alter an existing
system in an effort to improve its quality or performance. Reverse
engineering refers to automated tools that read program source code as
input and create graphical and textual representations of program
design–level information such as program control structures, data
structures, logical flow, and data flow. A repository is a centralized
database that contains all diagrams, screens, forms, and report
definitions, data structure, data definitions, process flows and logic, and
definitions of other organizational and system components; it provides a
set of mechanisms and structures to achieve seamless data–to–tool and
data–to–data integration. Reusability is the ability to design software
modules in a manner so that they can be “reused” in other systems
without significant modification. Upper CASE tools are CASE tools
designed to support the information planning and the project
identification and selection, project initiation and planning, analysis, and
design phases of the systems development life cycle. Version control
(within the CASE repository) refers to a feature supported in some more
advanced CASE products that allows one repository to contain the
description of several versions or releases of the same application
system. A repository is considered to be active in development when it is
used as a documentation tool and is accessed by various CASE tools
during systems development. A repository is considered to be active in
production (AIP) when the repository is more than a documentation and
development tool. Specifically, it is AIP when the mechanism through
which application programs are constructed, changed, and made
consistent with evolving and changing business polices and procedures
are made through the repository. Cross life cycle CASE refers to CASE
tools designed to support activities that occur across multiple phases of
the systems development life cycle.

2. The use of CASE is growing as a result of how CASE has evolved to

support a wider variety of system development activities. Yet, the
deployment of CASE within organizations has been slower than expected
due to several factors, including:

 The high cost of equipping systems analysts with CASE

 The long training times needed for learning CASE
 Slow return on investment for CASE
 Lack of integration between and across CASE tools and environments
 Given these factors, the outlook for CASE is good, however wide–spread
adoption is not imminently anticipated. System functionality is increasing
and systems are becoming increasingly integrated.

3. The objectives for CASE in organizations are contained in Table 4–1.

4. As stated in the chapter, CASE is an expensive technology, often leaving

only large–scale system builders capable of the investment required for
organization–wide adoption. Yet, many smaller organizations have
effectively deployed CASE by using fewer and less sophisticated tools to
automate only a subset of all development activities, thus substantially
reducing deployment costs.

5. CASE fulfills several roles within an organization; one of which is to

improve the quality and speed of the systems developed. However, the
adoption of CASE is highly related to the use of a formal systems
development process. Many CASE products force or encourage analysts
to follow a specific methodology or philosophy for systems development.
For example, Texas Instrument’s IEF product is integrally related to the
information engineering style of systems development. Thus, an
organization without a widely–used methodology or one that does not
match CASE tools will find it difficult to use CASE. Without a match
between a methodology and CASE, CASE is simply another graphical
drawing, word processing, and reporting package.

6. CASE impacts systems analysts, programmers, users, top managers,

functional managers, and IS project managers. The common impacts of
CASE on each of these individuals are listed in Table 4-2.

7. The driving forces behind the adoption of CASE are summarized in Table
4–3, and the resisting forces are summarized in Table 4–4.

8. The general types of CASE tools are diagramming tools, computer display
and report generators, analysis tools, a central repository, documentation
generators, and code generators. Diagramming tools enable system
process, data, and control structures to be represented graphically.
Computer display and report generators help prototype how systems
“look and feel” to users. Display (or form) and report generators also
make it easier for the systems analyst to identify data requirements and
relationships. Analysis tools automatically check for incomplete,
inconsistent, or incorrect specifications in diagrams, screens, forms, and
reports. A central repository enables the integrated storage of
specification, diagrams, reports, and project management information.
Documentation generators help produce both technical and user
documentation in standard formats. Code generators enable the
automatic generation of program and database definition code directly
from the design documents, diagrams, screens, forms, and reports. The
repository is likely the most important component of a comprehensive
CASE system because it provides the mechanisms through which tool and
activity integration can occur.
9. The repository is a centralized database that contains all diagrams,
screens, forms, and report definitions, data structure, data definitions,
process flows and logic, and definitions of other organizational and
system components; it provides a set of mechanisms and structures to
achieve seamless data–to–tool and data–to–data integration. The data
dictionary is a computer software tool used to manage and control access
to the information repository. It provides facilities for recording, storing,
and processing descriptions of an organization’s significant data and data
processing resources.

10. The differences between traditional non–automated systems

development and CASE–based systems development are summarized in
Table 4–7.

11. Supporting project identification and selection. The purpose of project

identification and selection is to examine the information needs of the
organization and to segment and rank these needs so that the most
beneficial projects are identified and selected. The desired output from
this process is a planning document in which the organization decides
how it will allocate its IS resources to specific projects. CASE can be used
to help display and structure higher–level organizational information.

Supporting project initiation and planning. The purpose of project

initiation and planning is to organize a project team and to create a high–
level project plan. The desired output from project initiation and planning
is the creation of the Baseline Project Plan. Project initiation and planning
is often referred to as a “mini–analysis” phase where the planning team
will extensively use the cross life cycle capabilities of the CASE repository
and documentation generator, in addition to project management
software.

Supporting analysis. The purpose of analysis is to determine the

requirements for the development project within the cost, labor, and
technical constraints of the organization. The desired output from these
three activities is a set of diagrams, screens, forms, and reports that can
be used as the basis for the system design. Many CASE tools can be used
during analysis. Especially important are the diagramming, screen, form,
and report generators, and, of course, analysis tools.

Supporting design. The purpose of design is to create detailed plans of

the software system. The desired output from design is a detailed plan
that defines the system specification consistent within the limitations and
characteristics of the environment in which the system will be
constructed. The CASE tools that can be used to support the design
phase include the diagramming, screen, form, and report generators,
analysis tools, and documentation generators.

Supporting implementation. The purpose of implementation is to

translate a system design specification into an information system. The
 desired output from implementation is to create, test, and deploy an
error–free system that meets the specifications of the design. The CASE
tools used during implementation include, of course, code generators,
but also the analysis tools, documentation generators, and screen, form,
and report generators which are commonly used to construct reference
materials such as the user, training, and installation guides.

Supporting Maintenance. The purpose of maintenance is to make

changes to existing software systems. The desired output from the
systems development maintenance process is, of course, updated
software, but also updated system specifications, diagrams, screens,
reports, and documentation. This also means that all CASE tools used to
support its initial development are used during maintenance.

12. Reusability is the ability to design software modules in a manner so that

they can be “reused” in other systems without significant modification.
There are many items that can be reused besides programming code
such as design documents (diagrams, specification documents, screen,
form, and report layouts) and project management modules (schedules,
assignments, report formats, project plans). The benefits of reusability
are reduced development time and cost and improved software quality
by using time–tested modules. Reusability is possible, but unlikely,
without CASE. CASE can be used to manage the complexity of keeping
track of countless modules, variables, and functions. It is unlikely that a
human could effectively do this without automated help.

Answers to Problems and Exercises

1. c lower CASE g reverse engineering e data dictionary
b upper CASE f re-engineering a information repository
h I–CASE d balancing

2. Student answers are likely to vary, particularly because this question

requires them to forecast. Be sure to have the students explain their
forecast and recommendations and provide a rationale for each. Students
will recognize that this area is rapidly evolving, especially in the object-
oriented and visual development tools area.

One likely scenario is that, like most other software, CASE tools will
continue to get more effective, easier to use, less expensive to purchase
and maintain, and will grow in use. Some industry experts believe that
generator tools are becoming so easy to use that the cost of making
requirements mistakes is drastically reduced. These people believe that I–
CASE has a limited future since it will be so easy to change the system as
new understandings of requirements are recognized. Still other industry
experts believe that CASE is necessary for reusability and the key is to be
able to change the specification models and have a new system
automatically generated. Part of this movement is object orientation,
which promotes reusability of system components, both conceptual and
physical.
3. It appears that one could duplicate the form shown in Figure 4-7 by using
a standard graphics package. It may take some time, but the form could
probably be replicated fairly closely. There are several important
advantages to using a CASE tool for form generation. The CASE tool will
have form templates, buttons, and other pre–existing features made
explicitly for form generation. The CASE tool can help you to ensure that
you use correct, consistent data labels and other form elements. The
forms and the form generation tool can be linked to other development
tools, to other parts of the system being developed, and to the actual
data. Finally, you can actually use the forms you generate as part of the
system being developed.

4. Students should be able to come up with a significant number of data

elements for a university. A sample list includes student identification
number, student name, student local address, student local telephone
number, student permanent address, student permanent telephone
number, course number, instructor, employee identification number, and
so on. The data storage requirements for a university are tremendous. To
find out exactly how this information is organized, students might talk to
systems personnel in charge of database administration. If the university
(or other organization) does not use CASE tools, have the students think
about what data management would be like with the CASE tools.
Problems of homonyms and synonyms, redundant data and data
maintenance modules, costly efforts to change data specifications, and
much more would occur. Conversely, if the university does use CASE
tools, have the students think about what data management would be
like without the CASE tools. Essentially, coordination of the meaning and
format of data would be much easier, whether data is stored in one or
many databases.

5. Students should be able to find documentation from either a home or

university PC. Generally, students will feel that documentation is good if
it is relatively easy to use and if it helps them to find the information they
need and/or solve their problems. It may be useful to list on the board the
criteria students are using to evaluate documentation. Then have the
students talk about how CASE tools would help to improve documentation
on each of these criteria. CASE is best at producing documentation for
systems analysts, not users. Documentation is a subsystem of the overall
information system, so it, too, can be modeled by a CASE tool. Updating
of the documentation can be managed by CASE, since modules of the
documentation can be viewed as system modules.

6. This question is likely to generate some debate among students. Some

people believe that, ultimately, all software will behave as predicted by
the CASE vendors described in this question. Others believe that software
will never become this “automated.” Still others believe that software will
become very easy to use and very automated, though never to the
extent described in this question. Regardless of whether or not students
believe this goal is possible, they should see that it is a worthwhile goal
 to attempt to achieve. Part of the answer depends on what type of
system is being built. Transaction processing systems are very
predictable and repeatable, so nearly 100 percent of the code for such
systems could be generated. On the other hand, decision support
systems and many analytical or scientific applications do not involve
routine, previously used modules, and must be specified at a very
detailed level, close to code if not code itself.

7. The problems that might arise if an organization uses different CASE tools
are similar to those that might arise if an organization does not use CASE
tools at all. These problems include using different naming conventions in
different parts of systems and across systems, incompatibilities among
systems and system components, redundant data storage, and so on. It
is not always possible to exchange repository contents between CASE
tools (some tools, like R&O’s Rochade help in transferring repository
contents between CASE tools). I–CASE and shared databases basically try
to address these same problems. The only difference is that, while shared
databases are an attempt to have systems that remedy these problems,
I–CASE tries to remedy these problems as systems are being built. There
are several metadata standards for CASE repositories that some CASE
vendors have adopted, in which case exchange of data between tools is
facilitated.

8. The data dictionary screens contain much information about the entity.
However, students may ask about the users and number of instances.
Students should be encouraged to discuss the importance of keeping
such detailed information about an entity.

9. Students should readily recognize that systems development

environments are rapidly evolving to include visual and CASE-like
features. CASE products provide support for some portion of the systems
development process. CASE products may provide object-oriented and
visual programming capabilities. Object-oriented development
encapsulates the data and instructions together in an object. Visual
development tools enable the systems developer to “draw” the design
using predefined objects.

Guidelines for Using the Field Exercises

1. Answering this question may take a great amount of time, but
interviewing these people will be useful to the students. Students are
likely to find that the use of CASE, object-oriented, and visual
development tools is higher in larger organizations with larger, more
complex systems, with longer, more complex systems development
processes. Systems personnel using these systems development tools
will likely report that it makes their job easier and systems development
faster. Students should be careful not to generalize from their small
sample to all organizations. There are millions of business organizations
in this country alone, and the samples taken from even all of the students
 does not adequately represent what is happening at all organizations.
However, their interviews should provide useful information about
systems development tool usage.

2. Students should be able to find what they need from a vendor, an article
in the popular press, or from the documentation accompanying the CASE
tool used at their university. Even the less expensive, relatively simple
CASE tools now available to students for use on their PC’s have many of
the components of the CASE products discussed in Chapter 4. Students
should be encouraged to visit the web sites of several of the companies
discussed in this chapter. A quick search of the web will provide students
with information about product capabilities, product comparisons, and
product vendors.

3. This question parallels Field Exercise 1 in many ways. In fact, it would be

useful to have students answer Field Exercises 1 and 3 simultaneously
with the same set of interview participants. People are finding useful,
innovative ways to use these systems development tools throughout the
SDLC. For example, some people are using CASE form generators in
conjunction with the Joint Applications Design method to perform live,
interactive development with users. These systems personnel are likely
to cite many of the advantages and disadvantages for using the CASE
products discussed in this chapter.

4. It will be useful for students to share their data. Create a grid on the
board that lists the various CASE tools on one axis and all the features
and benefits on the other axis. Then use the students’ information to
check off boxes in the matrix. Have the students discuss whether they
believe this information to be truth, hype, or both. Students might then
take the completed matrix and have systems personnel who are familiar
with CASE tools review and comment on the matrix.

5. This is an excellent question for students that know the SDLC well. This is
basically the kind of analysis that organizations should be going through
to determine whether or not they can and should use CASE tools.
Students should be able to determine ways that CASE tools can be used
throughout the SDLC. It will be more difficult, however, to determine the
time and expense involved in those parts of the process that could be
better done using CASE tools. Encourage the students to do the best they
can to determine this information. Even their best guesses will still be
useful. Chances are that, if the projects being considered are moderately
large and complex, the case can be made for using CASE tools.

6. Vendors are typically very willing to give this information, so the students
should have success in getting the information necessary for answering
this question. Nearly all software vendors have plans for and/or are
working on future versions of their software. CASE tool vendors are no
different. It will be useful for students to compare their answers for
different CASE tool vendors. This will allow the students to learn more
about the competitive dynamics of the CASE tool market. Students
 should be encouraged to visit the web sites of various CASE tool vendors,
including Oracle, Microsoft, Borland, and Powersoft. Ask students to
compare and contrast the various products in class.

Guidelines for Using the Broadway Entertainment

Company Cases
Broadway Entertainment Company, Inc. (BEC) is a fictional company for
which brief cases appear after Chapters 4 through 19, with the exception of
Chapters 12 and 13. These BEC cases illustrate what might happen as an
idea for a new system arises and then how the idea evolves and is managed
through systems development phases. Each case addresses only some of the
issues, skills, techniques, or methodologies that apply during systems
development. The BEC cases are meant to give your students a sense of an
organizational context for systems development; the cases do not teach
techniques or provide tutorials, and they are not comprehensive reviews of all
of the principles introduced in the associated chapter. Thus, it would be very
difficult to teach from the cases. Rather, the cases supplement the chapters,
where concepts are introduced and techniques are explained. Important
points are highlighted through each case, but only selected skills, techniques,
tools, and methods are illustrated.

The BEC cases serve as a useful “change of pace” for your students for
several reasons. First, the cases do not teach, rather they illustrate. Thus,
they are easy to read and to understand. Second, the cases help your
students to understand the organizational processes in which systems
development activities occur. For students who do not have business
experience, reading about systems development from an organizational and
people perspective will give them a deeper understanding of how to apply
what they are learning in this textbook and your course. Finally, the writing
style of the cases is more casual, which makes them fun to read. There is
humor, people have personalities, and most of the cases are conversational.
The cases are a refreshing way to see some of the concepts and skills
presented in the chapter come to life. Each case is short, so reading time is
also short.

The first two BEC cases appear after Chapter 4. Neither of these cases relates
directly to Chapter 4; rather, they serve as background for the cases that
begin after Chapter 5 and that do relate to the associated chapters. The first
case, Case Introduction, provides background information on BEC and its
markets. This information, as with any case study, is essential for
understanding the context in which business decisions are made, including
decisions about new information systems. This description includes a history
of information systems and the IS organization at BEC. The case also
introduces some of the people who will appear in subsequent cases.

As a background case, you do not need to spend much time discussing this
case. In order to prepare your students to appreciate the subsequent cases
better, you can use the following questions either for class discussion or as
brief writing assignments.

1. What business is BEC in?

2. What are the forces that influence BEC, its market, and its
competition?

3. Is BEC profitable and what is its growth potential?

4. What qualities have led to BEC’s success so far?

5. Is the IS organization at BEC poised to undertake significant systems

development in the near future?

The second BEC case, The Existing Application Portfolio, follows the Case
Introduction. The purpose of this case is to layout BEC’s current investment in
information systems. Since decisions about requests for and the development
of new systems must relate to the systems in place, this case also provides
necessary information to understand issues raised in subsequent cases. The
case gives an overview of the systems that support both corporate and in–
store functions and processes. The case also summarizes the hardware and
network architecture in which application systems operate, and mentions
some of the key programming environments BEC uses for systems. No
attempt has been made to be comprehensive or detailed—this is beyond our
needs and would take too much space. Rather, this case should give your
students a sense of the comprehensiveness of systems and will allow them to
anticipate issues of compatibility and interaction with existing systems as the
new system described in subsequent cases evolves. The case also expands
on the discussion from the Case Introduction concerning the status of
systems and the information systems function within BEC.

You may want to spend approximately 15 minutes discussing this case in

class. Following are some discussion questions which you can use in class or
as brief writing assignments to help your students review the content of the
second BEC case.

1. What type of computing environment is present at BEC?

Centralized, decentralized, distributed, client/server?

2. What areas of BEC store operations are supported by application

systems? What areas are not supported?

3. What areas of BEC corporate activities are supported by

application systems? What areas are not supported?

4. What has BEC done to facilitate the global utilization of their

application systems?
 5. What particular business rules apply to BEC that might not apply
to other competing organizations? How do these rules affect systems at
BEC?

6. Do corporate and in–store systems seem to be tightly or loosely

coupled at BEC?

7. What challenges and limitations will affect what and how

systems are developed in the future at BEC?

5
Identifying and Selecting Systems
Development Projects

Chapter Overview
The purpose of this chapter is to introduce students to the first phase of the
systems development life cycle—identifying and selecting systems
development projects. The chapter takes the position that organizations can
benefit from following a formal process for identifying and selecting projects.
To do this, the chapter first overviews the corporate strategic planning
process and then links this process to information systems planning. Both are
presented as a three-step process. For information systems planning, the first
step is described as a process in which a senior manager, a business group,
an IS manager, or a steering committee identify all possible systems
development projects that an organization unit could undertake. Next,
projects are classified and ranked according to some criteria that are
important to the organization. Finally, those projects deemed most likely to
yield significant organizational benefits, given available resources, are
selected for subsequent development activities.

Instructional Objectives
Specific learning objectives are included at the beginning of the chapter.
From an instructor’s point of view, the objectives of this chapter are to:

1. Illustrate the project identification and selection process.

2. Provide a comprehensive overview of the corporate strategic planning

and information systems planning process.
3. Describe the relationship between corporate strategic planning and
information systems planning.

4. Illustrate how information systems planning can be used to assist in

identifying and selecting systems development projects.

5. Explain how information systems planning matrices can be used to

determine affinity between information systems and IS projects and the
impact of IS projects on business objectives.

Classroom Ideas
1. This chapter introduces many different concepts and terms that are
central to understanding the role of corporate strategic planning and
information systems planning in the identification and selection of
information systems development projects. Review Questions 1 and 2
may be important to discuss in class to be sure that your students are
understanding the material. Be sure that you ask your students to review
the Key Terms listed at the end of the chapter.

2. During a lecture, you can use the tables and figures in the chapter to
assist in pointing out to the students the major concepts brought out in
the chapter. Linking the planning processes to a specific example (e.g.,
the Pine Valley Furniture example in the chapter) is often a very good way
for students to understand abstract planning concepts.

3. An alternative to lecturing on the contents of the chapter is to lecture

from the Review Questions, Problems and Exercises, and Field Exercises
from the end of the chapter. Selected questions can be posed to students
to help focus a discussion on specific concepts. For example, Problems
and Exercises 2 and 3 allow students to actively consider the process of
linking a mission to objectives. Additionally, Problems and Exercises 9
and 10 help students gain valuable skills in dealing with planning
matrices.

4. Another very effective in–class exercise is to ask students who have been
on systems development teams to compare their experiences to the
concepts presented in Chapter 5. This discussion can be a good way to
elaborate on alternative ways for identifying and selecting information
systems projects. Some organizations are very informal, compared to
what is described in the book. Usually you can start a good debate on
how formal project identification and selection should be, and who should
control this process. Stress the tradeoffs of formal vs. informal processes:
consistency, awareness, budget and investment controls, long–term
focus, etc. vs. rapid action, commitment, current business needs, etc.

5. If you have access to CASE software, it is often engaging for students to

see demonstrations of how CASE can be used to manipulate planning
matrices (e.g., affinity clustering). For example, you can use Problems
 and Exercises 9 and 10 to illustrate the power of CASE when
manipulating planning matrices.

6. If you have access to a practicing systems analyst, an insightful activity is

to invite him/her into your class to discuss how he/she identifies and
selects projects in his/her organization. You may want to invite this
person in after Chapter 6 since discussions of organizational practices on
project identification, selection, planning, and initiation often blend
together. Consistency with organizational procedures, history of
performance of the IS unit, management style, competitiveness of
industry, and many other factors can affect how an organization chooses
to undertake these processes. Have your guest explain why the process
is more bottom–up or top–down. Be sure that this person addresses the
interaction between business plans, IS plans, and project selection.

7. A role play is also an effective way for students to gain an understanding

of the project identification and selection process. In such an exercise,
have some students play different roles for selecting new system or
hardware projects within your university, school, or department. Have
some students play the role of the steering committee and have others
suggest projects. Jointly agree to the mission, objectives, and strategy.
Now, let the steering committee try to prioritize a list of projects. Keep
asking them how each project serves the mission or which objectives
does the project help satisfy.

8. An excellent video segment, “Making the Business Case,” is available as

a supplement to your lecture on Chapter 5. This video segment, which
serves as a good transition from Chapter 5 to Chapter 6, is approximately
15 minutes long. Notes on using this video segment are included in a
separate section of this Instructor’s Manual. See the Preface to this
Instructor’s Manual for information on how to obtain this and the other
video segments produced for use with the second edition of Modern
Systems Analysis and Design.
Answers to Review Questions
1. Bottom-up planning is a generic information systems planning
methodology that identifies and defines IS development projects based
on solving operational business problems or taking advantage of some
business opportunities. A competitive strategy is the method by which
an organization attempts to achieve its mission and objectives. Corporate
strategic planning is an ongoing process that defines the mission,
objectives, and strategies of an organization. Information systems
planning is an orderly means of assessing the information needs of an
organization and defining the systems, databases, and technologies that
will best satisfy those needs. The mission statement is a statement that
makes it clear what business a company is in. Objective statements are
a series of statements that express an organization’s qualitative and
quantitative goals for reaching a desired future position. Top-down
planning is a generic information systems planning methodology that
attempts to gain a broad understanding of the information system needs
of the entire organization. Affinity clustering is the process of arranging
planning matrix information so that clusters of information with some
predetermined level or type of affinity are placed next to each other on a
matrix report. Value chain analysis refers to the process of analyzing an
organization’s activities for making products and/or services to determine
where value is added and costs are incurred.

2. A mission is a statement that makes it clear what business a company is

in. Objective statements express an organization’s qualitative and
quantitative goals for reaching a desired future position. A competitive
strategy is the method by which an organization attempts to achieve its
mission and objectives.

Corporate strategic planning is an ongoing process that defines the

mission, objectives, and strategies of an organization. Information
systems planning is an orderly means of assessing the information needs
of an organization and defining the systems, databases, and technologies
that will best satisfy those needs.

Top–down planning is a generic information systems planning

methodology that attempts to gain a broad understanding of the
information system needs of the entire organization. Bottom–up planning
is a generic information systems planning methodology that identifies
and defines IS development projects based on solving operational
business problems or taking advantage of some business opportunities.

Low–cost producer is a strategy that reflects competing in an industry on

the basis of product or service cost to the customer. Product
differentiation is a strategy that reflects capitalizing on a key product
criterion requested by the market. Product focus or niche is a strategy
that is similar to both the low–cost and differentiation strategies but with
a much narrower market focus.
 A data entity is a single piece of information. An information system
creates, retrieves, updates, or deletes one or more data entities.

3. Project identification and selection consists of identifying potential

development projects, classifying and ranking projects, and selecting
projects for development. These activities are overviewed below.

Identifying Potential Development Projects. Organizations vary as

to how they identify projects, and all methods of identification have been
found to have strengths and weaknesses. Research has found, for
example, that projects identified by top–management more often have a
strategic organizational focus. Some projects are identified by top–down
initiatives while others are identified by bottom–up initiatives. Since
limited resources preclude the development of all proposed systems,
most organizations have some process of classifying and ranking the
merit of each project. Those projects deemed to be inconsistent with
overall organizational objectives, redundant in functionality to some
existing system, or unnecessary will be removed from consideration.

Classifying and Ranking Projects. The second major activity in the

project identification and selection process focuses on assessing the
relative merit of potential projects. As before, different organizations may
follow different processes for this activity.

Selecting Projects for Development. Project selection is a process of

considering both short– and long–term projects and selecting those most
likely to achieve business objectives. Additionally, as business conditions
change over time, the relative importance of any single project may
substantially change.

4. Project evaluation criteria are listed and described in Table 5–2.

5. Value chain analysis is the process of analyzing an organization’s

activities for making products and/or services to determine where value
is added and costs are incurred. After gaining an understanding of each
activity, function, and process where value is or should be, the
organization can determine associated costs. The organization can then
use this information to compare its value chain with other organizations.
This technique is one method the company can use to prioritize
information systems development projects.

6. The chapter provided several factors as evidence for the need for
improved information systems planning, including: (a) the cost of
information systems has risen steadily and approaches 40% of total
expenses in some organizations; (b) many systems cannot handle
applications that cross organizational boundaries; (c) many systems often
do not address the critical problems of the business as a whole nor
support strategic applications; (d) data redundancy is often out of control,
and users may have little confidence in the quality of data; (e) systems
maintenance costs are out of control as old, poorly planned systems must
 constantly be revised; (f) application backlogs often extend three years or
more, and frustrated end users are forced to create (or purchase) their
own systems, often creating redundant databases and incompatible
systems in the process.

7. Corporate strategic planning can be thought of as a three–step process.

The first step in the corporate strategic planning process is the
development of the mission statement. The mission statement of a
company typically states in very simple terms what business the
company is in. After defining its mission, an organization can then define
its objectives. The objective statements refer to “broad and timeless”
goals for the organization. These goals can be expressed as a series of
statements that are either qualitative or quantitative, but typically do not
contain details that are likely to change substantially over time. Once a
company has defined its mission and objectives, a competitive strategy
can be formulated. A competitive strategy is the method by which an
organization attempts to achieve its mission and objectives.

8. The generic competitive strategies—low cost producer, product

differentiation, and product focus or niche—are summarized in Table 5–3.

9. Information systems planning (ISP) is an orderly means of assessing the

information needs of an organization and defining the information
systems, databases, and technologies that will best satisfy those needs.
ISP is a three step process in which the first step is to assess current IS–
related assets––human resources, data, processes, and technologies.
Next, target blueprints of these resources are developed. These
blueprints reflect the desired future state of resources needed by the
organization to reach its objectives as defined during strategic planning.
Finally, a series of scheduled projects are defined to help move the
organization from its current to future desired state.

10. Several positive outcomes from the top–down planning approach—

broader perspective, improved integration, improved management
support, and better understanding—are listed and described in Table 5–5.

11. A Location–to–Function matrix identifies which business functions are

being performed at various organizational locations. A Location–to–Unit
matrix identifies which organizational units are located or interact with a
specific business location. A Unit–to–Function matrix identifies the
relationships between organizational entities and each business function.
A Function–to–Objective matrix identifies which functions are essential or
desirable in achieving each organizational objective. A Function–to–
Process matrix identifies which processes are used to support each
business function. A Function–to–Data Entity matrix identifies which
business functions utilize which data entities. A Process–to–Data Entity
matrix identifies which data are captured, used, updated, or deleted
within each process. A Process–to–Information System matrix identifies
which information systems are used to support each process. A Data
Entity–to–Information System matrix identifies which data are created,
 updated, accessed, or deleted in each system. An Information System–
to–Objective matrix identifies which information systems support each
business objective as identified during organizational planning.

Answers to Problems and Exercises

1. d corporate strategic planning b competitive
strategy g top-down planning
c mission statement e information systems planning h bottom-up
planning
a objective statement i value chain analysis f affinity clustering

2. Below are some sample mission statements.

Courtyard by Marriott
To provide economy and quality minded frequent business travelers with a
premier, moderate-priced lodging facility which is consistently perceived
as clean, comfortable, well maintained, and attractive, staffed by friendly,
attentive and efficient people.

McDonald’s
To offer the fast food customer food prepared in the same high–quality
manner world-wide, tasty and reasonably priced, delivered in a
consistent, low-key decor and friendly atmosphere.

3. There are typically two types of objectives used: financial and strategic.
Financial objectives target outcomes that relate to improving the
company’s financial performance. Two examples are: (1) increasing
earnings growth by 10 to 15 percent per year, and (2) boosting return on
equity investment from 15 to 20 percent. Strategic objectives target
outcomes that will result in greater competitiveness and a stronger long–
term market position. Three examples are: (1) overtaking rivals on
quality or customer service, (2) attaining lower overall costs than rivals,
and (3) achieving technological superiority over rivals. Companies
generally either try to achieve a low–cost leadership strategy or a
differentiation strategy where they try to differentiate themselves from
competitors based on features, service, or some other factor(s). Within
these two general strategies companies sometimes also provide either a
broad or focused set of products and/or services. Of course, some
companies try to achieve several of these goals. For example, some
implement a best–cost provider strategy, where they give customers
more value for their money by combining an emphasis on low cost with
an emphasis on upscale differentiation.

4. Reasons why people circumvent the formal IS planning process include:

planning is difficult and costly (time, money, people, other resources),
people want short-term results, people disagree with the IS
vision/architecture, people don’t want to change current system/plan, and
 people fear change generally. On the one hand, these reasons are not
justifiable because people may not be thinking and acting in the
organization’s best interests. However, strong resistance to a new system
may signal real problems with the system. In any event, such resistance
must be managed in order for the new system, in whatever form, to be a
success.

The implications for poor or no strategic IS planning are many. Users may
not be able to access data that they need. The data that the user works
with may be inconsistent or incompatible with other data. Users may be
receiving mixed signals about strategic applications and how the
organization desires to apply information technology. There may be little
or no guidance regarding the procurement of hardware and/or software.
Finally, this may lead to what F. Sweet has called the “Winchester
Syndrome” (April, 1984. Datamation). He reasoned that without proper
planning, information systems will suffer the same fate as the famous
Winchester Mystery House, with its false chimneys, doors that open onto
blank walls, stairways that lead to ceilings, and so on. The Winchester
Mystery House is a monument to “on the fly” design.

5. This would present a difficult situation for the IS planners. They would be
attempting to plan and garner the support and participation of others in
an atmosphere where people do not plan. In addition, because IS plans
should be driven by the organization’s mission, the IS planners would, in
essence, be planning in a vacuum. The IS planners would have to work
hard to determine what the organization’s mission was (i.e., they would
have to do corporate planning while doing IS planning). It is likely that
there will be many different, possibly even conflicting notions of what the
mission is and ought to be.

6. At this early stage the most important criteria is the extent to which the
project under consideration supports the organization’s mission. At this
point, economic concerns are secondary. Economic concerns will become
more important during the next project phase— project planning and
initiation—after a preliminary analysis of the project request provides the
evidence for a business case.

7. In an organization that truly does an “excellent” job of IS planning, the

goal of the planners is to develop systems that support the organization’s
mission. If a project is identified from a bottom–up process that supports
the organization’s mission, even if this new system was not originally
“planned” for, the planners are likely to incorporate this new system into
their IS planning. In organizations where planning is down well, there are
mechanisms that build flexibility into the planning process. Planning
shouldn’t be too rigid and inflexible. Also, having a plan can stimulate
people to think of specific projects that help to fulfill the plan (see the
Broadway Entertainment case that appears after Chapter 5 for an
example of this).
8. Figure 5–14 shows a good example of this. Fabrication, assembly, and
finishing each uses the data entities work center, equipment, employees,
and work order. Such clustering suggests that these functional areas are
likely to work closely together in time and/or on related or sequential
tasks. In any event, they definitely use similar information in their work
processes. The analyst might develop the sub-systems for these
functions simultaneously. Alternatively, one subsystem might be built
which serves each of the functional areas.

9. The locations include northern California, upper–Midwest, sales rep city

#1, sales rep city #2, sales rep city #3, sales rep city #4, sales rep city
#5, and sales rep city #6. For this organization, the units include
research and development, manufacturing, accounting, finance, human
resource management, sales, and information systems. One central
function is circuit manufacturing, which includes the processes of circuit
printing, drying, and testing. Another important function is circuit design,
which includes the processes of drawing the artwork for a circuit and
developing a prototype. This organization uses many of the data entities
that are commonly used by most manufacturers, such as customer,
product, vendor, raw material, order, work center, equipment, employee,
invoice, and work order. The information systems used include payroll
processing, accounts payable, accounts receivable, inventory
management, computer–aided design, and computer–integrated
manufacturing.

10. Two likely matrices are provided below using the information above. The
first example given is for a function–to–data–entity matrix. The second
example is for an information system–to–data entity matrix. This
organization also uses office automation applications such as electronic
mail, word processing, spreadsheets, graphics packages, and Internet
interface software, such as Netscape.

In the following matrices, data entities are abbreviated as: CU=Customer,

PR=Product, VEN=Vendor, RM=Raw Material, OR=Order, WC=Work
Center, EQ=Equipment, EMP=Employee, INV=Invoice, and WO=Work
Order.

Function–to–Data Entity Matrix

Data Entities C P V R O WE E I W
U R E MR C Q MN O
N P V

Functions
Circuit Manufacturing X X X X X X X X

Circuit Design X X X X X X X X

Order Fulfillment X X X X X
Data Entities C P V R O WE E I W
U R E MR C Q MN O
N P V

Functions
Distribution X X X X

Accounts Receivables X X X

Accounts Payable X X X
 Information System–to–Data Entity Matrix
Data Entities C P V R O WE E I W
U R E MR C Q MN O
N P V

Information System
Payroll Processing X X

Accounts Payable X X X

Accounts X X X X
Receivable

Inventory X X X X X
Management

CAD X X X X

Cam X X X X X X X X X

11. The most important change would be to the matrices involving locations.
These matrices would need to be updated to reflect the eight new
locations.

Guidelines for Using the Field Exercises

1. Students should be able to track down an actual organizational mission
statement from an annual report either from their library, the Internet, or
directly from the organization. If the mission statements are crafted well,
the students should be able to tell what business the organization is in
and what that organization values. For example, from the mission
statement of Courtyard by Marriott, one can tell that they are in the
lodging industry for business travelers and that they value having a high
quality, clean facility, providing high quality service, and having
competent, friendly staff members. If the organization is planning for and
implementing information systems strategically, then these systems
should support the organization’s mission. For example, at Courtyard,
automated registration systems help them to provide better service.

2. This question may take relatively more time and effort to answer, but the
usefulness of answering this question is commensurably higher. If the
organization chosen is at least of moderate size, then there is probably
some degree of formal IS planning. Similarly, such an organization is
likely to engage in some degree of formal strategic planning. If the
organization is doing things right, there should be a clear fit between the
IS plan and the organization’s strategic plan, with the organization–wide
plan driving the IS plan. If there is not a good fit, have the students
 express ideas on any problems that may arise and their forecasts for the
future of this company.

3. With a small number of short interviews of IS and non–IS personnel within

the organization chosen, the student can quickly generate a fairly
accurate portrayal of the IS plan. In fact, the student is likely to provide
accurate, interesting, and useful information to the IS manager when
presenting the outline to him/her.

4. This is a useful exercise and should be fairly easy to complete using

nearly any organization (e.g., a university). Using the example of a
university, some sample locations might include the main campus,
additional campuses, remote “distance learning” locations, an off-campus
business incubator, and, if the university is part of a state system, a
“chancellor’s” office. Some of the units would include academic colleges
(e.g., the School or College of Business), academic administration (e.g.,
Registrar’s Office), and business units (e.g., Plant and Equipment). In
addition, a university will have a host of functions, processes, and data
entities. Part of the university would have functions, processes, and data
entities just as a business organization would have. The academic parts
of the university would have additional functions, processes, and data
entities not found in a business setting. For example, one function is
having students register for classes. One process for this function would
be students requesting classes. Some data entities would be student,
course, instructor, and so on. Have students compare their planning
matrices, particularly if they have chosen similar organizations.

5. This information can be found on the Web. The home pages for each of
these companies can be found at:
1) http://www.microsoft.com/
2) http://www.ibm.com/
3) http://www.att.com/

Students should write their own versions of the mission statements

before reading the actual mission statements. Students are likely to
already have learned a lot about these organizations and their missions
simply by listening to, watching, and reading their advertisements.
Advertisements often give us a very accurate, current summary of the
organization’s mission. Thus, students are likely to write fairly accurate
mission statements for these three large, prominent organizations. Let
the students share their ideas on what information systems would be
useful to help these organizations achieve their respective missions. Are
there any differences in the types of systems that would be useful to
these organizations?

6. Students are likely to find a variety of ways that information systems

projects are identified. Methods for this range from the informal to the
formal, and the origin of requests comes from a variety of places within
different organizations. How information systems projects are identified
 tells us a lot about how the broader organization is managed and about
the value that is placed on information systems.

Guidelines for Using the Broadway Entertainment

Company Case
The BEC case associated with Chapter 5, Identifying and Selecting the
Customer Activity Tracking System, introduces the idea for a new
information system, the development of which will be the focus of all of the
BEC cases through Chapter 19. This case also introduces several of the key
players in the case: the client, IS management, the IS project approval board,
and the lead analyst. The case shows how an idea for a new system can arise
bottom–up, but stimulated from a top–down understanding of business
direction and needs. It will be interesting for your students to see how the
initial idea for the system evolves through the subsequent cases.

The case illustrates how a supportive IS organization assists a user who has
an idea for an information system that could lead to competitive advantage.
This BEC case addresses the stimulus for the idea, how IS handled an inquiry
about such a system, how a lead analyst might work with a user to formulate
the idea for a system into a workable form, and how to align a system
request with the priorities of a business.

This case can be used simply as a reading assignment to supplement Chapter

5, or you can use it more actively for class discussion or a written
assignment. Some possible discussion questions are the following:

1. Does the client, Nancy Chen, have a good enough understanding of her
business needs to be requesting an information system at this point?

2. Should Nancy have gone directly to Karen Gardner for assistance before
talking with members of her own unit first to see what they think of the
idea? How would you have dealt with this idea if you had been Nancy
Chen?

3. How do you assess Karen Gardner’s way of handling Nancy Chen’s

inquiry? Is there anything else Karen should have done before or as part
of assigning Jordan Pippen to work with Nancy?

4. Would you have provided any additional information in the request for the
CATS project to the SPB? Is the content of the CATS request consistent
with the kind of information outlined in Chapter 5 for inclusion in an initial
system project request?

5. What would your reaction have been to the CATS project request if you
had been a member of the SPB? What factors would you consider in
deciding whether to approve this request?
 6. Assuming that the Customer Activity Tracking System has potential
competitive advantage, how should BEC evaluate this project request?
Should project selection criteria be different for different types of
information systems? In your opinion, does CATS have potential
competitive advantage?

7. What type of systems development methodology might be appropriate

for CATS? In particular, what would be your next steps in this project if
you were Jordan Pippen?

6
Initiating and Planning Systems Development
Projects

Chapter Overview
The purpose of this chapter is to introduce students to the second phase of
the SDLC, initiating and planning information systems projects. Project
initiation focuses on activities designed to assist in organizing a team to
conduct project planning. During project initiation, one or more analysts are
assigned to work with a customer to establish work standards and
communication procedures. Project planning is the process of defining clear,
discrete activities and the work needed to complete each activity. The
objective of the project planning process is the development of a Baseline
Project Plan (BPP) and the Statement of Work (SOW). The BPP becomes the
foundation for the remainder of the development project. The SOW produced
by the team clearly outlines the objectives and constraints of the project. As
with the project initiation process, the size, scope, and complexity of a project
will dictate the comprehensiveness of the project planning process and
resulting documents. An important aspect of the project initiation and
planning process centers on the assessment of a project’s feasibility and risk.
The chapter describes several types of feasibility including, economic,
technical, operational, schedule, legal and contractual, and political. Students
may find the techniques used to assess economic feasibility are similar to
techniques they learned in a prior course in managerial accounting or
finance. Other forms of feasibility assessment are likely to be new. The extent
to which you focus on each aspect of feasibility will be influenced by your
overall curriculum.

Instructional Objectives
Specific student learning objectives are included at the beginning of the
chapter. From an instructor’s point of view, the objectives of this chapter are
to:

1. Illustrate the steps involved in the project initiation and planning process.

2. Explain the need for and to describe the contents of a Statement of Work
and Baseline Project Plan.

3. Provide a comprehensive overview of the various methods for assessing

project feasibility.

4. Explain the differences between tangible and intangible benefits and

costs and between one–time and recurring benefits and costs.

5. Illustrate how to perform cost–benefit analysis and describe what is

meant by the time value of money, present value, discount rate, net
present value, return on investment, and break–even analysis.

6. Describe how to evaluate the technical risks associated with a systems

development project.

7. Explain the activities and participant roles within a structured

walkthrough.

8. Prepare your students to develop a plan for conducting a term project

involving several phases of systems development using the SDLC or
other methodologies.

Classroom Ideas
1. This chapter introduces many different concepts and terms that are
central to understanding the project initiation and planning process.
Review Questions 1 and 2 at the end of the chapter may be important to
discuss in class to be sure that your students are understanding the
material. Be sure that you ask your students to review the Key Terms
listed at the end of the chapter.
2. During a lecture, you might want to use the tables and figures in the
chapter to assist in pointing out to the students the major concepts from
the chapter. Linking the processes described in the chapter to a specific
example (e.g., the Pine Valley Furniture example in the chapter) is often a
very good way for students to understand more abstract concepts. You
may want to blend tables and figures from Chapters 6 and 7 given the
interrelatedness of these chapters. As part of a lecture, engage students
to suggest various costs and benefits that might arise with specific
systems. One alternative is to briefly describe a systems development
project with which you have been involved and ask the students to list
the possible costs, benefits, and risks that would be part of a feasibility
assessment of that system.

3. An alternative to lecturing on the contents of the chapter is to lecture

from the Review Questions, Problems and Exercises, and Field Exercises
from the end of the chapter. Selected questions can be posed to students
to help focus a discussion on specific concepts. Problems and Exercises 3,
4, 5, 6, and 7 can be done in class.

4. Another very effective in–class exercise is to ask students who have been
on systems development teams to compare their experiences to the
concepts presented in Chapter 6. This discussion is a good method for
elaborating on alternative ways for identifying and selecting information
systems projects. This comparison can be done through discussions of
Field Exercises, 3, 4, 5, or 6.

5. If you have access to practicing systems analysts, an insightful activity is

to invite them into your class to discuss how they initiate and plan
projects in their organizations. Ask them to provide such documentation
as: the Table of Contents for the equivalent of the Baseline Project Plan
and Statement of Work, project schedules and work descriptions,
feasibility tables or spreadsheets, and team organizations. Some
organizations have formal documents called business cases that must
accompany any project request; if possible, have your guests outline
what their organizations consider to be the ideal format for a business
case.

6. An excellent video segment, “Making the Business Case,” is available for

use with this chapter. This 12-minute segment can be used to introduce
this chapter, as a transition from Chapter 5, or as a way to close your
class on this chapter (given some discussion time). Notes on using this
video segment are included in a separate section of this Instructor’s
Manual. See the Preface to the Instructor’s Manual for information on how
to obtain the video segments produced for use with the second edition of
Modern Systems Analysis and Design.

7. An interesting discussion to have in class concerns the viability of

economic feasibility assessments. How accurate and helpful are classical
cost–benefit analyses of information systems? What measures of
 economic worth should be applied to systems projects? Should
information systems be treated as investments, necessary costs,
enablers of change, or otherwise? The books by Cash et al. and Parker
and Benson, listed in the References section at the end of the chapter,
give some good ideas on alternative ways of viewing the economics of
information systems. You may wish to find some more recent publications
in both trade and academic publications, since this is a recurring topic in
our literature. This topic may have been discussed in the introductory MIS
class the students took, so link this topic to what they studied in prior
courses. Remind your students that even when classical economic
feasibility is assessed at this stage of a project, often only categories of
costs and benefits, not actual dollar values, can be fixed at this point. The
incremental commitment and frequent review nature of systems projects
means that the economic feasibility (as well as other feasibilities) can be
reassessed at each project review point, with a decision to continue,
redirect, or terminate the project as an outcome.

Answers to Review Questions

1. A Baseline Project Plan is a detailed planning document that contains the
best estimate of a project’s scope, benefits, costs, risks, and resource
requirements. The discount rate is the rate of return used to compute the
present value of future cash flows. One-time costs are costs associated
with project or system startup and development. A recurring cost is a
cost resulting from the ongoing evolution and use of a system. A
walkthrough is a peer group review of any product created during the
system development process. A statement of work is a document
prepared for the customer during project initiation and planning that
describes what the project will deliver and outlines generally at a high
level all work required to complete the project.

2. Break–even analysis finds the amount of time required for the cumulative
cash flow from a project to equal its initial and ongoing investment. The
present value represents the current value of a future cash flow. The net
present value uses a discount rate, determined from the company’s cost
of capital, to establish the present value of a project. The return on
investment is the ratio of the net cash receipts of the project divided by
the cash outlays of the project.

Economic feasibility is the process of identifying the financial benefits and

costs associated with a development project. Legal and contractual
feasibility is the process of assessing potential legal and contractual
ramifications due to the construction of a system. Operational feasibility
is the process of assessing the degree to which a proposed system solves
business problems or takes advantage of business opportunities. Political
feasibility is the process of evaluating how key stakeholders within the
organization view the proposed system. Schedule feasibility is the
process of assessing the degree to which the potential time frame and
 completion dates for all major activities within a project meet
organizational deadlines and constraints for affecting change.

Intangible benefits are derived from the creation of an information

system that cannot be easily measured in dollars or with certainty.
Tangible benefits are derived from the creation of an information system
that can be measured in dollars and with certainty.

Intangible costs are costs associated with an information system that

cannot be easily measured in terms of dollars or with certainty. Tangible
costs are those costs associated with an information system that can be
measured in dollars and with certainty.

3. Project initiation focuses on activities designed to assist in organizing a

team to conduct project planning. The types of activities performed
during project initiation are listed in Table 6–1. Project planning is the
process of defining clear, discrete activities and the work needed to
complete each activity within a single project. The objective of the project
planning process is the development of a Baseline Project Plan (BPP) and
a Statement of Work (SOW). The range of activities performed during
project planning is shown in Table 6–2.

4. The Baseline Project Plan (BPP) contains all information collected and
analyzed during project initiation and planning. The plan reflects the best
estimate of the project’s scope, benefits, costs, risks, and resource
requirements given the current understanding of the project. The BPP
specifies detailed project activities for the next life cycle phase, analysis,
and less detail for subsequent project phases (since these depend on the
results of the analysis phase). The content and format of a BPP depends
on the size, complexity, and standards of an organization.

5. Three methods for performing economic cost–benefit analysis (net

present value, return on investment, and break–even analysis) are listed
and described in Table 6-6.

6. The types of project feasibility factors are economic, technical,

operational, schedule, legal and contractual, and political. Economic
feasibility is the process of identifying the financial benefits and costs
associated with a development project. Technical feasibility is the process
of assessing the development organization’s ability to construct a
proposed system. Operational feasibility is the process of assessing the
degree to which a proposed system solves business problems or takes
advantage of business opportunities. Schedule feasibility is the process of
assessing the degree to which the potential time frame and completion
dates for all major activities within a project meet organizational
deadlines and constraints for affecting change. Legal and contractual
feasibility is the process of assessing potential legal and contractual
ramifications due to the construction of a system. Political feasibility is
the process of evaluating how key stakeholders within the organization
view the proposed system. No factor is “most” important; one factor may
 be most important in some situations, while another may be “most”
important in others.

7. The potential consequences of not assessing and managing risks can

include failure to attain expected benefits from the project, inaccurate
project cost estimates, inaccurate project duration estimates, failure to
achieve adequate system performance levels, and failure to adequately
integrate the new system with existing hardware, software, or
organizational procedures.

8. Numerous factors can be used to assess a project’s riskiness, including

project size, project structure, familiarity of the development group with
similar systems and technology, and the familiarity of the user group with
the systems development process. Table 6-8 lists and describes these risk
factors in more detail.

9. There are two primary categories of benefits from an IS project: tangible

benefits and intangible benefits. Tangible benefits are those derived from
the creation of an information system that can be measured in dollars
and with certainty. Intangible benefits are those derived from the creation
of an information system that cannot be easily measured in dollars or
with certainty.

10. Intangible benefits are derived from the creation of an information

system and cannot be easily measured in dollars or with certainty.
Potential intangible benefits were listed in Table 6-3.

11. The time value of money (TVM) refers to the concept of comparing
present cash outlays to future expected returns. A dollar today is worth
more than a dollar one year from today because money can be invested.
The rate at which money can be borrowed or invested is called the cost
of capital and is called the discount rate for TVM calculations.

12. A structured walkthrough occurs when a peer group systematically

reviews a product created during the systems development process. The
objective of this review is to assure that the product conforms to
organizational standards and that all relevant parties understand and
agree with the information contained in the product (e.g., a Baseline
Project Plan). Most walkthroughs are not rigidly formal or exceeding long
in duration. It is important, however, that a specific agenda be
established for the walkthrough so that all attendees understand what is
to be covered and the expected completion time.

At walkthrough meetings, there is a need to have individuals play specific

roles. A coordinator plans the meeting and facilitates a smooth meeting
process. This person may be the project leader or a lead analyst
responsible for the current life cycle step. The presenter describes the
work product to the group. The presenter is usually an analyst who has
done all or some of the work being presented. A user (or group) assures
that the work product meets the needs of the project’s customers. This
 user would usually be someone not on the project team. A secretary
takes notes and records decisions or recommendations made by the
group. This may be a clerk assigned to the project team, or it may be one
of the analysts on the team. The standards bearer role is to assure that
the work product adheres to organizational technical standards. Many
larger organizations have staff groups within the unit responsible for
establishing standard procedures, methods, and documentation formats.
These standards bearers validate the work so that it can be used by
others in the development organization. A maintenance oracle reviews
the work product in terms of future maintenance activities. The goal is to
make the system and its documentation easy to maintain.

Answers to Problems and Exercises

1. h Baseline Project Plan c one-time cost b schedule feasibility

e economic feasibility g recurring cost i legal and contractual

feasibility
a tangible benefits d technical feasibility k political feasibility

j intangible benefits f operational feasibility

2. The students should conclude that this is a relatively small project and
should not take very long to complete. If their familiarity with PCs is
moderate to high, or if they have the help of someone who is familiar
with buying and installing PCs, then the risk for this project should be
relatively low. One risk can arise when leading–, or “bleeding–” edge
technology is selected. For example, as this book was finalized, Windows
98 was about to be introduced. You might want to have students
comment on how reliable Windows 98 is and the risk accepted by the
early adopters of this critical software.

3. Use of a PC at work can provide a number of tangible benefits. For

example, use of a PC at work can help reduce labor costs. For example,
documents can be prepared, edited, and copied faster with a PC and
word processing software than without this equipment. The use of a word
processor and a spreadsheet can help reduce errors in spelling and in
calculation. If the right software is used, spreadsheet and graphics can be
embedded within word processing documents, allowing greater flexibility
in creating and integrating documents. File and network management
software can allow greater control over work quality and workflow. Given
these sample tangible benefits, the use of a PC seems to be beneficial. In
addition, several of the intangible benefits listed in Table 6-3 apply to the
use of a PC at work. For example, spreadsheet analysis can help shorten
and strengthen the decision-making process. Use of project management
software can help improve resource control and project outcome quality.

4. There would be several one–time costs that students should easily

choose from Table 6-4. For example, the purchase of the equipment (PC’s,
 network interface cards, PC software, LAN software, cabling) and furniture
(workstation tables and chairs) would present substantial one–time costs.
There might also have to be structural modifications to the facilities
where the network will reside, which will also present one-time costs.
Recurring costs will include the costs of maintaining and replacing
equipment and software and for the personnel required to fulfill these
tasks, including managing network accounts and shared disk space and
backing up disks.

5. The following spreadsheet summarizes the economic analysis requested

in this question.
Problem and Exercise #5
0.12
Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Totals
Net Economic
Benefit $0 $85,000 $85,000 $85,000 $85,000 $85,000
Discount Rate (.12) 1.0000 0.892857 0.797194 0.711780 0.635518 0.567427
PV of Benefits $0 $75,893 $67,761 $60,501 $54,019 $48,231

NPV of all Benefits $0 $75,893 $143,654 $204,156 $258,175 $306,406 $306,406

One-Time Costs ($75,000)

Recurring Costs $0 ($35,000) ($35,000) ($35,000) ($35,000) ($35,000)

Discount Rate (.12) 1.0000 0.8929 0.7972 0.7118 0.6355 0.5674
PV of Recurring Costs $0 (31,252) ($27,902) ($24,912) ($22,243) ($19,860)

NPV of all Costs ($75,000) ($106,252.00) ($134,154) ($159,066) ($181,309) ($201,169) ($201,169)

Overall NPV $105,237

Overall ROI 0.52

Break-even Analysis
Yearly NPV
Cash Flow ($75,000) $44,641 $39,860 $35,589 $31,776 $28,371
Overall NPV
Cash Flow ($75,000) ($30,359) $9,501 $45,090 $76,865 $105,237

Project Break-even occurs between years 1 and 2

Use first year of positive cash flow to calculate break-even fraction 0.762
Actual Break-even occurs at 1.8 years

6. Students should estimate, as best they can, the dollar figures for each of
the costs they described in their answer for question 4. In addition, they
should quantify, as best they can, the benefits from such a system. They
should then present an analysis with each of the items provided in the
spreadsheet for the previous question. For the answer provided above for
question 4, let us assume that the one-time costs of implementing this
LAN are $50,000.00 and the recurring costs are $20,000.00 per year.
Assume that the benefits are $65,000.00 per year. See the following
spreadsheet analysis for an economic summary of this situation.
 Problem and Exercise #6
Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 TOTALS
Net economic
$ 0 $ 65,000 $ 65,000 $ 65,000 $ 65,000 $ 65,000
benefit
Discount rate
1.0000 0.8929 0.7972 0.7118 0.6355 0.5674
(12%)
PV of benefits $ 0 $ 58,036 $ 51,818 $ 46,266 $ 41,309 $ 36,883

NPV of all
$ 0 $ 58,036 $109,853 $156,119 $197,428 $234,310 $234,310
benefits

$
One-time costs (50,000)

$ $ $ $ $
Recurring costs $ 0
(20,000) (20,000) (20,000) (20,000) (20,000)
Discount rate
1.0000 0.8929 0.7972 0.7118 0.6355 0.5674
(12%)
PV of recurring $ $ $ $ $
$ 0
costs (17,858) (15,944) (14,236) (12,710) (11,348)

$ $ $
NPV of all $ $ $ $
costs (50,000) (67,858) (83,802) (98,038) (110,748 (122,096 (122,096
) ) )

Overall NPV $112,214

Overall ROI 0.92

Break-even
analysis
Yearly NPV $
$ 40,178 $ 35,874 $ 32,030 $ 28,599 $ 25,535
Cash Flow (50,000)
Overall NPV $
$ (9,822) $ 26,051 $ 58,081 $ 86,680 $112,214
Cash Flow (50,000)

Project break-even occurs between years 1

and 2
Break-even
0.274
fraction
Actual break-even occurs at 1.3
years
7. For the system described briefly in the answer for question 4, let us
assume the following generic system specifications. There will be nine
333-MHZ Pentium IIs, each with 32MB of RAM, 8GB hard drives, and 17-
inch color monitors. There will be one 400-MHZ Pentium II, with 64MB of
RAM and a 12GB hard drive with a 17-inch high-resolution color monitor.
Each PC will have a high quality network interface card, and each will
come with Windows 98. The LAN will be Novell NetWare, with twisted-pair
cabling.
8. The following spreadsheet summarizes the economic analysis requested
in this question.

Problem and Exercise

#8
0.1
Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Totals
Net Economic $0 $85,000 $85,000 $85,000 $85,000 $85,000
Benefit

Discount Rate (10%) 1.0000 0.909091 0.826446 0.751315 0.683013 0.620921

PV of Benefits $0 $77,273 $70,248 $63,862 $58,056 $52,778

NPV of all Benefits $0 $77,273 $147,521 $211,382 $269,439 $322,217 $322,217

One-Time Costs ($75,000)

Recurring Costs $0 ($35,000) ($35,000) ($35,000) ($35,000) ($35,000)

Discount Rate (10%) 1.0000 0.9091 0.8264 0.7513 0.6830 0.6209
PV of Recurring $0 (31,252) ($28,926) ($26,296) ($23,905) ($21,732)
Costs

NPV of all Costs ($75,000) ($106,252.00 ($135,178) ($161,474) ($185,379) ($207,111) ($207,111
) )

Overall $115,106
NPV

Overall 0.56
ROI

Break-even Analysis
Yearly NPV ($75,000) $46,021 $41,322 $37,566 $34,151 $31,046
Cash Flow

Overall NPV ($75,000) ($28,979) $12,343 $49,909 $84,059 $115,106

Cash Flow

Project Break-even occurs between years 1 and 2

Use first year of positive cash flow to calculate 0.701
break-even fraction
Actual Break-even 1.8 years
occurs at
9. The following spreadsheet summarizes the economic analysis requested
in this question.

Problem and Exercise

#9
0.12
Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Totals
Net Economic $0 $85,000 $85,000 $85,000 $85,000 $85,000
Benefit

Discount 0.12 1.0000 0.8929 0.7972 0.7118 0.6355 0.5674

Rate
PV of Benefits $0 $75,893 $67,761 $60,501 $54,019 $48,231

NPV of all Benefits $0 $75,893 $143,654 $204,156 $258,175 $306,406 $306,406

One-Time Costs ($75,000)

Recurring Costs $0 $40,000 $40,000 $40,000 $40,000 $40,000

Discount 0.12 1.0000 0.8929 0.7972 0.7118 0.6355 0.5674
Rate
PV of Recurring $0 ($35,714) ($31,888) ($28,471) ($25,421) ($22,697)
Costs

NPV of all Costs ($75,000) ($110,714) ($142,602) ($171,073) ($196,494) ($219,191) ($219,191)

Overall $87,215
NPV

Overall ROI 0.40

Break-even Analysis
Yearly NPV ($75,000) $40,179 $35,874 $32,030 $28,598 $25,534
Cash Flow
Overall NPV ($75,000) ($34,821) $1,052 $33,082 $61,681 $87,215
Cash Flow

Project Break-even occurs between years 1 and

2
Use first year of positive cash flow to calculate 0.971
break-even fraction
Actual Break-even 1.97 years
occurs at
10. The following spreadsheet summarizes the economic analysis requested
in this question.

Problems and Exercise #10

0.12
Year 0 Year 1 Year 2 Year 3 Totals
Net Economic
Benefit $0 $85,000 $85,000 $85,000
Discount Rate (12%) 1.0000 0.8929 0.7972 0.7118
PV of Benefits $0 $75,893 $67,761 $60,501

NPV of all Benefits $0 $75,893 $143,654 $204,156 $204,156

One-Time Costs ($75,000)

Recurring Costs $0 $35,000 $35,000 $35,000

Discount Rate (12%) 1.0000 0.8929 0.7972 0.7118
PV of Recurring Costs $0 ($31,250) ($27,902) ($24,912)

NPV of all Costs ($75,000) ($106,250) ($134,152) ($159,064) ($159,064)

Overall NPV $45,092

Overall ROI 0.28

Break-even Analysis
Yearly NPV Cash Flow ($75,000) $44,643 $39,860 $35,589
Overall NPV Cash Flow ($75,000) ($30,357) $9,503 $45,092

Project Break-even occurs betw een years 1 and 2

Use first year of positive cash flow to calculate break-even fraction 0.762
Actual Break-even occurs at 1.76 years
11. The following spreadsheet summarizes the economic analysis requested
in this question. Since the overall NPV is negative, the ROI is not useful in
this situation.

Problem and Exercise #11

0.1
Year 0 Year 1 Year 2 Year 3 Ye ar 4 Year 5 Totals
Net Economic
Benefit $0 $50,000 $55,000 $60,000 $65,000 $70,000
Discount Rate (10%) 1.0000 0.9091 0.8264 0.7513 0.6830 0.6209
PV of Benefits $0 $45,455 $45,455 $45,079 $44,396 $43,464

NPV of all Benefits $0 $45,455 $90,909 $135,988 $180,384 $223,848 $223,848

One-Time Costs ($90,000)

Recurring Costs $0 $40,000 $40,000 $40,000 $40,000 $40,000

Discount Rate (10%) 1.0000 0.9091 0.8264 0.7513 0.6830 0.6209
PV of Recurring Costs $0 ($36,364) ($33,058) ($30,053) ($27,321) ($24,837)

NPV of all Costs ($90,000) ($126,364) ($159,421) ($189,474) ($216,795) ($241,631) ($241,631)

Overall NPV ($17,783)

Overall ROI -0.07

Break-even Analysis
Yearly NPV Cash Flow ($90,000) $9,091 $12,397 $15,026 $17,075 $18,628
Overall NPV Cash Flow ($90,000) ($80,909) ($68,512) ($53,486) ($36,411) ($17,783)

Project break-even w ill not occur during the life of this project.
12. The following spreadsheet summarizes the economic analysis requested
in this question. Since the overall NPV is negative, the ROI is not useful in
this situation.

Problem and Exercise #12

0.12
Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Totals
Net Economic Benefit 0 $ 50,000 $ 55,000 $ 60,000 $ 65,000 $ 70,000
Discount Rate (12%) 1.0000 0.8929 0.7972 0.7118 0.6355 0.5674
PV of Benefits 0 $ 44,643 $ 43,846 $ 42,707 $ 41,309 $ 39,720

NPV of all Benefits $0 $44,643 $88,489 $131,195 $172,504 $212,224 $212,224

One-Time Costs $ (90,000)

Recurring Costs $0 $ 40,000 $ 40,000 $ 40,000 $ 40,000 $ 40,000

Discount Rate (12%) 1.0000 0.8929 0.7972 0.7118 0.6355 0.5674
PV of RecurringCosts $ - $ (35,714) $ (31,888) $ (28,471) $ (25,421) $ (22,697)

NPV of all Costs $ (90,000) $ (125,714) $ (157,602) $ (186,073) $ (211,494) $ (234,191) $ (234,191)

Overall NPV $ (21,967)

Overall ROI -0.09

Break-even Analysis
Yearly NPV Cash Flow $ (90,000) $ 8,929 $ 11,958 $ 14,236 $ 15,888 $ 17,023
Overall NPVCash Flow $ (90,000) $ (81,071) $ (69,114) $ (54,878) $ (38,990) $ (21,967)

Project Break-even w ill not occur during the life of this project.

13. The following spreadsheet summarizes the economic analysis requested

in this question. Since the overall NPV is negative, the ROI is not useful in
this situation.

Problem and Exercise #13

0.1
Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Totals
Net Economic Benefit $0 $50,000 $55,000 $60,000 $65,000 $70,000
Discount Rate (10%) 1.0000 0.9091 0.8264 0.7513 0.6830 0.6209
PV of Benefits $0 $45,455 $45,455 $45,079 $44,396 $43,464

NPV of all Benef its $0 $45,455 $90,909 $135,988 $180,384 $223,848 $223,848
One-Time Costs ($90,000)

Recurring Costs $60,000 $60,000 $60,000 $60,000 $60,000

Discount Rate (10%) 1.0000 0.9091 0.8264 0.7513 0.6830 0.6209
PV of Recurring Costs $0 ($54,545) ($49,587) ($45,079) ($40,981) ($37,255)

NPV of all Costs ($90,000) ($144,545) ($194,132) ($239,211) ($280,192) ($317,447) ($317,447)

Overall NPV ($93,599)

Overall ROI -0.29

Break-even Analysis
Yearly NPV Cash Flow ($90,000) ($9,091) ($4,132) $0 $3,415 $6,209
Overall NPV Cash Flow ($90,000) ($99,091) ($103,223) ($103,223) ($99,808) ($93,599)

Project Break-even w ill not occur during the lif e of this project.

14. The answer for this problem is the same as Problem and Exercise #10.

15. Students should submit an answer that is somewhat like the following.
For the system described above for answer 4, 6, and 7, assume that this
system will be used for the office automation needs of a small group of
office workers.

These group members need a way to share documents and peripheral

devices such as laser printers. Their work requires them to collaborate
and share documents, yet they have had no efficient way to do so. It was
determined that it would be more efficient for them to use a network to
share files than to be continually sharing physical documents or
exchanging diskettes. In addition, using a network would enable them to
buy and easily share one laser printer rather than having to buy several
laser printers or share one laser printer that is not networked. The system
is to include replacement PCs for each of the nine group members, plus
one more expensive PC to serve as a repository for data and unique
software applications. There are many other such LANs throughout the
organization, each connected to the organization’s network. At this point
there are no foreseeable constraints to implementing the system. This is
one of the last offices to be given a LAN.
 It is important that this initial section of the Baseline Project Plan Report
be done well so that there is a complete, accurate description of the
fundamental aspects of this project that everyone understands and
agrees on. Without this, there might be disagreements later about what
this system will entail, and/or an inadequate or unwanted system might
be implemented.

16. Alternative system configurations for the system described above include
the use of a different LAN operating system, such as Artisoft LANtastic or
Microsoft Windows NT. In addition, they may choose not to replace the
existing PCs used by this work group, or they may choose to replace their
PCs with another type of PC. For example, they may choose to upgrade
all of the PCs with IBM-compatible PCs, or they may choose to replace the
PCs with Apple Power PCs. Another alternative is to use a wireless LAN or
even use an existing mainframe or departmental minicomputer as the
server for the LAN. Other alternatives involve choices on the
implementation schedule, such as phasing–in the equipment. Alternatives
might be based on different assumptions, such as the number of
concurrent users, server space allotted for each user, the type of
applications to be run on the network, or budget limitations. At first
glance, this system seems to be highly feasible. The implementation of
similar systems of PCs and LANs has become common throughout many
organizations.

17. This system seems to be feasible from an economic perspective. The

initial costs are significant, but they are far outweighed by the tangible
and intangible benefits that this system will provide. This system is
relatively easy to implement, and the technology used is very stable, so
the system is technically feasible. The skills required among personnel
may be new, so there may be some risk that the technical staff will have
difficulties understanding multi–user operating systems. The system
solves the business problem well and will not change day–to–day
activities adversely. Thus, the system is operationally feasible. As long as
software is used legally and is not copied illegally, the system should
present no legal or contractual problems. The group members within this
office will be required to use technology that is new to them. If they are
resistant to the change, this may present problems. Given the relative
simplicity of this system and the stability of the technology, the project
seems feasible from a schedule, timeline, and resource perspective.
Overall, this system seems to be feasible, although the willingness of the
office workers should be taken into account. If they are resistant to the
change, then the change will have to be managed carefully. This
feasibility analysis matches fairly well with the simpler feasibility analysis
conducted in answer to Problem and Exercise 4. In any event, it is always
best to supplement the gut feeling about feasibility with a more formal,
detailed analysis of feasibility among the various feasibility categories. By
analyzing feasibility in each of these categories, you might uncover some
potential problem or concern (such as user resistance to change) that you
might overlook with a simpler judgment of feasibility.
18. Assume for this project a team of four members has been created. The
team consists of a team leader, who is a senior systems analyst, a junior
analyst, the office supervisor, and one of the other office workers. The
two analysts will work primarily with the two office personnel assigned to
the team. The other office personnel will communicate about the system
through the two office personnel who are on the team. All involved have
agreed that the system will have to meet the approval of the two office
personnel assigned to the team. In addition, the office personnel are in
the middle of a large, important project. Thus, the two systems personnel
have agreed to meet about this project when it is convenient for the
office personnel, and the systems personnel have agreed not to work in
such a way that disrupts the other office personnel. The team leader is
designated the official spokesperson for the project so that a consistent
message is given. The team also agrees to follow the systems
development guidelines established by the organization and to use
hardware and software supported by the company, when possible. People
sometimes feel that these project management issues are a waste of
time because they do not contribute directly to the completion of the
project. However, setting and agreeing on these ground rules for who will
work on the project and how they will work together is very important.
Without this agreement there are likely to be conflicts later on which may
adversely affect the success and timely completion of the project. Such
agreements manage everyone’s expectations and lead to greater
satisfaction with the project.

Guidelines for Using the Field Exercises

1. Students should be able to present a Project Overview, Recommendation,
Alternatives, and System Description for nearly any project they are
considering. This is the point of this question; the Baseline Project Plan is
robust and is useful for planning nearly any project.

2. Similarly, the students should be able to discuss any of their projects in

terms of these feasibility categories. Have the students share their
feasibility information on their various projects to show the class that
these feasibility issues are important for all projects, whether they
involve systems or not.

3. The Baseline Project Plans used in the organizations studied by students

are likely to vary slightly from the Baseline Project Plan discussed in this
chapter. However, each of these plans is likely to be comprised of the
same basic elements. Students are likely to find that the plans used are
modified in various ways during the life of the projects. It is best to think
of these plans as a set of flexible guidelines rather than a set of rigid
operating procedures that are etched in stone. Project planning should be
flexible. The point of a plan is to guide and prepare, not to constrain.
 4. Most PC–based software packages have a licensing agreement that
permits the purchaser to use one copy of the software on any single
computer, provided the software is in use on only one computer at any
time. If an organization has multiple licenses for the software, then at any
time they may have as many copies of the software in use as they have
licenses. The software is typically considered in use on a computer when
it is loaded into the temporary memory (i.e., RAM) or installed into the
permanent memory (e.g., hard disk, CD–ROM, or other storage device).
Some software vendors allow that if the software is permanently installed
on the hard disk or other storage device of a computer and one person
uses that computer more than 80% of the time it is in use, then that
person may also use the software on a portable or home computer. Some
software vendors also allow the purchaser to make one set of back–up
copies of the original diskettes. Organizations frequently purchase site
licenses that allow them to make and use multiple copies of software.
Software vendors vary on the strictness of their licensing agreements.
However, over the past few years software vendors have become stricter
with the licensing agreements and infringements throughout business,
education, and government.

5. Students are likely to find a variety of ways that information systems

projects are initiated. Sometimes the initiation comes from users,
sometimes from the managers of users, sometimes from systems
personnel. In addition, project initiation is relatively informal in some
organizations, while in other organizations the process is relatively
formal. It will be useful for the students to compare their answers to see
the variety of ways that this task is completed. Have the students talk
about the relative merits of these various methods.

6. Students are likely to find organizations that develop information systems

quickly and/or in an ad–hoc fashion. In these settings the systems
personnel are probably under great pressure to build systems as quickly
as possible. Under such pressure, there is probably little or no time for
planning. Alternatively, it may be that there is planning, but that it
happens on the back of envelopes or in the minds of the systems
personnel. It will be useful for students to compare their answers to this
question and discuss the potential disadvantages of this lack of planning
and the reasons for why the systems personnel develop systems in this
way.

Guidelines for Using the Broadway Entertainment

Company Case
The BEC case associated with Chapter 6, Initiating and Planning the
Customer Activity Tracking System, is one of the longer BEC cases since
it illustrates the process of getting a systems development project off the
ground. The case shows how the project initiation team developed a scope for
the system, selected project standards and a methodology, and structured
these elements into an initial project plan, including a schedule of activities.

The centerpiece of this case is the development of the Baseline Project Plan.
An important objective in your use of this case is to have your students
compare the BPP for the CATS project with the standards for a BPP outlined in
Chapter 6. It is probably this issue that you will want to emphasize in class
discussion or written exercises. Of interest is not only the content of the BPP
but also the process followed by the project initiation team to develop this
BPP.

This case can be used simply as a reading assignment to supplement Chapter

6; in this case, tell your students to use this case as a review of the major
points from Chapter 6, since the CATS project illustrates how an organization
might apply the principles outlined in the chapter. You can use the case more
actively for class discussion or a written assignment. Some possible
discussion questions are the following:

1. Is the content of the Baseline Project Plan for the CATS project consistent
with the BPP content suggested in Chapter 6?

2. What skills are required on a project initiation and planning team, and do
Jordan and Nancy apparently possess all of these skills?

3. In retrospect, what would you have done differently in preparing the BPP
for the CATS project? What other activities would you have done and
what other information would you have prepared?

4. Do Figures 1 and 2 have sufficient detail to be useful? How much more

detailed could you be at this stage in a project?

5. Assess the CATS project schedule shown in Figures 3 and 4. Do you have
any recommendations on restructuring this schedule to improve the
project? Are the resource requirements consistent with this project
schedule?

6. Figures 5, 6, and 7 explain the scope of the project. What other

information might Nancy and Jordan provide to better understand and
explain the scope of this project?

7. Did Nancy and Jordan assume appropriate roles during the walkthrough
meeting for the Baseline Project Plan? If you were Jordan, would you have
developed a different agenda for this meeting?

8. If you were a member of the SPB, would you have found the economic
justification for the project acceptable for this stage of the project? What
questions might you have asked about system justification to supplement
the information provided in the BPP?
7
Determining System Requirements

Chapter Overview
The purpose of this chapter is to acquaint students with some of the many
methods systems analysts use to collect information about information
system requirements. The chapter begins with a discussion of the more
traditional requirements gathering techniques, such as interviews,
questionnaires, and obtaining information from organizational documents.
The latter part of the chapter is devoted to more recently developed
techniques and tools, such as Joint Application Design (JAD), group support
systems, prototyping, and CASE tools. This chapter concludes with a
discussion of business process reengineering.

From their study of this chapter, students should take with them an
appreciation of the different types of requirements information analysts
collect and the different methods they can use to collect these requirements.
However, reading about and discussing how analysts collect requirements is
no substitute for direct hands–on experience with the techniques. Most of the
classroom suggestions listed below involve some type of hands–on
experience for students. You probably won’t have time to do all of these in
class, but even one or two of these exercises will give students a much better
insight into the requirements collection process.
Instructional Objectives
Specific student learning objectives are included at the beginning of the
chapter. From an instructor’s point of view, the objectives of this chapter are
to:

1. Provide insight into using interviewing to determine system requirements,

including the preparation of an interview plan.

2. Show students how questionnaires are designed, distributed, and used to

determine system requirements.

3. Discuss the advantages and pitfalls of observing workers to determine

system requirements.

4. Demonstrate how the analysis of business documents provides system

requirements information.

5. Illustrate how Joint Application Design promotes efficient and quick

system requirements determination.

6. Show how computing, in the form of CASE tools and group support
systems, can support requirements determination.

7. Show how prototyping can be used for requirements determination.

8. Show that BPR involves more than just tweaking or automating

processes.

9. Illustrate how disruptive technologies enable the breaking of long-held

business rules.

Classroom Ideas
1. Point out that, while requirements determination tools and techniques are
very valuable in the analysis phase, analysts can benefit from their use in
other phases of the life cycle. Demonstrate this with examples from other
phases. For example, JAD is also useful in the early phases of design,
such as where input forms and output formats are designed. Also,
observation can be useful during system implementation to verify that
the new system is being used as expected.

2. Use Figure 7–2 to show how to construct an interview plan. Construct a

plan with students during class and have them generate similar plans for
homework.

3. Use Field Exercise 1 at the end of the chapter as an in–class exercise. This
exercise typically takes about one hour to complete, including time for
 discussion of the results. Students can submit the reports at the next
class meeting.

4. Illustrate in class the right and wrong ways to develop questionnaires.

Discuss with students, using Table 7–4, the advantages and
disadvantages of questionnaires compared to interviews.

5. Use the box “Lost Soft Drink Sales” as a point–of–departure for a class
discussion of the advantages and disadvantages of direct observation.
You may want to expand the discussion of direct observation, especially if
you have experience as an action researcher, since the methods are
similar. You could include coverage of the use of confederates, how to
avoid observer biases, and other issues you consider important. We have
found that students are reluctant to use direct observation and need to
be encouraged to consider it equal to interviewing.

6. Figures 7-3, 7–4, and 7–5 can serve as the basis for a discussion of
documents and how system requirements can be determined from them.
Bring in other documents to add to the discussion or have students
collect various documents they have, such as bills and order forms. Show
how you can analyze such documents to discover business rules as well
as content requirements. For example, a shipping form will show whether
the firm recognizes potentially ship to, order from, and bill to addresses; a
class registration form may indicate the maximum length for student
names. Save these forms since they can also be used with Chapters 14
and 15 in discussing input, output, and user interface design.

7. Much useful information to supplement a class discussion of JAD is

contained in the end–of–chapter references. The Wood and Silver book is
an especially good source.

8. Three of the four video segments that accompany this textbook can be
used with Chapter 7. The most appropriate is the one on “Joint
Application Design.” This video segment is about 18 minutes long. Also
very appropriate is the video segment called “Managing User
Expectations,” which is about 12 minutes long. A third video segment on
“Application Engineering” could be used, if you have not already used it
with a prior chapter. Notes on using these video segments are included in
a separate section of this Instructor’s Manual. See the Preface to this
Instructor’s Manual for information on how to obtain the video segments
produced for use with the second edition of Modern Systems Analysis and
Design.

9. Using a business case, run a mock JAD in class, with some students
assigned roles as analysts, others as managers, and others as users. As
with a real JAD, the person chosen as facilitator is crucial to the exercise’s
success. The mock JAD should be preceded by the type of careful
planning that precedes actual JADs, as outlined in the text. Several
possible business cases for such an exercise are included in this
Instructor’s Manual.
10. Use a CASE tool to support the mock JAD outlined in Classroom Idea #9.

11. Use a group support system to support the mock JAD outlined in
Classroom Idea #9. The planning necessary for the JAD will have to be
supplemented with the planning necessary for GSS use.

12. Conduct a prototyping session in class, using a 4GL, a prototyping tool, or

a CASE tool with a prototyping component. If such software is available to
your students, have them create prototypes based on system
requirements found in a business case or in materials you provide.

13. Take an activity with which students are familiar, such as enrollment.
Have the students reengineer this activity. Encourage students to be
innovative.

Answers to Review Questions

1. Joint Application Design is a structured process in which users, managers,
and analysts work together for several days in a series of intensive
meetings to specify or review system requirements. Prototyping is an
iterative process of systems development in which requirements are
converted to a working system which is continually revised through close
work between an analyst and users. A group support system is an
information system, typically consisting of a series of networked
computers, in which specially designed software allows group members
to share files and to enhance group communication and cooperation.
Requirements determination is that phase of analysis in which analysts
gather information on what the system should do from as many sources
as possible: from users of the current system, from observing users, and
from reports, forms, and procedures. Requirements structuring is that
phase of analysis in which analysts document and organize the
information they have collected about an information system. Formal
system refers to the official way a system works as described in
organizational documentation. An informal system is the way a system
actually works. Business process reengineering refers to the overall
process by which current business methods are replaced with radically
new methods.

2. Systems analysis is the part of the systems development life cycle in

which you determine how the current information system functions and
assess what users would like to see in a new system. There are three
sub–phases in analysis: requirements determination, requirements
structuring, and alternative generation and choice.

3. Traditional techniques for collecting requirements include interviewing

and listening, administering questionnaires, observing users, and
analyzing procedures and other documents.
 Interviewing and listening involves talking with users individually or as a
group to discover their views about the current and target systems; it
also involves carefully preparing an interview outline and guide before
conducting the interview. Interviews are best done when only a few
people are involved, when you need open–ended questions or the
questions vary from individual to individual, or when a more personal
method is needed.

Administering questionnaires involves designing a questionnaire and

determining who should respond to it; this method is typically used when
there are too many key users to interview individually. Questionnaires are
best when many people are involved, each person is to answer roughly
the same questions, and people are remote or do not need personal care.

Directly observing users involves watching how people work in order to

uncover information users may not be consciously aware of. Direct
observation is best when detailed or complicated procedures must be
documented, when you do not want people to know they are giving you
information you need, when only a few people are involved, and
observational data are representative of all situations.

Analyzing procedures and other documents involves identifying and

collecting written procedures, forms, reports, and other relevant
documents in order to better identify data and processes that would be
part of the current and target systems. Analyzing documents is the best
technique when documents are complete and unbiased, when other
forms of requirements determination are too obtrusive, and when history
must be studied and people do not have first–hand data about history.

4. Interviews provide large amounts of rich, detailed information, but they

are expensive to conduct in terms of the time they demand.
Questionnaires, on the other hand, can reach many people at once,
making them relatively less costly than interviews, but the data collected
in this way will not be as rich or as plentiful as is the case with interviews.
Both techniques involve careful planning and execution to be successful.
Deciding which technique to use will be dependent on such factors as the
size and complexity of the information system under study, the size and
complexity of the organization in which the system resides, the funding
available, and the expertise and preferences of the analysts.

5. Joint Application Design or JAD is a structured process in which users,

managers, and analysts work together for several days in a series of
intensive meetings to specify or review system requirements. It’s better
than traditional techniques because you have all key personnel in one
place at one time, saving everyone time and resulting in high levels of
system ownership as more people have more of a role in the
development process. Weaknesses include the level of commitment
necessary to make the JAD work, the high degree of required planning,
and the typical lack of computer support.
 6. Computing has been used to support requirements determination in the
form of CASE tools, group support systems, and prototyping.

7. Computing has been used to support JAD in the form of the computer
used by the scribe, CASE tools used during the JAD to illustrate and
change form and report designs, group support systems to elicit a higher
level of group member participation, and prototyping tools to provide JAD
participants with workable system prototypes based on their ideas and
preferences stated during the JAD.

8. CASE tools can support requirements determination by supporting JAD

and prototyping with diagramming, form and report design, repository
access, and prototyping tools. The best-suited CASE tools are upper CASE
tools.

9. Prototyping can be used during requirements determination to collect

user requirements and present them in the form of a working system
prototype. Users can look at, play with, and compare the prototype to
their system requirements. Analysts can then adjust the prototype to
better fit what the users have in mind. Prototyping is better than
traditional methods where system requirements are not well understood,
where few users that are stakeholders are involved, where designs may
be complex, where there have been past communication problems, and
where the necessary tools are readily available. Prototyping may be
worse than traditional methods where formal requirements are not
documented, where prototypes become idiosyncratic to the initial user,
where issues of data sharing and integration with other systems are
ignored, and where SDLC checks are bypassed.

10. Group support systems provide unique benefits for group requirements
determination through allowing everyone the opportunity for equal
participation through typing instead of talking, and anonymity allows the
shy and those afraid of criticism to participate.

11. As part of the BPR effort, key business processes should be identified.
Key business processes are the structured, measured set of activities
designed to produce a specific output for a particular customer or
market. Once these key business processes have been identified, those
activities that can be radically improved should be identified. Primary
candidates include those activities that are viewed as important,
changeable, or dysfunctional. Benefits of BPR include radical
improvements in speed, quality, and customer satisfaction.

12. Disruptive technologies enable the breaking of long-held business rules

that inhibit organizations from making radical business changes.
Disruptive technologies enable companies to apply information
technology innovatively. As a point of discussion, ask students to discuss
the concept of a virtual university. Is this an acceptable application of a
disruptive technology?
Answers to Problems and Exercises
1. d open–ended questions b JAD session leader e key business
processes
a closed–ended questions c scribe

2. Numerous articles are available in the library and on the web. CASE
tools are useful in JAD sessions because the JAD team can use the CASE
tools (i.e., creating data flow diagrams, entity–relationship diagrams, and
a data dictionary) together. This helps the team to better, and more
quickly, develop the system. A GSS is useful in JAD sessions because
more team members can participate, the GSS can help keep the team on
track, the team members can use the electronic, anonymous
brainstorming tools, and the GSS automatically, accurately captures the
outputs of the sessions. Some of the limits to using CASE and GSS in JAD
are the availability of the tools, the learning curve for these tools if the
team members are not familiar with them, and potentially over–
structuring the development process.

3. The analyst could conduct the observations unobtrusively, so that the

effect on the users’ behavior is minimized. This could be done using a
confederate or by a hidden camera. The analyst could also brief the users
on the observation so that the users will relax and behave naturally. For
example, you can make it clear to users that they are not being
evaluated and that the observations collected will not be associated with
anyone individually. In addition, the analysts could perform multiple
observations over time. This would tend to minimize the effects of
aberrant behaviors. Alternatively, the analysts could supplement their
requirements determination with additional data collection methods.

4. One of the primary problems with analyzing business documents is that

they don’t give the full picture of how work is done and why. First,
business documents are often incomplete, since people have selectively
retained documentation. Second, business documents often describe the
formal system as opposed to the informal system, which is more often
the way the work is actually completed. Whether the business documents
are accurate or not, they provide useful information. If the business
documents are accurate, then much of the work of gathering information
requirements is nearly finished. If the business documents are inaccurate,
then the analyst can use these to understand how the work processes
ought to be done, or are thought to be done, or, perhaps, should not be
done. In any event, analyzing business documents should be done in
conjunction with other, supplemental data collection methods. In
addition, the analyst should speak to multiple people to gather their
perceptions and uses of the documents.

5. Students might suggest the following for the JAD leader: the JAD sessions
should be off–site, the proper people should be invited to the JAD
sessions, establish clear ground rules for the sessions, set and follow a
 clear agenda, distribute the agenda to all participants before the
sessions, remain neutral on issues, make sure that everyone has the
opportunity to participate, encourage people to be creative and break
free of traditional ways of doing things, manage time effectively, and
follow up with meeting notes.

6. Students should note that the objective of the meeting is to determine

which courses to take to develop the skills needed to be hired as a
programmer/analyst. The agenda might include introductions,
background, discussion of the courses already taken, discussion of course
requirements not yet met, discussion of additional courses to take for
preparation, plotting course schedules for successive semesters,
summary of major points, questions from advisor, and closing. A meeting
like this can last anywhere from 30 to 60 minutes, depending on the level
of familiarity that the advisor has with the student’s case.

7. Three possible closed–ended questions, each in a different style, are:

1. Which of the following is the best thing about the word processor that
you currently use to do your job (pick only one):
a. good help system
b. extra tools such as spell check, grammar check, thesaurus, and
autocorrect
c. compatibility with other applications such as graphics package and
spreadsheet

2. Please rank the following three items in terms of their need for
improvement in the next version of this word processor. Place a “1” by
the item which is most in need of improvement.
a. ease of use
b. speed
c. compatibility

3. Should the next version of this word processor enable you to create
and use hypertext markup language documents for use on the World
Wide Web?

1 2 3 4 5 6 7
Strongl Agree Agree Neutral Disagree Disagree Strongly
y Somewha Somewh Disagre
Agree t at e

8. One way is to ask open–ended questions to let the individual write

whatever is on their mind. In this way the questionnaire can be more
probing than if it had only closed–ended questions. Another method is to
ask a multiple choice question or a yes/no question, and then, depending
on which answer the respondent chooses, have them branch off into a
specified set of questions. Alternatively, you might create different
 versions of a survey instrument, for example, one for users and one for
managers of users.

9. Because the group interview might be more difficult to conduct and more
time consuming, the analyst might add to the interview guide “time
certain” events or “time stamped” agenda items. For example, if the
meeting begins at 8:00 a.m., and the manager of the users will come in
to the meeting to give a brief talk, this event might be scheduled for 8:15
a.m. until 8:30 a.m. Other processes in the meeting will be postponed
during this event. With time stamping, the analyst writes definitive start
times next to each of the agenda items and then uses this to keep the
group on track. Alternatively, the analyst might write specific questions
that should be asked of specific members of the interview group. If
several analysts are involved in the group interview, the group could be
broken into parallel sessions, each with its own agenda. Finally, agenda
activities should be allotted for discussion and interchange between the
interviewees, so that consensus and synergy can occur.

10. Some of the problems include difficulty in scheduling, enabling all

group members to participate during the meeting, some people being
afraid or not willing to speak in front of certain other people, conflicts
existing among group members, keeping the group on track during the
meeting, and accurately collecting all the information as multiple people
speak at once. Some of the ways to deal with these problems include
having training in team building, group dynamics, and managing conflict;
having multiple interviewers work together; and using a technological aid
such as CASE or GSS.

11. The answer to this question can be facilitated by revisiting the definitions
for corporate strategic planning and information systems planning.
Corporate strategic planning is an ongoing process that defines the
mission, objectives, and strategies of an organization. Information
systems planning is an orderly means of assessing the information needs
of an organization and defining the systems, databases, and technologies
that will best satisfy those needs. The key to understanding BPR is that it
is the search for and implementation of radical change in key business
processes. Those organizations involved with BPR are looking for new,
innovative ways to perform these processes.

Guidelines for Using the Field Exercises

1. This exercise can take up much of a class period, but it is very useful.
This simulates actual interviewing and gives the students much needed
interview practice, comparison, and feedback. Be sure to allow sufficient
time for discussion, or alternatively, have students write a short paper on
their observations (as mentioned at the end of the exercise).

2. This should be a useful method for learning about the team’s work
processes. Students should be able to identify and apply the comparative
 advantages and disadvantages of group interviews as discussed in the
chapter. Student observations may vary based on group size, group
history, and whether the group leader is present.

3. If the teams chosen closely follow the prescribed method of work, then
the information from the interview should match the information from the
written documentation. If, however, some of the teams chosen use a
more informal system for completing work, then the information from the
interview is not likely to match the information from the written
documentation. Have the students compare their answers and talk about
why, and with what implications, these differences might exist.

4. JAD is becoming a more and more popular development method, so the

students should be able to find systems professionals who have and/or
are using JAD. The feedback the students get should mirror the
information on JAD presented in this chapter, and it will be useful for the
students to have the textbook information confirmed by systems
professionals in the “real world.” If the systems professionals provide
additional information not covered in the text, be sure to have this shared
with the rest of the students. It is likely that the skills of the group leader
will be critical in their assessment of the JAD experience.

5. For good background on JAD, students might read Guide (1990). “JAD
Across the Life Cycle.” Guide International Inc., Publication no. GPP–219.
For more recent publications on JAD, students will find articles in IS
journals in the academic literature and IS magazines in the popular press.
In addition, the proceedings of the annual International Conference on
Information Systems and the Hawaii International Conference on Systems
Sciences frequently have articles on JAD.

6. Students will discover that the organization’s systems were not merely
tweaked; they were significantly modified to the betterment of the
organization. If students are not able to find a contact person, a visit to
the library or to the web will yield results. Also, you may want to
encourage your students to identify companies that have undergone BPR,
such as Ford. Ask the students to identify the tangible and intangible
benefits of this process. Students should identify the costs as well.

Guidelines for Using the Broadway Entertainment

Company Case
The BEC case associated with Chapter 7, Analysis: Requirements
Determination for the Customer Activity Tracking System, illustrates
how information collected during an interview might be interpreted for
determining the requirements for a new information system. This case also
introduces two of the systems analysts assigned to the CATS project and one
of the primary users of this system.

A segment of the interview notes is included in the case; however, an agenda

for the interview is not included. The implication is that maybe an agenda—
interview guide—did not exist, at least not one at the level of detail
suggested in Figure 7–2 from the chapter. Also included is the transcript of a
possible conversation two of the analysts are having concerning the interview
notes. The discussion provides a sense of how interview notes can be used,
some of the benefits of doing interviews, and the need for follow–up
questioning after an interview. The discussion also points out how different
analysts can see different key points from interview notes, and hence, the
power of the team approach to systems analysis and design.

This case itself is not very provocative. It can, however, be used to stimulate
some interesting class discussion about how an interview is conducted and
the results achieved. Thus, we recommend that you take some time in class,
probably after you lecture on Chapter 7, to discuss some questions based on
this case. Some possible discussion questions are the following:

1. From the information included in the case, how would you rate Frank
Napier’s ability as an interviewer? Do you think he was well prepared for
his interview with Wendy Yoshimuro? In answering these questions,
assume that Wendy’s interview was one of the first interviews Frank
conducted for the CATS project.

2. Besides Wendy, who else should the CATS team analysts be interviewing
(use general titles for the kinds of people who you think should be
interviewed)?

3. Based on these interview notes, what CATS requirements have been

identified?

4. Why is Frank so interested in Wendy as an interviewee?

5. What kinds of questions should Jordan ask the seven BEC store managers
in the meeting she has scheduled? Assume that this is a group interview,
not seven individual interviews.

6. What impact does the DFD in Figure 2 have on structuring interviews for
the CATS project?

7. Why does Frank think that both individual interviews and a JAD should be
used for requirements determination on the CATS project? Do you think
both are necessary? Why?
8
Structuring System Requirements: Process
Modeling

Chapter Overview
The purpose of this chapter is to show students one particular method for
modeling business processes, data flow diagrams (DFDs). Although there are
several methods and techniques available for process modeling, we have
chosen to focus on DFDs because they have been popular for many years,
especially in the structured analysis and design literature. Many CASE tools,
such as the Visible Analyst Workbench™, IEF™, and others, have incorporated
DFDs into their sets of system development tools and techniques.

The chapter is divided into several distinct sections, each of which builds on
what has come before. After a brief introduction to process modeling, data
flow diagramming techniques are introduced in a section called “Data Flow
Diagramming Mechanics.” This section demonstrates the basic DFD symbols,
definitions, and rules. We use the Gane and Sarson symbol set throughout
the book, and these symbols are explained in this section. There is also an
example from Hoosier Burger, the food ordering system first shown in
Chapter 2. This section also includes explanations of decomposition and
balancing.

The second major section of Chapter 8 introduces the concept of four

different types of DFDs: (1) current physical, (2) current logical, (3) new
logical, and (4) new physical. We use another example from Hoosier Burger,
its inventory control system (which is manual), to illustrate the first three
types of DFDs. We point out that current practice in using DFDs indicates that
very little time should be spent on the current physical DFD.

The third major section in this chapter, “Using Data Flow Diagramming in the
Analysis Process,” is novel for an introductory systems analysis and design
text. In this section, guidelines for drawing and using DFDs in analysis are
introduced. This is different from the mechanical rules presented earlier.
Topics include completeness, consistency, timing, iterative development,
primitive DFDs, and analyzing DFDs for system inefficiencies and
discrepancies among DFDs that are supposed to be modeling the same
system. We use another Hoosier Burger example and output from Oracle’s
Designer/2000 CASE tool to illustrate some of these concepts.

Instructional Objectives

Specific student learning objectives are included at the beginning of the

chapter. From an instructor’s point of view, the objectives of this chapter are
to:

1. Show how logically modeling processes can be done with data flow
diagrams.

2. Teach students data flow diagram symbols and the mechanical rules
necessary for them to create accurate and well–structured process
models.

3. Show students how to decompose data flow diagrams into lower–level

diagrams.

4. Illustrate the concept of balanced DFDs.

5. Explain and demonstrate the differences among the four levels of DFDs:
current physical, current logical, new physical, and new logical.

6. Illustrate how data flow diagrams can be used as tools to support

systems analysis.

Classroom Ideas
1. Use Figures 8–2 and 8–6 to illustrate the basic DFD symbols and the
correct and incorrect ways to draw the diagrams. Use Figure 8–3 to
demonstrate the problem with trying to include sources/sinks inside the
system being modeled.

2. Once you have taught the basics of drawing DFDs, have students
complete Problems and Exercises 2 through 4 and 10 as in–class
exercises that you can then go over in class to emphasize the points you
have made.

3. Figures 8–5, 8–7, 8–8, and 8–9 can be used in class to teach
decomposition. These can be followed with students completing in–class
Problems and Exercises 5 and 11.
4. Use Figure 8–10 to illustrate unbalanced DFDs.

5. Supplement the material in the chapter on DFD mechanics,

decomposition, and balancing with your own examples, which you can
work through together in–class. A good source of such examples is
written organizational procedure statements. Modified procedure
statements also make good homework problems. See Problems and
Exercises 12 and 13 for examples. We have found that it is best to devote
at least one complete class period to working examples. Students can
prepare these diagrams outside of class or try for the first time in class.
Many issues arise that are best handled from examples such as the
following difficulties that students often encounter:

 identifying when to show a direct data flow between processes and

when to decouple these with a data store (emphasize that data stores
allow different processes to work at different rates and at different
times)

 deciding what activities to encompass with each process (emphasize

the principle of cohesion and the goal of each process being of roughly
equal size and complexity)

 distinguishing processes from sinks and sources (emphasize factors

such as audience and the ability to change or control in making such
distinctions)

 logical inconsistencies or ambiguities in narrative descriptions

(emphasize that this is the power of DFDs and the typical interaction
between requirements structuring and requirements determination
necessary to resolve such ambiguities)

6. The Hoosier Burger inventory control system example in the text is

designed to demonstrate the differences between current physical,
current logical, and new logical DFDs. Working through the entire
example in class is an effective way to illustrate the differences in these
three types of DFD. Working through another example from your own
experience, or having students come up with their own examples, will
supplement the Hoosier Burger example.

7. Use a CASE tool in class to demonstrate other ways to model processes

other than DFDs. Have students compare and contrast these alternative
methods with DFDs.

8. Using a CASE tool that supports DFDs, show in class how the tool
provides for decomposition and balancing and how DFDs are linked to the
CASE repository. Later, when teaching Chapter 10, you can show how the
repository links DFDs and entity–relationship diagrams.
9. Use a CASE tool in class to show how the tool checks for completeness,
consistency, and other elements of analysis as discussed in the chapter.

Answers to Review Questions

1. A new logical data flow diagram is a model of the target information
system that depicts the functionality and data flows of the target system
without regards to how the system will be physically implemented. A
current logical data flow diagram is a model of the current information
system in which the physical aspects of the system are removed as much
as possible so that the current system is reduced to its essence, to the
data and the processes that transform them, regardless of actual physical
form. Decomposition is an iterative process of breaking the description of
a system down into finer and finer detail, creating a set of diagrams in
which one process on a given diagram is explained in greater detail on a
lower–level diagram. Balancing is the conservation of inputs and outputs
to a data flow diagram process when that process is decomposed to a
lower level. A level–0 data flow diagram is a data flow diagram that
represents a system’s major processes, data flows, and data stores at a
high level of detail. A context diagram provides an overview of an
organizational system, showing the system boundary, external entities
that interact with the system, and the major information flows between
entities and the system. Process modeling is the process of graphically
representing the functions, or processes, which capture, manipulate,
store, and distribute data between a system and its environment and
between components within a system. A primitive DFD is the lowest level
of decomposition for a data flow diagram.

2. A data flow diagram is a picture of the movement of data between

external entities and the processes and data stores within a system.
Systems analysts use data flow diagrams to help them model the
processes internal to an information system and how data from the
system’s environment enter the system, are used by the system, and are
returned to the environment. DFDs help analysts understand how the
organization handles information and what its information needs are or
might be. Analysts also use DFDs to study alternative information
handling procedures during the process of designing new information
services.

3. The rules for DFDs are listed in Table 8–2 and illustrated in Figure 8–6.
Processes cannot have only outputs, cannot have only inputs, and must
have a verb phrase label. Data can only move to a data store from a
process, not from another data store or an outside source. Similarly, data
can only be moved to an outside sink or to another data store by a
process. Data to and from external sources and sinks can only be moved
by processes. Data flows move in one direction only. Both branches of a
forked or a joined data flow must represent the same data. A data flow
cannot return to the process from which it originated.
4. Decomposition is the iterative process by which a system description is
broken down into finer and finer detail, creating a set of diagrams in
which one process on a given diagram is explained in greater detail on a
lower–level diagram. Balancing is the conservation of inputs and outputs
to a data flow diagram process when that process is decomposed to a
lower level. You can determine if a set of DFDs are balanced or not by
observing whether or not a process which appears in a level–n diagram
has the same inputs and outputs when decomposed for a lower-level
diagram.

5. The highest level DFD is called a context diagram. It represents the

system as a single process, with all the related entities and the data flows
in and out of the system. The next level diagram, called a level–0,
decomposes the one process from the context diagram into two to nine
high–level processes. Each process in a level–0 diagram can be
decomposed if necessary. Each resulting diagram is called a level–1.
Should processes in a level–1 diagram be decomposed, each resulting
diagram would be called a level–2 diagram. Each one of these processes
would be decomposed on a level–3 diagram, and so on.

6. Current physical DFDs often show the people and technology used within
a system, showing who does what and the media on which data are
stored. Current logical DFDs attempt to show the essence of the system
without regard to the actual physical implementation.

7. Detailed DFDs for the current physical system tend to take a great deal of
time and then tend to be tossed aside as the focus shifts from the current
to the new system. By not drawing current physical DFDs, or by drawing
only cursory ones, analysts can save themselves effort and focus from
the beginning on what is really important, the new system.

8. DFDs can be used as analysis tools to help determine the completeness

of a system model and a model’s internal consistency, as a way to focus
on when system events occur through analyzing timeliness, and, through
iterative use, to develop and check models. Analysts can study DFDs to
find excessive information handling, thus identifying areas for possible
efficiencies.

9. You stop decomposing a DFD when the following six conditions are
satisfied.

 Each process is a single decision or calculation or a single database

operation, such as retrieve, update, create, delete, or read.

 Each data store represents data about a single entity, such as a

customer, employee, product, or order.

 The system user does not care to see any more detail, or when you and
other analysts have documented sufficient detail to do subsequent
systems development tasks.
  Every data flow does not need to be split further to show that different
data are handled in different ways.

 You believe that you have shown each business form or transaction,
computer screen, and report as a single data flow.

 You believe there is a separate process for each choice on all lowest–level
menu options for the system.

10. Sources and sinks are always outside of the system being considered.
They are of interest to the system being considered only because they
represent sources of data coming into the system and destinations for
data leaving the system. If any data processing occurs inside a source or
sink, it should be of no interest to the system being modeled. If the
processing is of interest, however, or if the identified source/sink has
several inputs and outputs to and from the rest of the system, it may be
better considered as an internal process.

11. Context diagrams have only one process that represents the entire
system being modeled and show only the data flows into and out of the
system. The diagram also includes sources and sinks, which represent
the system’s environmental boundaries. There are usually no data stores
in a context diagram.

Answers to Problems and Exercises

1. d source/sink b data store f DFD completeness
a data flow c process e DFD consistency

2. There are a number of ways that students could draw their data flow
diagrams, particularly depending on the level of detail they choose to
capture. Students should realize that there isn’t necessarily one “right”
data flow diagram for this or most other business processes. Some of the
relevant data flows might include payment information, receipt, goods
sold information, and inventory information. Some data stores might
include a goods sold file, an inventory file, and daily sales total file. Some
processes might include update goods sold file, update inventory file,
update daily sales total file, and produce management reports. Some
sources/sinks might include customer or store manager. A sample context
and level–0 data flow diagram for this exercise is provided below. In the
level–0 data flow diagram, Transform Customer Purchase, Update Goods
Sold File, Update Inventory File, and Update Sales Total File, were selected
as processes rather than as sources/sinks because they were deemed to
be central to the point of sale process. Point out why these DFDs are
balanced.
Context Diagram

0
Rece
Point
Custo of Sale
System Store
Manag
Pay ement
Level-0 Diagram

Rece 1
Transf
orm
Custo
mer
Purcha
se

Goods Inve Sale

ntor

2 3 4
Update Update Update
Goods Invento Sales
Sold ry Total
File File File

Forma Forma Forma

tted tted tted

Goods Invento Sales

D Sold D ry File D Total
1 File 2 3 File
Invent
Sales
Goods Totals
Sold 5
Produc
e Store
Manag Manag
ement ement
Report
s
3. Please refer to the sample context and level–0 data flow diagrams for this
exercise. As with the previous question, there are a number of ways that
students could draw their data flow diagrams for this question,
particularly depending on the level of detail they choose to capture.
Students should realize that there isn’t necessarily one “right” data flow
diagram for this or most other business processes. It is important that the
diagrams be balanced, have a clear and purposeful boundary, and obey
the rules for drawing DFDs.

Context Diagram

Order 0 Cap
Infor and
Stude Order Shipp
Entry
System
Rece

Level-0 Diagram

Order Cap
Infor Rece and

1 2 Invent 3
Valid Update
Finaliz ory Invento
Validat
e e ry
Order Order File

Invent
ory Forma
tted
 Invento
D ry File
2

4. Students should go through the rules discussed in this chapter (and

presented in Table 8–2 and Figure 8–6) one at a time and check each of
their data flow diagrams. Alternatively, if the students are using a CASE
tool to create their data flow diagrams, the CASE tool may be used to
automatically check for errors in the diagrams. There are no rule
violations in the example DFDs, but we cannot verify that there are no
logical problems until we decompose the diagrams to a primitive level.
One obvious missing system capability is how to handle invalid orders;
typically, processes to handle abnormal conditions, like invalid orders, are
shown on primitive or at least low-level diagrams.
5. The students may choose a variety of situations to use for the nth level
data flow diagrams for this answer. Basically, the students should
continue the process of decomposition until they have reached the point
where no sub–process can logically be broken down further (i.e., each
process meets the definition of a primitive process). See the level–1 data
flow diagram for this exercise, which shows a sample decomposition of
the process titled Finalize Order from the level–0 data flow diagram
provided for Problem and Exercise 3. The (italicized) labels for processes
and sources/sinks without borders represent the origin or destination of
flows that pass between this subsystem and other system components.
Note that the Goods Sold File is a potential black hole, or should possible
be treated as a sink.

Level-1 Diagram

Shipp

Validate

2
2 2
.
Generat Rec . Receip .
1 Log Generat
2 3
1e Goods e
Receipt 1
Sold Informa
Data tion
for
Shippin
g
Goods Inve
Valid
Sold
Order

Goods Update
Validate
D Sold
2 File

6. Some errors and peculiarities in these diagrams include:

 Different names and numbers are used for apparently the same data
store on the two diagrams.

 In the level–0 diagram, the data store, Class Roster, does not have the
data flow, Scheduled Classes, flowing into it, rather this data flow
connects processes 2 and 3, thus these DFDs are not balanced.

 Process 1 appears to accomplish nothing since its inflow and outflow are
identical; such processes are uninteresting and probably unnecessary; it
is possible that this process will become interesting when it is
decomposed, where validation and error handling processes might
appear.
  Process 2 does not appear to need Course Request as input in order to
perform its function, as implied by its name.

 Some students may also wonder if process 3 has input sufficient to

produce its output; for example, where are prior class registrations kept
so that process 3 can determine when a course is full?

7. Physical data flow diagrams help you better understand the people
and/or computer systems that are used in the overall system’s
processing. Logical data flow diagrams help you better understand the
essence of the system, the data and the processes that transform them,
regardless of actual physical form. Further, the new logical data flow
diagrams can then show any additional functionality necessary in the
new system, to indicate which, if any, obsolete components have been
eliminated, and any changes in the logical flow of data between system
components, including different data stores. The data flow diagrams for
the new physical system can then be constructed with the data flow
diagrams for the new logical system as a guide. As discussed in the
chapter, experts used to recommend that all four levels of data flow
diagrams (current physical, new physical, current logical, and new logical)
be constructed because: (1) analysts knew little about the business of the
user and needed to develop a detailed current physical data flow diagram
in order to understand the business, (2) users were not able to work with
a new logical data flow diagram right away, and (3) there is not much
work in turning current logical data flow diagrams into new logical data
flow diagrams.

8. For data flow diagrams to be complete, all the necessary components of

a data flow diagram should be included in the diagram and fully
described in a project repository. As described in the chapter, with most
CASE tools, the CASE tool’s repository, is linked to the diagram.
Whenever you define (or redefine) a process, data flow, source/sink, or
data store on a data flow diagram, an entry is automatically created (or
updated) in the repository for that element. Figure 8–18 shows a sample
report of the contents of a CASE repository entry. It is this tight linkage
between diagrams and the CASE repository that creates much of the
value of a CASE tool. Further, you cannot have an entry in the repository
that is not on some diagram. The repository is also helpful for enforcing
DFD rules; for example, during decomposition, the repository remembers
what were all of the inflows and outflows of an exploded process. The
repository also keeps track of any split or joined data flows.

9. The various views (e.g., process, logic, data) of an information system

each have their own unique characteristics and provide the most relevant
information to different information system specialists. This variety is
best understood, expressed, and managed by using diagrams and
documentation that are specifically tailored for each view of the system.
For example, data flow diagrams are useful for capturing the flow of data
through business processes, but they are not useful for describing the
forms and relationships among data. As information systems become
 larger and more complex, it becomes even more important to use the
right tool and technique to develop each component of an information
system. One technique that captured all aspects of an information
system model on one diagram or in one notation would likely be too
complex for systems professionals to handle.

10. Three major errors in Figure 8-22 are:

 Process 1.0 (P2) has only inputs, making it a “black hole.”

 Data flow DF5 should not move directly from source E1 to data store DS1
without first going through a process.

 Data flow DF1 should not move directly from source E1 to sink E2 without
first going through a process.

Other peculiarities (such as Process 1.0 has label P2 and the data store
has only a label, not a number) are only that, not errors.

11. There is a general formatting issue with these DFDs since there are no
numbers on processes and data stores, but the student should be able to
find logical errors as well. These diagrams show the decomposition of
process P1 on the level–0 diagram. Three particular logical errors in
Figure 8-23 are:

 The data store DS1, not DS2, should be represented on the level-1
diagram.

 Data flow DF3 should be an outflow on the level–1 diagram, and data flow
DF6 should not be on the Level–1 diagram.

 Process P1.4.2 has no inputs and is thus a “miracle.”

12. The example context and level-0 data flow diagrams represent one
possible way to model the hiring process described in this question.
Variations, based on different assumptions, are possible. For example, it
is possible to include the processes performed by the Personnel Manager
outside the system as a source/sink; in our diagram, we assume the way
the Personnel Manager does her/his work might be studied in more detail
and the way this work is done is subject to change. Also, some students
might show Applicant and Hired Employee as separate sources since only
Hired Employees provide the information on a non–disclosure agreement.

Our example assumes that there is always a successful hiring decision

(that is, there is no loop between Processes 4 and 3 in the level–0
diagram); we also assume application and job description data flows are
accurate and complete, so there is no reason to explode associated
processes to show error handling. We also assume that all Hiring Decision
Letters result in an accepted hiring offer. You may want to give your
students our example answer and ask them to identify additional
 assumptions we have made, which may be different than what they
concluded. Our simplifications mean that it is unlikely that our level–0
diagram needs to be decomposed.

Our example solution also shows split data flows; be sure to emphasize
that a split flow means that the same data flow at the same time, but to
multiple destinations. In our example, we also show the Employee data
store only on the level–0 diagram, not on the context diagram.
Technically, you could show it on the context diagram, but we assume
that this is a detail that is necessary to be known only to those looking at
level–0 and lower diagrams. A frequent mistake our students have made
is to forget to include the purge process (on level–1 or lower diagrams) to
get rid of year–old applications. Related to this, since applications are
retained for a year and the system operates whenever new jobs are
posted (this timing can’t be seen on DFDs), there is a need to have an
application data store inside the system (that is, on level–1 and lower
diagrams); some students will miss this essential element of the logical
system description.

Students could choose to further decompose the processes; if they do,

check that the decompositions are balanced and provide detail needed to
show separate processing steps and unique data flows and stores. Some
students also make mistakes by trying to use information in the Problem
and Exercise that is meaningless for drawing DFDs (for example, there
are 500 engineers of different types); this exercise is a good opportunity
to emphasize with your students that any given system model, like a
DFD, does not model all aspects of an organization, although these facts
are relevant (the fact that there are 500 engineers is relevant for physical
database design, for example).

Context Diagram

Interview

Appli
Engin

Job
Blank Descri
Non-
0

Hiring
Complete System Intervi
d ew

Appli Appli
 Hiring

Level-0 Diagram
Completed

Blank Non-

Valid Purge
1 Appli 5
Appli Recei
Purge
Appl ve
Applic Year-
Appli
cation
D ations old
Appli
1 cation
s
Year-old

Applicat
ions
3
Intervie Choos Applicat
e ions for
for
Intervi 6
Create
ew Emplo
yee
Appli Recor
New
d
Hiri
ng

Engi Job
Job D Descrip 4
Descr Evalua Employ
2 tions te D ees
2 Relev
Receiv ant and 3
e Hire
Job
Descri
ption Interview

Hiring

13. The sample context and level–0 data flow diagrams represent one
possible way to model the help desk process described in this question.
In our solution, we have chosen to include the processes performed by
the consultants and operators as subsystems within the system rather
than as sources/sinks; this adds detail, but allows bottlenecks in these
processes to be corrected. Note that data store D1 is repeated in the
level–0 diagram, to avoid excessive crossing of data flow lines. Several
processes could be exploded further, but the student would probably
have to make many assumptions to do so.
 There are a number of ways that the students could choose to improve
this system. For example, with the current system a customer may have
to explain their problem and/or question over and over to multiple
people: an operator and possibly several consultants. The customer may
begin to believe that they are getting the “run-around” characteristic of a
large bureaucracy. One way to avoid this potential problem is to let the
initial operator have access to the customer problem database so that
when the caller is handed off to a consultant the customer’s already
opened problem file will go along with them. In addition, the operator
could have sufficient information and the option to direct the call to the
proper consultant. Alternatively, clients could call the assigned consultant
directly on follow–up calls to an initial call for help.

Ask your students for characteristics of a DFD that imply areas for
improvement. Possible answers are: processes that simply collect and
pass on information rather than transforming data, collecting the same
information into several processes, placing untransformed data into data
stores thus causing unknown delays in processing this data, or cycles or
loops that have no apparent termination.

Context Diagram

Call

Inquiry on

0
Nature of Non-
Help Help
Client Call Report Desk
System Other
New

Interim

Final Call
Level-0 Diagram

Call New

1
Recei
Inquiry on Call Report # 9
ve Close
Call Nature Final Call Call
Report

Call
Call
D queue Closed
Infor 1 Call New
2 Help Infor
Deter Desk
mine Close
Direct 5
ion Deter 8
of 3 Previ mine Resear
Help Deter ch
Call ous Proble
Desk mine Proble
m
if First m
Status
Call
Cal
Non-
Help
First Open Pro
Call Call ble
4 Call
Create D report
Call
Report
2 file Ne
Other
Call w
Call
Report
D queue
6 1 7
Transf Recor
er Open Call
d
Call New
Probl
em Infor
matio
Interim n
14. A suggested answer is provided below.

Context Diagram

Prescrip 0
Drug
Hospit
Unfilled al
Docto
Pharma Store
cy
System Patient
Unfilled Number
Order

Level-0 Diagram

1
Revie
Prescrip w&
Doct Send
Prescr
iption
Unfilled
to
Statio Phar
Prescr n Patient
Unfilled macy D File
Order
1

2 Patie
Revie
w
Prescr
iption
Order
by
Statio Order
n Order

3
Fill
Order

Drug
Billi
4
Gener Patient
ate Number
Label

Drug Nurs
15. A suggested answer is provided below.

Context Diagram

0
Purchas Shipping
Contra
Gover cting
System Gover
Invoic
Invalid
Purchas

Level-0 Diagram

Purchas Contrac
1 t Terms
Verify
Gov
Purch
Contrac
ase Dt
Order
Invalid Validat 1 Databas
Purchas e

Validat

Comple
ted PO
Shippin
Inv 2
Check
Invent
ory

Validat

Not-
in-

3
Pull & Validated
Ship PO,
Items
from
Contra
Invent D cts
ory
Shipping 2 File
Bill for
16. A suggested answer is provided below.

Context Diagram

Seminar &
Reserv &
0 Negotia
Seating Info
Booki No. Negotia
tion
Contract
tion Sales
Trainin Info Mana
Agreeme
Info
g Contract ger
nt Info
Logisti Agreement
Possible cs Info
System
Approved

Travel
Availabil Flight
ity, Cost,
Availabil
Flight
ity, Cost,
Reser
Mtg Travel
Potent

Level-0 Diagram

Availabil
ity, Cost,
Mtg
Reserv &
1 Negotia
Seating Info
Arran Negotia
tion
Pote Contract
tion
ge Info
Availabil Agreeme
Info Sale
for Contract
ity, Cost, nt Info
Meeti Agreement
ng Info
Seminar & Facilit
Consultant ies
Boo
Me
No. etin
Seminar Mtg
Anticip g
2 Seminar
Possible
Make D logistics
Consu
Cons ltant Consultant 1 database
Apprvd Travel
Arran Flight
geme
Travel nts
Flight Trav
3 Reser
Deter
mine
&
Send Requ
Semin est
4 Semin
ar ar
Gathe
Mater
r, Box
ials Ship &
ment Send
Mater
ials to
Meeti
 y

Guidelines for Using the Field Questions

1. Because data flow diagrams are a popular tool, students are likely to find
analysts who are using them. Students are also likely to find that data
flow diagrams for real information systems are much larger and more
complex than those discussed in this chapter. This is likely to help
students see why data flow diagrams are so useful. Without them, it
would be difficult to make sense of large, complex business processes
and information systems. Students will also likely discover different
notations are in use than depicted in this text. Some systems analysts
may prefer object–oriented modeling rather than DFDs or may state that
their organization is reducing the use of DFDs in favor of entity–
relationship diagrams and other notations. It would also be interesting to
discover what type of drawing or CASE tool analysts use for developing
and maintaining DFDs.

2. Students are likely to have a difficult time constructing data flow

diagrams for a real business process and information system. As with
previous questions, there are a number of ways that students could draw
their data flow diagrams for the system under question. Students should
realize that there isn’t necessarily one “right” data flow diagram for this
or most other business processes. Even if the students have not had
much practice in constructing data flow diagrams, they can still construct
diagrams that will be interesting and useful to the people who have
developed or who are using and/or maintaining the system under
questions. Remind students to start with a context diagram and use
decomposition to create refined, focused diagrams of different
subsystems. It is difficult to draw DFDs also because it can be difficult to
get an unambiguous explanation from one or several people and
business documents about how a system works (or is supposed to work).
Real business situations are typically messy, and unequivocal
descriptions are not easy to obtain. This point is important for your
students to learn and reveals the value of reasonably precise notations
(models) such as DFDs.

3. Most CASE tools have capabilities for automatically checking for,

reporting on, and warning of rule violations in data flow diagrams. Many
of the CASE tools with graphical user interfaces let the user simply click
on a button to run various tests of the integrity of the diagrams. Some
CASE tools automatically do not allow a user to commit errors while
constructing the diagram. For example, the CASE tools will display an
error message in a pop–up window when a user makes a mistake, such as
attempting to place a data flow directly between two sources/sinks.

4. Students are likely to find that various other types of software packages
have elements in them that can be used to construct data flow diagrams.
For example, a drawing package might include data flow diagram
symbols (many flow charting packages, like ABC Flowcharter and Visio,
include DFD symbols). Alternatively, a database management package
might include some data dictionary features. However, none of these will
 be as effective and easy for constructing data flow diagrams as will a
CASE tool with features for this purpose. If students don’t believe this,
have them construct a simple data flow diagram using a drawing
package, and then have them move sources or processes around on the
screen. Chances are that the drawing package doesn’t automatically
move all the connected data flows while these objects are moved around
the screen. With a CASE tool, when an object is moved, its connecting
data flows move with it. Similarly, with a CASE tool you can often move to
a different, related data flow diagram by clicking on a button or by double
clicking on a particular process. Also, drawing packages do not know DFD
rules, so no automatic error checking can be done and decomposition is
not a function of the package. In addition, since a drawing package has
no repository, symbols on different diagrams probably cannot be linked
(e.g., when details on a higher–level diagram change, these are
automatically reflected on nested diagrams).

5. Students might find that these people draw their business process using
either a data flow diagram, a flow chart, a series of input/output models,
or some combination of these techniques. People will draw the diagram
using the techniques they are familiar with. If they are not familiar with
any techniques for modeling processes, then they will probably draw
pictures that represent physical reality (e.g., a piece of paper moving
from one person to another person, or a piece of paper moving from one
person to a file cabinet). For people who are not familiar with data flow
diagrams, the students should find that it is relatively easy to show them
that data flow diagrams are a better way to model processes. Chances
are that this person’s original picture already has many of the elements
of a standard data flow diagram anyway. Research has found that process
modeling is a very natural activity for most people, even when they are
not formally trained in this technique.

Guidelines for Using the Broadway Entertainment

Company Case
The BEC case associated with Chapter 8, Structuring System
Requirements: Process Modeling for the Customer Activity Tracking
System, illustrates how systems analysts can use process flow models to
clarify business processes and their information requirements. This case
highlights how process models can help an analyst identify inefficiencies and
potential problem areas in current business practices. This case also
introduces the CASE tool used at BEC—Designer/2000. Designer/2000 is a
commercial CASE tool available from Oracle.

This case shows how a systems analyst begins to structure information

collected during requirements determination into an unambiguous description
of current and desired systems. The case shows how imprecise requirements
statements can be, and how structured analysis tools, like DFDs, bring clarity
to one’s understanding of a system. As in other cases, the purpose of this
case is to help the student understand how techniques and tools are applied,
not simply the rules of certain models or the principles of information system
modeling. Thus, the case illustrates the interactive nature of requirements
determination and structuring, in which the structuring process leads to more
questions about the true nature of system requirements. To facilitate
discussion, ask your students the following questions.

1. Would the DFDs serve any benefit during the meeting with the store
managers? Why or why not?

2. How was the CASE tool beneficial to Frank?

3. Do you believe that any of the lowest level processes in Figures 2, 3, and
4 need to be further exploded, or are all of these primitive processes?

4. What impact does process modeling have on project planning? How

accurate do you think a Baseline Project Plan can be before detail process
modeling is done?

5. Based on the fax Frank sent Jordan, what kinds of questions should Jordan
ask the seven BEC store managers in the meeting she has scheduled?
Assume that this is a group interview, not seven individual interviews.
9
Structuring System Requirements: Logic
Modeling

Chapter Overview
The purpose of this chapter is to introduce students to three different
techniques that can be used to represent processing logic. Starting with the
data flow diagrams students learned about in Chapter 8, we proceed here to
show students how to represent the logic contained in the process symbols in
data flow diagrams. This chapter serves as a brief introduction to three
commonly used techniques for logic modeling. The instructor may want to
focus on one or two techniques and enlarge on the coverage presented here.

Structured English, decision tables, and decision trees are traditional methods
used to represent processing logic. We show how Structured English
statements are used to represent the basic constructs in structured
programming: sequence, choice, and repetition. We also provide some simple
examples using the Hoosier Burger inventory control system, as well as some
exercises at the end of the chapter. Some students may confuse Structured
English with the pseudocode they learned in their programming classes. We
explain the difference by pointing out that pseudocode is closer to code than
Structured English, and pseudocode must incorporate statements about
opening and closing files and initializing variables (and so on) that logic
statements in Structured English do not include. We see Structured English as
a tool to facilitate communication between analysts and users, while
pseudocode is a tool to facilitate communication between analysts and
programmers.

After Structured English, we turn to decision tables and decision trees, both
intended to represent more complicated processing logic than simple
Structured English statements. We provide two examples of creating and
simplifying decision tables, along with a set of rules to follow. We also provide
two simple decision tree examples, one of which models the same logic as
the “payroll” decision table example.

The chapter concludes with a section on how to decide among Structured

English, decision tables, and decision trees. This section is based on the
results of systems development research comparing the three techniques.

Instructional Objectives
Specific student learning objectives are included at the beginning of the
chapter. From an instructor's point of view, the objectives of this chapter are
to:

1. Show how Structured English can be used to model process logic.

2. Demonstrate how decision tables and decision trees can be used to

represent the logic of choice in conditional statements.

3. Discuss how students can select among Structured English, decision

tables, and decision trees for representing processing logic.

Classroom Ideas
1. Use Figures 9–2 and 9–3 to open your discussion of Structured English.
Have students complete Problems and Exercises 2, 3a, and 6 in class.

2. Work through both decision table examples contained in the text, using
Figures 9–4 and 9–5, then work through Figures 9–6 and 9–7. Have
students complete Problem and Exercise 3b in class.

3. Use Figures 9–8, 9–9, and 9–10 to illustrate the creation and navigation
of decision trees. Have students convert decision tables from other
exercises to decision trees.

4. Lead a class discussion of how to choose among Structured English,

decision tables, and decision trees. Use Tables 9–2 and 9–3 as a place to
start.

5. Divide the class into teams. Assign either Problem and Exercise 10, 11,
or 12 to the teams. Have some teams solve the assigned problem with
Structured English, others with decision tables, and others with decision
 trees. After giving the groups time to complete their tasks, have group
representatives present and explain their solutions. Ask those observing
to determine which solution works best for that particular problem and
why. End with a class discussion of what worked and what did not and
why.

Answers to Review Questions

1. Structured English is a modified form of the English language used to
specify the logic of information system processes. Although there is no
single standard, Structured English typically relies on action verbs and
noun phrases and contains no adjectives or adverbs. A decision table is a
matrix representation of the logic of a decision, which specifies the
possible conditions for the decision and the resulting actions. A decision
tree is a graphical representation of a decision situation in which decision
points (nodes) are connected together by arcs (one for each alternative on
a decision) and terminate in ovals (the action which is the result of all of
the decisions made on the path that leads to that oval). In a state–
transition diagram, an event is an occurrence that results in the
movement from one state to another. State refers to a mode or condition
of existence for a process or a system, as determined by current
circumstances.

2. The purpose of logic modeling is to show the rules that govern the
behavior of processes represented in data flow diagrams. Structured
English, decision tables, and decision trees all model decision logic. State
diagrams model temporal logic and are discussed in Chapter 12.

3. Structured English is a modified form of the English language used to

specify the logic of information system processes. Sequence is
represented by listing statements at the same level of indentation.
Conditional statements are represented by BEGIN IF/END IF statements
and by case statements. Repetition is represented by DO ... UNTIL and
DO…While statements.

4. Pseudocode is more like a programming language than is Structured

English. Pseudocode is used as a communication tool between analysts
and programmers, while Structured English is used as a communication
tool between analysts and users.

5. The steps for creating a decision table are: (1) name the conditions and
the values each condition can assume; (2) name all possible actions that
can occur; (3) list all possible rules; (4) define the actions for each rule; (5)
simplify the decision table. To reduce the size and complexity of a decision
table, use separate, linked decision tables, or use numbers that indicate
sequence rather than Xs where rules and action stubs intersect.
6. Decision trees are organized in a hierarchical fashion, starting with the
root node on the far left, and proceeding to subsequent decision nodes. All
possible actions are listed in leaf nodes on the far right.

7. You can use the tool you understand best and prefer; however, you
should also consider the appropriateness of the tool for the specific
situation. For example, some research shows decision trees are best for
determining the correct conditions and actions from a description of a
problem. Structured English was found to be best at converting conditions
and actions to sequential statements. Structured English is not as easy to
validate as decision tables and decision trees, however. Decision tables
are better than decision trees at portraying complex logic, are more
compact, and are easier to manipulate. Decision trees are better than
decision tables at portraying simple problems and at helping people make
decisions in practice.

8. Structured English uses action verbs, such as read, write, print, sort,
move, merge, add, subtract, multiply, and divide. Unlike regular English,
Structured English does not use adjectives or adverbs.

9. A limited entry in a decision table is where the value is either yes or

no.

10. To determine the number of rules a decision table must cover, simply
determine the number of values each condition may have and multiply
the number of values for each condition by the number of values for every
other condition.

Answers to Problems and Exercises

1.c rules b condition stubs
a action stubs d indifferent conditions

2.Students should realize that, as described in the chapter, each analyst will
have his or her own particular dialect of Structured English. There is no
standard version of it. There are many possible ways to represent with
Structured English the decision logic in the decision table of Figure 9–5.
One possible representation is provided below in a series of conditions.

BEGIN IF
IF Employee–Type is Salary
THEN PAY base salary
END IF
BEGIN IF
IF Employee–Type is Hourly
AND Hours–Worked is <40
THEN CALCULATE hourly wage AND PRODUCE Absence Report
END IF
BEGIN IF
 IF Employee–Type is Hourly
AND Hours–Worked is 40
THEN CALCULATE hourly wage
END IF
BEGIN IF
IF Employee–Type is Hourly
AND Hours–Worked is >40
THEN CALCULATE hourly wage AND CALCULATE overtime
END IF

3.One of the data flow diagrams from the Hoosier Burger example in the
previous chapter (see Figure 8–15) is reproduced in Figure 9-2. A
Structured English representation of the four processes is presented in
Figure 9-3. There may not be enough time to have students write
Structured English for each of the processes for each of the Hoosier
Burger data flow diagrams in the previous chapter. At a minimum the
students should understand the examples already given in this chapter
and write their own Structured English for one more piece of the data flow
diagrams from Hoosier Burgers. One such example is provided below for
the process, Query Inventory Levels, from the level–0 data flow diagram
for Hoosier Burger's new logical inventory control system, Figure 8–16.

Process 5.0: Query Inventory Levels

DO
ACCEPT Inventory–record–id
READ Inventory–record for Inventory–record–id
PRINT Quantity–in–stock and Inventory–item–name
UNTIL End–of–file

Figure 9–6 provides a decision table for Hoosier Burger's inventory

reordering. Provided below is a sample decision table for the relatively
simple process, Generate Payments.

Conditions/ Rules
Courses of Action 1 2 3
Due status L D N
Generate Rush Payment X
Generate Payment X
Postpone Payment X
Due status:
L = Late; Date of invoice is more than 30 days before today's date.
D = Due; Date of invoice is 30 days before today's date.
N = Not due: Date of invoice is less than 30 days before today's date.

4. Sample decision trees for Figures 9–6 and 9–7 are provided below. After
constructing these trees, students should be able to appreciate the
complexity of modeling logic, even for a problem with only three
variables. In addition, drawing the second tree shows graphically how
much easier it is to deal with the reduced decision table and tree.
 Problem and Exercise 4

A Standing daily order

S
3 Standing daily order, summer reduction
D H
Standing daily order, holiday reduction
2
A Standing weekend order
P W S
3 Standing weekend order, summer reduction
H
Standing weekend order, holiday reduction
1
A Minimum order quantity

3 S Minimum order quantity

N D H
Minimum order quantity
2
A Minimum order quantity

W 3 S Minimum order quantity

H
Minimum order quantity

1. What type of item is it? Perishable (P) or nonperishable (N).

2. What time of the week is it? Weekday (D) or weekend (W).
3. What season of the year is it? Academic (A), summer (S), or holiday (H).

Problem and Exercise 4

A Standing daily order

3 S Standing daily order, summer reduction

D H
Standing daily order, holiday reduction
2
A Standing weekend order
P W S
3 Standing weekend order, summer reduction
H
Standing weekend order, holiday reduction
1
N
Minimum daily order

1. What type of item is it? Perishable (P) or nonperishable (N).

2. What time of the week is it? Weekday (D) or weekend (W).
3. What season of the year is it? Academic (A), summer (S), or holiday (H).
5. A good place to begin for the analyst would be to start with the processes
represented in the data flow diagrams. Basically, the analyst wants to
elicit information from users that will help the analyst model the logic
within these processes and the events (discrete or passage of time) that
initiate each process. The analyst is trying to get at the process decision
and temporal logic involved in the users' business processes. The analyst
could ask users to literally describe what happens in each of the processes
on the data flow diagrams. When does the process occur? What are the
explicit steps? How and by whom are they performed? In what sequence
and at what time are they performed? Are there any conditions,
constraints, or contingencies on any of these steps happening? If so, what
are they and how do they happen? Additionally, if these are current
processes, the analyst could observe the actual processes happening to
see if this fits with what users are describing.

6. One way to represent the purchase process described in this question

with Structured English is provided below. The students may come up with
different versions depending on their form of Structured English and their
assumptions about this purchasing process. Notice the similarities
between the Bid Process and the Rebid Process in this logic; your students
may find a way to reduce the number of statements in this logic due to
these similarities.

BEGIN IF
IF Purchase–amount is greater than $15,000.00
THEN Purchasing–Department APPROVES RFP
DO Bid Process
ELSE Purchasing–Department APPROVES Purchase
PURCHASE equipment
END IF
RETURN
(Bid Process)
SEND RFP
BEGIN IF
IF three Proposals received
AND Winning–Vendor is APPROVED by Purchasing–Department
AND no Violations
THEN AWARD contract
PURCHASE equipment
ELSE DO Rebid Process
END IF
RETURN
 (Rebid Process)
SEND RFP
BEGIN IF
IF Winning–Vendor is APPROVED by Purchasing–Department
AND no Violations
THEN AWARD contract
PURCHASE equipment
END IF
ISSUE Purchase Order
RETURN

7.A computer–based tool that helped people to create and edit Structured
English logic models might have a library of “generic” business processes
already described. Users could then choose a corresponding process and
quickly and easily edit it so that it fits with their situation. Such a tool
might also have a library of common logic, such as IF/THEN and/or
DO/UNTIL structures, that could be called up and edited to fit the
situation. In addition, this tool might have common commands (such as
DO and BEGIN IF) and verbs (such as read, write, print, sort, move, merge,
add, subtract, multiple, and divide) ready to choose from either a menu or
as buttons.

8. Presented below is a sample decision table and decision tree for some
aspects (exclusive of the bidding process) of the answer presented to
Problem and Exercise 6 above. The decision table and decision tree
express the same information; one expresses the information in tabular
form while the other expresses the information in graphical form. For this
situation, where there are several, nested, complicated conditions, the
Structured English presented in the answer to Problem and Exercise 6 may
be more useful than one table or tree (although several tables may be
suitable).

Conditions/ Rules
Courses of Action 1 2 3 4
Purchase amount G L G L
Vendor Approved Y Y N N
Award Contract to Winning Vendor X
Issue Purchase Order X X
Purchase equipment X X
Award Contract to Other Appr Vendor X
Find another Approved Vendor X
Purchase amount: G = greater than $15,000.00, L = less than or equal
to $15,000.00
Vendor Approved: Y = Yes; approved by Purchasing Department
N = No; not approved by Purchasing Department

Problem and Exercise 8

1. Is purchase greater than $15,000?
2. Is the vendor approved by Purchasing Department?

Award contract to winning vendor, issue

Y purchase order, purchase equipment
2
N
Y
Award contract to other approved vendor

1
Y Issue purchase order, purchase equipment
N
2
N
Find another approved vendor
9. A computer–based tool that helped people to create and edit decision
table and decision tree logic models might have a library of “generic”
tables and trees available. Users could then choose a table or tree and use
it as a template with which to fill in their information. Alternatively, the
tool might have the user build their decision table, and then the tool
would automatically convert the table into a tree, and visa versa. The tool
would also automatically check for errors of completeness and
consistency. Interestingly, a tool, called ADDS was developed as early as
the 1960s by NCR Corp. to generate, print, and check for errors in decision
tables. A decision table or tree tool would be just as useful as one built for
making Structured English logic models; both tools would, much like a
CASE tool, automate systems development tasks.

10.Provided below is one way to represent the sales process described in this
question with Structured English. The students may come up with different
versions depending on their form of Structured English and their
assumptions about this sales process. In fact, there are many aspects of
the problem that are ambiguous and creating structured logic models
helps the analyst find ambiguities. You will want to emphasize to your
students this interaction between requirements structuring and
requirements determination.

The Structured English has two routines, one for handling each purchase
and one for determining end–of–year bonuses. The method for calculating
base rep end–of–year bonus is not specified, so only a general statement
is included. These models assume that Customer Satisfaction is measured
on a 5–point scale and all customer ratings are averaged to arrive at one
number between 1 and 5 for a rep’s customer service rating. Ratings of 4
or 5 increase the bonus, and ratings of 1 or 2 lower the bonus; we include
some sample percentages for increasing and decreasing the bonus under
these circumstances. We have also included some sample logic for how
the annual bonus is decreased if purchases are less than orders, but the
exact logic would have to be determined from more analysis since
specifics are not included in the exercise.

Also presented is a sample decision table corresponding to the Structured

English purchase–routine. Since there are four limited entry conditions,
there would be 16 rules in one, complete decision table. To save space, we
have combined three separate, 16–rule condensed tables into one. The
first section of rules addresses whether to reduce the purchase amount for
large cumulative sales; the second section shows the logic for calculating
commission; and the third section indicates when a bonus is due. We
present the table in this way to show students that they can adapt the
basic decision table notation in creative ways to depict, in very compact
form, some complicated logic. Note that each section covers all 16 rules
due to indifferent responses to some conditions; we use numbers in the
action portion of each section to show the sequence in which actions
should be performed.

An accompanying decision tree represents the combined logic of the

second and third sections of this decision table. Note in the decision tree
that a NO answer to the first condition implies that the answer to the
second condition must be YES, so a branch of the tree is eliminated.

(purchase–routine)
BEGIN IF
IF customer–annual–purchases greater than $100,000
THEN SUBTRACT (.1 X purchase–amount) from purchase–amount
END IF
ADD purchase–amount to customer–annual–purchases
ADD purchase–amount to rep–sales
BEGIN IF
IF purchase within rep–region AND purchase is not a shared–sale
THEN ADD ((.10) X purchase–amount) to rep–commission
END IF
BEGIN IF
IF purchase within rep–region AND purchase is a shared–sale
THEN ADD ((.08) X purchase–amount) to rep–commission
END IF
BEGIN IF
If purchase not within rep–region
THEN ADD ((.02) X purchase–amount) to rep–commission
END IF
 BEGIN IF
IF rep-sales equal to or greater than rep–sales–goal
THEN ADD 5% of purchase–amount to rep–commission
END IF
(rep–bonus)
BEGIN IF
IF rep–sales equal to or greater than rep–sales–goal
THEN GRANT family vacation
END IF
CALCULATE rep–bonus based on rep–sales
BEGIN IF
IF customer–satisfaction–rating equal to or greater than 4
THEN INCREASE rep–bonus by (customer–satisfaction–rating
multiplied by (.01))
END IF
BEGIN IF
If customer–satisfaction–rating equal to or less than 2
THEN DECREASE rep–bonus by ((customer–satisfaction–rating
multiplied by
(.01)) minus .1) multiplied by 2)
END IF
BEGIN IF
IF rep–amount–of–orders is equal to or greater than 125% of rep–
sales
THEN DECREASE rep–bonus by rep–amount–of–overage
END IF
PAY rep–commission plus rep–bonus
 Conditions/ Rules
Sections <1> <––2––> <3>
Courses of Action 1 2 3 4 5 6
7
Customer–annual–purchases >$100,000 Y N – – – –
–
Purchase within rep region – – Y Y N –
–
Shared Sale – – N Y – –
–
Rep–sales => rep–sales–goal – – – – – Y
N
Subtract 10% from purchase–amount 1
Add purchase–amount to customer–annual–purchases 2 2
2
Add purchase–amount to rep–sales 3 3 3
Add 10% of purchase–amount to rep–commission 4
Add 8% of purchase–amount to rep–commission 4
Add 2% of purchase–amount to rep–commission
4
Add 5% of purchase–amount to rep–commission
5

Problem and Exercise 10

1. Is sale in home region?
2. Is sale shared?
3. Is Rep-sales => Rep-sales-goal?
Y Pay 13% commission

Y 3
Pay 8% commission
N
2
Y Pay 15% commission

N 3
Pay 10% commission
N
1
Y Pay 7% commission

2 3
Pay 2% commission
N

11. This problem narrative describes a process of handling information rather

than a decision process, so logic modeling would not be as useful as
process modeling. This exercise emphasizes for the student the different
 purposes for the different forms of requirements structuring models.
Presented below is one way to use Structured English to represent a
typical tenure review process as described in this question. The students
may come up with different versions depending on their form of
Structured English and their assumptions about the tenure process.

For this answer it was assumed that all possible levels would participate
in the review. Also presented are a sample decision table and
corresponding decision tree for one piece of this process, the decision
whether a faculty member should go up for tenure (the first BEGIN IF
block in the Structured English code). Each of these models is useful in its
own way. The Structured English model helps you see the “line by line”
logic that will later translate into code. The table and tree help you to see
particular pieces of the logic that are difficult to decipher from the lines of
text with the Structured English approach.

BEGIN IF
IF faculty-member length-of-service equals 6 years
OR IF faculty-member has permission-for-early-tenure
THEN faculty-member SUBMITS tenure-packet
END IF
DO
department committee REVIEW packet
department chair REVIEW packet
school/college committee REVIEW packet
associate dean REVIEW packet
dean REVIEW packet
university-wide faculty committee REVIEW packet
provost REVIEW packet
president REVIEW packet
(review process — same for each type of review)
DO
EVALUATE research-accomplishments
EVALUATE teaching-performance
EVALUATE service-contributions
MAKE AND WRITE recommendation/decision

Conditions/ Rules
Courses of Action 1 2 3 4
Length of Service S N S N
Special Permission Y Y N N
Go up for tenure X X X
Postpone tenure review X

Length of Service: S = sufficient; at least six years of service,

N = not sufficient: fewer than six years of service.
Special Permission: Y = yes; special permission of come up for tenure
review.
N = no; no special permission.
 Problem and Exercise 11
1. Appropriate length of service? Sufficient (S) or not sufficient (N).
2. Special permission to come up for tenure?

Y Go up for tenure

S 2
Go up for tenure
N
1
Y Go up for tenure

N 2
Postpone tenure review
N

12.Presented below is one way to use Structured English to represent the

hardware and software assignment process as described in this question.
The students may come up with different versions depending on their
form of Structured English and their assumptions about the tenure
process. For example, the rules for additional hardware and software are
imprecise in the description. Also presented is a sample decision table; a
corresponding decision tree for one piece of this process is included in a
separate figure. As discussed in previous answers, each of these models is
useful in its own way. The Structured English model helps you to see the
“line by line” logic that will later translate into code. The table and tree
help you to see particular pieces of the logic that are hard to decipher
from the lines of text with the Structured English approach.

BEGIN IF
IF user-status equals light
OR IF user-status equals moderate AND user has
approval-for-standard
THEN ISSUE standard-hardware-complement
END IF
BEGIN IF
IF user-status equals heavy
 OR IF user-status equals moderate AND user has
approval-for-upgrade
THEN ISSUE upgrade-hardware-complement
END IF
BEGIN IF
IF user-status equals mobile
THEN ISSUE mobile-hardware-complement
END IF
BEGIN IF
IF user-hardware-needs equal special
THEN ISSUE additional-hardware
END IF
BEGIN IF
IF user-software-needs equal special
THEN ISSUE special-software complement
ELSE ISSUE standard-software-complement
END IF

Conditions/ Rules
Courses of Action 1 2 3 4 5 6 7 8
User Status L L H M O L H M O
Special Approvals S S S S U U U U

Standard Complement X X X
Upgrade Complement X X X
Mobile Complement X X
User Status: L = light; H = heavy; M = moderate; O = mobile
Special Approvals: S = standard; approval for standard complement
U = upgrade; approval for upgrade complement

Problem and Exercise 12

1. What is the user’s status? Light (L), heavy (H), moderate (M), or mobile (O).
2. What special approvals do they have? Standard (S) or upgrade (U).

S Standard complement
2
U Standard complement

S Upgrade complement
2
U Upgrade complement
1
S Standard complement
2
U Upgrade complement

S Mobile complement
2
U Mobile complement
13.A suggested answer for this question is provided below.

Y Take 2 Major
Classes & 1
1 Elective

Take 1 Major
N Classes & 1
Elective

1. Able to register for both

Physics (P) & Physics Lab (PL)?
2. Able to register for English Comp (EC)?
3. Able to register for COBOL (C)?
4. Able to register for Music Appreciation (MA)?

Register for
R = Replacement Class(es)
P, PL, EC, C
4 Y & MA
Register for
N P, PL, EC, C
Y & 1 R for
Y Register
4 P, PL, EC,
Y 3 MA & 1 R
Register for
N Y P, PL, EC, &
Y 4 N 2Register
R for
2 P, PL, C,
Register forMA
Y 3 P,&PL,
1 RC, &
Y N Register for
N 4 P,2 PL,
R MA &
1 2R
N Registerfor
Register for
Y Y N P, PL, &
EC, C, MA 3R
Y
N 2 4 &2R
3 Register for
N EC, C, & 3 R
Y Register for
N 4
N EC, MA & 3
Y Register for
R
N EC & 4 Rfor
Y Register
3
4 C, MA & 3
R
Register for
N C & 4 R
N Y Register for
4
MA & 4 R
N Register for
RR
14.A suggested answer is provided below.

1. Master of MIS program?

2. MBA program?
3. Located in the southeast?
4. Top 10 program in country?
5. At least 1 well-known faculty member?
6. Financial Aid available?
7. Scholarship awarded?

Appl
6
y
7 Appl
Y y
Y Do
Not
Appl
Appl
N
6 yy
Y N
Appl
Y 7
Y y
3 Do
Y
4
N Not
Do
Appl
N yNot
N Appl
N Y Appl
y
Y 6 y
Y Appl
Y Y 5 7 y
N Do
3 Not
1
N N
Do
Appl
yNot
Y Appl
Appl
Y N Y 6
N yy
Y 5 Y Appl
N 7
2 4
N y
N Do
N Not
N Do
Appl
Not
y
Do
Appl
Not
y
Do
Appl
Not
y
Appl
y
15.A suggested answer is provided below.

1. Application loan amount < $2,000?

2. Application loan amount  $2,000 and  $200,000
3. Car, mortgage, or other type of loan?
4. Employment income verified?
5. Loan amount requested exceed cost of attendance?
6. Loan amount request < $35,000?
7. Credit rating good or excellent?
8. Credit rating fair?
9. Does applicant have account at bank?

Ap
pro
Y Y ve
Ap
7 9 pro
Y
ve
De
N 8 ny
De
Y Ap
ny
N pro
7 YN Ap
ve
Y pro
ve
8 De
N ny
Y 4
Y Ap
GetYadd'l N pro
N applic info &Y Ap
ve
Y
1 forward to VP pro
Y ve
7 8
3 De
Y Y Ap
ny
N pro
N N 6
ve
N
N De
2
7 ny
De
N
5 N
ny
N

Forward
to VP
Guidelines for Using the Field Exercises
1. To order a cap and gown a student typically begins by giving her name,
address, phone number, payment, and payment information. She then
must either give or be measured for cap and gown sizes. Next, the
student must indicate her area of study so that a corresponding color for
the cap tassel can be ordered. Some areas of study and their
corresponding colors are: agriculture is maize, economics is copper,
medicine is green, arts is white, teaching is white, science is golden
yellow, architecture is violet, business administration is drab, engineering
is orange, fine arts is brown, forestry is russet, music is pink, and public
administration is peacock blue. The sleeves on the gown are also
different for the different degrees conferred. Bachelor candidate gowns
have long pointed sleeves, master candidate gowns have long, closed
sleeves that are open at the wrists, and doctoral candidate gowns have
round, bell–shaped sleeves and velvet about the neck and on chevrons
on the sleeves. In addition, the hoods worn are different. Bachelor
candidates wear either a small hood or none at all, master candidates
wear hoods of moderate length, and doctoral candidates wear a full hood.
These hoods also have colors that are significant. The hoods are lined
with the colors of the college or university, and the hoods are trimmed
with the color of graduate’s area of study. Presented below is some
sample Structured English for pieces of a cap and gown ordering process.
The advantage of using Structured English here versus using decision
tables or decision trees is that a lot of information and logic can be
summarized succinctly in these models. Structured English can more
easily be converted into useable code, and identifiable modules of logic
are easily created.

DO
GET customer-information
GET cap-size
GET gown-size
BEGIN IF
IF customer is bachelor-candidate
THEN ISSUE cap
ISSUE bachelor-gown
ISSUE tassel
END IF
BEGIN IF
IF customer is master-candidate
THEN ISSUE cap
ISSUE master-gown
ISSUE tassel
ISSUE master-hood
ELSE ISSUE cap
ISSUE doctoral-gown
ISSUE tassel
ISSUE doctoral-hood
END IF
 BEGIN IF
IF area-of-study is economics
THEN color-of-tassel AND color-of-hood-lining is copper
END IF
BEGIN IF
IF area-of-study is teaching
THEN color-of-tassel AND color-of-hood-lining is white
END IF
BEGIN IF
IF area-of-study is business administration
THEN color-of-tassel AND color-of-hood-lining is drab
END IF
BEGIN IF
IF area-of-study is engineering
THEN color-of-tassel AND color-of-hood-lining is orange
END IF

2. The English language is vast, rich, and complex. There are any number of
ways that a thought or idea can be expressed. Thus, it is difficult to
represent process logic with regular written English in a way that is
simple, consistent, and will convey the exact, unambiguous meaning to
everyone who reads it. The Structured English approach provides a
relatively small, truncated version of English that is tailored to
representing procedure and action, is more easily and consistently
understood by people, and can easily be converted to code.

3.As described in Martin, DeHayes, Hoffer, and Perkins, 1994, Managing

Information Technology: What Managers Need to Know, Macmillan
Publishing, one of the most significant events in programming over the
past forty years was the movement toward structured programming,
particularly for third-generation, or procedural programming languages,
and fourth–generation, or English–like programming languages. Structured
programs are divided into modules, where each module has only one
entry point and only one exit point. In structured programs the logic is
easy to follow and understand. Thus, program maintenance and correction
are easier than for nonstructured programs. In addition, when changing
nonstructured programs there are often unforeseen effects on other parts
of the program, which has been described as ripple effect. In a structured
program the system logic is placed in a set of control modules at the top
of the program structure. Then each function that the program performs is
isolated into a self–contained module that is called by these control
modules. Thus, changes within a module do not have ripple effects on the
rest of the program. Also, structured programming uses a limited set of
basic logical structures to simplify the logic of the program to make it
easier to understand. Elements of structured programming now pervade
nearly every aspect of third–generation, fourth–generation, object–
oriented, and event–driven programming languages.
4. In a shopping mall a variety of sales transactions occur in a variety of
ways. Each one of the techniques discussed in this chapter—Structured
English, decision tables, decision trees, and state–transition diagrams—
could be useful to help model the logic of these sales transactions. Which
technique is used depends on the scale and scope of the transactions,
which aspects of the mall operation you want to depict, and on the skills
and tastes of the users and systems personnel involved.

Guidelines for Using the Broadway Entertainment

Company Case
The BEC case associated with Chapter 9, Structuring System
Requirements: Logic Modeling for the Customer Activity Tracking
System, illustrates how information collected during an interview might be
structured for representing the decision logic in a new information system.
This case illustrates and compares a decision table and a decision tree
representation for the same logic.

This case is a straightforward description of the application of logic modeling.

It can, however, be used to stimulate some interesting class discussion about
the interaction between logic modeling and requirements determination.
Students often do not understand how interactive requirements
determination and structuring are. Also, before they do requirements
structuring, they may not appreciate the types of questions an analyst needs
to ask during requirements determination in order to have all the information
needed to unambiguously model decision and timing logic. Some possible
discussion questions are the following:

1. Where did Frank Napier find the information he needed to develop the
decision logic models shown in this case? Where else might he look to
extend and validate his work?

2. What are the relationships between data flow diagrams and logic models
such as decision tables and trees? How does an analyst use these
different models to cross–check each?

3. Was it really necessary for Frank to develop both Figures 2 and 3? Do you
think that different types of errors in representing decision logic could be
identified using one or the other of these types of decision models, and if
so, what types of errors might more likely be found using each type of
decision model?
10
Structuring System Requirements:
Conceptual Data Modeling

Chapter Overview
The purpose of this chapter is to present a detailed description of the
techniques used to structure the data requirements for an information system
application. The chapter emphasizes entity–relationship (E–R) diagramming,
the most common notation used by practicing systems and data analysts.
The chapter explains how E–R diagramming is used along with process and
logic modeling techniques to develop a thorough, unambiguous description of
system requirements. In addition to the standard constructs of the E–R model
(entities, attributes, and relationships), we also describe the data–oriented
questions that should be raised during requirements determination so that an
analyst can do data modeling. The chapter also introduces the modeling of
business rules for entity integrity, referential integrity, domains, and
triggering operations using both E–R diagrams and textual constraint
statements.

Instructional Objectives
Specific student learning objectives are included in the beginning of the
chapter. From an instructor’s point of view, the objectives of this chapter are
to:

1. Emphasize the importance of understanding organizational data and

convince your students that unless they can represent the data
requirements of an application unambiguously in logical terms, they
cannot implement a system that will effectively serve the needs of
management.

2. Present the E–R model as a conceptual data model that can be used to
capture the structure and much (although not all) of the semantics (or
meaning) of data in several front–end stages of the systems development
process.

3. Show students how data, process, and logic models all represent data
requirements, but that conceptual data models (such as an E–R diagram)
provide a more thorough and stable representation of data than do other
types of system structures.

4. Show students, via an example from Hoosier Burger, how to match data
requirements from data, process, and logic system models. This example
emphasizes the differences between data stores and data entities, yet
shows how to reconcile process and data models to be sure each covers
all data requirements (while each represents different semantics about
data).

Classroom Ideas
1. This chapter was written to be read following Chapters 8 and 9 on
process and logic modeling, respectively. Many instructors, however,
want to emphasize data modeling by having students study data
modeling first among requirements structuring methods. If you wish to do
this, you can tell students to skip reading the section “An Example of
Conceptual Data Modeling at Hoosier Burger,” which is the only section of
this chapter that is tightly linked to the preceding chapters. You can then
have students read this section after reading Chapters 8 and 9.

2. This chapter covers a topic also addressed in most database

management courses. Depending on your curriculum, this chapter may
review previously covered material or may be covered (in more depth) in
a subsequent course. We believe that conceptual data modeling is not
strictly a database topic, but is essential for thorough systems analysis,
thus it is an activity that should not be assigned to only specialists
(database analysts). Although we strongly encourage you to cover this
chapter in your SA&D course, you should coordinate how you address this
topic with those who teach database courses. This chapter is carefully
written for the systems analysis and design student. First, data modeling
is presented as a step of the larger systems development process.
Second, questions to ask users and to investigate via other requirements
 determination techniques are introduced, again placing data modeling
within the whole systems development effort. Finally, the wording is less
technical, and the breadth and depth of coverage has been reduced to
make the material more accessible to those who do not have an
extensive database background. We believe that this chapter is an
excellent refresher for those who have already studied E–R modeling and
will provide a solid introduction to E–R modeling for those students who
will address this topic later in a database course.

3. This is a very detailed chapter, and there are many concepts as well as
notations to cover. We suggest that you devote at least two lecture
periods to this chapter, and if possible schedule a third session that you
devote entirely to working sample exercises with your students.

4. It is important to review with students how central a role data modeling

and data design play in systems development. You should discuss Figure
10–2 with your students and show examples of the types of data models,
designs, and code developed in each phase of the systems development
process. Discuss who in the organization is typically most involved in
each of the phases and how end users may best participate in the
process.

5. It is important that systems analysts learn what questions to ask during

requirements determination. Learning what questions to ask comes from
the experience of developing structured statements and models, like E–R
models, of requirements. A good in–class exercise to emphasize what
information needs to be collected during requirements determination to
do data modeling is Problem and Exercise 13. Have your students work in
pairs and have one student role play the manager of Pine Valley
Furniture’s order entry department and the other student role play a
systems analyst. Give the students about 10 minutes to prepare for the
interview and about 15–20 minutes to conduct the interview. Have each
team within the class period or afterwards develop an E–R diagram based
on the interview answers. Have different pairs present their results and
discuss in class why the data models differ between teams. This exercise
emphasizes the importance of careful interviewing and the need to be
impertinent by seeking out detailed business rules at every point in the
interview.

6. Introduce the notation that is used in the chapter for E–R diagrams
(Figure 10–5). Give an example (and then have students give examples)
for each of the constructs shown in the figure.

7. Contrast the terms “entity type” and “entity instance.” Discuss other
examples, such as STUDENT (with each student in the classroom as an
instance). Warn the students that the term “entity” is often used either
way, with the meaning intended to come from the context in which it is
used.
 8. Discuss the representation of multivalued attributes and repeating groups
in E–R diagrams and give some examples. If students are familiar with
programming languages that support arrays and other data structures of
repeating data, use this understanding to emphasize the need to
separate conceptual from physical data modeling.

9. Discuss relationships and their different degrees (Figure 10–6). Have your
students develop additional examples (we find that students can be quite
creative with this type of exercise when paired up in class!).

10. Introduce the concept and notation of cardinalities in relationships (Figure

10-8). Again, have your students develop additional examples.

11. As a general suggestion, you should show (develop step–by–step) many

examples of small (two to three entities) and larger (eight to ten entities)
E–R diagrams in class. Develop these from your own personal experience.
Three approaches work well, and mixing these is best. One approach is to
give students descriptions of an organization and have them identify
entities, attributes, and relationships (with degrees and cardinalities). You
can do this as a group exercise, asking for volunteers or calling on
students in class. The second approach is to show E–R diagrams and ask
factual and interpretive questions about the business depicted in the
diagram (such as, how many faculty advisors might a student have, or
would all universities have only one department associated with each
course and why). Yet a third approach is to pair students and have one
student in the pair develop an E–R diagram for an exercise you give
them, and then have the other student in the pair read the diagram to
see if it agrees with the description. Once each pair of students develops
a diagram both are satisfied with, have several teams present their
diagrams to the class and discuss differences. You can also have students
bring in copies of computer system forms and reports and develop E–R
models for each. Some of the Problems and Exercises at the end of the
chapter can be used for such in–class practice problems; see especially
Problems and Exercises 2, 6, 9, 10, 11, 16, and 22. If you have part–time
students, or students with prior work experience, several of the Field
Exercises also make excellent class discussions.

12. Unary and ternary relationships can be especially difficult for some
students. Present several examples of each (for unary, for example, a
hierarchical organization structure, or the relationships between
geographical areas or governmental territories; for ternary, for example,
a faculty member advising students about majors, or a customer buying
products through different sales channels).

13. If you have the time, an exciting way for students to better appreciate
conceptual data modeling is to listen to a guest speaker who has
developed an enterprise data model for a local organization. Students are
usually amazed by how many entities and relationships exist in any
reasonably–sized organization (several dozen entities and relationships
are common, and models with a hundred entities exist). Such a guest can
 usually discuss the difficulties in developing this data model,
misunderstandings people had or controversies that existed before the
data model was developed, how the data model is being used to guide
the development of many new or redesigned systems, and the
administrative effort necessary to maintain such a data model (as well as
many other topics).

14. We have discovered that students who study process modeling before
data modeling often have some special difficulties with this chapter. First,
students may try to include entities for the sources and sinks for the
process model. You must emphasize with your students that data entities
have to be described by attributes, and each instance must have a
primary key. Further, there will usually be multiple instances. For
example, in a data model for a retail store, a student might include the
store or the store’s manager as a data entity. Such concepts do not
satisfy the definition of a data entity. Second, students may try to use
relationships to represent data flows rather than structural associations
between entities. This often occurs when students try to model system
outputs as entities. For example, some students will create an entity for a
major system report (say a monthly sales summary report), and then
show a relationship between the customer entity and the report. You
should emphasize that although copies of the report may be kept on file,
system outputs are derived from other data; these data are used to
produce any of the system outputs, and hence the outputs are
redundant.

Answers to Review Questions

1.The term “entity type” refers to a collection of entities that share common
properties or characteristics. A business rule is a specification that
preserves the integrity of a conceptual or logical data model; four
types of business rules are commonly recognized: entity integrity,
referential integrity, domains, and triggering operations. An instance is
a single occurrence of an entity type. An identifier is a candidate key
that has been selected as the unique, identifying characteristic for an
entity type. A relationship is an association between the instances of
one or more entity types that is of interest to the organization.
Minimum cardinality specifies the minimum number of instances that
one entity will have in an association with another entity. An attributive
entity, also called a weak entity, contains attributes that repeat for
each instance of some other entity; an attributive entity is the result of
representing multivalued attributes in a separate entity. An associative
entity, or gerund, is an entity type that associates the instances of one
or more entity types and contains attributes that are peculiar to the
relationship between those entity instances. An attribute is a
characteristic of an entity that is of interest to the organization. Degree
is the number of entity types that participate in a relationship. A
trigger is an assertion or rule that governs the validity of data
manipulation operations such as insert, update, and delete.
2. Some systems developers believe that a data model is one of the most
important parts of the statement of information system requirements
for three reasons: (1) completely representing data requirements is
crucial for the design of databases, programs, computer screens, and
printed reports—critical elements of any information system; (2) data
rather than processes are the most complex aspects of many
information systems, and hence must be modeled with clarity; (3) data
characteristics and natural structures (as opposed to processing
requirements) are reasonably permanent, so designing information
systems based on data yields more stable systems with longer lives
(and less maintenance).

3. Data modeling performed during information systems planning tends

to be less detailed than in the phases of the development of a system.
Further, a data model prepared during planning covers many systems,
but usually shows only entities and relationships, not attributes, and an
entity in a planning data model may represent several entities and
relationships in other data models. The purpose of data modeling
during project initiation and planning is to show the scope of the
proposed system in terms of data requirements. Entities, attributes,
and relationships represented are only those needed for the application
under study. Data modeling during the analysis phase adds details and
validates the earlier project data model, since systems analysts have
now thoroughly studied specific information requirements. Thus, the
resulting data model is usually more extensive, including more entities,
attributes, or relationships, than earlier data models.

4. Data stores, data flows, and even processes all provide information for
data modeling. A data store often represents one or more data entities
and their associated attributes. All data in data flows must either be
stored in some entity, be computed from data in entities, or in rare
circumstances pass through the system. The description of a process
can shed light on business rules that must be represented in the data
model.

5. Although many CASE tools do not support representing ternary

relationships but rather force the analysts to represent the ternary
relationship as three binary relationships, this enforced representation
is not semantically correct. A ternary relationship represents the
simultaneous association of three entities (such as a selling
relationship links a customer with a product and salesperson), not
three binary relationships (between a sale entity/gerund and customer,
sale and product, and sale and salesperson). When representing a
ternary relationship as three binary relationships, you make the
minimum cardinality 1 for each of the three entities in their
relationships with the gerund (such as, for each sale there is exactly
one customer and exactly one salesperson and at least one product),
but the maximum cardinality can be 1, many, or a specific value.
 6. A many–to–many relationship must be modeled as an associative
entity when there are attributes associated with the relationship.

7. A triggering operation business rule governs the validity of data for

insertion, update, and deletion operations on an entity. A triggering
rule controls the integrity of data when data maintenance events
occur. The rule states what condition must be true when the data
maintenance event occurs, and what action is to be taken under this
condition.

8. One–to–one and many–to–many relationships (gerunds) may have

attributes. For example, a one-to-one unary relationship between
employees, Married to, may have a Date Married attribute, and a
many-to-many binary relationship between students and courses,
Takes, may have a Grade attribute.

9. An important linkage is that each describes, in different ways, the data

requirements of an information system; these different descriptions
must be consistent. For example, rules in a decision table may
correspond to business rules in a data model; attributes in data flows
must be stored in or generated from attributes of data entities;
different states on a state–transition diagram correspond to different
values for an attribute, which may then define a domain business rule
for that attribute.

10. The degree of a relationship indicates the number of entity types

participating in a relationship. The three most common relationships
are unary, binary, and ternary. An employee working for a department
is an example of a binary relationship. A part composed of other parts
is an example of a unary relationship. A customer placing an order with
a salesperson is an example of a ternary relationship.

11. An example of a ternary relationship might be that of a car service. A

particular driver and car might be assigned to a particular client.

12. The primary deliverable for the conceptual modeling part of analysis is
an E-R diagram, showing the major categories of data and the business
relationships between them. A full set of entries about data objects to
be stored in the project repository is also produced.

13. Minimum cardinality refers to the minimum number of instances of

entity B that can be associated with entity A. If the minimum
cardinality of B is one, then entity B is a mandatory participant in the
relationship. However, if the minimum cardinality for entity B can be
zero, then entity B can be thought of as an optional participant in the
relationship.

14. An identifier that meets the criteria set forth in the chapter would be
an ideal choice. The criteria include: (1) choosing an attribute that will
not change its value over the life of each entity type, (2) choosing an
 attribute that for each instance of the entity will have valid values and
will not be null, (3) avoiding intelligent key usage, and (4) substituting
surrogate keys for large composite keys.

15. E-R diagrams are produced (1) to cover just the data needed in the
project’s application; (2) for the application system being replaced; (3)
to document the entire database from which the new application’s data
is extracted; and (4) for the whole database from which data for the
application being replaced is drawn.

Answers to Problems and Exercises

1. e entity type c many–to–many relationship d gerund
b alias a domain

2. This is a version of a bill–of–materials structure in which components

are different entities from products, but raw materials are considered
components. The exercise also indicates a minimum cardinality of
three for the number of components composing a product, but no such
restriction is placed on components as part of other components.
Gerunds are used for the many–to–many relationships since quantity
attributes are indicated. Unique attribute names have been used even
though the exercise text involved homonyms. The following E–R
diagram depicts this situation.

Problem and Exercise 2

C_Description

Component No
Product No Unit of Measure

COMPRISED 3
PRODUCT COMPONENT
OF

Cost
C_Quantity
P_Description

G_Quantity GOES INTO

3. One interpretation of this exercise is not as complicated as the
situation involving products at Pine Valley Furniture. In its simplest
terms, there are two prices implied in this exercise: the price at the
time of a transaction and the current price. This simply means two
different price attributes, one associated with the transaction gerund
and one associated with the stock entity. The following E–R diagram
depicts this situation (we have included only a few attributes to clarify
this example).

Problem and Exercise 3

CUSTOMER Ticker Code

Current Price

BROKER TRANSACTION STOCK

Order No T_Price

Date No of Shares

4. Many CASE tools already have facilities to help people create and edit
E–R diagrams. Users can use the mouse to select drawing tools, such
as for drawing entity symbols, from a tool palette and draw symbols
with a click and drag of the mouse. Some tools also let users link the
elements of the E–R diagram directly with elements of a data
repository and other parts of the CASE tool. Such a tool might also
have a library of “generic” diagrams and relationships for common
business processes (e.g., order entry, manufacturing company,
personnel management). Users could then choose the diagrams for a
corresponding process and quickly and easily edit them so that they fit
with the situation. A data modeling CASE tool might also be able to
translate verbal descriptions of business rules into semantically rich
data models. Such a feature would allow more direct translation from
requirements determination to requirements structuring. Also, an E–R
tool should be seamlessly integrated with other requirements
structuring tools, so that all dimensions (data structure, data
 movement, processing logic, and timing of events) of the same object
can be nonredundantly and consistently modeled.

5. This exercise defines two entities—Training Program and Training

Module—with a one–to–many relationship (Composed of) between
them, and a unary optional (since some modules don’t have a
prerequisite, and some modules are not a prerequisite to other
modules) many–to–many relationship (Is Prerequisite for) on the
Training Module entity.

6. This exercise defines two entities—ADVISOR and STUDENT— and two

relationships—Is Assigned Advisor and Registers—between ADVISOR
and STUDENT. An advisor is assigned to zero to many students, and a
student is assigned to exactly one advisor; an advisor registers zero to
many students, and a student is registered by exactly one advisor. An
important rule in the exercise is that the data model covers only “the
current term,” so no historical records need to be kept. As an
alternative, it is also possible to create a data model with the above
two entities and a ROLE gerund in between, where ROLE has an
attribute of ROLE PLAYED (which could take on values of ‘Advises,’
‘Advises and Registers,’ and ‘Registers’). Then, we would create a
relationship between the entities through the gerund such that an
advisor is associated with zero to many students, and a student is
associated with one or two advisors. The problem with this alternative
is clarifying on only the data model what combination of ROLE PLAYED
values are permitted for a given student.

7. Since Part_Number and Drawing_Number will most likely have unique

values for each entity instance; these attributes are candidate keys.
Part_Number is a logical choice for the identifier. Since a part number
is unique, is a single-attribute, and will not be null, these features
make it a good candidate.

8. The identifier is a combination of Employee_ID and Course_Name. If an

employee is permitted to take the course multiple times, then the
identifier is no longer unique. Therefore, another identifier will need to
be specified. The new identifier could be a combination of
Employee_ID, Course_Name, and Date. Students will also specify other
identifiers for this situation.

9. An employee can work on one-to-many projects; the Includes

relationship is a binary relationship. No associative entities are directly
shown by the associative entity or gerund symbol. The only many–to–
many relationship, Works On, has no attributes, so it does not need to
be shown as an associative entity. The SKILL attribute could also be
modeled as an attributive or weak entity. It is not possible for the
Includes relationship to have attributes since it is a one–to–many
relationship. Only one–to–one and many–to–many relationships are
allowed to have attributes. TASK could be modeled as a gerund since it
falls at the intersection of mandatory binary relationships between
 PROJECT, TOOL, and CITY, depending on the meaning of task. As
currently modeled, TASK is something done on a project with a tool at a
city, so it is not an independent concept. TASK can be modeled as an
entity since it has its own primary key independent of the keys of
PROJECT, CITY, and TOOL. Some semantic information would be lost if
TASK were modeled as a gerund (e.g., the minimum cardinalities
related to task on the Includes, Done at, and Used on relationships).

10. Following is one possible set of relationship cardinalities for Figure 10–
18.

Places: A customer places zero to many orders, and an order is

for exactly one customer.
Generates: An order generates zero to one backorder, and a
backorder is for exactly one Order.
Includes: An order includes one to many products, and a product is
included on zero to many orders.
Comprised of: A product is comprised of one to many
components, and a component goes into making one to
many products.
Supplied by: A component is supplied by zero to many vendors
(we make some components), and a vendor supplies one
to many components.

11. Each of the four statements in the exercise yields a new entity and
relationship with an entity in Figure 10–18.

(1) The assignment of customers to sales representatives adds a

SALES REP entity and an Assigned to relationship such that a sales
rep is assigned to one to many customers, and a customer is
assigned to zero (the statement does not say all customers are
assigned a sales representative) or one Sales Reps (a sales
representative gets a unique set of customers).

(2) From our experience, the statement in this exercise that causes
the most difficulty is the one about customers becoming
“members” with unique benefits. The debatable term is “unique.”
We suggest that “unique” means that only members, not other
customers, receive those benefits. Then the following
representation would be reasonable: Create a BENEFIT entity and a
many–to–many Receives relationship between BENEFIT and
CUSTOMER such that a customer receives zero (not all customers
are members) to many benefits (each benefit is recorded as a
separate instance of the BENEFIT entity), and a benefit is received
by zero (on a transient basis, nobody may hold a given benefit) to
many customers (this also allows different members to receive
different benefits). Again, this statement points out how much
more precise an E–R model is than is a requirements, narrative
statement.
 (3) The creation of manufacturing teams adds a TEAM entity (the
exercise does not say we need to know what employees are on a
team) and a Produces relationship such that a team produces one
to many products, and a product is produced by exactly one team
(teams get unique sets of products, and some team has to produce
each product).

(4) The assignment of purchasing agents to vendors is analogous to

the situation in (1), so we create an AGENT entity and a
relationship such that an agent is responsible for one to many
vendors, and a vendor is under the responsibility of zero or one
agents.

12. Student answers will vary depending on the document they find. Each
of the types of documents mentioned generally involve three or four
entities or gerunds, with a gerund representing the many–to–many
relationship between two of the other entities. Also, each of these
documents have master entity or header data and detail or line item
data. The following figure, showing data found on a typical customer
sales receipt, is representative of each of these three situations. Since
the gerund LINE ITEM does not have a specific attribute for its primary
key, we show the primary key as the concatenation of the primary keys
from the associated entities, which is typical of gerunds. Since
normalization is not done until logical data modeling (see Chapter 16),
students may combine some entities. For example, in the following
figure, it is permissible to combine the CUSTOMER attributes into the
CUSTOMER RECEIPT entity.

13. This is, of course, a very open–ended question. An actual interview

dialogue could be quite long and would vary depending upon the
particular order entry function. The following is an excerpt from a
representative interview script. This excerpt illustrates the types of
initial questions and probing questions that might arise as an analyst
attempts to understand the data required to support order entry.
Bolded terms indicate data modeling requirements. You might want to
suggest to your students that they create a script that includes
questions from all eight of the areas covered in Table 10–1 so that they
practice exploring all the dimensions of data modeling.

Question: What basic operations are performed in order entry?

Answer: Order entry concerns the creation and maintenance of data
about customer orders.

Question: What do you know about a customer order?

Answer: We know the date, our order number, the customer’s P.O.
number, and promised delivery date of the order itself, and the
name, ship–to address, bill–to address, customer number, and
phone number of the customer, plus the product number,
quantity ordered, color ordered (if applicable), and description of
 every item on the order. (So, there are customer, customer
order, product, and order line item entities.)

Question: Does a customer have the same ship–to and bill–to

address for every order she places?
Answer: No, the ship–to address can vary by order, but the bill–to
address is always the same for each of our customers. Some
customers have many stores to which we ship furniture. If we
have a customer, like Fred’s Furniture, which has different
purchasing offices where invoices are to be sent for different
regions of the country, we will consider each office a separate
customer for billing purposes. (Thus, ship–to address is a
characteristic of the customer order, whereas bill–to
address is a characteristic of the customer.)

Question: What distinguishes one customer from another customer?

Answer: We assign each customer a unique customer number.

Question: Must a customer have a customer number before you

start to keep track of them?
Answer: Yes, but often we don’t know some of the other data about a
customer, like the bill–to address. (So, nulls are not
permitted for customer number, but other customer and
order data can be null.)

Question: What is the format of a customer number?

Answer: A customer number is six digits long. (This is useful
information to clarify what an attribute is and is
necessary information for later physical file and database
design steps.)

Question: Are there any restrictions on when an order can be

promised?
Answer: Yes, the promised delivery date has to be no sooner than one
day after the date of the order and cannot be more than three
months after the order date. (So, there are integrity rules on
promised delivery date.)

Question: How long do you retain data about customer orders?

Answer: We need to retain order data for seven years after the order is
paid. (So, it is likely that many customers will have many
associated orders.)

Question: Do you keep information about customers that have never

ordered from you or who have not ordered for more than seven
years?
Answer: Yes, we do receive data about prospective customers, and we
want to keep track of all the customers we’ve ever had. (So,
the minimum cardinality is 0.)
 Question: Are customers grouped or categorized in any way?
Answer: Yes, we group customers by regions of the country or by foreign
country (which we consider separate regions), and we have a
sales manager responsible for each region.

Question: Can a sales manager be responsible for more than one

region and must a region have only one manager?
Answer: Yes. (So, there is a one–to–many relationship between
sales manager and region, and then a one–to–many
relationship from region to customer.)

Question: Can a sales manager be responsible for a customer order

outside her region?
Answer: Yes, either because she initiates that order or because she
changes regions after the order is placed.

Question: Do you want to keep track of these out of region orders

for sales managers?
Answer: Yes, since sales managers are paid partially based upon
commissions. We need to distinguish and track both the sales
manager of the region in which the customer resides as well as
the sales manager who initiated the sale. (So, there will need
to be relationships from customer order to customer to
region to sales manager as well as a relationship directly
from customer order to sales manager.)

14. This is actually a fairly complex situation. For the exercise here, we
take the statement literally that a reservation is a ternary relationship
(a gerund if it has associated data) between the three listed entities.
We assume that a flight means a flight on a particular day, hence flight
has a composite primary key. Thus, a seat on a flight may have a
passenger. A passenger must have some seat on one or many flights.
A passenger will have exactly one seat on a given flight. The following
E–R diagram depicts this situation.

15. The answer to Problem and Exercise 14 is a commonly encountered

example of a ternary relationship. Other examples are:

 television programming: the ternary relationship between a TV

show, a date/time slot, and a channel.
 shipping: the ternary relationship between a product, a carrier, and a
ship–to location

 class scheduling at a multi–campus university: the ternary

relationship between a course, an instructor, and a campus

A difficult issue with a ternary relationship is determining the

cardinalities along each edge of the relationship. Be sure students can
argue the logic of the cardinalities they choose.
 16. A vessel holds potentially many consignments, and a consignment is
on at most one vessel, which probably means that Holds tracks the
consignments currently held on a vessel (and the vessel, if any, which
currently holds a consignment). A vessel goes on potentially many
voyages, but a voyage involves only one vessel. The Transports
relationship says that a consignment is transported on zero to many
voyages (which may involve the same or different vessels––who
knows), and a voyage transports zero to many consignments. Given
that a consignment might be on many voyages, and even though each
voyage involves exactly one vessel, we don’t know from just Transports
and Goes on which vessel a consignment is currently on (there are no
attributes from which to infer this). Thus, it would appear that we need
all three relationships.

17. A suggested answer is provided on the next page.

18. A suggested answer is provided on a following page.

19. A suggested answer is provided on a following page.

 Street_ City
Address

Name State
CUS
TOM
ER
Plac
Custom Zip
es
er_No
ORD
ER
Incl
udes

PRO
DUC
T Order_
Date
Order_
No
Promise
_Date

Quantit
y
Descrip
tion
Product
_No
Unit_Pr
ice
FE #18, Part A:
Offer_Date,
Offer_Price
Offer_Name

Propert PRO
y_No

FE #18, Part B:
Offer_
Propert Offer_ Date Offer_P
y_No No rice
Offer_
PRO OFF Name
PER ER
TY

FE #18, Part C:

Offer_
Date

Propert Offer_ Offer_P

y_No No rice

PRO

OFF

Buyer_
No

POT
 Name

Phone_
No

Address

FE #19, Part A:

Is_
Marr Date_M
ied_t arried
o

FE #19, Part B:

Marr
ied Date_M
arried

20. One suggested answer for a domain integrity rule follows. Ask students
if limits should be placed on the range of this attribute. Why or Why
not? For the triggering operation, an assumption is made that when an
account is first opened the initial balance cannot be less than $100.00.

Domain Definition:

Name: Balance
Meaning: Balance of the Customer’s Account
Data Type: Numeric
Format: 2 decimal Places
 Uniqueness: Nonunique
Null support: Non-null

Triggering Operation:

User Rule: Initial ACCOUNT Balance is equal to or greater than $100.00

Event: Insert
Entity name: ACCOUNT
Condition: Initial Deposit < required starting ACCOUNT Balance
Action: Reject the insert transaction

21. The text and figures of Problems and Exercises 10 and 11 do not tell us
much about the processes and logic underlying these data and
relationships. We do know that there will be data stores on the DFDs
for the associated business situation that contain the same attributes
as contained on the E–R diagram. These E–R diagrams do, however,
tell us a bit about the business rules that apply. For example, we know
that each sales representative is assigned to a small, unique set of
customers, that some customers are “members,” which entitles them
to special benefits, and so on. These are all statements that would
have been collected during requirements determination and would be
listed as business rules. There would be processing step where, for
example, customers would be assigned their benefits, but the process
description for the associated processing steps would not show the
rules which govern the assignment of benefits to customers. A decision
table might outline these rules, the result of which is the determination
of which benefits a member receives.

While the E–R diagrams tell us much about the data, relationships
among data, and the relevant business rules, the process models
(DFDs) and the logic models (Structured English, decision tables, and
decision trees) from previous chapters tell us more about the business
process and the flow of data. Obviously, we need to know about the
data, the relationships, the business rules, and the business processes
in order do develop a good system. Thus, the various modeling
techniques are complementary. If either data or logic modeling
techniques were done poorly (or not done at all) the resulting system
would suffer. For example, if data modeling were left out, the business
process would be understood well but the implementation of the
databases would likely be flawed. The system would probably provide
information to the right person at the right time, but the information
would be useless. Conversely, if logic modeling techniques were done
poorly, the databases might be implemented well, but they wouldn’t
be doing anyone much good.

22. This is one of the more complex exercises since there are many
entities and relationships and some complicated business rules. We
assume that a case worker may not have been assigned a purchase
request yet, and that some vendors, who only bid on the large
purchase requests, are not approved to supply commonly purchased
products and services. We assume that a purchase request is for
exactly one product or service. We also assume that a purchase
request is tracked before bids start to come in. Finally, we assume that
to be recognized as a customer, the “customer” must have submitted
at least one purchase request. The E–R diagram can be more explicit
(than we show below) if generalization modeling techniques are used.
Without supertype and subtype relationships, we are forced to use a
TYPE attribute on the PURCHASE REQUEST entity; we would have to
write detailed business rules that indicate that large purchase requests
require bids, whereas small requests do not. It also appears from the
text of the exercise that only small purchase requests are associated
with products and services, which would necessitate a business rule to
elaborate on the E–R diagram. An E–R diagram, using just the concepts
discussed in Chapter 10 and including a few attributes, follows.
Problem and Exercise 22

REP APPROVAL DATE PURCHASE APPROVAL DATE

P/S ID
P.O. NO DATE ISSUED

Wants to Buy
Submits PURCHASE PRODUCT/
CUSTOMER
Is Submitted by REQUEST Is Bought on SERVICE
Has Approved
Has Assigned Awarded to Supplier
EMPL ID
Is Approved
to Supply
Is Awarded to

CASE
BID VENDOR
WORKER Is Assigned to

EMPL ID DATE RECEIVED VENDOR ID

Guidelines for Using the Field Exercises
1. Students are likely to come up with a number of E–R diagrams for a
variety of work settings. If they focus their answer on a situation that
mirrors one discussed in the book (e.g., order entry), or if several
students focus on the same situation in different organizations, it will
be useful for them to compare their answers. This will show them the
different business rules used across organizations for these same
activities and the robustness and applicability of the E–R diagramming
technique. Alternatively, they could build on their own educational
experiences and the education examples provided in this chapter and
draw an E–R diagram for a situation at their school.

2. The students should find that the E–R diagramming technique is fairly
robust and applicable across a variety of situations. There should be
little or no difference in using the technique for service– versus
product–oriented organizations. Similarly, there should be little or no
differences in using the technique for public, private, or governmental
organizations. The students may find that governmental organizations
are a bit more rule–bound than are non–governmental organizations,
and so there may be more and stricter rules that apply to data. Other
than this, the only major differences found should be in the various
ways that data happen to be stored and used in these organizations.
This is not likely to be based on the “type” of organization, but on the
choices made for managing data and business processes. Some more
detailed and dedicated students may find that the E–R model needs
more semantic richness or some extended constructs. Business rules
provide one useful extension. As an alternative, you might suggest that
students read about the object–oriented database model; some people
believe that the OO data model is richer than the E–R model, and your
students will certainly find many similarities.

3. Students are likely to discover that conceptual data modeling is

handled in a variety of ways. Some larger organizations, with relatively
large systems staff, will offer formal training in conceptual data
modeling, and they will have formal conceptual data modeling as a
fixed part of the analysis phase. This activity might even be performed
by systems personnel with the explicit title of “modeler,” “data
modeler or analyst,” or “conceptual data modeler.” In other
organizations, conceptual data modeling might be done less formally,
probably by an “analyst” who performs this and many other functions
throughout the SDLC. In other organizations, particularly those where
the systems are relatively small and simple, there may be no true
conceptual data modeling done; that is, systems are implemented
without a thoughtful design of a conceptual database for the
organization.

4. If the students find analysts who have experience with conceptual data
modeling, then these analysts are likely to be able to come up with
examples for all three relationships. The analysts’ experiences with
 each type of relationship will vary depending on their amount and level
of experience with modeling and the relatively complexity of the
systems they help to develop and maintain.

5. Students are likely to find that where E-R diagrams are being used the
systems personnel are probably using CASE tools to create and edit
them. Many of these CASE tools have been discussed throughout this
book. CASE tools with E–R diagramming features are very effective for
the creation and manipulation of good E–R diagrams and the linking of
E–R diagram elements to other information within the CASE tool and
system. For those people that are drawing E–R diagrams by hand,
perhaps they do not know of or haven’t yet found the proper
automated tool for doing so. Even with the limitations of CASE tools to
draw advanced E–R features (such as ternary relationships), advanced
features can be simulated and useful, approximate data models (albeit
imprecise for generating code) can be created.

6. There are several different standards for ER diagramming. The Peter

Chen method uses diamonds for the relationships, while the James
Martin version uses no symbols for relationships but instead calls for
the relationship to be written near each entity box in the relationship.
There are also different ways to represent minimum and maximum
cardinality. In addition, some CASE tools use their own slightly
modified, non-standard notation. So, whatever the student is able to
get from a systems analyst will probably be different from what is in
the book, even if only slightly. The best way to find and analyze the
differences is to do a point-by-point comparison.

7: The answer is similar to that for FE 6 in that the details of the diagram
will depend on the ER diagramming method being used. The bill-of-
materials ER diagram will also be more specific as it will pertain to a
specific assembly or subassembly.

Guidelines for Using the Broadway Entertainment

Company Case
The BEC case associated with Chapter 10, Structuring System
Requirements: Conceptual Data Modeling for the Customer Activity
Tracking System, illustrates how a conceptual data model is developed.
This case reviews the thought processes used and the questions asked when
a systems analyst translates system requirements into the precise
description found in an E–R data model. The case also illustrates how a data
model evolves during a project, as the team develops a better understanding
of the data requirements and the meaning of data. In addition, the case
shows how an E–R model can be translated into words and a list of model
contents by a CASE tool.

The case contains primarily dialogue between a data analyst and two
systems analysts as the data analyst and one of the system analysts explain
their joint work to the second systems analyst. In this dialogue the analysts
discuss the use of the CASE repository and its querying capabilities, the
linkages between an E–R model and other requirements structuring
documentation (such as decision tables, data flow diagrams, and state–
transition diagrams), and standards for drawing E–R diagrams. The case
reads like a mini–structured walkthrough, so your students might develop
some sense for how to conduct a walkthrough from reading this case. The
case also teases out some physical database design issues, and emphasizes
by example how conceptual, logical, and physical database design issues are
kept as much separate from one another as possible during systems
development. Overall, the case emphasizes the importance of being
impertinent when doing data modeling, and the need to have an intimate
understanding of the rules by which the business operates in order to make
the data model and associated repository entries semantically rich.

This case is not very complex and does not contain any conflict since the
conceptual data model is not very complicated. For many multi–user, multi–
department systems, a conceptual data model can contain several dozen
entities and possibly a hundred relationships. Even with its relative simplicity,
this case can, however, be used to stimulate some interesting class
discussion about the necessary impertinence of analysts involved in data
modeling. Thus, we recommend that you take some time in class, probably
after you lecture on Chapter 7, to discuss some questions based on this case.
Some possible discussion questions are the following:

1. The case discusses a “keyword search capability in the CASE tool.” How
do you think Buffy and Jorge used this capability? What contents of the
repository were they searching? What difficulties might they encounter in
doing a keyword search? How could they overcome such difficulties?

2. On page 381 of the case, the business rule is given that a video customer
transaction can link a product with a particular video. Do Buffy and Jorge
have any other choices on how to model this association without violating
the business rule (currently, they chose to link the customer transaction
and the product profile)?

3. On page 385, Buffy argues for the separation of conceptual, logical, and
physical data modeling. Do you accept her argument? Why or why not?

4. Again on page 385, Frank suggests that a repository entry needs to be

made to remind those individuals doing physical database design of
some of the issues uncovered during conceptual design. Write this
repository entry. To what object or objects in the repository would you
attach this note?

5. What are some examples of business rules not shown on the E–R diagram
or stated in Figure 3 that should be written to fully document the data
model for CATS?
 6. What are the pros and cons of including attributes on an E–R diagram
versus separately in only a repository report?

7. What do you think the ‘uid’ next to some of the attributes in Figure 3
signifies?

8. In what ways is the E–R diagramming notation in Figure 2 different from

the notation described in the chapter? Are these differences important?
Why or why not?

11
Selecting the Best Alternative Design
Strategy

Chapter Overview
This chapter has three primary purposes: (1) to show students that all of the
software associated with a systems development project is not developed in–
house; (2) to emphasize that analysts should consider several design
strategies before choosing the one to pursue for further development in
design; and (3) to return to and update the Baseline Project Plan first
developed during project initiation and planning (Chapter 6). A secondary
purpose is to emphasize to students that the consideration of a packaged
software solution should be done after the analysis efforts are complete, not
as a substitute for analysis.

More than half of this chapter is devoted to a presentation of various sources

of software and the reasoning that should be followed to choose among the
many options available to an analysis team for developing design strategies.
The point we are trying to emphasize here is that the make vs. buy decision
is not a choice of one or the other, but is in reality a spectrum of choices
ranging from make at one end and buy at the other. Just as important, more
choices these days are made toward the buy end of the scale. We also
include a discussion of outsourcing, an option for systems development and
management that may not occur to many students in their first systems
development course.

When discussing design strategies (which we define as “a high–level

statement about the approach to developing an information system, which
includes statements on the system’s functionality, hardware and system
software platform, and method for acquisition”), we revisit the Hoosier Burger
inventory control system. Our goal here is to show how, given their system
objectives and constraints, Hoosier Burger might develop a series of design
strategies for their new system. We present a weighted multi–criteria decision
making matrix as one way to compare design strategies side–by–side and to
choose one alternative for further development. There are other decision-
making strategies that can be used to decide among design strategies, and
instructors may want to demonstrate them to their students. Some systems
development texts present design strategy generation and choice as the first
activity in the design phase of the systems development life cycle. To us, it
made more sense to close analysis with design strategy selection so that all
of the design phase is devoted to an already identified and management–
approved design strategy.

Finally, we revisit and update the Baseline Project Plan from Chapter 6.
Updating an entire Baseline Project Plan is beyond the scope of this chapter,
so instead we list the sections of the Plan that would be updated and show
how more accurate information can be used to update both the cost benefit
analysis and the project schedule. The BPP needs to be updated at this point
since the end of the analysis phase typically is a project milestone, often with
review by those that must approve continuation of funding for the project.

Instructional Objectives
Specific student learning objectives are included at the beginning of the
chapter. From an instructor’s point of view, the objectives of this chapter are
to:

1. Show students that in–house developed systems are not the only source
for software.

2. Teach students how to assemble the various pieces of an alternative

design strategy.

3. Demonstrate how to generate three alternative design strategies for an

information system, focusing on what should and should not be part of
the strategy at this stage and why.
4. Show students at least one way to choose among design strategy
alternatives.

Classroom Ideas
1. Use Figure 11–2 and an updated version of the same information from the
most recent Datamation 100 survey to begin a discussion of the many,
varied sources of software in the marketplace. Datamation also publishes
data for the international market as well as the U.S. market, so such data
can be used as the starting point for a discussion of the international
computer software market.

2. Use Table 11–4 to summarize a discussion of alternative sources for

software and how to choose among them for specific software needs. This
can also serve as the basis for a discussion of the make vs. buy decision
and can be expanded to include the “not invented here” syndrome.

3. Emphasize the concept of a design strategy with your students. Our

experience indicates that this is a relatively difficult concept for many
students to grasp. Their first inclination is to think of a strategy as simply
a set of system functional requirements, and that different strategies are
many, moderate, and few (basic) functions. Certainly, this is one
component of a design strategy, but point out that operational platform
and acquisition source are also choices that must be made to set the
direction for design efforts.

4. Have students research the proper format and contents for Requests for
Proposal and have them create and/or present RFPs for a specific design
strategy (see Problem and Exercise 3). RFP preparation should include
discussion of the hardware, software, and organizational issues discussed
in the chapter.

5. Work through the Hoosier Burger example in class, including creating the
multi–criteria decision matrix. Expand on student understanding of this
comparison technique by introducing changes in Hoosier Burger’s
objectives and constraints and showing how these changes affect the
matrix and maybe the final choice. Or give students another example,
with objectives, constraints, and some design strategy options, having
them generate alternative strategies and the corresponding matrix (such
as Problems and Exercises 10 and 11).

6. Using the Hoosier Burger multi–criteria decision matrix (Figure 11–6),

show how changes in existing weights and ratings affect the alternative
strategy scores and the final choice. Lead a class discussion on how all of
these numbers are generated and what they really mean. Ask students
about how they think management will actually use the numbers
provided in the matrix. For example, what happens if management really
supports one of the design strategies that was not chosen as optimal?
7. In class, compare and contrast the Hoosier Burger multi–criteria decision
matrix with other decision-making techniques (such as elimination by
aspects, allocating points out of some total, or ranking). Have students
judge when each technique is preferable to others and why. Discuss the
concept of mandatory, essential, and desirable features or criteria.
Discuss how to apply these three kinds of features/criteria under different
multi–criteria decision-making techniques.

8. In class, work through the Baseline Project Plan and the changes in it
discussed in the chapter, using Figures 11–7 through 11–11 and Tables
11–5 and 11–6. Have students make some of the specific changes that
are discussed more abstractly in the text. Discuss with students the
reasoning behind a Baseline Project Plan and the purpose it serves. (Also
see Problem and Exercise 8.)

Answers to Review Questions

1. Outsourcing is the practice of turning over responsibility of some to all of
an organization’s information systems applications and operations to an
outside firm. A request for proposal is a formal document that provides
detailed specifications about a target information system and asks
vendors for information on how they would develop or provide the
system. A design strategy is a high–level statement about the approach
to developing an information system. It includes statements on the
system’s functionality, hardware and system software platform, and
method for acquisition. A turnkey system is an application system,
usually including both hardware and software, where customization of the
system is limited if available at all. A custom software producer is a
company that works with client companies to produce customized
systems to deal with specific client needs. The client may lack the
personnel or the expertise to develop the system in–house. In deciding on
a vendor, vendor support refers to whether and how much support the
vendor can provide. Support occurs in the form of assistance to install the
software, to train user and systems staff on the software, and provide
help as problems arise after installation. A Baseline Project Plan is a
project management plan, which includes a preliminary description of the
system as requested, an assessment of the feasibility (including schedule
feasibility) or justification for the system (the business case), and an
overview of management issues for the system and project. This plan is
presented to a steering committee or other body who approves the
commitment of funds to conduct the project.

2. The deliverables from generating alternatives and selecting the best

one include: (1) identifying at least three substantively different system
design strategies for building the replacement information system; (2)
choosing the design strategy judged most likely to lead to the most
desirable information system; (3) preparing (updating) a Baseline Project
Plan for turning the most likely design strategy into a working information
system.
3. Analysts generate three alternatives because three alternatives can
neatly represent both ends and the middle of a continuum of potential
solutions.

4. Five sources of software were identified in the text. These include

hardware manufacturers, packaged software producers, custom software
producers, enterprise-wide solutions, and in–house developers. Hardware
manufacturers are among the world’s leading software producers, but the
software they make is limited mostly to operating systems and utilities. In
contrast, packaged software producers develop all kinds of software for
all kinds of markets. Custom software producers, sometimes called
consulting firms, develop specific, customized software that matches a
client’s particular needs. Enterprise solutions consist of a series of
integrated modules; these modules are integrated to focus on business
processes rather than on business functional areas. In–house
development requires the resources, especially trained staff, to develop
software targeted to an organization’s own specific needs.

5. To decide what off–the–shelf software to buy, compare products and

vendors. Use the following criteria (among others that may be more
situation–specific): cost, functionality, vendor support, viability of vendor,
flexibility, documentation, response time, and ease of installation.

6. The issues analysts consider when trying to determine if new hardware

or system software are necessary focus on whether a particular design
strategy can be run on existing hardware and systems software
platforms. Advantages of running the target system on existing platforms
include lower costs, familiarity, ease of integration, and few or limited
data conversion costs. On the other hand, parts of the target system may
require specific platforms, and new platforms allow for substantial
upgrading. An RFP is a formal document that provides detailed
specifications about a target information system and asks vendors for
information on how they would develop the system. Analysts use RFPs as
a way to get vendors to perform the necessary research into specific
design strategies and the hardware and systems software vendors
believe are necessary for developing the new system.

7. Other than hardware and software, issues analysts must consider

include implementation issues (such as changes in work relationships,
training, and disruptions in work procedures) and organizational issues
(such as cost of implementation, determining what management will
support, and whether users will accept the new system).

8. Analysts consider many issues in developing alternative solutions to

information system problems. Of particular interest are the system
owner’s and users’ prioritized system objectives and system (and
development) constraints. Analysts consider which design strategies
would minimally satisfy objectives and not violate constraints, on the one
hand, as well as which design strategies would meet or exceed objectives
 with minimal violation of constraints. There are many possible design
strategies between these two extreme positions.

9. While alternative design strategies may be compared in many different

reasonably objective ways (we feature but one in this chapter), the actual
design strategy chosen by management will depend on what
management’s true objectives are for a particular development project.
Management may ignore constraints, or alternatively, choose the least
expensive system to develop, regardless of which design strategy
appeared to be the best in the objective comparison.

10. Every section of the Baseline Project Plan is updated during the
alternative generation and selection step of analysis.

11. To verify vendor claims about a software package, an analyst can ask
for a software demonstration, use the software (and its documentation
and training materials) personally, talk with other users of the software,
and consult independent software testing and abstracting services
(surveys available for a fee).

12. Enterprise solutions consist of a series of integrated modules; these

modules pertain to specific, traditional business functions. However,
these modules are integrated to focus on business processes rather than
on business functional areas. Enterprise solution advantages include a
single repository of data for all aspects of a business process, flexible
modules, less maintenance, more consistent and accurate data, and ease
of adding and integrating new modules into the existing system. Possible
disadvantages of this approach include complexity, lengthy
implementation, lack of in-house expertise, expense, and changing how
the organization conducts its business.

Answers to Problems and Exercises

1. d alternative generation and selection b requirements determination
c requirements structuring a design strategy

2. The software industry continues to be a high-growth, dynamic sector of

the economy. Thus, the students are likely to find changes in the more
recent rankings. Microsoft continues to grow and increase its dominance.
There have also been some recent mergers, which will affect the
rankings. We see changes in the rankings as companies sell more or less
software. Some software vendors have done a good job of forecasting
market needs and then producing and selling good products to meet
those needs. Two examples of this are Microsoft, with its Windows-based
products, and Lotus, with Notes and its bevy of other applications. In
general, foreign competition into the U.S. market has had minimal effects
on the software industry. Many market analysts consider Oracle, Sybase,
Borland, and Novell to be prime targets for mergers and acquisitions,
which could significantly change their relative market positions. Longer
 term, the definition of a software company is likely to become cloudy
since the computer software and entertainment industries are becoming
indistinguishable.

3. The request for proposal (RFP) is used when the organization wants to
solicit proposals from several competing vendors. RFPs usually first give
some background information on the company and the business units
involved in the request, an explanation of the information systems needs,
a description of what is wanted from the vendors (i.e., what information
they must provide or other actions they must take), and an explanation of
any rules or procedures for the RFP and system development process.
The bulk of the document then describes the mandatory, essential, and
desirable requirements in the areas of need (e.g., functionality, hardware,
software, and service). Students’ RFP outlines should include these key
features.

4. In the first accompanying spreadsheet, the weights have been

changed to reflect a weighting that represents systems development
projects in the governmental agencies. In these settings, a great deal of
weight is given to the costs and time frame of the system being
proposed. As often happens in governmental agencies, by weighting
costs and timing more heavily in this example the outcome has changed.
Alternative A and Alternative C have traded places; Alternative A now has
the highest score. By changing the weighting, we may have just traded
the more technically proficient solution for the more cost effective (at
least in terms of “short term” costs).

The second accompanying spreadsheet reflects changes in the ratings of

Alternative B. With slight improvements in the ratings for this alternative,
it now has the highest score. This shows how important the ratings can
be and how subtle changes and/or biases in ratings can have significant
impacts on the final outcome.

The third spreadsheet has the additional criteria of “references” and “in
use.” “References” are written references from other organizations
currently using the vendor’s systems. “In use” means that the technology
proposed must have been in use by a paying customer for 6 months.
These are very common criteria for organizations that value stability of
the vendor and technology over performance and having state-of-the-art
technology. These additional criteria change the outcomes; Alternative B
now has the highest score. These changes appear to have caused the
more stable vendor (i.e., the vendor with the better references and the
track record for using the technology it has proposed) to be chosen over
the vendor who scored higher on other performance indicators.

First
Spreadsheet
(Government Agencies)
 Weig
Criteria Alt A Alt B Alt C
ht
Ratin Scor Ratin Scor Ratin Scor
g e g e g e
Requirements
Real-time data
10 5 50 5 50 5 50
entry
Auto re-order 10 3 30 5 50 5 50
Real-time data
10 1 10 3 30 5 50
query
90 130 150
Constraints
Development
25 5 125 4 100 3 75
costs
Hardware costs 25 5 125 4 100 4 100
Time to operation 15 5 75 4 60 3 45
Ease of training 5 5 25 3 15 5 25
350 275 245
Total 100 440 405 395

Second
Spreadsheet
(New Weights for Alternative B)
Weig
Criteria Alt A Alt B Alt C
ht
Ratin Scor Ratin Scor Ratin Scor
g e g e g e
Requirements
Real-time data
18 5 90 5 90 5 90
entry
Auto re-order 18 3 54 5 90 5 90
Real-time data
14 1 14 4 56 5 70
query
158 236 250
Constraints
Development
20 5 100 5 100 3 60
costs
Hardware costs 15 5 75 5 75 4 60
Time to operation 10 5 50 5 50 3 30
Ease of training 5 5 25 4 20 5 25
250 245 175
Total 100 408 481 425
 Third Spreadsheet
(Additional Criteria)

Weig
Criteria Alt A Alt B Alt C
ht
Ratin Scor Ratin Scor Ratin Scor
g e g e g e
Requirements
Real-time data
16 5 80 5 80 5 80
entry
Auto re-order 16 3 48 5 80 5 80
Real-time data
12 1 12 3 36 5 60
query
140 196 220
Constraints
Development
16 5 80 4 64 3 48
costs
Hardware costs 13 5 65 4 52 4 52
Time to operation 8 5 40 4 32 3 24
Ease of training 3 5 15 3 9 5 15
200 157 139
Other
References 8 3 24 4 32 4 32
In use 8 5 40 3 24 1 8
64 56 40
Total 100 404 409 399

5. The list for evaluating computer hardware and system software would
be very similar to that for selecting off-the-shelf application software. In
addition to cost, functionality, vendor support, viability of vendor,
flexibility, documentation, response time (or other performance criteria,
such as number of transactions per unit of time or other benchmark tests
or raw processor speed), and ease of installation, we might include: the
current staff’s familiarity with the new system, need for retraining,
compatibility and connectivity with current systems, cost of converting
old systems to the new platform, ease of future upgrades, and track
record of the vendor in successfully implementing this new system in
other organizations.

6. For this method of evaluation to be valid, one assumes that all relevant
criteria are known and included and that the weights and ratings are
accurate. More important, this method assumes that the alternatives and
criteria lend themselves to a quantitative analysis. Some people argue
that some parts of the analysis inherently cannot be quantified. For
example, it is difficult to truly explicitly rate and weight the amount of
trust that you can place in a vendor and your belief that they will indeed
 follow through on their claims. Further, this method assumes that the
criteria are independent of each other, and thus scores are additive.

7. One other quantitative method for choosing between alternative

systems would be to choose almost exclusively based on cost. This may
seem far-fetched, but in most state and federal agencies information
systems are chosen this way. People in these agencies are often forced by
law to choose the least expensive system that meets some minimum
level of adequacy for the relevant information system needs. Indeed,
many states and parts of the federal government are attempting to
change this method of awarding governmental contracts. One other more
qualitative method often used is to choose the vendor that not only
supplies the necessary system but also provides the best value–added
services and components. For example, many companies will choose a
vendor that, in addition to the basic system, is willing to supply additional
training, free components, less expensive maintenance, or has offered to
enter into a strategic partnership that is of mutual benefit to both
companies.

When multiple decision makers will collaborate and make the decision
together, there are several methods for incorporating their interactive
input. For example, for a quantitative analysis such as that presented in
Figure 11-6, each decision maker could first enter their ratings for each
alternative across each criteria. This data could then be summarized
using a spreadsheet, and the average and/or summary rating across all
decision makers could then be used to choose a vendor. In addition,
group support systems could be used to tally the individual, anonymous
ideas, comments, and/or votes of multiple, collaborating decision makers.
Since there are many multi–criteria decision-making methods (e.g.,
another popular one uses pairwise comparisons), students may come up
with many alternatives for this question.

8. Basically, the students should include in the meeting the deliverables

from the three major sub–phases of analysis: requirements
determination, requirements structuring, and alternative generation and
selection. Some other key issues that must be decided are who else to
invite to the meeting, the level of detail to present to Bob Mellankamp,
and, subsequently, how long the meeting should last. The meeting should
not only summarize the findings from analysis but also validate these
findings by outlining the process followed. An updated BPP should be
covered. Without more information, it may be difficult for the students to
decide on these other key issues. Have them identify the information that
would be needed to decide on these issues. For example, they may want
to know more about Mellenkamp’s personality and preferences before
deciding.

9. In addition to cost, functionality, vendor support, viability of vendor,

flexibility, documentation, response time, and ease of installation, there
are a number of other “real world” criteria that might be included. People
often choose applications packages, such as word processors and
 spreadsheets, based solely on their familiarity with the packages and/or
their bias toward one hardware platform or operating system over
another. To a certain extent this can be functional. On the other hand,
this could also be dysfunctional. For example, it would be useful to
consider the current staff’s familiarity with the new applications software
and the resulting need for retraining. However, it would be dysfunctional
if a company did not ever choose new software because of the
employees’ lack of familiarity with it. Eventually, software will evolve and
the market will change, and the employees (and the company) will be left
behind using antiquated technology. Some other criteria include
compatibility with currently used application software (so, for example,
data can be shared), compatibility with existing hardware and system
software, ability to support a range from novice to experienced (or
power) users, and appeal of the user interface (ease of use).

10. Some basic system alternatives include: (1) build the system in-house
using a programming language such as C or Microsoft Visual Basic; (2)
purchase off-the-shelf packages, such as Microsoft Excel and Access,
along with the necessary computer and telecommunications equipment,
and use these to build the necessary systems in–house; (3) purchase
custom software and a turn–key system from either a generic information
systems consulting firm such as Andersen Consulting or EDS or from a
specialized systems provider for the food retail or pizza retail industry; (4)
outsource the systems to an outside firm.

Each of these alternatives has unique advantages and disadvantages.

Given that the system needs to be stable, easy to use, and built relatively
quickly, and given that this organization probably has little or no in–house
systems personnel, the third or fourth alternatives are probably most
realistic.

11. It will be useful for students to create a spreadsheet like that one
presented in Figure 11–6. They should list in the criteria category each of
the requirements and constraints described in the problem, plus any
others that they believe are relevant. As best they can, have them weight
each of these criteria and use them to rank each of the four alternatives
presented in the previous answer. They may have to make some
assumptions in order to complete each of the ratings. This method of
analysis should be useful even for this relatively small system. The
method will force the decision maker to flesh out relevant criteria and
weighting and be as objective as possible in rating each alternative on
each criteria.

12. Having only one design strategy can be problematic in several ways.
First, there will be no guarantee that the best, the correct, or even an
adequate system for the situation is being developed or purchased. This
is not obvious because it is unclear if other alternatives were considered,
and if they were, those present cannot see why the one choice won out.
Second, if the one strategy is because only one vendor is used, there are
no benefits from having multiple vendors compete for an RFP. For
 example, the vendor has no incentive to keep their price as low as
possible. Third, without the detailed, public systems specifications that
are part of a competitive bid process, there is not likely to be much in the
way of written documentation to refer back to if the vendor does not
fulfill their promises. If the analysts present only one design strategy
during the oral presentation to the project steering committee or client,
the recommendations are likely to be (at worst) rejected, or (at best)
accepted with great skepticism. It is also possible that those present at
the meeting will start to generate alternatives, each representing that
person’s position. The meeting will likely quickly deteriorate since a fair
assessment of ad hoc alternatives cannot be done within the limits of a
meeting. In any event, this is not a good way to begin the development
of an information system (or to build a career).

13. The list for evaluating alternative custom software developers would be
very similar to that for selecting off-the-shelf application software or for
computer hardware and system software. In addition to cost,
functionality, vendor support, viability of vendor, flexibility,
documentation, response time, and ease of installation, we might include
the current staff’s familiarity with the software, need for retraining,
compatibility and connectivity with current systems, and the track record
of the vendor in successfully implementing similar software in other
organizations. Such vendors should have an established track record of
developing similar software in other organizations. Their references
should be checked thoroughly, including visits to these other sites. If the
developer’s role will end after the application is accepted, then the
reputation of the vendor for handling this transition from external
development to internal maintenance is important. From a legal point of
view, you may want to select a custom developer based on the
willingness to sign a non–disclosure agreement, so that they are not
allowed to develop a similar system for one of your competitors, at least
for some amount of time.

14. The project team can use the advantages of the enterprise resource
planning design as part of their strategy for selling this system. The team
can stress that this solution consists of a series of integrated modules,
these modules are integrated to focus on business processes, and the
firm can integrate all parts of a business process. This approach includes
a single repository of data, thus providing more consistent and accurate
data and less maintenance. These modules are flexible and new modules
can be easily integrated into an existing system.

Also, an enterprise resource planning (ERP) system might be justified on

the following grounds: 1) it is a complete enterprise-wide solution that
models all aspects of each transaction, supposedly seamlessly and within
a single system; 2) an ERP system is based on a single repository of all
corporate data, which implies consistency, accuracy and flexibility of the
data; 3) adding new modules should be relatively painless as all modules
are specifically designed to work together. On the other hand, some
might counter that ERP systems are complex and require expensive
 outside expertise for implementation, and that the organization itself has
to adjust to fit the software's model of how organizations should operate
rather than the reverse.

Guidelines for Using the Field Exercises

1. Since pricing and capabilities change rapidly, ask your students to visit
the web sites of several vendors, including Compaq, IBM, Gateway, Dell,
and Microsoft. For discussion purposes, three alternatives are presented
below; however, please note that the information provided in this answer
will need to be updated at least each semester.

Low-end alternative: 200MMX Pentium Processor, 16MB of RAM, 2.1GB

hard drive, 16X CD-ROM, 15” color monitor, running Microsoft Windows
98, and equipped with Microsoft Office 97. Cost is about $1200.

Mid-range alternative: 233MHz Pentium II with MMX, 32MB of RAM, 2.5GB

hard drive, 15” color monitor, a 24X CD-ROM, running Microsoft Windows
98, and equipped with Microsoft Office 97. Cost is about $1,700.

High-end alternative: 400MHZ Pentium II with MMX, 64MB of RAM, 12GB

hard drive, 17” monitor, DVD-ROM drive, running Microsoft Windows 98,
and equipped with Microsoft Office 97, Microsoft Works, and Microsoft
Encarta. Cost is about $3,300.

2. The spreadsheet below presents the quantitative analysis for the three
alternatives described in the previous answer. Speed, storage, ease of
use, reliability, costs, and time to operation were the criteria used. The
mid-range alternative has the highest score because it has acceptable
rankings for the performance–oriented criteria and scores well on the
highly weighted criteria of costs. As is often the case, people often buy
more technology than they really need. The counter argument is that, for
PCs, one should buy as much power as they can reasonably afford so the
technological life of their equipment is longer, and they will be better
able to take advantage of new software as it becomes available.
 Field Exercise 2
Spreadsheet

Criteria Weight Pentium Pentium II Pentium II

200MHz 233 MHz 400MHz

Rating Score Ratin Score Ratin Score

g g
Requirement
s
Speed 15 3 45 4 60 5 75
Storage 15 3 45 4 60 5 75
Ease of Use 15 4 60 5 75 5 75
Reliability 15 4 60 5 75 5 75
60 210 270 300
Constraints
Costs 25 5 125 4 100 2 50
Time to 15 5 75 5 75 5 75
Operation
40 200 175 125
Total 100 410 445 425

3. Students should be able to either find and use a copy of three different
spreadsheets or find information about each package. They might also try
visiting a computer retailer, particularly a large one such as CompUSA or
Egghead Software. At such stores the students will be able to test a
variety of software packages. Some of the criteria the students are likely
to use include: speed, ease of use, compatibility with other packages,
price, and features. It will be useful for students to compare their
analyses to see the differences and similarities. This will help them to
understand how difficult it is for software vendors to be all things to all
customers.

4. Business people are likely to use this list of criteria in some formal or
informal way. Have the students present their answers to the class so
that they can learn about a variety of companies. It will be useful for
students to see how companies actually use these criteria and methods
in purchasing off–the–shelf software.

5. These may be difficult for the students to obtain. It may be necessary

for the instructor to obtain copies of RFPs either from business contacts
or from a university. It is very useful for students to see real RFPs.
Students will be amazed at how lengthy and detailed these can be for
larger, more complex systems. They are likely to be particularly amazed
at how complicated RFPs can become for governmental agencies.

6. Chances are any organization that a student contacts about its ERP
implementation will have a lot to say about it, provided they are willing to
share the information. Typically, ERP implementations take several years
 and cost quite a bit in terms of consultant fees. There are many reasons
to move to an ERP system, just as there are many reasons to not move to
an ERP system (see the answer to PE 14 above). The organization was
probably attracted to the promise of uniformity and consistency made by
ERP vendors, although the exact reasons will differ from firm to firm.
Chances are good that the organization has had to make some internal
changes, such as realigning departments internally to take advantage of
the opportunities ERP systems offer, as well as to meet the demands ERP
systems make in order to operate most effectively. And the chances are
also good that most of the implementation work has been done by
outside consultants, so for firms not used to managing large numbers of
contractors, an ERP implementation would be a new and different
experience. The implementation is likely still going on at whatever firm a
student happens to talk with, but it has probably been going on for many
months or years, as each ERP implementation is a learning experience for
the consultants and the adopting firm.

Guidelines for Using the Broadway Entertainment

Company Case
The BEC case associated with Chapter 11, Analysis: Selecting the Best
Alternative Design Strategy for the Customer Activity Tracking
System, illustrates the presentation of the results from the analysis phase of
a systems development project. As with many of the BEC cases, the style is
conversational, in which several of the principles in the case are discussing
their plans for the presentation. This conversational format helps students to
imagine how the job of a systems analyst actually plays out on a daily basis.

The case highlights the various roles of different team members and how
each is the best person to present certain findings. The case also shows how
the team anticipates the perspectives of those who will attend the
presentation and how the presentation content is customized to fit the
audience. Consistent with the suggestions from the chapter, the CATS team
has three alternative design strategies to outline. One of these, Alternative 2,
will likely be a surprise to the students, since it is a purchased package
solution. There has been no hint in prior BEC cases that such an alternative
was possible or being considered. The fact that this arises suggests that the
CATS team has considered all alternatives and has been creative. As noted
earlier, it is only after a thorough analysis that purchased software
alternatives be seriously considered. There is no way the CATS team could
have evaluated a package until all the requirements were collected,
structured, and analyzed. The real surprise is that this turns out to be the
recommendation!

Thus, this case is rather provocative, compared to prior BEC cases.

Consequently, this case can lead to a very lively debate about the viability of
the evaluation of the alternatives and how this resulted in the selection of the
package solution. This debate is enhanced by the fact that the “vendor” of
the package is not a typical software firm, but another consumer goods and
services organization, probably not in the business of supporting external
software customers. However, BEC does not seem to care about this, since all
they (i.e., the CATS team) want is the design and code, which they will then
customize and adapt. Thus, the package gives the design and
implementation steps a “jump start,” not a “short circuit.” By the way, we
hope your students see the pun embedded in the juxtaposition of the CATS
project and the TwoCat software.

We recommend that you take some time in class, probably after you lecture
on Chapter 11, to discuss several questions based on this case. Some
possible discussion questions are the following:

1. Do you agree with the assignments of who will present what at the CATS
analysis phase walkthrough meeting with the SPB? What would you
change and why?

2. Although three alternative design strategies clearly show a range of

possibilities, each alternative must be representative choices. Do the
three alternatives the CATS team plans to present seem representative to
you? Are these good choices in your estimation?

3. What is your assessment of the purchased software alternative? Is it

viable to purchase software from a non–software firm? How does BEC
intend to utilize this software in the development of their own customer
activity tracking system? What is the added advantage of acquiring the
software versus simply learning from the experience of TwoCat and then
creating a similar system from scratch?

4. Assuming the requirements and constraints for CATS are necessary and
sufficient, does the analysis presented in Figure 4 make sense? Would
you question any of the weights or ratings?

5. Given that the CATS team recommendation is Alternative 2, if you were

on the CATS team, how would you present this recommendation? What
issues would you expect to arise concerning this solution, and what
response would you give to the concerns raised?

6. Compared to a purely in–house development, how do you think the

remaining phases of the CATS project will change if Alternative 2 is
accepted?
12
Object-Oriented Analysis and Design

Chapter Overview
The purpose of Chapter 12 is to introduce students to object-oriented analysis
and design. OOAD’s increasing popularity is brought about in part because of
its ability to represent complex relationships, as well as data and data
processing, with a consistent notation. Students are introduced to several
techniques that systems analysts can use to perform object-oriented analysis
and design. The techniques and notations presented in this chapter include
use cases, class diagrams, state diagrams, and sequence diagrams. The
standard object-oriented language, UML, is used to present these techniques
and notations.

The chapter begins with a comparison of the object-oriented development life

cycle and the traditional development life cycle. The object-oriented
development life cycle consists of three primary phases: analysis, design,
and implementation. An object representation will develop as it moves
through each of these phases. After a brief introduction to UML, students are
shown how to prepare use cases, class diagrams, state diagrams, and
sequence diagrams. This chapter concludes with a discussion of these
various diagramming techniques and their use in analysis and design.
Instructional Objectives
Specific student learning objectives are included at the beginning of the
chapter. From an instructor’s point of view, the objectives of this chapter are
to:

1. Discuss the similarities and differences between the object-oriented

development life cycle and the more traditional systems development life
cycle.

2. Show the similarities and differences between OOAD and more

traditional, structured SA&D notations and methods.

3. Reinforce the terminology utilized in this chapter.

4. Discuss when each of the modeling techniques would be utilized in the

object-oriented development life cycle.

5. Show students how to construct each of the models presented in the

chapter.

6. Show and discuss how the models are related to each other.

Classroom Ideas
1. An OO specification can become very extensive since all aspects are
integrated into one model, so you will need to use simple examples. After
briefly reviewing OOAD terminology and notation, we recommend that
you teach from examples for the rest of the class. The situations
described in Problem and Exercise 7 are suitable to work in class. Our
experience is that the greatest discussion will center around what
methods should exist and where they should be located (that is, with
what object).

2. It is essential that students have a sound understanding of the core

concepts of OOAD: object, class, encapsulation, inheritance, and to some
extent polymorphism. Be sure students can distinguish an object from a
data entity instance and a class from an entity type. Emphasize the
ramifications of encapsulation for systems development, which deal
primarily with decoupling system components.

3. Compare and contrast the OOAD phases with the traditional SDLC
phases. Stress to the students that in the beginning the model is
abstract, showing more detail as it moves through the OOAD phases. The
text uses a good analogy; OOAD resembles more of an onion than a
waterfall.

4. If you have access to practicing systems analysts, invite them to your

class to discuss their usage of OOAD.
5. Stress the benefits of OOAD, especially the increased consistency
among the models developed during object-oriented analysis and design.

6. For some students this may be their first exposure to object-oriented

analysis and design. One way to approach the presentation of this
material is to make heavy use of the figures and illustrations utilized in
the chapter. Use these figures and illustrations to reinforce the
terminology and diagramming rules presented in the text.

7. An interesting exercise for the students involves the use of Figures 12-20
and 12-21. As a class discussion or group exercise, ask the students to
discuss how these diagrams should be modified (if at all) to
accommodate transfer students from other universities or junior colleges.

8. Review Question 2 is a good tool for comparing and contrasting the

terminology presented in this chapter.

Answers to Review Questions

1. An actor is an external entity that interacts with the system; it is
someone or something that exchanges information with the system. A
use case is a complete sequence of related actions initiated by an actor;
it represents a specific way of using the system. An object class refers to
a set of objects that share a common structure and a common behavior.
The state of an object encompasses an object’s properties and the values
those properties have. An object’s behavior represents how an object
acts and reacts. Encapsulation is the technique of hiding the internal
implementation details of an object from its external view. An operation is
a function or a service that is provided by all the instances of a class. A
method is the actual implementation of an operation. A constructor
operation is an operation that creates a new instance of a class. A query
operation is an operation that accesses the state of an object but does
not alter the state. An update operation is an operation that alters the
state of an object. An abstract class has no direct instances, but whose
descendants may have direct instances. Multiplicity indicates how many
objects participate in a given relationship. A class-scope attribute is an
attribute of a class that specifies a value common to an entire class,
rather than a specific value for an instance. An association class is an
association which has attributes or operations of its own or which
participates in relationships with other classes. Polymorphism occurs
when the same operation may apply to two or more classes in different
ways. Overriding is the process of replacing a method inherited from a
superclass by a more specific implementation of that method in a
subclass. In composition, a part object belongs to only one whole object
and lives and dies with the whole. An event is something that takes place
at a certain point in time; it is a noteworthy occurrence that triggers a
state transition. State transition refers to changes in the attributes of an
object or in the links an object has with other objects.
2. A use case represents a sequence of related actions that have been
initiated by an actor.

An extends relationship extends or adds to a use case by adding new

relationships. For example, the Class Registration use case can function
fine on its own; however, in certain circumstances, additional actions will
need to be performed, such as registering a student for a special class,
thus requiring an extended use case. However, when one use case
requires the use of another use case while executing then a uses
relationship is appropriate.

An object, or object instance, refers to an individual object; an object

class refers to a set of objects that share a common structure and a
common behavior. Jacob James and Colby Michael are both object
instances. Employee is an example of an object class.

An attribute is a property of an object; an operation is a function or a

service that is provided by all the instances of a class.

An object’s state encompasses an object’s properties and the values

those properties have. An object’s behavior represents how an object
acts and reacts. The object’s behavior is dependent on the object’s state
and the operation being performed.

An operation is a function or a service that is provided by all the

instances of a class. The method is the actual implementation of the
operation.

A query operation is an operation that accesses the state of an object but

does not alter the state; however, an update operation is an operation
that alters the state of an object.

An abstract class is a class that has no direct instances, but whose

descendants may have direct instances. A concrete class is a class that
can have direct instances.

A class diagram shows the static structure of an object-oriented model:

the object classes, their internal structure, and the relationships in which
they participate. An object diagram is a graph of instances that are
compatible with a given class diagram.

An association is a relationship between object classes. An aggregation is

a type of association; however, an aggregation is a part-of relationship
between a component object and an aggregate object.

Abstracting common features among multiple classes, as well as the

relationships they participate in, is called generalization. Aggregation is a
part-of relationship between a component object and an aggregate
object.
 Overriding by extension occurs when an operation inherited by a subclass
is extended by adding some behavior; however, in contrast, overriding by
restriction occurs when the inherited operation is restricted or tightened
by a new operation.

As it relates to state diagrams, a state is a condition during the life of an

object during which it satisfies some condition, performs some action, or
waits for some event. An event is something that takes place at a certain
point in time. An event changes an object’s state.

An event is something that takes place at a certain point in time; as a

result of that event, an action occurs.

An entry activity is performed upon entering a state; an exit activity is

performed when leaving a state.

A state diagram is a model of the states of an object and the events that
cause the object to change from one state to another. A sequence
diagram depicts the interactions among objects during a certain period of
time.

A generic sequence diagram shows the sequences corresponding to all

the scenarios of a use case. An instance sequence diagram shows the
sequence for one scenario.

A synchronous message is a type of message in which the caller has to

wait for the receiving object to finish executing the called operation
before it can resume execution itself. An asynchronous message is a type
of message in which the sender does not have to wait for the recipient to
handle the message.

3. The object-oriented development life cycle involves developing an object

through analysis, design, and implementation phases. As the model
develops, its focus shifts from an external, abstract focus to one that is
more detailed and internally focused. Object-oriented analysis focuses on
what the new system should do, not how it will function. During this
phase, a model of the real-world application is developed showing its
important properties. During object-oriented design, the analyst will
specify how the application-oriented model will be realized in the
implementation environment. This necessitates research into the impact
that the implementation environment will have on the design. The design
phase consists of two subphases: system design and object design.
During system design, the system designer proposes a system
architecture. During object design, a design model is built by adding
implementation features. During the implementation phase, the design is
implemented via a programming language or DBMS.

4. The biggest difference between the models is that the object-oriented

models build on each other and are consistent. Models developed during
 structured analysis and design are weakly connected and lack a common
representation.

5. An extends relationship is used when a use case requires the addition of

new behaviors or actions.

6. A uses relationship is necessitated when a use case requires (uses)

another use case while executing.

7. A vehicle can be identified as the superclass. Then, we can identify three

subclasses: cars, trucks, sports utilities, and recreational. Ask your
students to expand on this answer.

8. When an association has attributes, operations, or participates in

relationships of its own, the association should be modeled as an
association class.

9. A suggested answer is provided below.

10. A suggested answer is provided below.
11. A suggested answer is provided below.

12. A suggested answer is provided below.

13. Student answers will vary.

14. Student answers will vary.

15. One example of aggregation is a vehicle. A car will have front and side air
bags, an air conditioner, an engine, tires, possibly a trunk, and other
components.

16. A suggested answer is provided below.

Answers to Problems and Exercises

1. c concrete class e overriding d composition j event
b abstract operation a polymorphism g object
class i activation
f aggregation h association class j abstract use case
2. A suggested answer is provided below.
3. A suggested answer is provided below.
4. A suggested answer is provided below.
5. A suggested answer is provided below.
6. A suggested answer is provided below.

7. A suggested answer is provided below.

Part A.
7. Part B.

7. Part C.
7. Part D.

7. Part E.

8. A suggested answer is provided below.

9. A suggested answer is provided below.
10. A suggested answer is provided below.
11. A suggested answer is provided below.
11. Suggested answer continued.

12. A suggested answer is provided below.

13. A suggested answer is provided below.

14. A suggested answer is provided below.

Part A:
14. Part B.
14. Part C:
15. A suggested answer is provided below.
16. An example of a state transition is opening a checking account at a local
bank. Have students use this example and prepare a state transition
diagram.

Guidelines for Using the Field Exercises

1. An example of superclass/subclass relationship is with equity securities.

Equity securities represent ownership shares in a corporation. Equity
securities have attributes such as name, symbol, exchange and price. A
particular type of equity security is common stock. Preferred stock is
another type equity security that offers the holders fixed dividends each
year. An attribute for preferred stock would be dividend rate.

2. Examples of superclass/subclass relationships should be available in both

service and manufacturing businesses. In the service businesses you will
find several classes of employees, ranging from part-time to full time with
benefits. In manufacturing you might find several types of engineers
(electrical, mechanical).

Numerous operational business rules can be found in both types of

businesses. In manufacturing, rules regarding quality standards and how
overhead should be allocated to jobs can be found. In the service
industry, rules related to processes, such as how an item is purchased,
represent sequences in the object-oriented models.

3. The translation of the EER (or E-R) diagram should map the entity types
and attributes into classes. EER diagrams can represent generalizations
that also map to class diagrams. EER and E-R notation is different than
UML. Association relationships remain the same. E-R diagrams usually
show keys. Keys can be represented with class attribute names followed
by the {key} notation.

4. The main differences will most likely be in the notation used to describe
the model. Students may find systems analysts using Booch, OMT, or
their own custom notation. Students should see if the notations in use
can represent use-cases.
13
Rapid Application Development

Chapter Overview
The purpose of this chapter is to present an overview of one of the more
popular approaches to systems development that differs from the traditional
systems development life cycle, Rapid Application Development. The key
aspect of RAD that makes it so quick is its combined use of CASE tools, rapid
prototyping, and Joint Application Design, with heavy user involvement
throughout the process. This chapter presents an introduction to RAD, the
components of RAD, several approaches to RAD, several success stories, and
the advantages and disadvantages of RAD. Martin’s approach to RAD, as well
as the McConnell approach, is overviewed in this chapter. To help students
see the application of RAD, a specific RAD life cycle (Cambridge Technology
Partners) and three RAD success stories are presented. This chapter
concludes with a discussion of the advantages and disadvantage of RAD.

Instructional Objectives
Specific student learning objectives are included at the beginning of the
chapter. From an instructor’s point of view, the objectives of this chapter are
to:

1. Explain the basic concepts of Rapid Application Development.

2. Compare and contrast RAD with the traditional systems development life
cycle.

3. Explain the advantages and disadvantages of the RAD approach such

that students develop a general idea of when to use RAD.

4. Identify several approaches to RAD.

Classroom Ideas
1. Use Figure 13-1 to compare and contrast the RAD systems development
life cycle to the traditional SDLC.
2. Ask students to research RAD in both of Martin’s many writings on the
subject and in the trade press. Ask them to present their findings to the
class.

3. Ask students to research other alternatives to the SDLC; have them

report on what they found and how these alternatives compare to RAD.

4. Use a code-generating CASE tool and JAD sessions to conduct a mock

RAD in class. This will require a great deal of preparation to present
salient aspects of the process during a single class period. An alternative
approach would be to have students use the RAD approach in their
semester projects.

5. Encourage students to visit the Borland Delphi Web site and read the
cases presented there. Have the students summarize their findings.

6. If possible have a systems analyst speak to your class about how his/her
company utilizes RAD.

Answers to Review Questions

1. Prototyping is an iterative process of systems development by which
requirements are converted to a working system, which is continually
revised through close work between an analyst and users. JAD is a
structured process in which users, managers, and analysts work together
for several days in a series of intensive meetings to specify or review
system requirements. Rapid Application Development is a systems
development methodology created to radically decrease the time needed
to design and implement information systems. RAD relies on heavy user
involvement, JAD sessions, prototyping, integrated CASE tools, and code
generators. User design is the second phase of RAD where end users and
information systems professionals participate in JAD workshops and use
integrated CASE tools to support rapid prototyping. Requirements
planning is the first phase of RAD, in which high-level end users
determine system requirements, where the determination is done in the
context of a discussion of business problems and business areas.

2. The four phases of RAD are requirements planning, user design,

construction, and cutover. High-level end users determine system
requirements during the requirements planning phase. During user
design, end users and information systems professionals participate in
JAD workshops and use integrated CASE tools to support rapid
prototyping. During construction, the same users and IS professionals
involved in user design now build a working system, relying heavily on
CASE code generators. System implementation occurs during cutover.

3. Both Martin and McConnell present differing views of the four RAD pillars.
Martin’s four pillars include tools, people, management, and
methodology. Tools refers to the software development tools; people
 refers to individuals having the right skills; methodology identifies the
tasks and the ordering of these tasks; management provides facilitation
and support. Martin further suggests that an organization should “grow
into” the RAD development approach. McConnell’s four pillars of RAD
include avoiding classic mistakes, applying development fundamentals,
managing risks, and applying schedule-oriented practices. McConnell’s
RAD approach has a more conservative management flavor, stressing the
avoidance of mistakes such as the silver-bullet syndrome, requirements
gold plating, and feature creep. He also stresses the application of
development fundamentals and risk management. After “efficient
development” has occurred, then schedule-oriented practices can be
developed.

4. Prototyping, JAD, integrated CASE tools with code generators, CASE tool
repositories, and/or visual development environments are important
components. JAD sessions can be used to facilitate the prototyping
process, where users and analysts are working together to define
requirements and design new systems. Integrated CASE tools and code
generators can be utilized to design and implement the new production
system. The CASE tool repository is beneficial in that it promotes the
reuse of templates, components, or previous systems described in the
repository.

5. The two trends mentioned in the text are the increased speed and
turbulence of doing business in the late 1980s and early 1990s and the
ready availability of high-powered computer-based tools to support
systems development and easy maintenance.

6. Scalability, when applied to systems development, means that a given

system designed for use on one level may need to be expanded for
another level (or conversely, may need to be reduced.) This sometimes
happens when a system designed by an end user for his or her personal
use becomes used by several people in the user’s department. Later the
same system may end up being used for employees with similar needs
throughout the organization. In this case, the system has to be scaled
upward so that it meets the demands of use by more and more people in
more and more situations. When a system is designed through RAD, it
obviously starts out small, although the production system may end up
being much larger. Facilitating such scalability is not always easy to do,
but it is much easier to accomplish if planned for during systems analysis
and design.

7. The Cambridge RAD methodology utilizes five phases: scope, rapid

solutions workshop, design, development, and rollout. Executives, end
users, and technical specialists are brought together for several
facilitated, cross-functional meetings. The focus of these meetings is on
end-user needs and the business drivers for change. The deliverables for
this phase include business goals, critical success factors, a cost-benefit
analysis of the proposed application, an analysis of the fit between the
application and the client’s business processes, and a joint
 implementation plan. During the rapid solutions workshop, analysts and
client representatives build a prototype system. During the design phase,
two subteams are established: a user design team and a technical design
team. The user design team is responsible for gathering functional and
interface specifications for the complete application from the end users.
Information gathered at this stage is used in the technical design phase.
Requirements are made operational during development. Rollout has two
subphases, preparation and execution.

8. The Martin and Cambridge approaches are very similar. Figure 13-7 can
be used to illustrate this point. Martin’s requirements planning phase
corresponds to the first two phases of the Cambridge approach, scope
and rapid solutions workshop. Each approach has a design phase;
Cambridge’s development phase is similar to Martin’s construction
phase; Martin’s cutover phase is similar to Cambridge’s rollout phase.

9. The primary advantage of RAD is speed, which leads to economic savings

as well as a production system put into use earlier than would normally
be the case. Smaller design teams also save money and are easier to
manage. System quality should be increased due to the reliability of the
code generators used. Code generators also allow new system features
or other changes to be included more quickly. Finally, the system should
closely match business conditions, since the time between initial design
and production is greatly shortened and communication between users
and developers is often improved. Disadvantages include the chance that
developers will sacrifice a good understanding of the business area for
speedy development. This may lead to an ill-defined project that is
difficult to manage (for example, to do cost and time estimates). Also,
certain basic aspects of good systems development may be overlooked,
including consistency, programming standards, reusability, scalability,
interfaces with other systems, and planning for systems administration
for the production system.

10. The problem situation will dictate when RAD should be used; however,
the primary advantage of RAD can be used to answer part of this
question. Systems requiring rapid development are prime candidates for
this approach, thus systems responding to new government regulations,
opportunities for competitive advantage, and/or changing business
conditions would fall in this category. Total reliance on RAD for all systems
development can pose problems with nonconformance to standards, lack
of reusability between system components, and lack of consistency
between systems modules. Systems requiring tight integration with other
systems would most probably benefit from a more traditional systems
development approach.

11. JAD is one component that is useful during the RAD process. Analysts and
users rely on JAD-like sessions to facilitate the prototyping process.

Answers to Problems and Exercises

1. c RAD b prototyping a code generation

2. Since prototyping is used within RAD, there are obvious similarities

between these two methods. A primary difference is that the results of
prototyping within RAD (that is, the code) is used within the working
system, whereas the result of pure prototyping is a model for the working
system. RAD also differs from prototyping in that RAD has a more formal
requirements-definition phase. It is also typical with RAD that there are
several users, whereas prototyping is often applied when there is one or a
few users. Also, prototyping may not use a CASE tool but may use 4GLs
instead. Both RAD and prototyping emphasize iterative development and
direct user involvement in a process driven by the user.

3. Since the RAD four-phase life cycle resembles the SDLC, these can be
complementary methodologies. RAD can be used to accelerate the SDLC
steps of analysis through installation. RAD could be used on selected
modules of a new system—modules that needed to be developed quickly
and that are more stand-alone.

4. It is difficult to conceive of doing RAD without 4GLs, code generators, and

CASE tools. Manual programming in a 3GL simply would not support the
rapid rebuilding of prototypes implicit within RAD. Object-oriented and
visual development environments would also be of great help in RAD.
RAD could also utilize pre-packaged software, especially for core modules
of a new system, with RAD development concentrating on the
customization and extensions of the package.

5. A RAD-developed system can be out of alignment with the direction of

the business because the requirements planning phase tends to
concentrate only on the needs of the requested application, without
consideration of business direction and systems beyond the scope of the
project. Thus, analysis of the business area, and potential re-engineering
of it, are not considered. One way to overcome this potentially serious
flaw of RAD is to include on the RAD team a few users and senior
managers who know the direction of the business. Another tact is not to
duplicate data into a new database but use existing databases and the
agreed-upon data model of the business. Yet another approach would be
to use reusable code and centrally maintained models as much as
possible. Thus, as these modules are updated in response to new
business conditions, so will be the RAD-developed system.

6. As explained in this chapter, RAD seems to apply only to certain types of

systems, although the need to develop systems more rapidly is true for
all types of systems. Since RAD tends to ignore or at least minimize
consideration of business direction and interactions with other systems,
RAD is more applicable to stand-alone applications that may have short
lives. RAD might not work when a large development team is needed
(either a massive system or a large number of users). RAD also would not
work for a system for which there was limited user commitment or
 agreement of involvement in the development project. It is not only
decision support systems that would be suitable for RAD. Even a limited-
in-scope transaction processing system could be developed via RAD, but
more typically other types of systems suitable for RAD would be expert
systems, executive information systems, and management information
systems for which all the data either existed or new data was of interest
only to the new application.

7. As mentioned in the text, RAD is a shortened, yet similar, version of the

traditional SDLC. The RAD planning and design phases concentrate work
efforts on system functional and user interface requirements, at the
detriment of a detailed business analysis and concern for system
performance issues. The new system is often developed in isolation from
other systems, thus coordination with existing standards and systems is
often not done. RAD makes heavy use of prototyping and performing
tasks in parallel, and the bulk of the work is done during the design and
development phases. Since users have been very involved in the RAD
process, the new system, when delivered, should be more readily
accepted by them.

8. One approach to this question is to encourage students to visit the

Borland Delphi Web site (the URL is provided in the chapter references).
Ask the students to review several of the cases and identify what
characteristics of these cases made the usage of RAD appropriate. In
general, systems that require rapid development because of cost, time,
and necessity are prime candidates.

9. Both approaches are necessary for understanding the successful

application of RAD. The McConnell approach stresses the necessity of
management, while the Martin approach stresses the importance of the
correct combination of tools, people, methodology, and management.

10. McConnell’s approach stresses the management of RAD projects. The

project should be carefully planned and managed, utilizing many of the
skills presented in Chapter 3. An open communication with end users can
also be used to address the unrealistic expectations that these users may
have.

Guidelines for Using the Field Exercises

1. Most of the major systems consulting firms have a RAD alternative in
their standard systems development methodology. So, if it is more
convenient to have students investigate another specific firm, like
Andersen Consulting, or to explore several different firms, the
objectives of this question would still be met. Typically, systems
developers have their favorite techniques, tools, and methodologies,
so it is likely that not everyone has embraced the approved RAD
method. For many consulting firms, their RAD method is not separate
from but rather works with their traditional, well-tested methods. This
 combination of traditional methods and RAD tends to minimize the
potential hazards of a pure RAD approach. Have your students present
their findings in class. Have them show how the methodology they
investigated differs from the RAD method outlined in the chapter, and
if the students have investigated several firms, try to draw out the
differences between the methods.

2. The difficulty with this question is that there are so many different
implementations of RAD, most firms will say they have used RAD but
with vastly different processes and results. Thus, the reasons for
project selection will likely vary. What is important is to understand
how an organization chooses to use the methods, techniques, and
tools it does under what circumstances. Students will likely find that
there are many common influential factors, but that the history of
information systems successes and failure in each organization causes
certain factors to dominate. Have the students present their findings
and try to draw comparisons across organizations.

3. Students will likely provide a variety of answers. However, most will

mention integrated CASE tools with code generators and prototyping
facilities as being extremely beneficial. As an extension of this
exercise, consider asking the students to compare and contrast three
CASE products and the abilities of each to support a RAD approach.

4. This is a very practical approach to presenting the many benefits of

RAD. Since several cases are presented at this site, one way to handle
this field exercise is to assemble the students into groups, assign each
group one of the cases at the Borland Delphi Web site to review, and
ask each group to present its review to the class. By using this
approach, several of the cases can be overviewed, outlining the
successes of each.
Sample Course Project Case Study

Introduction

Many systems analysis and design instructors choose to

include a project as a significant part of the course. At some
schools, a separate project course exists. For these project
experiences, instructors use either field projects, usually in a
local organization or campus unit, or a case study–based
project. When using a case study–based project, an
instructor can choose to use a detailed case which contains
all of the information a student or student team needs to
know about the organization and system requirements, in
which case it is the students’ responsibility to check these
requirements for consistency, structure them, and compose
them into a design or working system. An alternative to such
a detailed case is to provide students only general
background information and then arrange project activities
in which the students glean the addition information they
need from interviews or questionnaires.

In this chapter of the Instructor’s Manual we provide a

sample project case study in the form of the last alternative
mentioned above. Several other sample projects of this
same nature are available to adopters of the second edition
of Modern Systems Analysis and Design by accessing the
Addison Wesley Longman World Wide Web site (see the
Preface to this Instructor’s Manual for the URL for this site).
These cases studies are designed to be worked on by teams
of 3–5 students. Each team has the same, unstructured
assignment, and it is totally up to each team to determine
how to proceed (including how to organize itself, what steps
to follow, etc.). The expectations for this sample project case
study is to prepare a Baseline Project Plan for a project to
deal with the user’s request. The instructor or other
confidants play the roles in the case situation and provide
additional information to the teams as they request it, either
through interviews (inside or outside of class) or
questionnaires. It would be possible to evolve this case as
designed to follow through with additional project steps and
systems development phases, as time permits in your
course.

The structure of the sample case study provided here is as

follows:

(1) A memo from the team’s supervisor giving them their

charge for the situation they confront.

(2) An internal company memo in which a user manager

requests a system study. Items (1) and (2) are all the
students receive to begin the project. They must capture
any other information they need to work on the case by
asking questions of role players.

(3) An “interview script” which gives the person or people

playing the case study roles some basic additional
background information they will need to respond to
student requests for additional information. This script
provides general background on the case, the personas of
the key players in the case, guidelines on how to conduct
an interview or distributing the additional case
information to the students, and some scripted answers
to possible student questions to the role players. These
scripted answers are certainly not comprehensive, but
they will give the instructor or confidants some basis for
constructing answers to any and all questions.

(4) Four handouts of specific information which are given to

the students if they ask the right questions during
interviews and other role playing interactions with the
case key players.
Sample Case Study

The sample case study materials appear on the following

pages, in a format suitable for duplication. You have the
right, by adopting Modern Systems Analysis and Design, to
make as many copies of these materials as you wish.
Consolidated Industries
Memorandum

To: Your Systems Analysis Team

From: James Duffy, Director of Business
Systems
Date: September 25, 1998
Phone: 4–3786

I just received the attached memo from Hank Jeffries, an old

friend of mine who is now in charge of Vehicle Management.
He is looking for help in analyzing some problems that have
arisen in his department. I’d like you to meet with Hank and
explore his situation.

From what Hank says in the memo and from a prior

discussion I had with him, I’d suggest that you carefully
consider his situation. I doubt that there is a ready–made
solution. I’m not sure they really know what their problems
are. I don’t know how much you can find out from one
interview with Hank and some of his staff, so I don’t expect
you to know how to solve his problems from just this one
meeting. In fact, I don’t think Hank expects us to come up
with a solution to his problems right now.

What I’d like you to do is meet with Hank and his staff and
find out what kind of help he’d like from us. This will be a
“free” session, part of developing potential business for us
with his department. After you meet with Hank, organize
your thoughts into a recommendation for me and Hank on
what kind of analysis we might do for Vehicle Management.
Prepare a presentation that you can take to Hank to sell our
business analysis services. Remember, now that we are a
profit center, we have to sell clients on the idea that we can
help them solve their business problems. We don’t give free
advice anymore! If we tell Hank what to do, he’s likely to hire
someone else to implement the solution.
Hank is a pretty astute manager, although still learning
about his new department. So, you’ll have to develop a clear
proposal and figure out what key points are necessary to sell
our services. This should be a good opportunity for you to
show me that you can generate new business for Business
Systems. How’s that for a challenge?

Good luck. You’re on your own!

Consolidated Industries
Memorandum

To: James Duffy, Director of Business

Systems
From: Hank Jeffries, Manager of Vehicle
Management
Date: September 23, 1998
Phone: 4–2487

Jim, it was good to see you again last week at the company
picnic. Time has passed quickly since we graduated from
Mid–State University. I'll never forget our I–core group!!
Again, congratulations on your promotion. You people in
systems always seemed to have a leg up on the rest of us.

Thanks for letting me bend your ear about what I think is

going on here in Vehicle Management. As I said, I’m just
starting to understand this place after spending all those
years in personnel. It’s a big change for me. Even after a
month in this job, I still have much to learn. My problem is,
I’m not sure how to begin to understand what’s happening
here. I’ve been thinking all weekend about your offer to help
me and my department look at some problems we are
having. I think you might just be able to help. Let me explain
our situation a little more carefully, this time without trying
to eat a Brat at the same time.

Briefly, Vehicle Management is responsible for the

corporation's fleet of executive cars, rental vehicle pool, and
other company owned vehicles. We purchase, plate,
maintain, and sell all corporate vehicles. At any time, we
have approximately 300 vehicles (cars, trucks, etc.) in our
fleet. We have to place and track new vehicle orders,
inventory all vehicles and record who is assigned each
vehicle, update vehicle maintenance history and
requirements to meet manufacturer warranties, and handle
all internal billing.

Vehicle Management is a profit center within the corporation.

My office staff of six clerical and professional workers
handles all management functions (plus we are also
responsible for the mechanics in the garage). The garage
handles all routine functions when a vehicle comes in from
use (cleaning, gassing, parking, etc.), but we decide and tell
the garage personnel when preventive and routine
maintenance are to be done or when to take a vehicle out of
the fleet. We decide when to turn over vehicles and what
vehicles to order. We handle titling, plating, invoicing, and
inventorying of vehicles. We also must keep track of the
driving history (accidents, tickets, etc.) of all employees who
use company vehicles. We do this with very little personal
contact with employees since none of my staff work in the
garage.

We seem to have a variety of problems. More specifically, we

have had difficulty:

 keeping up with the ever increasing workload in the office

(e.g., the department has had a 50% growth in number of
vehicle use transactions in each of the past three years)

 producing special information for our use or for our

customers (e.g., it takes us a lot of time to prepare
summaries of vehicle use by customer department,
authorization code, or event)

 selling vehicles at the best time (we can get the best
trade–in price when we sell a vehicle with the right
combination of mileage and age)

 processing vehicle requests for special events (e.g.,

customer promotional activities, community service
programs, or officer meetings)
  preparing a comprehensive history of use and
maintenance on a given vehicle

 sending out and tracking follow-up maintenance reminder

notices to those assigned a vehicle

Jim, we have tried everything we can think of and, yet, our

problems seem to get worse. We operate on very low
margins, and corporate does not show any interest in our
problems. Consequently, we don’t have much money to
spend. We don’t want an elegant solution, just one that
works. I’m not sure what the real causes of our problems are.
Maybe our office procedures are messed up, maybe it’s the
computer system we use, or maybe I need to add staff. I
sure wish you could tell me how to figure out what my real
problems are!

I know you people in Business Systems are real computer

experts, but I’m not sure our computer system is the
problem. The department purchased some fleet
management software two years ago when they saw growth
was going to be explosive. The system runs on the corporate
mainframe and handles our basic data needs. We have one
terminal in our office and one in the garage. We try to
operate like a real rental car agency since corporate staff
can rent from us or any local or national chain agency.
“Customer service” seems to be important to those who rent
from us, but none of us have ever worked for one of “the big
guys.” So, I’m not sure we are doing what our customers
want.

What I’d like to do is schedule a time when several of my

staff and I can meet with a couple of the business
consultants in your department and discuss what you might
be able to do for us. Then, maybe you can give me a
proposal or outline on how we could proceed from there. I’ll
have Sally call you in a couple of days and we’ll set up a
time to talk.
cc: Stan Fox (Vehicle Disposition)
Sue Quinlan (Rental Operations)
Jack Sutton (Vehicle Maintenance)
Judges Interview Script

Background

Objective of Case: The purpose of the case is not to have

the students recommend a solution to the problems. Rather,
the purpose is to have the students devise and describe a
project that would investigate the problems and which would
then lead to (when conducted) recommended solutions.
Thus, the case emphasizes the ability to scope a situation for
study and the development of a methodology for systems
analysis. If you wish, and time permits, you can have the
student teams take the project into subsequent steps of
more detailed analysis, design, and implementation.

General Tone: Since we do not want the student teams to

concentrate on solving a problem, we don’t want to give
them too much detail. The information that we want to give
them relates to the scope of operations, concerns of
individuals (but no hard data to back up concerns), and
questions we’d like the team to investigate. So, responses to
questions like:

“I don’t know the answer to that.”

“I really wish someone would look into that for me.”
“I think ‘x’ is happening, but I’m not sure.”
“I have some concerns about that, but that’s not in my
area.”
“"I have not been here long enough to really understand
what is happening there.”
“I haven’t had a chance to look into that, yet.”

are good answers in the role–playing interview. We want to

make sure the students see the need for further study, and
design a project plan that does the appropriate analysis.

Your “Personas” in the Case: The three Vehicle

Management staff involved in the interview are:
 Hank Jeffries, Manager of Vehicle Management:
Hank Jeffries has been in the job one month. He had been
in personnel for 10 years and this is his first assignment
outside of personnel. He is just learning about the Vehicle
Management Department, so he has limited knowledge
about how his department works or what his staff does in
any detail. That is, he frequently has to answer “I don’t
know” to questions about department operations and
history. Jeffries recently received his MBA after going to
school part–time for five years. The company has
assigned him to Vehicle Management as a way to see if
he has potential for further advancement. Jeffries was an
HR major as an undergraduate 10 years ago. In school he
had one systems oriented course, but it involved
mainframe computing in FORTRAN with punched cards.
His work in personnel had no contact with systems. Hank
is concerned primarily with the customer service issue
mentioned near the end of the case, but being new to the
department, he cannot articulate very well what he
means by customer service. He does not understand the
vehicle rental business, including how to buy or sell the
fleet.

 Sue Quinlan, Head of Rental and Assignment

(oversees all vehicle use): Sue has been one of the most
vocal to Hank about the need for changes in Vehicle
Management procedures. Sue came to Consolidated six
months ago after working for four years as a travel agent.
Sue is progressive, but she does not know the operations
of the department very well, yet. Sue has not gotten
along very well with the other two managers in the
department since her customer service philosophy is
somewhat at odds with the approach others take. Sue is
openly critical of what she has seen in the department
and has many concerns, often without hard data, that the
department could function much better.
  JackSutton, Garage Operations Supervisor: Jack is a
card carrying bureaucrat. He rules the garage operations
with an iron hand, and not a very polite one at times. He
sees his job as controlling a company asset, not providing
customer service. Jack has been around the longest and
holds on to old habits. He schedules all maintenance
work on vehicles and decides when to outsource work. He
also handles (through Helen McGill) all correspondence
with company employees concerning service of rental
and assigned vehicles. Jack and Sue openly feud due to
their different perspectives (Jack—control and Sue—
customer service).

Vehicle Management Culture: The Department has

several internal conflicts which should come out in the
interview. First, the professional and clerical staff is a mixture
of first and second level managers (and clericals), some of
whom view the department as managing vehicles (corporate
assets) and others of whom want to provide service to those
who are assigned vehicles. Second, there has been
considerable turn–over in department staff, so there is
neither much organizational memory or rapport among the
staff. Decision making procedures have not been formalized,
so the managers all make independent decisions.
Communication between managers is poor. Hank, being new
to the department, often gets caught in the cross–fire
between other managers. The other managers are still trying
to “test” Hank, and are somewhat envious and upset that he
was brought in over them. For example, Jack is not reluctant
to say such things as: “Hank, you don’t really understand my
problems.” or “Once you’ve been here as long as I have, ...”

Key Items of Information: There are four potential

handouts for distribution to each student team. Each
handout is to be given only when the team asks any of the
kinds of questions listed under the associated handout
below:
(1) Vehicle Management Department Staff —
Any one of the following questions:
“Who works in Vehicle Management?”
“Would you please introduce yourselves and tell us a
little about your responsibilities?”

(2) Vehicle Management Organization Chart —

Any one of the following questions:
“How is the department organized?”
“Do you have an organization chart of your department
we could see?”

(3) Vehicle Management Department Operations: Overview

—
Any two of the following questions:
“Who are your customers?”
“What kinds of vehicles do you have?”
“How does someone get approved to rent a vehicle
from you?”
“Can any employee rent or be assigned a car?”
“Where do you keep the vehicles?”

(4) Memo from Sue Quinlan to Hank Jeffries —

Sue is to drop a hint during the interview that this memo
exists (e.g., the team might ask Sue what she sees as
some of the problems, and Sue might say, “As I outlined
in a recent memo to Hank, ...” and then mention one or
two of her concerns, but not the whole memo. Then, if
they ask any one of the following questions:
“Can we see a copy of your memo, Sue?”
“Hank, could you give us a copy of Sue’s memo?”

Questions

Refer to the four handouts for additional information when

answering questions.
Q: Where are company vehicles located and used?: A:
The company has employees in several dispersed buildings
in the metropolitan area, but the vehicle garage and pool is
centrally located at one site, the corporate headquarters
building. Vehicles are used both in and out of state.

Q: Who rents/gets vehicles from Vehicle

Management?: A: Customers are only company
employees. Customers are both individuals and
departments. Often the person placing a reservation is
different from the person actually using the vehicle (e.g., a
secretary for a manager, an event manager for a group of
volunteer drivers). Each of the top ten corporate executives
is entitled to a car of his/her choice ($35,000 price limit), and
each of the 30 traveling sales staff also, if they request, is
assigned a car. Some departments (like the courier service,
cafeteria service, building maintenance) also have vehicles
permanently assigned. All other customers rent for specified
time periods.

Q: How often do you change vehicles in the fleet?: A:

Executives get a new car each year. Sales staff have cars for
two years or 40,000 miles, which ever comes first. At the end
of this time, the car goes into the rental fleet if needed, or is
sold at an auction. Cars and mini-vans are kept in the fleet
based upon a rather complex calculation that minimizes total
operating cost. This is different for each make and model of
vehicle, and relates to its resale value, age, mileage,
expected maintenance costs, and other factors. Stan Fox
handles these decisions, so you’ll have to talk to him about
the details. Trucks, busses, and maintenance vehicles are
kept as long as possible, basically until maintenance costs
get prohibitive.

Q: How satisfied are you with your computer system?:

A: The computer system that supports Vehicle Management
is a comprehensive transaction processing system, but it has
no decision support. It handles all billing, vehicle purchasing
and receiving, vehicle retirement, vehicle tracking, and other
operational functions. However, it is not a commercial
reservation system. The terminal screens require special
training to use, so employees outside the department have
to work through department staff. The system does not print
out any documentation when an employee picks–up or
drops–off a car; all “paperwork” is processed through
sending written verification from batch printouts in intra–
company mail, or through internal charges. Internal charges
can be made without countersignatures or any checks. There
are no checks against renting department budgets to verify
that the department has sufficient funds allocated.

Q: Are employees careful when using company

vehicles?: A: Jack does not find employees cooperative. He
thinks that employees are not good about returning vehicles
on time, and those assigned vehicles (individuals and
departments) are not prompt about bringing vehicles in for
scheduled and required maintenance. Sue thinks that, in
addition, many reservations are canceled at the last minute
or there is a no–show. Often vehicles are needed without
more than a couple of hours warning. Accidents with
company vehicles may or may not be reported by the
employee involved. Often Vehicle Management hears about
a claim on an accident from an insurance company or the
police. Employees may have renting privileges revoked or at
least their supervisors can be notified by Vehicle
Management if abuse is habitual.

Q: Are you competitive with car rental companies?: A:

Sue tries to tell employees that Vehicle Management has two
advantages over commercial rental agencies: price and
location. Even though they are a profit center, Vehicle
Management just tries to break even. In each of the last
three years they have shown a slight profit, but not
substantial enough with which to do anything major. Their
price is about 10% less than the commercial agencies. Being
located at the main headquarters building is an advantage
for most employees, but not all.
Q: Are customers satisfied with the reservation
system?: A: We aren’t sure. Every once in a while a
customer will mention what a nice car they had on their last
trip, and we either don’t have that kind of vehicle or can’t
find any record of them using one of our cars when they said
they did.

Q: What are the procedures for checking in a car in

the garage?: A: Mileage, car condition, etc. are entered on
the terminal in the garage. We clean and gas the car, and do
a light inspection to make sure everything is working. We
change the oil every 3,000 miles and change the tires every
40,000 miles. We rotate tires every 10,000 miles. We make
sure all required maintenance is done during the warranty
period, and then do regular maintenance thereafter.

Q: What does (Sally, Helen, Margie) do?: A: Hank has

not gotten into the details of Sally’s job, yet. She basically
runs the office (buys forms, supplies, etc.) and organizes
financial records for Hank. Helen reviews vehicle use
information and tells the garage mechanics when to service
vehicles. She looks at information about the condition of
vehicles as they come in and contacts the renter or assignee
for more information when needed. Margie answers the
reservation phone and enters vehicle reservations into the
computer system. Besides this overview, Hank, Jack, and
Sue don’t really know much about what the office staff does
on a day–to–day basis.

Q: Are you understaffed in any of your operations

(like the garage)?: A: No. We can outsource some of the
garage work, and we can keep up with the requests for
vehicles.

Q: With the 50% volume growth in the past few years,

how have you coped with the extra work?: A: We were
probably over staffed before. But now as a profit center, we
can increase or decrease garage and office staff as we can
afford them.
Q: How well do the office staff and garage mechanics
get along?: A: They don’t get along very well. They have
very little contact with one another other than by phone and
written instructions. Jack does not think the office staff
understand the need to run an efficient garage operation.

Q: What would you like your computer system to do

that it does not do now?: A: Jack and Sue would like to be
able to customize new reports or inquiries as I need them.
They want to pick fields, sort the data, and show summaries.
They can’t give examples of what I need, but they are willing
to explore that in another discussion later. Besides that, they
don’t really use the system that much. Sally and Margie are
the main users. Hank has no insight to this question.

Q: Sue, what do you see as some of the problems in

the department?: A: As I told Hank in my memo, I think
we have to become more customer focused. I think we are
losing business to commercial rental agencies, our computer
system is not very helpful in our competitive situation, and
we have to find new ways to satisfy our customers. I keep
thinking back to my experience as a travel agent, and see a
lot of opportunities for us. I have not had time to investigate
my concerns; maybe you guys can help us do that.

Q: Jack, what do you see as some of the problems in

the department?: A: I’m not sure there are many
problems, at least everything seemed to be working fine
until a few months ago. I’m having trouble now getting cars
serviced in time for their next reservations, and Sue’s always
bugging me about having the garage people promptly enter
information about the vehicles. I can’t understand why
executives, salespersons, and departments with assigned
vehicles won't bring in vehicles for required maintenance
when he tells them to. Don’t they realize that if they want
their vehicle to work when they use it, the vehicle has to be
serviced regularly?
Q: What is being done to improve communication
within the department?: A: Hank, Sue, and Jack just
started meeting every Monday morning to review issues
each raises. Hank serves as a moderator, and asks
questions. Hank is concerned about everyone working
together better.
 Vehicle Management Department Staff

Bios of Interviewees: The three Vehicle Management staff

involved in the interview are:

 Hank Jeffries, Manager of Vehicle Management:

Hank Jeffries has been in the job one month. He had been
in personnel for 10 years and this is his first assignment
outside of personnel. He is just learning about the Vehicle
Management Department, so he has limited knowledge
about how his department works or what his staff does in
any detail. Jeffries recently received his MBA after going
to school part–time for five years. The company has
assigned him to Vehicle Management as a way to see if
he has potential for further advancement. Jeffries was an
HR major as an undergraduate 10 years ago. In school he
had one systems oriented course, but it involved
mainframe computing in FORTRAN with punched cards.
His work in personnel had no contact with systems.

 Sue Quinlan, Head of Rental and Assignment

(oversees all vehicle use): Sue has been one of the most
vocal to Hank about the need for changes in Vehicle
Management procedures. Sue came to Consolidated six
months ago after working for four years as a travel agent.

 Jack Sutton, Garage Operations Supervisor: He

schedules all maintenance work on vehicles and decides
when to outsource garage work. He also handles all
correspondence with company employees concerning
service of rental and assigned vehicles.

Department Staff: There is one manager responsible for

vehicle purchasing and selling (Stan Fox), another for
managing vehicle maintenance and repair (Jack Sutton), and
the third oversees the rental and assignment operations
(Sue Quinlan). The three clerical staff handle vehicle
reservations (Margie Hall, who reports to Sue), billing and
receivables (Sally Ryan, who also serves as office manager,
and who reports to Hank), and coordination with the garage
(Helen McGill, who reports to Jack).
 Vehicle Management Department Operations

Overview

Company Location: The company has employees in

several dispersed buildings in a metropolitan area, but the
vehicle garage and pool is centrally located at one site, the
corporate headquarters building. Vehicles are used both in
and out of state.

Customers: Customers are only company employees.

Customers are both individuals and departments. Often the
person placing a reservation is different from the person
actually using the vehicle (e.g., a secretary for a manager,
an event manager for a group of volunteer drivers). Each of
the top ten corporate executives is entitled to a car of his/her
choice ($35,000 price limit), and each of the 30 traveling
sales staff also, if they request, is assigned a car. Some
departments (like the courier service, cafeteria service,
building maintenance) also have vehicles permanently
assigned. All other customers rent for specified time periods.

The Fleet: The fleet includes cars, min–-vans, trucks, two

small buses, and some maintenance vehicles. It does not
include fork–lifts or other such vehicles used in
manufacturing settings. Vehicles are rented for varying
amounts of time — some for a day (e.g., a day–trip to visit a
customer), some for months (e.g., for a given project), and
some on assignment (e.g., top executives and traveling sales
staff, catering department). All vehicles are maintained in
the company garage or Jack Sutton may choose to send a
vehicle out to a private repair service (e.g., to do warranty
work, to handle an overload situation, or to do body work).
Vehicle Management has to know where a vehicle is at all
times (that is, whether it is with an employee, in the garage,
or out for repair).
Authorization: Not just anyone can rent or be assigned a
vehicle from the fleet. Each rental or assignment must be
done under an approved authorization code, which is an
internal billing number (departments, projects, products,
special events, and individuals get authorization codes).
Consolidated Industries
Memorandum

To: Hank Jeffries, Manager of Vehicle

Management
From: Sue Quinlan, Rental and
Assignment
Date: September 10, 1998
Phone: 4–2486

Hank, now that you have settled–in to your job, I wanted to

outline a few of my concerns about the operation of the
department. I’ll be brief, and then we can discuss these and
other issues at your convenience.

 Corporate departments are demanding more information

about costs of their operations, including vehicle use.
Some of the commercial vehicle rental agencies I used to
work with as a travel agent have developed systems that
can print monthly or on demand a picture of vehicle
rental use and costs, broken down by person, type of
vehicle, and other parameters, for their corporate clients.
Our computer system has no capabilities in this area.
Further, I’m told the system is programmed in COBOL
under CICS; Systems tells me they are moving away from
this platform, and they no longer have much expertise in
such technologies.

 We have no internal marketing function for our

department, and I suspect that we are losing business to
commercial companies. However, there is no hard data
on this. I’d like for us to consider adding a marketing
manager and restructuring my job with this new position;
the goal would be to be more proactive in promoting the
department’s product. Again, the computer system has
no features that would support a marketing function.
  I’d like for us to consider selling vehicles to employees
when the vehicles are retired rather than selling them to
car brokers at auctions. This function could also be
handled by the possible new manager.

 Jack Sutton keeps telling me that trucks and utility

vehicles pose a special concern for him. Since these
vehicles are kept longer than cars, proper servicing of
them is crucial for a long life and greatest use.

 I think that we have to be more customer oriented in the

way we do business. For example, we (especially Jack)
has had a history of not being very tolerant with a
customer department's needs when we schedules routine
maintenance. For example, Jack has not instituted any
way to reserve replacement vehicles for a department
when their vehicle is in for scheduled service.

Let me know when you’d like to talk about these. If you know
of anyway we could get some help thinking about these
issues, I’d be glad to discuss my concerns with anyone.
****************
Teaching Notes for EDS Video

Introduction
In this section we overview and suggest how you might use the four video
segments based on the Broadway Entertainment Company; these video
segments are provided to adopters of the second edition of Modern Systems
Analysis and Design. These video segments are referenced in selected
chapters of this Instructor’s Manual; these references are intended to serve
as guides, indicating which video segments are appropriate for certain
chapters. Please check our web site (http://hepg.awl.com) for the latest
information about updates to these video segments.

All four video segments are realistic and practical examples of situations a
systems analyst might confront or in which she/he might be involved. The
video segments were written and produced by EDS Corporation, with
guidance from the textbook authors. Thus, the video segments are consistent
with the textbook (so your students can easily follow the video segments as
an integral part of the course), and they represent issues and ideas
encountered by one of the leading systems development and management
consulting firms in the world. The authors are indebted to Chris Ryan, Stu
Bailey, and Terry Zeuchow of EDS and Bob Tucker of Antaries Alliance (a CASE
tool firm partially owned by EDS) for their leadership in writing and producing
these video segments, and to Vern Olson of EDS for championing this project
to senior management within EDS.

In the following sections we overview each video segment and suggest some
discussion questions to use with students after they have viewed the video
segment. We suggest that you preview each video segment since we are
certain that you will see additional discussion points in each video segment,
and you will see various ways to link the video segment into your classroom
experience. We also suggest that you distribute at least a few of the
discussion questions to your students before they view the video segment.
This will help them think about the video segment as they view it, rather than
using the viewing of the video segment simply as a break in the class. Some
of the discussion questions could also be used as written assignments to be
turned in at the next class.

You do not need to use all of the video segments, and you do not need to use
them in any particular sequence. We have designed the video segments so
that each is independent of the other three, yet they fit together since they
all involve the same organization, have many of the same principle roles, and
have a consistent format and use consistent terminology. Each video
segment ends with a brief summary by one of the textbook authors, and one
of the video segments has an introduction by two of the textbook authors;
students are given some guidance to the main points of each video segment
through these elements of the video segments. However, at no point does
one video segment refer to another video segment nor do the authors refer
to specific textbook chapters. Thus, you have considerable freedom to use
the video segments as you wish, and you may find that you can show a video
segment with a chapter with which we did not expect that video segment to
fit. We encourage you to use the video segments creatively and to share your
insights on the video segments with others through the WWW site on the
textbook maintained by the publisher, Addison Wesley Longman.

Video 1: “Making the Business Case” (Length–12:19)

This video segment (which we suggest can be used best with Chapters 5 and
6) highlights two of the most common issues facing a systems analyst:
identifying the true business problem and linking the systems solution to the
problem and to the needs of the business. The situation depicted in the video
segment involves two principle roles: (1) Alice Carlson, a marketing manager
with an interest in store operations, and (2) Max Davis, a continuous
improvement specialist in the systems engineering group at BEC (Max is
really a systems analyst with a special focus).

This video segment illustrates various important points about the orientation
of systems work and about some traps into which systems analysts and user
managers can fall, including:

 Common requirements collection techniques, such as observation and

interviewing, are not foolproof, since they can capture perspectives, not
reality. The results of these techniques still must be scrutinized for logical
consistency, accuracy, and completeness. Sound, logical thinking is an
essential requirement for a systems analyst, and may be the real value–
added benefit a systems analyst provides to the organization.

 Technical solutions, when reached too quickly, may not deal with the
most important business issues. The video segment shows how Max
works to deals with business issues first, and how he bases the business
case for a new system not on the “neat” features of the system but on
the business reason why a system with specific features is needed.

 Systems analysts have a unique position within organizations that enable

them to have tremendous impact on business operations. Further,
systems analysts use analytical tools and study the organization in such
detail that they also possess unique and valuable insights about how to
improve the organization. Few business functional areas provide the
opportunities the systems field does for a person to develop such insights
about operations, how the organization works, and how the organization
might be improved.

Following are some questions you can use to stimulate discussion about this
video segment.
  What does the Deming quote shown at the beginning of the video
segment and the other references about continuous improvement have
to do with the issues encountered in this video segment?

 How might Max have used the business model graphic shown early in the
video segment to help identify the real problem and to develop the
business case for the proposed system?

 Why did Alice Carlson come to the conclusion that an information kiosk
would be the solution to the problem she observed in BEC? Try to get into
the mind of a typical business manager; suggest why Alice might have
wanted to jump to this conclusion? As a systems analyst, what do you
have to do in your interactions with user managers to overcome these
tendencies?

 If you were Alice Carlson, what else could you have done to investigate
the initial observations about customers not being able to find the videos
they want?

 Why was Max Davis skeptical of Alice’s proposed solution? Was he

skeptical? What special training or experience might Max have had that
made him respond to Alice’s suggestions as he did? How was he able to
respond this way and at the same time not insult Alice?

 What is “a business case” as illustrated in this video segment? How does

this relate to the notion of a business case developed in Chapters 5 and 6
of Modern Systems Analysis and Design?

What was the agenda for the marketing information systems steering
committee meeting shown in the video segment? Given that we might not
have seen the whole meeting, what agenda items do you think were not
shown or should have been included in the meeting?

Why does the kiosk appear near the end of the video segment given that it
was not part of the systems solution? What does this appearance of the
kiosk say about the mix of systems development projects often found in
an organization?

What other key points would you add to the summary of the lessons of this
video segment given by Professor Hoffer at the end of the segment?

Video 2: “Joint Application Design” (Length–18:17)

This video segment (which we suggest can be used best with Chapters 1 and
7) highlights the reasons for, benefits of, and conduct of an increasingly
popular requirements determination and validation technique—Joint
Application Design (JAD). The video segment does not raise issues about this
technique, rather it illustrates the motivation for JAD and how a JAD session is
planned and conducted. The situation depicted in the video segment involves
five principle roles: (1) Alice Carlson, a marketing manager, who does the
narration in the video segment and who was the initiator of the information
kiosk into BEC, (2) Andy Collins, a central district manager responsible for 27
BEC retail outlets and the initiator of the project to enhance the kiosks, (3)
Nancy Chen, VP of US operations and the sponsor of the JAD, (4) Jorge Lopez,
a systems analyst, and (5) Frank Napier, a systems analyst.

The video segment illustrates many important points about a JAD including
the steps required to conduct a JAD, with emphasis on the planning and
preparation steps. The overall JAD process as described in the video segment
is:

 Approach someone to be an executive sponsor to champion the JAD

 Conduct a definition meeting in which the following are agreed upon:

goals for the JAD, an agenda for the one or several sessions, a time line
for when to hold the sessions, a scope for the project and range of users
and other stakeholders affected, a list of attendees/invitees, and a
definition document which outlines all of these elements

 Preparation by the session leader / facilitator who schedules the sessions

and conducts an orientation session with relevant system analysts to
learn more about the business area to be addressed in the JAD

 Kickoff session conducted by the executive sponsor (at the beginning of

the first JAD session) to motivate the attendees

 The JAD sessions themselves

 Finalization, during which the scribe and facilitator complete a design

document, or blueprint for the development team, which summarizes the
findings of the JAD (attendees then sign–off on this document)

Following are some questions you can use to stimulate discussion about this
video segment:

 In what ways did the JAD in the video segment seem to be conducted
differently than the way a JAD is described in the text?

 Summarize the reasons for and benefits of a JAD raised in the video
segment. What additions would you make that were not mentioned in the
video segment?

 Why does the video segment stress the need for significant preparation
for a JAD?

 Why is an executive sponsor necessary / desirable for a JAD? What is this

person’s role before, during, and after a JAD?
  If you were Andy Collins, how would you have picked the facilitator for
the JAD illustrated in the video segment? What role does the systems
development group potentially play in training and providing facilitators?
Where might you go to find a facilitator if you were Andy?

 What role might prototyping play in a JAD? Under what conditions might it
be possible for a prototyping team to be of value during a JAD?

 Why was it Andy Collins, not one of the systems analysts, who was
getting Nancy Chen to sign–off on the development project which was the
result of the JAD?

 What other key points would you add to the summary of the lessons of
this video segment given by Professor Hoffer at the end of the video
segment?

Video 3: “Managing Expectations” (Length–12:14)

This video segment (which we suggest can be used best with Chapters 2, 7,
and 20) highlights the importance of a customer focus in developing
information systems. The video segment illustrates some of the problems
that can arise for a systems analyst when requirements are not thoroughly
investigated. The video segment also shows how difficult it is for users and
analysts to develop a shared understanding of requirements. The situation
involved in this video segment includes four roles: two systems analysts
(Doug and Lee) and two unnamed user mangers. The video segment shows
two versions of what might happen during a JAD session, one session in which
the analysts are not very aggressive in probing for requirements and one in
which the analysts dig more deeply into the minds and wishes of the users.

This video segment highlights that an analyst has to do more than just listen
to users during requirements collection sessions, such as in a JAD. Analysts
also have to probe, question, and pose what if situations. The analyst must
elicit requirements, even those not obvious to users. Analysts have to find
ways to avoid saying “we didn’t know you wanted us to build the system to
do ...”

Following are some questions you can use to stimulate discussion about this
video segment.

 The textbook discusses the potential costs during implementation and

maintenance if accurate requirements are not captured. Based on this
video segment, what are the possible consequences of not getting
requirements right by the time analysts present a logical system design
to users?

 What can an analyst (and the systems development methodology) do to

develop a shared understanding of system requirements with users?
 How can a systems analyst get users to speak the unspoken or assumed
system requirements?

 Why is it likely that users and analysts have different expectations for a
system?

 What can an analyst do if different users have different expectations for a

system?

 What other key points would you add to the summary of the lessons of
this video segment given by Professor Hoffer at the end of the video
segment?

Video 4: “Application Engineering” (Length–10:34)

This video segment (which can be used with various chapters in the second
edition of Modern Systems Analysis and Design, such as Chapters 1, 3, 7, and
13) introduces the notion to students that systems development can be
viewed as an engineering–like discipline. Systems development is discussed
in the video segment as a continuous improvement process in which not only
the business is continuously improved but also the methods and practices of
systems development are refined. The video segment emphasizes that the
purpose of application development is to improve the business and its
processes via the design and improvement of information systems. These
information systems add value to the organization. There are three principle
roles in this video segment: Karen, who is a BEC manager with operations
responsibilities, and two systems analysts—Max Davis and Jordan Pippen—
who have recently won the approval of a steering committee for funding a
new information systems project.

The video segment is driven by Karen’s questions as she tries to better

understand why Max and Jordan were successful in gaining the approval for
the project. The video segment discusses how Max and Jordan picked a
systems development method based on criteria developed from experience
that taught BEC when to apply different development methods. Max and
Jordan explain how they work with proven, yet evolving, methods which when
followed carefully have a high likelihood of success. There are strong
implications that systems development follows the same type of repeatable,
well planned, tested, and coordinated methods as are found in classical
engineering and R&D fields.

Following are some questions you can use to stimulate discussion about this
video segment:

 Compare how Max and Jordan explain RAD to how RAD is presented in the
textbook. What makes RAD different from the traditional structured
systems development life cycle?
 What does it mean to say that systems development is an engineering–
like discipline? From this video segment and your own experience, what
characteristics does systems development have that qualifies it to be
called “application engineering?”

 Describe the step of a system post audit mentioned in the video segment.
Why is this step considered part of the project close down and not part of
maintenance?

 In what ways might a systems development process be improved from

experience? If you think of the systems development process itself as a
system, what “systems” development process should be followed for
developing and maintaining the systems development process?

 What personal characteristics must systems developers have that will

allow them to be so open to changes in the methods, techniques, and
tools they use, which would characterize the constant improvement of
the systems development process implied in this video segment?

 What other key points would you add to the summary of the lessons of
this video segment given by Professor Hoffer at the end of the video
segment?