Project 2

1

2

: Organic House Step

3

4

5

tracking

6

7

4. Order Use Case Diagram

5. Customer Use Case Diagram

6. Detailed Grocery Case Diagram

MODULE CLASS DIAGRAM

Finding and Analysis

Product

· User chooses the menu by default category or by entering keywords – If the user wants to search by keyword processed to – The user enters the keyword of the product.

· System searches inventory for products that matches the keywords entered. 2.4. System returns the result and display products that are matched, process to – System display product by default category.

· Users add products to shopping carts or end browsing.

· If a user wants to add another product, proceed to

· User decides if he/she wants to modify the product in the shopping cart.

· If a user wants to modify, proceed to

· User makes changes to the shopping cart.

· System updates the shopping carts according to the user’s selected items.

· System displays all selected products in the shopping cart.

Order

· The user sends orders by desktop/mobile application.

· The system sends cart information which user selected

· The system calculates the total amount of the products.

· User checkout

· The app sends user’s selected items information

· The system displays the total amount, proceed to User will be notified the item is out of stock System will display payment options.

· User select payment options

· User pays by credit/debit cards.

· Users have the option to use loyalty points.

· The system prompts the user to select payment confirmation option.

· If the user confirms the payments, proceed to a successful transaction

· If the user rejects the payments, the process – Transaction successful – Bill will be printed.

· Products ready for delivery or pickup

Delivery

· Tracking number assigned to delivery.

· User location is located.

· Users are notified before the order is dispatched.

· User notified on arrival of product. – Delivery completed successfully.

User Updating

· The user wants to update information on the system.

· The system requires users to log in with an existing account.

· If they don’t have an account, proceed

· The system validates the user account.

· If user input is valid, proceed to profile account and system display

· If user input is invalid, proceed to user log-in

· The system displays the account holder’s profile.

· Users can change and update addresses, telephone, and emails and reset passwords.

· Users cannot delete the existing profile.

· The system sends the confirmation that the setting has been updated.

· App guide the user to the homepage

Authentication
User

As a new customer, I want to be able to register myself into the database of the system and create my own account so that I could gain full access to the app functionalities.

Acceptance criteria

· I must choose a username and password.

· I could enter my personal information such: address, city, telephone number, and country.

· After completing registration, I should receive an activation code.

· I should be required to provide that activation code and validate my account. – I should be able to log in and use the app

Product
User

As a customer, I want to enter keywords so that I can view a list of products that I want to see for order followed by adding them into the shopping cart.

Acceptance criteria

· Available products are displayed.

· I can search for products by entering keywords.

· I can add products to the shopping cart.

· I can delete products from the shopping cart.

· I can finalize my order.

Order
User

As a customer, I want to order products and I want to have the option of paying my orders with different types of visa and debit cards.

Acceptance criteria

· Order products are displayed so I can change my product.

· I can cancel my order

· I can remove orders from my account

· I can pay my orders with visa, debit and redeem my points card

References:

Costain, G., & McKenna, B. (2011). Experiencing the elicitation of user requirements and recording them in use case diagrams through role-play. Journal of Information Systems Education, 22(4), 367-380.

Furterer, S. L. (2020, June). Applying Systems Engineering Tools to Model a Food Justice

System in an Engineering Management Course. In 2020 ASEE Virtual Annual

Conference

Gemino, A., & Parker, D. (2009). Use case diagrams in support of use case modeling: Deriving understanding from the picture. Journal of Database Management (JDM), 20(1), 1-24.

Satzinger, J. W., Jackson, R. B., & Burd, S. D. (2012). Systems analysis and design in a changing world (6th ed). Course Technology, Cengage Learning.

https://www.netsuite.com/portal/resource/articles/accounting/procurement.shtml

https://arcoro.com/blog/most-common-hr-issues-solutions/

Organic House.

Team Members
Contributions:
Qing Jin: Target Market, Business Strategy, Foreseen Demands, System vision document
Naga Srinivas Guntupalli: Summary of the major systems in our company (Warehousing, shipping, marketing), System diagrams, Use case table and diagrams
Pranil Mali: Organizational Chart, Typical business system of our company, Process improvement for some of the business functions.

Target Audience
Individuals and families who are health conscious
Love organic food and products of high quality
Care about where their food comes from and how it has been produced
Enjoy shopping groceries online/offline

Business Strategy
Products of High Quality
Only natural and organic products of high quality
Product traceability and transparency
Online Shopping System with Same-day Delivery or Pickup
Shop on customers’ own schedule
Fast delivery with only a few clicks
Inclusive Culture
Hire staff that represents all our multicultural customers
Ensure diversity in suppliers and vendors

Demands Foreseen for Our Business
Increase Product Diversity and Add More Non-food organic Items
Personal care products, alcohol, clothing
Personalize Shopping Experience for Each Customer
Customize shopping experience based on unique needs

Organizational Chart
Following are the fictional officers, directors and managers of our company Called, “ ———————-”
Pranil Mali
President (CEO)
Vice president – Marketing and Sales
Naga Srinivas Guntupalli
Vice President – Finance and systems
Qing Jin
Vice president – Merchandising and Distribution

Continued…………
James Hoyme
Director of Operations and Purchasing
David Brunner
Director of Retail Sales
Erik Spencer
Director of System Development and support
Brian Hunt
Manager – Warehousing and Shipping

Fictional organizational chart:
To give a brief overview of our company we have formed a fictional organizational chart, which gives us a brief overview of different roles and responsibilities of individuals in our organization.

Typical business system of our company (What system is broken)
High-level picture of our company which shows the typical business system is show below.
This explains the different business functions and business processes our company has which eventually helps us to achieve our business outcome.

System Vision Document
Problem Description
In order to meet the growing demand from our customers, we plan to upgrade our current mobile websites to a mobile app, since the webpages are not able to cater to all the needs of our customers anymore.
System Capabilities
Support secure checkout and payment
Provide smoother user experience
Offer better customization options and instant customer service

System Vision Document
Business Benefits
Retain existing customers and attract new ones
Grow trust and loyalty in customers
Connect with our customers and build a stronger brand

Concise Summary
Warehouse: Tracking number assigned to delivery, User location is located. User notified before the order is dispatched, User notified on arrival of product, and delivery completed successfully.
Shipping: Customer browses the list of products by keyword searching or listing all of available products and then adding selected products into the shopping cart and deleting them from the cart.
Marketing: Application guide the user to the homepage, via social media and Internet.
Operations: Transaction processing systems that permits the organization to interact with external environments. it is essential to the day-to-day operations of business that these systems function smoothly and without interruption
Customer services: The agile approach based software development with values, principles, and core practices and four values are communication, simplicity, feedback, and courage for improving customer interaction with the software

Updating
User Updating
User wants to update information on the system.
System require user login with existing account.
Product
As customer want to enter keywords so that they can view a list of products that they want to see for order followed by adding into the shopping cart.
Shipping system
System updates the shopping carts according the user’s selected items.
System display all selected products in the shopping cart.

User updating (If they don’t have account, proceed System validates the user account, If user input is valid, proceed to profile account and system display If user input is invalid, proceed to user log-in, System displays the account holder’s profile, User can change and update address, telephone, and emails and reset passwords, User cannot delete the existing profile, System sends the confirmation that setting has been updated, App guide the user to the homepage)
Product (System updates the shopping carts according the user’s selected items and System display all selected products in the shopping cart).
Shipping system (System searches inventory for products matches the keywords entered. System returns the result and display products that matched, process and System display product by default category).

System Diagrams

1. Authentication/Registration Subsystem
2. Products Subsystem
3. Order Subsystem
4.Delivery Subsystem
5. User Updating Subsystem
6. Loyalty Subsystem
7. Tracking Subsystem
8. Report Subsystem

Use Case Diagram

1.2 User requests to login.
If user don not have an account, process to 1.2 registration.
1.1.3. User enter ID and password.
1.1.4. System verify the user ID and password, process to 1.1.5.
1.1.4.1. If it is invalid, process to 1.3.
1.1.4.2. If user failed to provide correct user ID and password in three successive attempts, block the account for 20 minutes and back to home page.
1.1.5. User is logged in.

References
Satzinger, J. W., Jackson, R. B., & Burd, S. D. (2012). Systems analysis and design in a changing world (6th ed). Course Technology, Cengage Learning.
Gemino, A., & Parker, D. (2009). Use case diagrams in support of use case modeling: Deriving understanding from the picture. Journal of Database Management (JDM), 20(1), 1-24.
Costain, G., & McKenna, B. (2011). Experiencing the elicitation of user requirements and recording them in use case diagrams through role-play. Journal of Information Systems Education, 22(4), 367-380.
Furterer, S. L. (2020, June). Applying Systems Engineering Tools to Model a Food Justice System in an Engineering Management Course. In 2020 ASEE Virtual Annual Conference
https://www.netsuite.com/portal/resource/articles/accounting/procurement.shtml
https://arcoro.com/blog/most-common-hr-issues-solutions/

THANK YOU

Team project

Team project

Team project

ISEM 530: Analysis and Design of Information Systems

Project Part 2

Detailed Design:

1. Refer to work done for Project Part 1 as a reference.

2. Summarize the contents of Project Part 1 for clarity.

3. Each team member should provide a Storyboard for one of the dialogs you identified. (See Chapter 8 of your textbook, Figure 8-18)

4. Each team member should provide a class abstract with subclass for at least one of the objects (See

Chapter 12 of the textbook, Figure 12-11).

5. Add Sequence Diagrams for your use cases with data access layer (See

Chapter 13 of your textbook, Figure 13-23).

6. Add a Communications Diagram for your use cases (See Chapter 13 of your textbook, Figure 13-9).

7. Describe how to make your system operational (high-level steps – implementing, testing, deploying etc.). (See Chapter 14 of your textbook.)

8. Research any Commercial Off the Shelf (COTS) that will satisfy your requirements. List at least one

COTS you found and describe at least one in more detail.

Deliverables:

1- Report: Submit a word document including the 8 Steps above.

2- PowerPoint file: Summarize your team’s work in a PowerPoint slide presentation and submit it:

1. The PowerPoint slides will be a team presentation in class.

2. Slide 1 should be a title page

3. Slide 2 should clearly specify the team members with Contribution noted as a percentage.

4. Slide 3 should be a summary of your fictional company (from project part 1).

5. Slide 4 should be a concise summary of the major systems in your company.

6. Slide 5 should be a clear statement about the system that is being updated or changed.

7. Slide 6 – XX: will present your designs to propose to your board of directors. Use diagrams or text from the required elements on page 1.

8. The Last slide should represent your references.

9. Depending on available class time, we may have to stop presentations that are too long.

10. The last slide should specify references.

11. One person from the group will upload the Report and PowerPoint.

The team’s slide presentation should be timed to last about 30 minutes. At 30 minutes we may need to stop the presentation based on time. Each team member should speak about their contribution.

S I X T H E D I T I O N
SYSTEMS ANALYSIS
AND DESIGN
I N A C H A N G I N G W O R L D
John W. Satzinger
Missouri State University
Robert B. Jackson
RBJ and Associates
Stephen D. Burd
University of New Mexico
Australia • Brazil • Japan • Korea • Mexico • Singapore • Spain • United Kingdom • United States

This is an electronic version of the print textbook. Due to electronic rights restrictions,
some third party content may be suppressed. Editorial review has deemed that any suppressed
content does not materially affect the overall learning experience. The publisher reserves the right
to remove content from this title at any time if subsequent rights restrictions require it. For
valuable information on pricing, previous editions, changes to current editions, and alternate
formats, please visit www.cengage.com/highered to search by ISBN#, author, title, or keyword for
materials in your areas of interest.

www.cengage.com/highered

Systems Analysis and Design in a
Changing World, Sixth Edition
John W. Satzinger, Robert B. Jackson,
Stephen D. Burd
Publisher: Joe Sabatino
Senior Acquisitions Editor: Charles
McCormick Jr.
Senior Product Manager: Kate Mason
Development Editor: Kent Williams
Editorial Assistant: Courtney Bavaro
Marketing Director: Keri Witman
Marketing Manager: Adam Marsh
Senior Marketing Communications
Manager: Libby Shipp
Marketing Coordinator: Suellen Ruttkay
Design Direction, Production
Management, and Composition:
PreMediaGlobal
Media Editor: Chris Valentine
Senior Art Director: Stacy Jenkins Shirley
Cover Designer: Itzhack Shelomi
Cover Credit: ©iStock Photo
Manufacturing Coordinator: Julio Esperas
© 2012 Course Technology, Cengage Learning
ALL RIGHTS RESERVED. No part of this work covered by the copyright herein
may be reproduced, transmitted, stored, or used in any form or by any means
graphic, electronic, or mechanical, including but not limited to photocopying,
recording, scanning, digitizing, taping, Web distribution, information networks, or
information storage and retrieval systems, except as permitted under Section 107
or 108 of the 1976 United States Copyright Act, without the prior written
permission of the publisher.
For product information and technology assistance, contact us at
Cengage Learning Customer & Sales Support, 1-800-354-9706.
For permission to use material from this text or product,
submit all requests online at www.cengage.com/permissions.
Further permissions questions can be e-mailed to
permissionrequest@cengage.com.
Some of the product names and company names used in this book have been
used for identification purposes only and may be trademarks or registered
trademarks of their respective manufacturers and sellers.
Library of Congress Control Number: 2011940028
ISBN-13: 978-1-111-53415-8
ISBN-10: 1-111-53415-2
Instructor Edition:
ISBN-13: 978-1-111-53284-0
ISBN-10: 1-111-53284-2
Course Technology
20 Channel Center Street
Boston, MA 02210
USA
Screenshots for this book were created using Microsoft Visio® and Project®, and
were used with permission from Microsoft.
Microsoft and the Office logo are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries. Course
Technology, a part of Cengage Learning, is an independent entity from the
Microsoft Corporation, and not affiliated with Microsoft in any manner.
iPhone, iPad, iTunes, Macintosh, and Mac OS X are registered trademarks of
Apple Inc.
Course Technology, a part of Cengage Learning, reserves the right to revise this
publication and make changes from time to time in its content without notice.
Cengage Learning is a leading provider of customized learning solutions with
office locations around the globe, including Singapore, the United Kingdom,
Australia, Mexico, Brazil, and Japan. Locate your local office at:
www.cengage.com/global.
Printed in the United States of America
1 2 3 4 5 6 7 15 14 13 12 11

www.cengage.com/permissions

www.cengage.com/global

DEDICATION
To my wife JoAnn—JWS
To my immediate and extended family—RBJ
To Dee, Amelia, and Alex—SDB

BRIEF CONTENTS
P A R T O N E An Introduction to Systems Development
1 From Beginning to End: An Overview of Systems Analysis and Design 3
Optional Online Chapter A The Role of the Systems Analyst
P A R T T W O Systems Analysis Activities
2 Investigating System Requirements 35
3 Use Cases 67
4 Domain Modeling 91
5 Extending the Requirements Models 119
Optional Online Chapter B The Traditional Approach to Requirements
P A R T T H R E E Essentials of Systems Design
6 Essentials of Design and the Design Activities 153
7 Designing the User and System Interfaces 187
P A R T F O U R Projects and Project Management
8 Approaches to System Development 225
9 Project Planning and Project Management 253
Optional Online Chapter C Project Management Techniques
P A R T F I V E Advanced Design and Deployment Concepts
10 Object-Oriented Design: Principles 293
11 Object-Oriented Design: Use Case Realizations 327
12 Databases, Controls, and Security 371
13 Making the System Operational 409
14 Current Trends in System Development 443
Index 481
iv

CONTENTS
Preface xvi
P A R T O N E An Introduction to Systems Development
1 From Beginning to End: An Overview of Systems Analysis
and Design 3
Software Development and Systems Analysis and Design 4
Systems Development Life Cycle 5
Introduction to Ridgeline Mountain Outfitters 6
Iterative Development 8
Developing RMO’s Tradeshow System 9
Where You Are Headed—The Rest of This Book 26
Chapter Summary 28
Review Questions 28
Chapter Case 29
P A R T T W O Systems Analysis Activities
2 Investigating System Requirements 35
Overview 36
The RMO Consolidated Sales and Marketing System Project 37
Systems Analysis Activities 40
What Are Requirements? 42
Models and Modeling 44
Stakeholders 46
Information-Gathering Techniques 48
Documenting Workflows with Activity Diagrams 57
Chapter Summary 60
Review Questions 61
Problems and Exercises 61
Case Study 62
Running Cases 63
Further Resources 66
v

3 Use Cases 67
Overview 68
Use Cases and User Goals 69
Use Cases and Event Decomposition 70
Use Cases and CRUD 77
Use Cases in the Ridgeline Mountain Outfitters Case 78
Use Case Diagrams 78
Chapter Summary 85
Review Questions 85
Problems and Exercises 86
Case Study 87
Running Case Studies 88
Further Resources 90
4 Domain Modeling 91
Overview 92
“Things” in the Problem Domain 92
The Entity-Relationship Diagram 98
The Domain Model Class Diagram 101
Chapter Summary 112
Review Questions 112
Problems and Exercises 113
Case Study 115
Running Case Studies 116
Further Resources 118
5 Extending the Requirements Models 119
Overview 120
Use Case Descriptions 121
Activity Diagrams for Use Cases 125
The System Sequence Diagram—Identifying Inputs and Outputs 126
The State Machine Diagram—Identifying Object Behavior 132
Integrating Requirements Models 142
Chapter Summary 143
Review Questions 144
Problems and Exercises 145
Case Study 147
Running Case Studies 148
Further Resources 150
P A R T T H R E E Essentials of Systems Design
6 Essentials of Design and the Design Activities 153
Overview 155
The Elements of Design 155
vi CONTENTS

Inputs and Outputs for Systems Design 159
Design Activities 160
Design the Environment 167
Chapter Summary 180
Review Questions 181
Problems and Exercises 182
Case Study 182
Running Case Studies 183
Further Resources 185
7 Designing the User and System Interfaces 187
Overview 188
User and System Interfaces 189
Understanding the User Interface 189
User-Interface Design Concepts 193
The Transition from Analysis to User-Interface Design 196
User-Interface Design 200
Identifying System Interfaces 208
Designing System Inputs 210
Designing System Outputs 211
Chapter Summary 218
Review Questions 219
Problems and Exercises 219
Case Study 220
Running Case Studies 221
Further Resources 222
P A R T F O U R Projects and Project Management
8 Approaches to System Development 225
Overview 226
The Systems Development Life Cycle 227
The Support Phase 232
Methodologies, Models, Tools, and Techniques 233
Two Approaches to Software Construction and Modeling 236
Agile Development 244
Chapter Summary 247
Review Questions 248
Problems and Exercises 249
Case Study 249
Running Case Studies 250
Further Resources 252
CONTENTS vii

9 Project Planning and Project Management 253
Overview 254
Principles of Project Management 255
Activities of Core Process 1: Identify the Problem and Obtain Approval 262
Activities of Core Process 2: Plan and Monitor the Project 271
Chapter Summary 283
Review Questions 283
Problems and Exercises 284
Case Study 286
Running Cases 287
Further Resources 289
P A R T F I V E Advanced Design and Deployment Concepts
10 Object-Oriented Design: Principles 293
Overview 294
Object-Oriented Design: Bridging from Analysis to Implementation 295
Object-Oriented Architectural Design 298
Fundamental Principles of Object-Oriented Detailed Design 304
Design Classes and the Design Class Diagram 308
Detailed Design with CRC Cards 314
Fundamental Detailed Design Principles 317
Chapter Summary 320
Review Questions 321
Problems and Exercises 322
Case Study 323
Running Cases 323
Further Resources 325
11 Object-Oriented Design: Use Case Realizations 327
Overview 328
Detailed Design of Multilayer Systems 329
Use Case Realization with Sequence Diagrams 332
Designing with Communication Diagrams 349
Updating and Packaging the Design Classes 351
Design Patterns 356
Chapter Summary 361
Review Questions 361
Problems and Exercises 362
Case Study 367
Running Case Studies 367
Further Resources 369
viii CONTENTS

12 Databases, Controls, and Security 371
Overview 373
Databases and Database Management Systems 373
Relational Databases 374
Data Access Classes 387
Distributed Database Architectures 387
Database Design Timing and Risks 391
Designing Integrity Controls 392
Designing Security Controls 396
Chapter Summary 403
Review Questions 404
Problems and Exercises 404
Case Study 405
Running Case Studies 406
Further Resources 408
13 Making the System Operational 409
Overview 410
Testing 411
Deployment Activities 417
Planning and Managing Implementation, Testing, and Deployment 423
Putting It All Together—RMO Revisited 434
Chapter Summary 437
Review Questions 438
Problems and Exercises 438
Case Study 439
Running Case Studies 439
Further Resources 441
14 Current Trends in System Development 443
Overview 444
Trends in System Development Methodologies 445
Trends in Technology Infrastructure 457
Trends in Application Software Availability 461
The Web as an Application Platform 465
Chapter Summary 475
Review Questions 476
Problems and Exercises 476
Case Study 477
Running Case Studies 478
Further Resources 480
Index 481
CONTENTS ix

FEATURES
Systems Analysis and Design in a Changing World, Sixth Edition, was written
and developed with instructor and student needs in mind. Here is just a sample
of the unique and exciting features that help bring the fi eld of systems analysis
and design to life.g
BRIEF CONTENTS
P A R T O N E An Introduction to Systems Development
1 From Beginning to End: An Overview of Systems Analysis and Design 3
Optional Online Chapter A The Role of the Systems Analyst
P A R T T W O Systems Analysis Activities
2 Investigating System Requirements 35
3 Use Cases 67
4 Domain Modeling 91
5 Extending the Requirements Models 119
Optional Online Chapter B The Traditional Approach to Requirements
P A R T T H R E E Essentials of Systems Design
6 Essentials of Design and the Design Activities 153
7 Designing the User and System Interfaces 187
P A R T F O U R Projects and Project Management
8 Approaches to System Development 225
9 Project Planning and Project Management 253
Optional Online Chapter C Project Management Techniques
P A R T F I V E Advanced Design and Deployment Concepts
10 Object-Oriented Design: Principles 293
11 Object-Oriented Design: Use Case Realizations 327
12 Databases, Controls, and Security 371
13 Making the System Operational 409
14 Current Trends in System Development 443
Index 481
hiking, ATV biking, camping, mountain climbing, rappelling—all had seen a
tremendous increase in interest in these states. People needed appropriate sports
clothes for these activities, so RMO expanded its line of sportswear to respond
to this market. It also added a line of high-fashion activewear and accessories
to round out its offerings to the expanding market of active people.
The company’s growth charted an interesting history of mail-order, brick-
and-mortar, and online sales. RMO got its start by selling to local clothing
stores in the Park City, Utah, area. In the late-1980s and early-1990s, it began
selling directly to customers by using catalogs with mail-in and telephone
orders. It opened its first store in 1994 and soon expanded to 10 retail outlets
throughout the West. Last year, retail store revenue was $67 million, telephone
and mail-order revenues were $10 million, and Web-based sales were $200 mil-
lion. Most sales continue to be in the West, although the market in several areas
of the eastern United States and Canada is growing.
RMO produces its own line of outdoor and sportswear clothing. However,
in order to offer a complete range of outdoor clothing in its retail outlets, it
also sells other brands of outdoor and sportswear clothing. In addition, other
types of clothing and accessories, such as footwear, leather apparel, and spe-
cialty sportswear, are available in the retail stores and through the online store.
Figure 1-2 shows a sample of the catalogs that RMO mails out. Although
mail-order and telephone sales are small, receiving the catalog encourages custo-
mers to go online to make purchases, so RMO continues to produce and mail
abbreviated versions of its catalogs.Figure 1-3 illustrates a typical order page from the online system.
Trade Shows
In order to keep its product line current and popular, RMO’s purchasing agents
attend apparel and fabric trade shows around the world. RMO purchasers have
a good track record of predicting what products will be good sellers. In addi-
tion, RMO is always watching for new products and accessories that will enable
it to expand its product line appropriately.
When purchasing agents attend a trade show, they frequently find various
products that they want to add to the spring, summer, or winter apparel offering.
2012 WINTER CATALOG
2012 W
IN
TER CATA
LO
G
FIGURE 1-2
RMO winter catalog
CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 7
a formal p
rocess to g
et a projec
t approved
; other org
anizations
have a les
s for-
mal proce
ss. Norma
lly, there
are two g
oals an or
ganization
must decid
e on to
get a proje
ct off the g
round:
■ Identify t
he problem
and docum
ent the ob
jective of t
he solution
system.
(Core Proc
ess 1)
■ Obtain a
pproval to
commence
the projec
t. (Core Pr
ocess 1)
System Visi
on Docume
nt
As with al
l new proj
ects within
RMO, a S
ystem Visi
on Docum
ent is deve
loped to
identify th
e benefits
to the com
pany and
the functio
nal capabi
lities that
will be
included in
the system
. Frequent
ly, this is d
one in two
steps: deve
loping a p
relimi-
nary statem
ent of ben
efits and t
hen addin
g estimate
s of specif
ic dollar c
osts and
dollar ben
efits. Figur
e 1-5 is th
e System V
ision Docu
ment for t
his project
.
Problem D
escription
Trade sh
ows hav
e becom
e an imp
ortant in
formatio
n source
for new
product
s, new
fashions
, and ne
w fabrics
. In addi
tion to th
e large p
roviders
of outdo
or clothin
g and
fabrics, t
here are
many sm
aller pro
viders. It
is impor
tant for R
MO to ca
pture inf
ormation

about th
ese supp
liers whi
le the tra
de show
is in pro
gress. It
is also i
mportan
t to obta
in
informat
ion abou
t specific
mercha
ndise pr
oducts th
at RMO
plans to
purchas
e.
Addition
ally, if qu
ality pho
tographs
of the p
roducts
can be o
btained
while at
the trade

show, th
en the c
reation o
f online p
roduct p
ages is g
reatly fa
cilitated.
It is reco
mmende
d that a
new sys
tem be d
eveloped
and dep
loyed so
field pur
chasing
agents c
an comm
unicate m
ore rapid
ly with th
e home
office ab
out supp
liers and
specific
products
of intere
st. This s
ystem sh
ould be
deployed
on porta
ble equip
ment.
System V
ision Doc
ument
RMO Trad
eshow Sy
stem
System C
apabilities
The new
system
should b
e capab
le of:
• Collec
ting and
storing
informat
ion abou
t the ma
nufactur
er/whole
saler (su
ppliers)
• Collec
ting and
storing
informat
ion abou
t sales re
presenta
tives and
other ke
y
person
nel for e
ach supp
lier
• Collec
ting infor
mation a
bout pro
ducts
• Taking
pictures
of produ
cts (and
/or uploa
ding stoc
k images
of produ
cts)
• Functi
oning as
a stand
-alone w
ithout co
nnection
• Conne
cting via
Wi-Fi (In
ternet) a
nd trans
mitting d
ata
• Conne
cting via
telepho
ne and t
ransmitt
ing data
Business
Benefits
It is antic
ipated th
at the de
ploymen
t of this n
ew syste
m will pr
ovide the
followin
g
business
benefits
to RMO
:
• Increa
se timely
commu
nication
between
trade sh
ow atten
dees an
d home
office,
thereb
y improv
ing the q
uality an
d speed
of purch
ase orde
r decisio
ns
• Mainta
in correc
t and cu
rrent info
rmation
about su
ppliers a
nd their
key pers
onnel,
thereb
y facilita
ting rapi
d comm
unication
with sup
pliers
• Mainta
in correc
t and rap
id inform
ation an
d image
s about
new pro
ducts, th
ereby
facilita
ting the
developm
ent of ca
talogs an
d Web p
ages
• Exped
ite the p
lacing of
purchas
e orders
for new
mercha
ndise, th
ereby ca
tching
trends
more ra
pidly and
speedin
g up pro
duct ava
ilability
FIGURE 1
-5
Tradeshow
System Vi
sion Docum
ent
10 PART
1 ■ An Int
roduction t
o Systems
Developme
nt
The innovative and entirely new text organization starts
with a complete beginning-to-end system development
example, moves immediately to systems analysis models
and techniques, and then to system design concepts
emphasizing system architecture, user interfaces, and
system interfaces. Analysis and much of design is
covered in the fi rst seven chapters. Next, the text focuses
on managing system development projects, including
contemporary approaches such as Agile development,
the Unifi ed Process, Extreme Programming, and Scrum,
after the student has a chance to learn what is involved
in system development. Finally, the text covers detailed
design topics, deployment topics, and current trends.
The text uses a completely updated integrated case study
of moderate complexity—Ridgeline Mountain Outfi tters
(RMO)—to illustrate key concepts and techniques. In
addition, a smaller RMO application—the Tradeshow
System—is used in Chapter 1 to introduce the entire
system development process.

FEATURES
solution to customer demand for catalog phone and mail orders. It is
integrated with the SCM and has reached capacity.
■ Retail Store System (RSS)—A retail store package with point-of-sale proces-
sing. It was upgraded eight years ago from overnight batch to real-time
inventory updates to/from the SCM.
■ Customer Support System (CSS)—This system was first deployed 15 years ago
as a Web-based catalog to support customer mail and phone orders. Four
years later, it was upgraded to an Internet storefront, supporting customer
inquiries, shopping cart, order tracking, shipping, back orders, and returns.
All organizations—including RMO—face a difficult challenge keeping all
their information systems current and effective. Because development resources
are limited, an organization’s technology and application architecture and its
information system inventory will include a mix of old and new. Older systems
were often designed for outdated operational methods and typically lack mod-
ern technologies and features that some competitors have adopted to improve
efficiency or competitiveness. Such is the case with RMO’s existing customer-
facing systems, which have several shortcomings, including:
■ Treating phone, Web, and retail sales as separate systems rather than as
an integrated whole
■ Employing outdated Web-based storefront technology
■ Not supporting modern technologies and customer interaction modes,
including mobile computing devices and social networking
Rather than incrementally update the existing sales systems, RMO plans to
replace them, as shown in Figure 2-1.
FIGURE 2-1 Proposed application architecture for RMO
Supply Chain Management (SCM) Consolidated Sales and Marketing System (CSMS)
Suppliers
Customers
Buyers
Retail Stores
Retail Sales
Phone Sales
CustomersTrade Show System (TSS)
Warehouses
Shipments
Orders
Shipments
Orders
Shipments
Online Sales
38 PART 2 ■ Systems Analysis Activities
The New Consolidated Sales and Marketing System
The goals of the Consolidated Sales and Marketing System (CSMS) are to modern-
ize the technology and functionality of the CSS and to add more customer-oriented
functionality. On the technology side, the CSMS will incorporate current Web
standards and be built under the assumption of high-bandwidth customer Internet
connections and high-resolution displays. Updating the technology will enable a
higher degree of interactivity, richer graphics, and a streamlined interface.
Key additions to system functionality will be support for mobile computing
devices, incorporation of customer feedback and comments into product informa-
tion, and integration of social networking functions. Unlike the CSS, the CSMS
will support smartphones and tablet computers with interfaces specifically designed
for each platform and with downloadable apps. Customer feedback will be
captured directly through the Internet storefront, from RMO-supported comment
forums and blogs, and mined from Facebook and Twitter. RMO will develop a
complete presence in each social networking venue and enable system users to
share purchases, recommendations, coupons, and store credits using those venues.
The new CSMS will also have four subsystems:
■ The Sales subsystem provides such basic functions as searching the online
catalog and purchasing items and paying for them online. However, it has
many new capabilities to assist the shopper making purchases. The system
will provide specific suggestions about accessories that go with the pur-
chased item. Images and videos of animated models will be available to help
the customer see how various items and accessory packages will look
together. The system will also provide information to shoppers about
related purchases made by other shoppers. Customer ratings and comments
are available for viewing. Finally, key social networking components will
permit shoppers to network with their friends by sending messages to ask
their opinions about particular merchandise items.
■ The Order Fulfillment subsystem will perform all the normal tasks of ship-
ping items and allowing customers to track the status of their orders as well
as the shipments. In addition, as part of order fulfillment, customers can rate
and make comments about particular merchandise and their overall shopping
experience. They may also make suggestions directly to RMO about the
attractiveness of the Web site and the quality of the service they received.
■ The Customer Account subsystem provides all those services that enhance the
customer experience. Customers can view and maintain their account informa-
tion. They also can “link up” with friends who are also customers to share
experiences and opinions on merchandise. The system will keep track of
detailed shipping addresses as well as payment preferences and information.
RMO also instituted a Mountain Bucks program wherein customers accumu-
late credits that can be used to redeem prizes as well as purchase merchandise.
Customers may use these Mountain Bucks for themselves or they may transfer
them to other people in their family/friends group. This is a great opportunity
to combine accumulated bucks to obtain expensive merchandise.
■ The Marketing subsystem is primarily for employees to set up the informa-
tion and services for customers. In this subsystem, employees can enter
information about all the merchandise offered by RMO. This subsystem is
also fed by the SCM system to maintain accurate data on the inventory in
stock and anticipated arrival dates of items on order. Employees also set up
the various promotional packages and seasonal catalogs by using the func-
tions of this subsystem. RMO is experimenting with a new idea to enhance
customer satisfaction: It is building partner relationships with other retailers
so that customers can earn “combined” points with RMO purchases or a
partner retailer purchase. These points can be used at RMO or transferred
and used at the partner. For example, because RMO sells outdoor and
sporting clothing, it has partnered with various sporting goods stores.
CHAPTER 2 ■ Investigating System Requirements 39
Performanc
e Considera
tions
Web sites
in general
and brow
ser-based
forms in
particular
are sensiti
ve to
application
design and
to the qua
lity of the
network c
onnections
between t
he
user’s com
puting dev
ice and th
e servers t
hat host th
e site. Wh
en a user
clicks a
hyperlink
or a contr
ol that act
s like a hy
perlink, th
e browser
sends info
rmation
entered by
the user (
if any) to
a Web ser
ver, along
with a req
uest for a
new
page. Tha
t informat
ion traver
ses multip
le network
s, is receiv
ed and pr
ocessed
by a serve
r, and the
n the resp
onse (a ne
w page to
be display
ed) is sent
back
over the n
etwork. T
he delay b
etween cli
cking a hy
perlink an
d the disp
lay of the
requested
page depe
nds on th
e amount
of data to
be transm
itted, the
display
and netwo
rk connect
ion speed
of the user
computing
device, the
capacity o
f the
networks
that carry
the messag
es, and th
e number
of other u
sers and a
pplica-
tions that
are compe
ting for th
at network
capacity.
A trade-of
f exists be
tween the
amount of
informatio
n transmit
ted betwee
n
the user’s
computing
device and
the server
and the tim
e it takes
for the pa
ge to
refresh; th
e more in
formation
that is tra
nsmitted,
the longer
the delay.
That
trade-off i
s especiall
y importa
nt for com
municatio
n over the
Internet, a
lthough
it is also a
significant
issue with
in corpora
te network
s when us
er desktop
s and
servers sha
re high-sp
eed conne
ctions.
There is a
lso a trad
e-off betw
een the a
mount of
informatio
n and oth
er
data cont
ained wit
hin a We
b page an
d a Web-
based app
lication’s
perfor-
mance. Pa
ges with e
xtensive in
formation
content or
with embe
dded prog
ram-
ming can
avoid or p
ostpone p
age refresh
es. For ex
ample, a p
age contai
ning a
blank ord
er form
may be q
uite smal
l. But ma
ny page
refreshes
will be
required i
f the brow
ser must i
nteract wi
th the ser
ver to val
idate ever
y input
as the use
r enters it
. If the pa
ge contain
ing the fo
rm also co
ntains em
bedded
validation
programs,
then man
y server i
nteraction
s and pag
e refreshe
s can
be avoide
d. Howev
er, the in
itial down
load of t
he page
will take
longer
because th
ere is mo
re content
and the v
alidation
programs
may be s
low if
the user c
omputing
device isn
’t very po
werful (e.
g., a relat
ively inex
pensive
cell phone
).
Designers
of Web-ba
sed user i
nterfaces
must perfo
rm a care
ful balanc
ing
act, provid
ing embed
ded “intel
ligence” w
ithin a pag
e to avoid
refreshes b
ut not
overloadin
g page con
tent so as
to avoid lo
ng delays
when the
user move
s from
page to pa
ge. Thoro
ugh testin
g is the be
st way to
ensure tha
t the right
balance
FIGURE 7
-11
Shopping c
art page fr
om RMO’s
Web site
CHAPTER 7
■ Designin
g the User
and System
Interfaces
205
An overview of the RMO
Consolidated Sales and Marketing
System (CSMS) is presented in
Chapters 1 and 2 to place the
projects in context. The planned
system architecture provides for rich
examples—a Web-based component,
a wireless smartphone/tablet
application, and a client/server
Windows-based component.
The new Consolidated Sales and Marketing
System (CSMS) is the system development
project used throughout the text for examples
and explanations. It is strategically important to
RMO, and the company must integrate the new
system with legacy systems and other planned
systems. There are four subsystems, and the
requirements and design models are all new in
this edition. UML diagrams are used throughout
for examples and exercises.

FEATURES
added. Th
us, the pro
ject can b
e carefully
planned, a
nd the sys
tem can b
e built
according
to the spec
ifications.
An adapti
ve approa
ch to the
SDLC is us
ed when th
e system’s
requiremen
ts
and/or the
users’ need
s aren’t w
ell underst
ood. In th
is situation
, the proje
ct can’t
be planne
d complet
ely. Some
system req
uirements
may need
to be dete
rmined
after prelim
inary deve
lopment w
ork. Devel
opers shou
ld still be
able to bu
ild the
solution, b
ut they nee
d to be fle
xible and a
dapt the p
roject as it
progresses
. Recall
that the Tr
adeshow s
ystem desc
ribed in Ch
apter 1 us
ed this app
roach.
In practic
e, any pr
oject coul
d have—a
nd most
do have—
predictive
and
adaptive e
lements. T
hat is wh
y Figure 8
-1 shows
them as e
ndpoints a
long a
continuum
, not as m
utually ex
clusive cat
egories. T
he predict
ive approa
ches are
more trad
itional an
d were co
nceived d
uring the
1970s thr
ough the
1990s.
Many of
the newer
, adaptive
approache
s have ev
olved with
object-orie
nted
technology
and Web
developme
nt; they w
ere created
during the
late-1990s
and
into the 2
1st centur
y. Let us
look at th
e more pr
edictive ap
proaches a
nd then
examine th
e newer ad
aptive app
roaches.
Traditional
Predictive A
pproaches
to the SDLC
The develo
pment of a
new inform
ation syste
m requires
a number
of differen
t but
related set
s of activi
ties. In pr
edictive ap
proaches,
there is a
group of
activities
that identi
fies the pr
oblem and
secures ap
proval to
develop a
new system
; this is
called pro
ject initiat
ion. A sec
ond group
of activitie
s, called p
roject plan
ning,
involves p
lanning, o
rganizing,
and sched
uling the
project. T
hese activi
ties map
out the pr
oject’s ove
rall structu
re. A third
group—an
alysis—foc
uses on di
scover-
ing and u
nderstandi
ng the det
ails of the
problem o
r need. Th
e intent he
re is to
figure out
exactly wh
at the syst
em must d
o to suppo
rt the busi
ness proce
sses. A
fourth gro
up—design
—focuses
on configu
ring and
structuring
the new s
ystem
componen
ts. These
activities u
se the req
uirements
that were
defined ea
rlier to
develop th
e program
structure a
nd the alg
orithms fo
r the new
system. A
fifth
group—im
plementati
on—includ
es program
ming and
testing the
system. A
sixth
group—de
ployment—
involves in
stalling an
d putting t
he system
into opera
tion.
These six
groups of
activities—
project ini
tiation, pr
oject plan
ning, anal
ysis,
design, im
plementat
ion, and d
eployment
—are som
etimes refe
rred to as
phases
of the sys
tem develo
pment pro
ject, and t
hey provid
e the fram
ework for
man-
aging the
project. A
nother ph
ase, called
the suppo
rt phase, i
ncludes th
e activi-
ties neede
d to upgr
ade and m
aintain th
e system
after it ha
s been de
ployed.
The suppo
rt phase is
part of the
overall SD
LC, but it
isn’t norm
ally consid
ered
part of th
e initial d
evelopmen
t project.
Figure 8-2
illustrates
the six ph
ases of
a tradition
al predicti
ve SDLC p
lus the sup
port phase
.
The most
predictive
SDLC app
roach (i.e.,
farthest to
the left on
the predict
ive/
adaptive s
cale) is ca
lled a wa
terfall mo
del, with
the phase
s of the p
roject
flowing do
wn, one a
fter anoth
er. As sho
wn in Figu
re 8-3, thi
s model a
ssumes
that the p
hases can
be carried
out and co
mpleted se
quentially.
First, a de
tailed
plan is de
veloped, t
hen the re
quirement
s are thor
oughly spe
cified, then
the sys-
tem is des
igned dow
n to the la
st algorith
m, and th
en it is pr
ogrammed
, tested,
and instal
led. After
a project
drops ove
r the wat
erfall into
the next
phase,
The choice
of SDLC v
aries depe
nding on th
e project
Predictive
SDLC
Adaptive
SDLC
Requireme
nts well un
derstood
and well d
efined.
Low techn
ical risk.
Requireme
nts and ne
eds
uncertain.
High techn
ical risk.
FIGURE 8
-1
Predictive
versus ada
ptive appro
aches
to the SDL
C
adaptive
approach
to the SD
LC an
approach tha
t assumes th
e project mu
st be
more flexible
and adapt to
changing ne
eds as
the project p
rogresses
phases
related grou
ps of develo
pment
activities, su
ch as planni
ng, analysis,
design,
implementat
ion, and sup
port
waterfall
model a
n SDLC appr
oach that
assumes the
phases can
be complete
d
sequentially
with no over
lap
228 PART
4 ■ Projec
ts and Proj
ect Manage
ment
etimes refe
ide the fra
mework f
or man-
rt phase, i
ncludes th
e activi-
after it ha
s been de
ployed.
ut it isn’t
normally c
onsidered
2 illustrate
s the six p
hases of
hase.
hest to the
left on the
predictive/
with the
phases of
the projec
t
Figure 8-3
, this mod
el assumes
ed sequen
tially. Firs
t, a detaile
d
oroughly s
pecified, th
en the sys
–
d then it i
s program
med, teste
d,
waterfall
into the n
ext phase
,
In the past, when RMO buyers wanted to place an order, they would exchange
contact information with the seller at the trade show and upon returning to the
home office would then follow up via e-mails and phone calls to formulate a con-
tract and make a purchase order. However, to expedite orders, RMO has now
initiated a project to develop a system for collecting and tracking information
about its suppliers and the new products it adds to its merchandise offerings.
Iterative DevelopmentIterative development is an approach to system development in which the sys-
tem is “grown” in an almost organic fashion. Core components are developed
first and then additional components are added. It is called “iterative” because
the six core development processes are repeated over and over again to add
additional functionality to the overall system. In other words, there is one big
project, which consists of many mini-projects, and the information system is
grown piece by piece.Figure 1-4 illustrates how an iterative Agile project might be executed. This
is a sample diagram. Real projects might be quite different. Across the figure,
you see six iterations. An iteration is like a mini-project in that it has a com-
pleted result and a constrained time frame. Often, it will last two to four weeks.
Down the left side of the figure, you see the six core processes. The rounded
FIGURE 1-3
RMO sample online ordering page
Core
Processes
1 2 3 4 5 6
Identify problem and obtainapproval
Plan and monitor the project
Discover and understand details
Design system components
Build, test, and integrate systemcomponents
Complete system tests and deploy
solution
Iterations
FIGURE 1-4
The six core processes, with iterations
for a typical project
iterative development an approach to
system development in which the system is
“grown” piece by piece through multipleiterations
8 PART 1 ■ An Introduction to Systems Development
The text describes predictive and adaptive
approaches to the SDLC and recommends
Agile, iterative development for most
projects. The SDLC used in the text
features a generic, condensed version of
the Unifi ed Process SDLC, which empha-
sizes iterations and core development
processes found in most current develop-
ment methodologies. Core processes and
iterations are emphasized over phases to
reduce the confusion that ordinarily
occurs when students are taught “phases”
and then told to use iterations. Project
planning and project management are
emphasized throughout, and the book
focuses more on systems analysis and
systems design as development disciplines
rather than phases.

FEATURES
7
Designing the User andSystem Interfaces
Chapter Outline
■ User and System Interfaces
■ Understanding the User Interface■ User-Interface Design Concepts
■ The Transition from Analysis to User-Interface Design
■ User-Interface Design
■ Identifying System Interfaces
■ Designing System Inputs
■ Designing System Outputs
Learning Objectives
After reading this chapter, you should be able to:■ Describe the difference between user interfaces and system interfaces
■ Describe the historical development of the field of human-computer interaction (HCI)
■ Discuss how visibility and affordance affect usability
■ Describe user-interface guidelines that apply to all types of user-interface types
and additional guidelines specific to Web pages and mobile applications
■ Create storyboards to show the sequence of forms used in a dialog
■ Discuss examples of system interfaces found in information systems
■ Define system inputs and outputs based on the requirements of the application
program
■ Design printed and on-screen reports appropriate for recipients
187
OPENIN
G CASE
Blue Sky
Mutual Fu
nds: A Ne
w Develo
pment Ap
proach
Jim William
s, vice pre
sident of f
inance for
Blue Sky M
utual
Funds, sp
oke first.
“There are
some thin
gs I like a
bout
this new
approach,
but other
things wo
rry me,”
he
told Gary
Johnson,
the compa
ny’s direct
or of infor
mation
technology
.
“This idea
of ‘growin
g’ the sys
tem throu
gh severa
l
iterations
makes a l
ot of sens
e to me. I
t is alway
s hard
for my pe
ople to kn
ow exactl
y what th
ey need a
new
informatio
n system
to do an
d what w
ill work b
est
for the co
mpany. So
, if they c
an get the
ir hands o
n the
system ea
rly, they c
an begin a
cceptance
testing an
d try
it out to se
e whether
it address
es their ne
eds in the
best
way.
“Let me s
ee if I und
erstand th
e big pictu
re, though
.
Your deve
lopment te
am and m
y investme
nt advisors
will
decide on
a few core
processes
that the sy
stem need
s to
support an
d then you
r team wil
l design an
d build a s
ystem
to suppor
t those co
re process
es. You w
ill do that
in a
mini-projec
t that will
last about
six weeks
. Then, yo
u will
continue a
dding mor
e function
ality throu
gh severa
l other
mini-projec
ts until the
system is
complete
and functio
ning
well. Is tha
t right?”
Jim was b
ecoming m
ore enthus
iastic abou
t this new
approach t
o system
developme
nt.
“Yes, that
’s the bas
ic idea,” G
ary said. “
Your users
need to u
nderstand
that the f
irst few v
ersions of
the
system w
on’t be co
mplete an
d may no
t be comp
letely
robust eit
her. But
these ear
ly version
s will giv
e them
something
to work w
ith and try
out. We a
lso need g
ood
feedback f
rom their a
cceptance
testing so
the system
will
be thoroug
hly tested
by the tim
e we are t
hrough.”
“I realize
that,” Jim
said. “My
people wi
ll like not
having to
think from
the very b
eginning a
bout every
thing
they need
the system
to do. The
y’ll like be
ing able to
try
things out
. As I said
earlier, I lik
e this appr
oach. How
ever,
the part I
don’t like
about this
approach
is that it w
ill be
more diffic
ult for you
to give me
a firm time
schedule a
nd
project co
st. That w
orries me
. In the p
ast, those
have
been two
of the m
ajor tools
we used
to monito
r a
project’s p
rogress. A
re you sa
ying that
now we w
on’t
have a sch
edule at a
ll? And yo
u want an
open budg
et?”
Jim frown
ed.
“It’s not a
s bad as i
t first sou
nds,” Gar
y said. “T
his
approach
is an ‘adap
tive’ appro
ach, by w
hich I mea
n that
because t
he system
is growing
, the proje
ct is more
open
ended. Th
e project
manager w
ill still cre
ate a sche
dule
and estim
ate the pr
oject cost
s, but she
won’t eve
n try
to identify
and lock
in all the
required f
unctionalit
y for
several of
the iteratio
ns. Becau
se the sys
tem’s sco
pe is
going to c
ontinually
be refined
over the f
irst few it
era-
tions, ther
e is the r
isk of ‘sco
pe creep.’
That is on
e of
the bigge
st risks w
ith adaptiv
e approac
hes. You
and I
should me
et with th
e project
manager
fairly frequ
ently
to ensure
that the s
cope is c
ontrolled
and the p
roject
doesn’t ge
t out of co
ntrol.”
“Okay,” J
im said. “Y
ou have co
nvinced m
e to try thi
s
new appro
ach. Howe
ver, let’s t
reat this p
roject as a
pilot
and see h
ow it work
s. If it’s su
ccessful, w
e will cons
ider
using this
iterative a
pproach o
n our othe
r projects.
” Jim
and Gary
agreed th
at a pilot
was the b
est way t
o get
started. G
ary then h
eaded off
to meet w
ith the pro
ject
manager a
nd get the
project sta
rted.
Overvie
w
Chapter 8
introduced
you to the
SDLC and
the variou
s alternati
ves for org
aniz-
ing softwa
re develop
ment activ
ities. By n
ow, you m
ay be ask
ing yourse
lf such
questions
as:
■ “How ar
e all these
activities c
oordinated
?”
■ “How d
o I know
which task
s to do fir
st?”
■ “How is
the work a
ssigned to
the differe
nt teams a
nd team m
embers?”
■ “How do
I know wh
ich parts o
f the new
system sho
uld be dev
eloped firs
t?”
The purp
ose of pr
oject plan
ning and
project m
anagemen
t is to br
ing
some ord
er to all
these (som
etimes see
mingly un
related) ta
sks. As y
ou will
learn in t
his chapte
r, the suc
cess of an
y given p
roject hig
hly depen
ds on
the skills
and abilit
ies of tho
se manag
ing the p
roject. Yo
u will als
o learn
that proje
ct manage
ment skill
s aren’t o
nly for pr
oject man
agers—tha
t all the
project tea
m membe
rs contrib
ute to the
manageme
nt of the
project an
d thus
to its succ
ess.
254 PART
4 ■ Projec
ts and Proj
ect Manage
ment
Each chapter provides a chapter outline,
states clear learning objectives, and
includes an opening case study.

FEATURES
because the packages contain only the classes from the use case interaction
diagrams that were developed in this chapter.
The other symbol used on a package diagram is a dashed arrow, which
represents a dependency relationship. The arrow’s tail is connected to the
package that is dependent, and the arrowhead is connected to the independent
package. Dependency relationships are used in package diagrams, class dia-
grams, and even interaction diagrams. A good way to think about a depen-
dency relationship is that if one element changes (the independent element),
the other (dependent) element might also have to be changed. Dependency
relationships can be between packages or between classes within packages.
Figure 11-19 indicates that several classes in the view layer are dependent on
classes in the domain layer. Thus, for example, if a change is made in the
ProductItem class, the SearchItemWindow class should be evaluated to capture
that change. However, the reverse isn’t necessarily true. Changes to the view
layer usually don’t carry through to the domain layer.
Two examples of dependency relationships are given in Figure 11-19. The
first, we have seen, is between classes. Another example is less detailed and indi-
cates a dependency between packages. Figure 11-20 indicates that the view
layer and the domain layer depend on the data access layer. For some simple
queries against the database, the view layer may directly access the data layer
without requiring any involvement of the domain layer. These dependencies
indicate that changes to the data structures, as reflected in the data access layer,
usually require changes at the domain layer and the view layer.
FIGURE 11-20 RMO subsystem packages
SearchItemWindow
AddItemWindow
AddAccessWindow
CustLoginWindow
Sales Subsystem
CartHandler
OnlineCart
CartItem
ReturnItem
Sale
SaleItem
AccessoryPackage
SaleTxn
Data Access Layer
PromoOfferingDA
ProductItemDA
InventoryItemDA
CustomerDA
OnlineCartDA
CartItemDA
ViewAccessWinodw
DisplayItem+AccessWindow
DisiplayItemWindow
Reporting Subsystem
Customer Account Subsystem
CustomerHandler
Customer
Address
FamilyLink
Message
Suggestion
Account CustPartnerCredit
Order Fulfillment Subsystem
Shipment Shipper
View Layer
Domain Layer
ProductItem
Inventory Item
PromoPartner
Promotion
PromoOffering
Marketing Subsystem
dependency relationship a relation-
ship between packages, classes, or use cases
in which a change in the independent item
requires a change in the dependent item
354 PART 5 ■ Advanced Design and Deployment Concepts
Note that each EBP (and thus each use case) occurs in response to a busi-
ness event. An event occurs at a specific time and place, can be described, and
should be remembered by the system. Events drive or trigger all processing that
a system does, so listing events and analyzing them makes sense when you need
to define system requirements by identifying use cases.Event Decomposition TechniqueAs stated previously, the event decomposition technique focuses on identifying
the events to which a system must respond and then determining how a system
must respond (i.e., the system’s use cases). When defining the requirements for
a system, it is useful to begin by asking, “What business events occur that will
require the system to respond?” By asking about the events that affect the
system, you direct your attention to the external environment and look at the
system as a black box. This initial perspective helps keep your focus on a high-
level view of the system (looking at the scope) rather than on the inner workings
of the system. It also focuses your attention on the system’s interfaces with out-
side people and other systems.Some events that are important to a retail store’s charge account processing
system are shown in Figure 3-2. The functional requirements are defined by
use cases based on six events. A customer triggers three events: “customer pays a bill,”
“customer makes a charge,” and “customer changes address.” The system responds
with three use cases: Record a payment, Process a charge, or Maintain customer
data. Three other events are triggered inside the system by reaching a point in time:
“time to send out monthly statements,” “time to send late notices,” and “time to
FIGURE 3-2 Events in a charge account processing system that lead to use cases
Charge account processing system
event something that occurs at a specific
time and place, can be precisely identified, and
must be remembered by the system
CHAPTER 3 ■ Use Cases 71
usually dis
tributed ac
ross geogr
aphic loca
tions. App
lication pr
ograms ca
n
access any
server and
usually ma
ke databas
e updates
to only on
e server.
Servers pe
riodically
exchange
update inf
ormation
to synchro
nize their
database c
opies.
■ Partition
ed databa
se server
architectu
re—Multip
le distribu
ted databa
se
servers are
used and t
he databas
e schema i
s partition
ed, with so
me conten
t
on only on
e server an
d some co
ntent copi
ed on all s
ervers. Co
ntent that
appears on
multiple se
rvers is pe
riodically
synchroniz
ed.
■ Cloud-ba
sed datab
ase serve
r architec
ture—Thi
s architect
ure isn’t re
ally
a separate
architectur
e. Rather,
it is a spec
ific implem
entation o
f one or
more of th
e other arc
hitectures
by using t
he services
of a cloud
computing
provider, s
uch as Am
azon or G
oogle. The
cloud prov
ider hosts
the databa
se
on multipl
e servers d
istributed
across a p
redefined
geographic
area.
Applicatio
n program
s access da
tabase serv
ices throug
h the clou
d provider
.
The cloud
provider t
akes care
of databas
e synchron
ization an
d backup.
The prima
ry advanta
ge of sing
le databas
e server a
rchitecture
is its simp
lic-
ity. There
is only on
e server to
manage, a
nd all clien
ts are prog
rammed to
direct
requests to
that server
. Disadvan
tages inclu
de suscept
ibility to s
erver failu
re and
possible o
verload o
f the netw
ork or se
rver. All
application
programs
that
FIGURE 1
2-16 Int
eraction am
ong proble
m domain
class, data
access cla
ss, and the
DBMS
promotio
nID
season
year
Promotio
n
descripti
on
startDate
endDate
getProm
otionID()
setProm
otionID()
getSeas
on()
setSeas
on()
getYear(
)
setYear(
)
getDesc
ription()
setDesc
ription()
getStartD
ate()
setStartD
ate()
getEndD
ate()
setEndD
ate()
Data upda
tes
and querie
s
Extracted
data and
processing
results
Database
DBMS
Data
SQL
dbConne
ction
Promotio
nDA
updateP
romotion
ID()
updateS
eason()
updateY
ear()
updateD
escriptio
n()
updateS
tartDate(
)
updateE
ndDate()
addNew
()
delete()
find()
// find
() – fi
nd a Pr
omotion
in the
databa
se
// base
d on Pr
omotion
ID
public
Promoti
on find
(int pr
omotion
ID)

thro
ws NotF
oundExc
eption
{
openCon
nection
(dbConn
ection)
;
// Buil
d an SQ
L query
String
query;
query =
“SELEC
T * FRO
M Promo
tion”;
query +
= ” WHE
RE Prom
otionID
= “;
query +
= promo
tionID;
try
{
resul
t = exe
cuteQue
ry(quer
y);
}
// rema
ining s
tatemen
ts not
shown
partitione
d databas
e server
architectu
re multipl
e distributed
data-
base servers
are used and
the database
schema
is partitioned
, with some
content on o
nly one
server and s
ome content
copied on al
l servers
cloud-bas
ed databa
se server
architectu
re use of
a cloud com
puting
service provi
der to provid
e some or al
l database
services
388 PART
5 ■ Advan
ced Design
and Deploy
ment Conce
pts
Margin defi nitions of key terms are placed in the
text when the term is fi rst used. Each chapter
includes extensive fi gures and illustrations
designed to clarify and summarize key points
and to provide examples of UML models and
other deliverables produced by an analyst.

FEATURES
Chapter Summary
Multilayer design of new systems isn’t limited to architec-
tural design. Detailed object-oriented design also identi-
fies the various levels in a system. The identification of
classes and their responsibilities follows the three-layer
pattern explained in this chapter. The three layers are
the view layer, the business (or logic) layer, and the data
access layer.
Three-layer design is part of the overall movement in
systems design based on design patterns. A design pattern
is a standard solution or template that has proven to be
effective to a particular requirement in systems design.
The other pattern, introduced in Chapter 10, is a use
case controller, which addresses the need to isolate the
view layer from the business layer in a simple way that
limits coupling between the two layers.
Detailed design is use case driven in that each use
case is designed separately. This type of design is called
use case realization. The two primary models used for
detailed design are the design class diagram and the
sequence diagram. Design class diagrams were discussed
in Chapter 10.
Detailed design of use cases entails identifying prob-
lem domain classes that collaborate to carry out a use
case. Each input message from an external actor triggers
a set of internal messages. Using a sequence diagram or a
communication diagram, the designer identifies and
defines all these internal messages. In the first cut, only
the problem domain classes and their internal messages
are identified. Next, the solution is completed by adding
the classes and messages for the view layer and the data
access layer.
The final step is to convert each message, along with
the passed parameters and return values, into method sig-
natures located in the correct classes. This information is
used to update the design class diagram. Changes are also
made to the design class diagram to show required visi-
bility between the classes in order to send messages in the
sequence diagrams.
As classes are identified during the design process,
they are added to the DCD. The DCD can also be parti-
tioned into several layers or into subsystems. Package dia-
grams are used to partition the DCD into appropriate
packages. Dependency between the classes and the
packages is also added to the package diagram.
Popular design patterns include the adapter pattern,
factory pattern, singleton pattern, and observer pattern.
The adapter pattern implements the design principle
“protection from variations” by allowing a changing
piece of the system to simply plug into a more stable
part of the system. When the pluggable piece of the sys-
tem needs to change, it can just be unplugged and the
updated component can be plugged in.
The factory and singleton patterns have much in
common. Both return a reference to a specific object.
Both allow only one instance of that object to exist in
the system. The difference is that the factory pattern
enforces a single occurrence for utility classes and the sin-
gleton only enforces a single occurrence for itself.
Key Terms
activation lifeline 335
communication diagrams 332
dependency relationship 354
design patterns 330
persistent classes 345
separation of responsibilities 345
sequence diagrams 332
use case realization 328
Review Questions
1. What is meant by the term use case realization?
2. What are the benefits of knowing and using design
patterns?
3. What is the contribution to systems development by
the Gang of Four?
4. What are the five components of a standard design
pattern definition?
5. List five elements included in a sequence diagram.
6. How does a sequence diagram differ from an SSD?
7. What is the difference between designing with CRC
cards and designing with sequence diagrams?
8. Explain the syntax of a message on a sequence
diagram.
9. What is the purpose of the first-cut sequence
diagram? What kinds of classes are included?
10. What is the purpose of the use case controller?
11. What is meant by an activation lifeline? How is it
used on a sequence diagram?
CHAPTER 11 ■ Object-Oriented Design: Use Case Realizations 361
Problems and Exercises1. Write a one-page paper that distinguishes among
the fundamental purposes of the analysis phase, the
design phase, and the implementation phase of the
traditional predictive SDLC.2. Describe an information system project that might
have three subsystems. Discuss how three iterations
might be used for the project.3. Why might it make sense to teach analysis and
design phases and activities sequentially, like a
waterfall, even though iterations are, in practice,
used in nearly all development projects?
4. List some of the models that architects create to
show different aspects of a house they are designing.
Explain why several models are needed.
5. What models might an automotive designer use to
show different aspects of a car?6. Sketch and write a description of the layout of your
room at home. Are both the sketch and the written
description considered models of your room?
Which is more accurate? More detailed? Which
would be easier to follow by someone unfamiliar
with your room?7. Describe a technique you use to help you complete
the activity “Get to class on time.” What are some
of the tools you use with this technique?
8. Describe a technique you use to make sure you get
assignments done on time. What are some of the
tools you use with this technique?9. What are some other techniques you use to help you
complete activities in your life?10. There are at least two approaches to the SDLC, two
approaches to software construction and modeling,
and a long list of techniques and models. Discuss
the following reasons for this diversity of
approaches: The field is young; the technology
changes quickly; different organizations have dif-
ferent needs; there are many types of systems;
developers have widely different backgrounds.
11. Go to the campus placement office to gather some
information on companies that recruit information
systems graduates. Try to find any information
about the companies’ approaches to developing
systems. Is their SDLC described? Do any mention
an IDE or a visual modeling tool? Visit the compa-
nies’ Web sites to look for more information.
12. Visit the Web sites of a few leading information
systems consulting firms. Try to find information
about their approaches to developing systems. Are
their SDLCs described? Do the sites mention any
tools, models, or techniques?
Case Study
A “College Education Completion” Methodology
Given that you are reading this book, you are probably a
college student working on a degree. Think about complet-
ing college as a project—a big project lasting many years
and costing more than you might want to admit. Some
students do a better job managing their college completion
projects than others. Many fail entirely (certainly not you),
and most complete college late and way over budget
(again, certainly not you).As with any other project, to be successful, you need
to follow some sort of “college education completion”
methodology—that is, a comprehensive set of guidelines
for completing activities and tasks from the beginning of
planning for college through to the successful completion.
1. What are the phases that your college education
completion life cycle might have?
2. What are some of the activities included with each
phase?
3. What are some of the techniques you might use to
help complete those activities?
4. What models might you create? Differentiate the
models you create to get you through college from
those that help you plan and control the process of
completing college.5. What are some of the tools you might use to help you
complete the models?
CHAPTER 8 ■ Approaches to System Development 249
RUNNI
NG CA
SE STU
DIES
Commu
nity Boa
rd of Re
altors
The Board
of Realtor
s Multiple
Listing Ser
vice (MLS
)
system isn
’t very la
rge in ter
ms of use
cases and
domain c
lasses. In
that resp
ect, the
functional
requireme
nts are sim
ple and w
ell unders
tood. ML
S
needs a W
eb site wi
th public
access to
the listing
s,
and it also
needs to a
llow agen
ts and bro
kers to lo
g
in to the s
ystem to a
dd and up
date listin
gs. There
is
very little
back-end
administra
tive data
maintenan
ce
required,
except to
add or up
date a rea
l estate of
fice
or agent.
1. Comp
ared to the
Tradeshow
application
described
in Chapter
1, how lon
g might th
is project
take,
and which
approach
to the SDL
C would b
e most
appropriat
e?
2. If you
use a pred
ictive SDL
C, how m
uch time
might eac
h phase o
f the proje
ct take? H
ow
much ove
rlap of ph
ases migh
t you plan
for?
Be specific
about how
you would
overlap
the phases
.
3. If you
use an ada
ptive SDLC
, how man
y iteration
s
might you
plan to inc
lude? Wha
t use cases
would
you analyz
e, design,
and imple
ment in th
e first
iteration?
What use
cases wou
ld you wo
rk on in
the second
iteration?
In addition
al iteration
s?
Think in t
erms of ge
tting the c
ore functio
nality
implement
ed early an
d then bui
lding the s
upport-
ing functio
nality.
4. Let us
say this pr
oject focus
ed on Web
access to
the MLS.
If you also
plan to de
ploy a sma
rtphone
application
for use by
the public
and by the
agents
and broke
rs, how m
ight this a
ffect your
choice of
the approa
ch to the S
DLC? Wh
at are the
implica-
tions for i
ncluding t
he smartp
hone appl
ication in
the initial
project ver
sus having
a separate
project
for wireles
s later?
5. Consi
der using
incrementa
l developm
ent to
include th
e Web app
lication an
d the wire
less sup-
port. Desc
ribe what
would be
included in
the first
and secon
d deploym
ents of the
project. Ta
ke into
considerat
ion that yo
u might w
ant to wor
k on
some initia
l problem
solving for
requireme
nts,
design, an
d impleme
ntation of
the wireles
s support
at the sam
e time you
are workin
g on the W
eb
application
.
The Spr
ing Bre
aks ‘R’
Us Trav
el Servi
ce
Recall fro
m Chapte
r 2 that
SBRU’s in
itial syste
m
included
four majo
r subsyste
ms: Reso
rt relation
s,
Student bo
oking, Acc
ounting an
d finance,
and Socia
l
networkin
g. The
project c
alls for
an adapt
ive
approach
to the SD
LC for sev
eral reason
s. One, it
is
relatively l
arge in sco
pe. Two, t
here is a d
iverse set o
f
users in se
veral func
tional area
s, internal
and extern
al
to the co
mpany an
d in seve
ral foreig
n countri
es.
Three, the
project ne
eds to us
e an asso
rtment of
newer tech
nologies th
at can com
municate a
nytime and
anywhere.
1. The SB
RU inform
ation syste
m includes
four major
subsystem
s: Resort r
elations, S
tudent boo
king,
Accountin
g and fina
nce, and S
ocial netw
orking.
Although
you have o
nly worke
d with the
domain
model clas
s diagram
for the So
cial netwo
rking
subsystem
, list as ma
ny of the d
omain clas
ses
that would
probably b
e involved
in each of
the
subsystem
s. Note wh
ich classes
are used b
y more
than one s
ubsystem.
2. Based
on the ove
rlapping c
lasses, wh
at domain
classes see
m to be pa
rt of the co
re function
ality for
SBRU? Dr
aw a dom
ain model
class diagr
am that
shows the
se classes
and their a
ssociations
.
3. Let us
say you pl
an to impl
ement the
basic use
cases that
create and
maintain t
he classes
that are
part of the
core funct
ionally yo
u just mod
eled.
Describe w
hat domai
n classes y
ou would
focus on
in each ite
ration if y
ou assume
d that you
would
need two
iterations
for the ini
tial core fu
nctional-
ity and tw
o addition
al iteration
s to comp
lete each
of the sub
systems.
4. How
might you
use increm
ental deve
lopment to
get some c
ore functio
nality or s
ome subsy
stems
deployed a
nd put int
o use befo
re the pro
ject is
completed
?
(continued
on page 2
51)
250 PART
4 ■ Projec
ts and Proj
ect Manage
ment
End-of-chapter material includes a
detailed summary, an indexed list of
key terms, and ample review
questions.
Each chapter also includes a collection of
problems and exercises that involves additional
research or problem solving, an end-of-chapter
case study that invites students to complete
analysis and design tasks appropriate to the
chapter, four running cases that create
challenging and integrated course assignments,
and a list of further resources.

PREFACE
When we wrote the first edition of this textbook, the world of system develop-
ment was in a major transition period—from structured methodologies to
object-oriented methodologies. We were among the first to introduce a compre-
hensive treatment of object-oriented methodologies, and Systems Analysis and
Design in a Changing World, Sixth Edition, continues to be the leader in teach-
ing object-oriented techniques.
However, change continues. Today, many new initiatives and trends have
become firmly embedded in the world of system development. First and fore-
most is the ubiquitous access to the Internet throughout the global economy.
The resulting explosion of connectivity means that project teams are now dis-
tributed around the world. In addition, large providers (such as Microsoft) and
a proliferation of small providers now contribute to a wonderfully rich and var-
ied software development environment.
In order to manage system development teams in today’s distributed, fast-
paced, connected, ever-changing environment, the techniques for software devel-
opment and the approach to project management have expanded. Along with
the foundational project management principles, additional approaches and phi-
losophies provide new, success-oriented methodologies, such as iterative, incre-
mental development approaches. These are thoroughly covered in this edition.
Even though Systems Analysis and Design in a Changing World, Sixth
Edition, continues to be the leader in its field, with thorough treatment of such
topics as use cases, object-oriented modeling, comprehensive project manage-
ment, the unified modeling language, and Agile techniques, it was time to take
another step forward in textbook design. This edition uses an innovative
approach to teaching systems analysis and design, taking advantage of the new
teaching tools and techniques that are now available. As a result, not only is
systems analysis and design easier to learn by using this approach, it is also
easier to teach. It brings together the best approaches for teachers and students.
In this edition, we accomplish three major new objectives. First, we teach all
the essential principles of system development—principles that must be followed
in today’s connected environment. Second, we teach and explain the new meth-
odologies and techniques that are now available because of widespread connec-
tivity. Third, we have organized and revamped the textbook so that it teaches
these new concepts in a new way.
For example, Chapter 1 presents a complete iteration in the development of
a new system. Students get to see that complete iteration—from beginning to
end (through implementation and testing)—before having to learn abstract prin-
ciples or memorize terms. Also, the newly written running cases throughout the
book focus on current issues of communication and connectedness and take the
students through all aspects of system development. Along with the textbook
itself, there are teaching tools, such as video explanations of complex models
and topics. We have also expanded the Instructor’s Materials and enhanced the
aids available through CourseMate, our online resource. Additional online
chapters are also available to enhance and extend the learning experience.
xvi

We are excited about this new approach. The time is right for new materials
and new tools for teaching systems analysis and design. Instructors will find this
textbook intuitive, powerful, and easy to use. Students will find it engaging and
empowering. Many concepts are presented so the students can teach themselves,
with coaching and direction provided by the professor. It will be an incredible
experience to teach and learn with this textbook.
Innovations
This edition is innovative in many respects. It includes key concepts from tradi-
tional and object-oriented approaches, covers the use case–driven object-
oriented approach (with UML modeling being detailed in depth), emphasizes
Agile and iterative development, and incorporates the latest concepts in project
management. Also, the material is completely reorganized to better support
learning systems analysis and design.
Coverage of Object Orientation and Traditional
Analysis and Design
This textbook is unique in its integration of key systems-modeling concepts that
apply to the traditional structured approach and the object-oriented approach—
user goals and events that trigger system use cases, plus objects/entities that are
part of the system’s problem domain. We devote one chapter to identifying use
cases and another chapter to modeling key objects/entities, including coverage of
entity-relationship diagrams, while emphasizing UML domain model class dia-
grams. After completing these chapters, instructors can cover structured analysis
and design by including an online chapter, or they can focus on object-oriented
analysis and design by using the chapters in this textbook. It is assumed from
the beginning that everyone should understand the key object-oriented concepts.
The traditional approach isn’t discarded; key structured concepts are included.
But these days, most instructors are emphasizing the object-oriented approach.
Full Coverage of UML and the Object-Oriented Approach
The object-oriented approach presented in this textbook is based on the Unified
Modeling Language (UML 2.0) from the Object Management Group, as origi-
nated by Grady Booch, James Rumbaugh, and Ivar Jacobson. A model-driven
approach to analysis starts with use cases and scenarios and then defines prob-
lem domain classes involved in the users’ work. We include requirements model-
ing with use case diagrams, domain modeling, use case descriptions, activity
diagrams, and system sequence diagrams. The FURPS+ model is used to empha-
sis functional and nonfunctional requirements.
Design principles and design patterns are discussed in depth, and system
architecture is modeled by using UML component diagrams and package dia-
grams. Detailed design models are also discussed in detail, with particular atten-
tion given to use case realization with CRC cards, sequence diagrams, and
design class diagrams.
Project Management Coverage
Many undergraduate programs depend on their systems analysis and design
course to teach project management principles. To satisfy this need, we cover
project management by taking a four-pronged approach. First, specific project
management techniques, skills, and tasks are included and highlighted through-
out this book. This integration teaches students how to apply specific project
management tasks to the various activities of the systems development life cycle,
including iterative development. Second, complete coverage of project planning
and project management is included in a separate chapter. Third, we include a
120-day trial version of Microsoft Project 2010 Professional in the back of this
PREFACE xvii

book so students can obtain hands-on experience with this important tool.
Fourth, a more in-depth treatment of project management techniques and prin-
ciples is provided in an online chapter on this book’s Web site. This information
is based on the Project Management Body of Knowledge (PMBOK), as devel-
oped by the Project Management Institute—the primary professional organiza-
tion for project managers in the United States.
Organized for More Effective Learning
This edition’s innovative and entirely new organization starts with a complete
beginning-to-end example of system development, moves immediately to systems
analysis models and techniques, and then proceeds to system design concepts,
emphasizing system architecture, user interfaces, and system interfaces. The stu-
dent sees analysis and much of design covered in the first seven chapters. Next,
the text focuses on managing system development projects, including Agile
development, after the student has had a chance to understand what is actually
involved in system development. Finally, the text covers detailed design topics,
deployment topics, and current trends, going into more depth about such
contemporary approaches as the Unified Process, Extreme Programming,
and Scrum.
Coursemate Companion Web Site
Cengage Learning’s Systems Analysis and Design in a Changing World, Sixth
Edition, CourseMate brings course concepts to life with interactive learning,
study, and exam preparation tools that support the printed textbook. Watch
student comprehension soar as your class works with the printed textbook and
the textbook-specific Web site. CourseMate goes beyond the book to deliver
what you need! Learn more at cengage.com/coursemate.
Engagement Tracker
How do you assess your students’ engagement in your course? How do you
know your students have read the material or viewed the resources you have
assigned? How can you tell if your students are struggling with a concept?
With CourseMate, you can use the included Engagement Tracker to assess stu-
dent preparation and engagement. Use the tracking tools to see progress for the
class as a whole or for individual students. Identify students at risk early in the
course. Uncover which concepts are most difficult for your class. Monitor time
on task. Keep your students engaged.
Interactive Teaching and Learning Tools
CourseMate includes interactive teaching and learning tools:
■ Quizzes
■ Case projects
■ Flashcards
■ Videos
■ PowerPoint presentations
These assets enable students to review for tests, prepare for class, and
address the needs of students’ varied learning styles.
Interactive eBook
In addition to interactive teaching and learning tools, CourseMate includes an
interactive eBook. Students can take notes, highlight, search for, and interact
with embedded media specific to their book. Use it as a supplement to the
printed text or as a substitute—the choice is your students’ with CourseMate.
xviii PREFACE

Organization and Use
Systems Analysis and Design in a Changing World, Sixth Edition, includes this
printed textbook, electronic editions, and supporting online chapters. The cur-
rent printed textbook provides a compact, streamlined, and focused presentation
of those topics that are essential and most important for information systems
developers. The online chapters extend those concepts and provide a broader
presentation of several topics. The online chapters may be integrated into the
course or simply used as additional readings as prescribed by the instructor.
There are three major subject areas discussed in this book: systems analysis,
systems design, and project management. There are additional subject areas,
which are no less important but aren’t discussed in as much depth. These
include systems implementation, testing, and deployment. In addition, we have
taken an approach that is quite different from other texts. Because students
already have a basic understanding of systems analysis and design from
Chapter 1, we immediately present in-depth concepts related to systems analysis
and design. We present project management topics later in the text. This allows
students to learn those project management concepts after understanding the
elements of systems analysis and design. We think it will be more meaningful
for students at that point in the course.
Part 1: Introduction to Systems Development
Part 1, comprising Chapter 1 and Online Chapter A, presents an overview of
systems development. The first chapter begins by briefly explaining the objec-
tives of systems analysis and systems design. Then, it provides a detailed, con-
crete example of what is required in a typical software development project.
Many students who take a programming class think that programming is all
you need to develop software and deploy a system. This chapter and the rest of
the book should dispel that myth.
Online Chapter A, “The Role of the Systems Analyst,” describes the many
skills required of a systems analyst. It also discusses the various career options
available to information systems majors. For students who are new to the disci-
pline of information systems, this chapter will provide interesting and helpful
knowledge about information systems careers.
Part 2: Systems Analysis Tasks
Chapters 2 through 5 cover systems analysis in detail. Chapter 2 discusses sys-
tem requirements, analysis activities, and techniques for gathering information
about the business problem. Developing the right system solution is possible
only if the problem is accurately understood. Chapter 2 also explains how to
identify and involve the stakeholders and introduces the concept of models and
modeling. Chapters 3 and 4 teach modeling techniques for capturing the
detailed requirements for the system in a useful form. When discussing an infor-
mation system, two key concepts are particularly useful: the use cases that
define what the end users need the system to do and the data entities/domain
classes that users work with while carrying out their work tasks. These two con-
cepts—use cases and data entities/domain classes—are important no matter
what approach to system development is being used. Chapter 5 presents more
in-depth requirements models, such as use case descriptions, use case diagrams,
system sequence diagrams, and state machine diagrams.
Online Chapter B, “The Traditional Approach to Requirements,” presents
the traditional, structured approach to developing systems. To those instructors
and students who desire to learn about data flow diagrams and structured
English, this chapter provides an in-depth presentation.
All these modeling techniques provide in-depth analysis of user needs and
allow the analyst to develop requirements and specifications. Again, the purpose
PREFACE xix

of systems analysis is to thoroughly understand and specify the user’s needs and
requirements.
Part 3: Essentials of Systems Design
Chapters 6 and 7 provide the fundamental concepts related to systems design
and designing the user experience. Chapter 6 provides broad and comprehensive
coverage of important principles of systems design and architectural design. It
serves not only as a broad overview of design principles but also as a founda-
tion for later chapters that explain the detailed techniques, tasks, skills, and
models used to carry out design.
Chapter 7 presents additional design principles related to designing the user
interface and the system interfaces. Designing the user interface is a combination
of analysis and design. It is related to analysis because it requires heavy user
involvement and includes specifying user activities and desires. On the other
hand, it is a design activity because it is creating specific final components that
are used to drive the programming effort. The screens and reports and other
user interaction components must be precisely designed so they can be pro-
grammed as part of the final system. Systems interfaces occur when one infor-
mation system communicates or interacts with another information system
without human intervention. System interfaces are becoming increasingly impor-
tant because of Web services and cloud computing.
Part 4: Projects and Project Management
By this point, students will have a basic understanding of all the elements of sys-
tems development. Part 4 brings together all these concepts by explaining more
about the process of organizing and managing development projects. Chapter 8
describes different approaches to systems development in today’s environment,
including several important system development life cycle models and Agile
development. It is an important chapter to help you understand how projects
actually get executed.
Chapter 9 extends these concepts by teaching foundation principles of project
planning and project management. Every systems analyst is involved in helping
organize, coordinate, and manage software development projects. In addition,
most good students will eventually become team leaders and project managers.
The principles presented in Chapter 9 are essential to a successful career.
Online Chapter C, “Project Management Techniques,” goes into more
detail regarding the tools and techniques used by systems analysts and project
managers to plan and monitor development projects. For those instructors and
students who would like to learn specific project management skills, this is an
important chapter.
Part 5: Advanced Design and Deployment Concepts
Part 5 goes into more depth with respect to systems design, database design,
and other important issues related to effective and successful system develop-
ment and deployment.
Chapters 10 and 11 explain in detail the models, skills, and techniques used
to design software systems. As mentioned earlier, systems design is a fairly
complex activity, especially if it is done correctly. The objective of these
two chapters is to teach the student the various techniques—from simple to
complex—that can be used to effectively design software systems.
Chapter 12 explains how to design the database from the information
gleaned during analysis and the identification of the object classes. Other related
concepts, such as controls and security, are also presented in this chapter.
Chapter 13 describes the final elements in systems development: final testing,
deployment, maintenance, and version control. Chapter 14 wraps things up by
looking at current trends and the future of software development.
xx PREFACE

Designing Your Analysis and Design Course
There are many approaches to teaching analysis and design courses, and the
objectives of the course differ considerably from college to college. In some aca-
demic information systems departments, the analysis and design course is a cap-
stone course in which students apply the material learned in prior database,
telecommunications, and programming courses to a real analysis and design
project. In other information systems departments, analysis and design is used
as an introduction to the field of system development and is taken prior to
more specialized courses. Some information systems departments offer a two-
course sequence emphasizing analysis in the first semester and design and imple-
mentation in the second semester. Some information systems departments have
only one course that covers analysis and design.
The design of the analysis and design course is complicated even more by the
choice of emphasizing either traditional content or object-oriented content—again,
depending on local curriculum priorities. Additionally, the more iterative
approach to development in general has made choices about sequencing the anal-
ysis and design topics more difficult. For example, with iterative development, a
two-course sequence can’t be divided into analysis and then design as easily.
The objectives, course content, assignments, and projects have many varia-
tions. What we offer below are some suggestions for using this textbook in vari-
ous approaches to the course.
Object-Oriented Analysis and Design Course
This is the course we designed the printed textbook to support, so all the
printed chapters but none of the online chapters are included. Note that object-
oriented design is included in detail. The course covers object-oriented analysis
and design, user and system interface design, database design, controls and secu-
rity, and implementation and testing. It is usually assumed that the projects will
use custom development, including Web development. The course emphasizes
iterative development with three-layer architecture, project management, infor-
mation gathering, and management reporting. One-semester courses are usually
limited to completing some prototypes of the user interface to give students clo-
sure. Sometimes, this course is spread over two semesters, with some implemen-
tation of an actual system in the second semester for a more complete
development experience. Iterative development is emphasized.
A suggested outline for a course emphasizing object-oriented development is:
Chapter 1: From Beginning to End: An Overview of Systems Analysis
and Design
Chapter 2: Investigating System Requirements
Chapter 3: Use Cases
Chapter 4: Domain Modeling
Chapter 5: Extending the Requirements Models
Chapter 6: Essentials of Design and the Design Activities
Chapter 7: Designing the User and System Interfaces
Chapter 8: Approaches to System Development
Chapter 9: Project Planning and Project Management
Chapter 10: Object-Oriented Design: Principles
Chapter 11: Object-Oriented Design: Use Case Realizations
Chapter 12: Databases, Controls, and Security (combine)
Chapter 13: Making the System Operational
Chapter 14: Current Trends in System Development
PREFACE xxi

Traditional Analysis and Design Course
A traditional systems analysis and design course provides coverage of activities and
tasks by using structured analysis, user and system interface design, database
design, controls and security, and implementation and testing. It is usually assumed
that the project will use custom development, including Web development. The
course emphasizes the SDLC, project management, information gathering, and
management reporting. One-semester courses are usually limited to completing
some prototypes of the user interface to give students closure. Sometimes, this
course is spread over two semesters, with some implementation of an actual system
in the second semester for a more complete development experience.
For this approach to the analysis and design course, a reasonable outline
would omit chapters and sections detailing object orientation and possibly cur-
rent trends but include the online chapters on the role of the systems analyst
and on traditional structured analysis. However, object-oriented concepts are
introduced throughout the text, so students will still be familiar with them.
Additionally, because of the amount of material to cover, the online chapter
detailing project management, financial feasibility, and scheduling might
be omitted.
A suggested outline for a course emphasizing the traditional structured
approach is:
Chapter 1: From Beginning to End: An Overview of Systems Analysis
and Design
Online Chapter A: The Role of the Systems Analyst
Chapter 2: Investigating System Requirements
Chapter 3: Use Cases
Chapter 4: Domain Modeling
Online Chapter B: The Traditional Approach to Requirements
Chapter 6: Essentials of Design and the Design Activities
Chapter 7: Designing the User and System Interfaces
Chapter 8: Approaches to System Development
Chapter 9: Project Planning and Project Management
Chapter 12: Databases, Controls, and Security (combine)
Chapter 13: Making the System Operational
In-Depth Analysis and Project Management
Some courses cover object-oriented systems analysis methods in more depth and
briefly survey structured analysis—with not much about object-oriented design—
while emphasizing project management. Sometimes, these courses are graduate
courses; sometimes, they assume design and implementation are covered in more
technical courses. In some cases, it might be assumed that packages are likely
solutions rather than custom development, so defining requirements and manag-
ing the process are more important than design activities. The online chapters
covering the role of the systems analyst, the traditional approach to structured
analysis, and project management would be included.
A suggested outline for a course emphasizing object-oriented analysis, with
in-depth coverage of project management, is:
Chapter 1: From Beginning to End: An Overview of Systems Analysis
and Design
Online Chapter A: The Role of the Systems Analyst
Chapter 2: Investigating System Requirements
Chapter 3: Use Cases
xxii PREFACE

Chapter 4: Domain Modeling
Chapter 5: Extending the Requirements Models
Online Chapter B: The Traditional Approach to Requirements
Chapter 6: Essentials of Design and the Design Activities
Chapter 7: Designing the User and System Interfaces
Chapter 8: Approaches to System Development
Chapter 9: Project Planning and Project Management
Online Chapter C: Project Management
Chapter 14: Current Trends in System Development
Available Support
Systems Analysis and Design in a Changing World, Sixth Edition, includes
teaching tools to support instructors in the classroom. The ancillary materials
that accompany the textbook include an Instructor’s Manual, solutions, test
banks and test engine, PowerPoint presentations, and figure files. Please contact
your Cengage Course Technology sales representative to request the Teaching
Tools CD-ROM if you haven’t already received it. Or go to the Web page for
this book at login.cengage.com to download all these items.
The Instructor’s Manual
The Instructor’s Manual includes suggestions and strategies for using the text,
including course outlines for instructors that emphasize the traditional struc-
tured approach or the object-oriented approach. The manual is also helpful for
those teaching graduate courses on analysis and design.
Solutions
We provide instructors with answers to review questions and suggested solu-
tions to chapter exercises and cases. Detailed traditional and UML object-
oriented models are included for all exercises and cases that ask for modeling
solutions.
ExamView
This objective-based test generator lets the instructor create paper, LAN, or
Web-based tests from test banks designed specifically for this Course
Technology text. Instructors can use the QuickTest Wizard to create tests in
fewer than five minutes by taking advantage of Course Technology’s question
banks or instructors can create customized exams.
Plug and Play!
Jumpstart your course with customizable, text-specific content within your
Course Management System!
■ Jumpstart—Instructors simply load a WebTutor cartridge or e-Pack into
their Course Management System.
■ Content—Text-specific content, media assets, quizzing, Web links, discus-
sion topics, interactive games and exercises, and more.
■ Customizable—Instructors can easily blend, add, edit, reorganize, or delete
content.
Whether you want to Web-enable your class or put an entire course online,
WebTutor delivers! Visit academic.cengage.com/webtutor to learn more.
PREFACE xxiii

Product Description
WebTutor and WebTutor Toolbox products are Course Cartridges and e-Packs
that provide content natively on a Course Management System (WebCT,
BlackBoard, Angel, D2L, and eCollege). The purpose of the product is to pro-
vide electronic solutions in an easy-to-use format with little upfront costs to
instructors.
For more information on how to bring WebTutor to your course, instruc-
tors should contact their Cengage Learning sales representative.
PowerPoint Presentations
Microsoft PowerPoint slides are included for each chapter. Instructors might use
the slides in a variety of ways, such as teaching aids during classroom presenta-
tions or as printed handouts for classroom distribution. Instructors can add
their own slides for additional topics they introduce to the class.
Figure Files
Figure files allow instructors to create their own presentations by using figures
taken directly from this text.
Credits and Acknowledgments
We have been very gratified as authors to receive so many supportive and
enthusiastic comments about Systems Analysis and Design in a Changing
World. Students and instructors in the United States and Canada have found
our text to be the most up-to-date and flexible book available. The book has
also been translated into many languages and is now used productively in
Europe, Australia, New Zealand, India, China, and elsewhere. We truly thank
everyone who has been involved in all the editions of our textbook.
This sixth edition was managed by Kate Mason, who was charged with
recruiting a new developmental editor, negotiating with the production depart-
ment for an accelerated writing and editing schedule, and dealing with numer-
ous author uncertainties and scheduling conflicts. Our developmental editor,
Kent Williams, was charged with the daunting task of pulling together material
that had been completely reorganized and submitted in what probably seemed
like a random order by what probably seemed like mad professors.
Last but certainly not least, we want to thank all the reviewers who worked
so hard for us—beginning with an initial proposal and continuing throughout
the completion of all six editions of this text. We were lucky enough to have
reviewers with broad perspectives, in-depth knowledge, and diverse preferences.
We listened very carefully, and the text is much better as a result of their input.
Reviewers for the various editions include:
Rob Anson, Boise State University
Marsha Baddeley, Niagara College
Teri Barnes, DeVry Institute—Phoenix
Robert Beatty, University of Wisconsin—Milwaukee
James Buck, Gateway Technical College
Anthony Cameron, Fayetteville Technical Community College
Genard Catalano, Columbia College
Paul H. Cheney, University of Central Florida
Kim Church, Oklahoma State University
Jung Choi, Wright State University
Jon D. Clark, Colorado State University
Mohammad Dadashzadeh, Oakland University
Lawrence E. Domine, Milwaukee Area Technical College
Gary Garrison, Belmont University
Cheryl Grimmett, Wallace State Community College
xxiv PREFACE

Jeff Hedrington, University of Phoenix
Janet Helwig, Dominican University
Susantha Herath, St. Cloud State University
Barbara Hewitt, Texas A&M University
Ellen D. Hoadley, Loyola College in Maryland
Jon Jasperson, Texas A&M University
Norman Jobes, Conestoga College—Waterloo, Ontario
Gerald Karush, Southern New Hampshire University
Robert Keim, Arizona State University
Michael Kelly, Community College of Rhode Island
Rajiv Kishore, The State University of New York—Buffalo
Rebecca Koop, Wright State University
Hsiang-Jui Kung, Georgia Southern University
James E. LaBarre, University of Wisconsin—Eau Claire
Ingyu Lee, Troy University
Terrence Linkletter, Central Washington University
Tsun-Yin Law, Seneca College
David Little, High Point University
George M. Marakas, Indiana University
Roger McHaney, Kansas State University
Cindi A. Nadelman, New England College
Bruce Neubauer, Pittsburgh State University
Michael Nicholas, Davenport University—Grand Rapids
Mary Prescott, University of South Florida
Alex Ramirez, Carleton University
Eliot Rich, The State University of New York—Albany
Robert Saldarini, Bergen Community College
Laurie Schatzberg, University of New Mexico
Deborah Stockbridge, Quincy College
Jean Smith, Technical College of the Lowcountry
Peter Tarasewich, Northeastern University
Craig VanLengen, Northern Arizona University
Bruce Vanstone, Bond University
Haibo Wang, Texas A&M University
Terence M. Waterman, Golden Gate University
All of us involved in the development of this text wish you all the best as
you take on the challenges of analysis and design in a changing world.
—John Satzinger
—Robert Jackson
—Steve Burd
PREFACE xxv

This page intentionally left blank

PART 1
An Introduction to Systems
Development
Chapter 1
From Beginning to End:
An Overview of Systems
Analysis and Design
Optional Online Chapter A
The Role of the Systems
Analyst
1

This page intentionally left blank

1
From Beginning to End:
An Overview of Systems
Analysis and Design
Chapter Outline
■ Software Development and Systems Analysis and Design
■ Systems Development Life Cycle
■ Introduction to Ridgeline Mountain Outfitters
■ Iterative Development
■ Developing RMO’s Tradeshow System
■ Where You Are Headed—The Rest of This Book
Learning Objectives
After reading this chapter, you should be able to:
■ Describe the purpose of systems analysis and design in the development of
information systems
■ Describe the characteristics of iterative systems development
■ Explain the six core processes of the Systems Development Life Cycle
■ Identify key documents that are used in planning a project
■ Identify key diagrams used in systems analysis and systems design
■ Explain the utility of identifying use cases in systems development
■ Explain the utility of identifying object classes in systems development
3

Software Development and
Systems Analysis and Design
Computers are everywhere today, and microchips impact every part of our lives.
We live in a world not only of ubiquitous computing but of pervasive communi-
cation and connectivity. An incredibly large part of our everyday lives depends
on computer chips, connection links, and application software.
You have grown up in this world of high technology. You use smartphones,
laptops, iPads, notepads, electronic game equipment, and so on. Your mobile
devices provide daily (if not hourly) text messages, tweets, videos, snapshots,
Internet access, games, and much more. Many of you have already developed
your own application software or you have a friend who has written applica-
tions for laptops, smartphones, iPads, or Facebook. Some of you have taken
programming classes; others of you have taught yourself how to write computer
application programs. Given that we live in this world of high-tech gadgets, we
might ask, “What is systems analysis and design, and why is it important?”
How does the development of new technology and new application software
utilize systems analysis and design? In other words, what role does systems anal-
ysis and design play in the development of high-tech solutions and applications?
First, let us provide two important definitions. A computer application
is a computer software program that executes on a computing device to carry
out a specific function or set of related functions. Sometimes, computer applica-
tion is shortened to app (such as an iPhone app or a Facebook app). An
information system is a set of interrelated computer components that collects,
processes, stores (usually in a database), and provides as output the information
needed to complete business tasks. Although these terms are sometimes used
synonymously, an application usually refers to only the computer software
involved, whereas an information system may include the software, the data-
base, and even the related manual processes. Examples of computer applications
include browsers that access the Internet to play games or calendaring apps.
Figure 1-1 shows a typical mobile digital device.
Why is systems analysis and design important in the development of infor-
mation systems? To answer that question, let us consider an analogous
FIGURE 1-1
Typical mobile digital device
computer application (app) a com-
puter software program that executes on a
computing device to carry out a specific
function or set of related functions
information system a set of interre-
lated computer components that collects,
processes, stores, and provides as output the
information needed to complete business tasks
4 PART 1 ■ An Introduction to Systems Development

situation: the art and science of creating a beautiful building. In this scenario,
there is the buyer who has the vision, the builder who will construct the build-
ing, and the architect who serves as the bridge between the buyer and the
builder. The architect helps the buyer develop the vision but must also commu-
nicate the building’s specifications to the builder. In doing so, the architect uses
various tools to first capture the vision from the buyer and then provide the
builder with instructions—including such tools as line drawings, blueprints, to-
scale models, detail specifications, and even on-site inspections.
Just as a builder doesn’t start construction without plans, programmers
don’t just sit down and start writing program code. They need someone (maybe
themselves) to function like an architect—planning, capturing the vision, under-
standing details, specifying needs—before writing the code and verifying that it
satisfies the vision. The software architect has to be able to understand and cap-
ture the vision of the persons funding the project. Usually, we call this person a
systems analyst. In situations where you are the programmer as well as the ana-
lyst, it might be easy to keep track of the details without writing them down.
However, in today’s world, with some system development teams distributed
worldwide, you may only be responsible for part of the programming, with the
rest handled by team members around the world. In a distributed team situa-
tion, it is much more important to have written documents to assist in under-
standing, capturing, explaining, and specifying the software application.
In a nutshell, systems analysis and design (SA&D) is about providing the
tools and techniques to you, the developer, so you can understand the need
(business need), capture the vision, define a solution, communicate the vision
and the solution, build the solution and direct others in building the solution,
confirm that the solution meets the need, and launch the solution application.
Included in SA&D are all the skills, steps, guidelines, and tools that support
and lead up to the actual programming of the system. SA&D includes such
“soft” skills as interviewing and talking to users as well as such “hard” (more
technical) skills as detailing specifications and designing solutions. Many of the
technical skills are associated with creating models that capture specifications or
define solutions. In this book, you will learn all these skills as well as how they
work together to develop an information system.
Let us conclude this section with a few more definitions. Systems analysis
consists of those activities that enable a person to understand and specify what
the new system should accomplish. The operative words here are “understand”
and “specify.” Systems analysis is much more than simply a brief statement of
the problem. For example, a customer management system must keep track of
customers, register products, monitor warranties, and keep track of service
levels, among many other functions—all of which have myriad details. Systems
analysis describes in detail the “what” that a system must do to satisfy the need
or to solve the problem.
Systems design consists of those activities that enable a person to describe
in detail the system that solves the need. The operative word in this case is
“solves.” In other words, systems design describes “how” the system will work.
It specifies in detail all the components of the solution system and how they
work together to provide the desired solution.
Systems Development Life Cycle
Initial development of a new system is usually done as a project. What this
means is that the activities required to develop a new system are identified,
planned, organized, and monitored. We can think of a project as a planned
undertaking that has a beginning and an end and produces some definite result.
Some projects are very formal, whereas others are so informal they can barely
be recognized as projects.
systems analysis those activities that
enable a person to understand and specify what
the new system should accomplish
systems design those activities that
enable a person to define and describe in detail
the system that solves the need
project a planned undertaking that has a
beginning and an end, and that produces some
definite result
CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 5

To manage a project with analysis, design, and other development activities,
you need a project management framework to guide and coordinate the work of
the project team. The Systems Development Life Cycle (SDLC) identifies all
the activities required to build, launch, and maintain an information system.
Normally, the SDLC includes all the activities that are part of systems analysis,
systems design, programming, testing, and maintaining the system as well as
other project management processes that are required to successfully launch and
deploy the new information system.
There are many approaches to the SDLC and many variations for projects
that have various needs. However, there is a core set of processes that is always
required, even though there is also an incredible number of variations of these
core processes—in how each process is planned and executed and in how the
processes are combined into a project. Here are six core processes required in
the development of any new application:
1. Identify the problem or need and obtain approval to proceed.
2. Plan and monitor the project—what to do, how to do it, and who does it.
3. Discover and understand the details of the problem or the need.
4. Design the system components that solve the problem or satisfy the need.
5. Build, test, and integrate system components.
6. Complete system tests and then deploy the solution.
There are many ways to implement these six core processes of the SDLC.
An information systems development process is the actual approach used
to develop a particular information system. Most information systems you will
develop are conceived and built to solve organizational problems, which are
usually very complex, thus making it difficult to plan and execute a develop-
ment project. In fact, many projects end up being much larger than expected—
often resulting in late deliveries that are over budget. During the last 10 years,
several new information systems development processes have been developed to
enhance project success. One of the newer and more effective ones is called
Agile Development. The basic philosophy of Agile Development is that neither
team members nor the user completely understands the problems and complexi-
ties of a new system, so the project plan and the execution of the project must
be responsive to unanticipated issues. It must be agile and flexible. It must have
procedures in place to allow for, anticipate, and even embrace changes and new
requirements during the development process.
Maybe the best way to understand these concepts is to see the way they
play out in a complete example. That is the objective of this chapter, “From
Beginning to End: An Overview of Systems Analysis and Design.” Here, we will
use a fairly small information system application to show you all six core pro-
cesses (as much as is feasible in a textbook, anyway). We will illustrate one way
to organize the various activities into an actual working project; in other words,
we will show you one version of an information system development process.
By going all the way through a very simple project, you will more easily learn
and understand the complex concepts provided in the rest of the text. Our proj-
ect involves Ridgeline Mountain Outfitters, a retailer and manufacturer of cloth-
ing for all types of outdoor activities.
Introduction to Ridgeline
Mountain Outfitters
Ridgeline Mountain Outfitters (RMO) is a large retail company that specializes
in clothing and related accessories for all types of outdoor and sporting activi-
ties. By the 2010s, the Rocky Mountain and Western states had seen tremen-
dous growth in recreation activities, and with the increased interest in outdoor
sports, the market for winter and summer sports clothes had exploded. Skiing,
snowboarding, mountain biking, water skiing, jet skiing, river running, jogging,
Systems Development Life Cycle
(SDLC) the entire process consisting of all
the activities required to build, launch, and
maintain an information system
information systems development
process the actual approach used to
develop a particular information system
Agile Development an information
systems development process that emphasizes
flexibility to anticipate new requirements during
development
6 PART 1 ■ An Introduction to Systems Development

hiking, ATV biking, camping, mountain climbing, rappelling—all had seen a
tremendous increase in interest in these states. People needed appropriate sports
clothes for these activities, so RMO expanded its line of sportswear to respond
to this market. It also added a line of high-fashion activewear and accessories
to round out its offerings to the expanding market of active people.
The company’s growth charted an interesting history of mail-order, brick-
and-mortar, and online sales. RMO got its start by selling to local clothing
stores in the Park City, Utah, area. In the late-1980s and early-1990s, it began
selling directly to customers by using catalogs with mail-in and telephone
orders. It opened its first store in 1994 and soon expanded to 10 retail outlets
throughout the West. Last year, retail store revenue was $67 million, telephone
and mail-order revenues were $10 million, and Web-based sales were $200 mil-
lion. Most sales continue to be in the West, although the market in several areas
of the eastern United States and Canada is growing.
RMO produces its own line of outdoor and sportswear clothing. However,
in order to offer a complete range of outdoor clothing in its retail outlets, it
also sells other brands of outdoor and sportswear clothing. In addition, other
types of clothing and accessories, such as footwear, leather apparel, and spe-
cialty sportswear, are available in the retail stores and through the online store.
Figure 1-2 shows a sample of the catalogs that RMO mails out. Although
mail-order and telephone sales are small, receiving the catalog encourages custo-
mers to go online to make purchases, so RMO continues to produce and mail
abbreviated versions of its catalogs.
Figure 1-3 illustrates a typical order page from the online system.
Trade Shows
In order to keep its product line current and popular, RMO’s purchasing agents
attend apparel and fabric trade shows around the world. RMO purchasers have
a good track record of predicting what products will be good sellers. In addi-
tion, RMO is always watching for new products and accessories that will enable
it to expand its product line appropriately.
When purchasing agents attend a trade show, they frequently find various
products that they want to add to the spring, summer, or winter apparel offering.
2012 WINTER CATALOG
2012 W
IN
TER CATA
LO
G
FIGURE 1-2
RMO winter catalog
CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 7

In the past, when RMO buyers wanted to place an order, they would exchange
contact information with the seller at the trade show and upon returning to the
home office would then follow up via e-mails and phone calls to formulate a con-
tract and make a purchase order. However, to expedite orders, RMO has now
initiated a project to develop a system for collecting and tracking information
about its suppliers and the new products it adds to its merchandise offerings.
Iterative Development
Iterative development is an approach to system development in which the sys-
tem is “grown” in an almost organic fashion. Core components are developed
first and then additional components are added. It is called “iterative” because
the six core development processes are repeated over and over again to add
additional functionality to the overall system. In other words, there is one big
project, which consists of many mini-projects, and the information system is
grown piece by piece.
Figure 1-4 illustrates how an iterative Agile project might be executed. This
is a sample diagram. Real projects might be quite different. Across the figure,
you see six iterations. An iteration is like a mini-project in that it has a com-
pleted result and a constrained time frame. Often, it will last two to four weeks.
Down the left side of the figure, you see the six core processes. The rounded
FIGURE 1-3
RMO sample online ordering page
Core
Processes
1 2 3 4 5 6
Identify problem and obtain
approval
Plan and monitor the project
Discover and understand details
Design system components
Build, test, and integrate system
components
Complete system tests and deploy
solution
Iterations
FIGURE 1-4
The six core processes, with iterations
for a typical project
iterative development an approach to
system development in which the system is
“grown” piece by piece through multiple
iterations
8 PART 1 ■ An Introduction to Systems Development

mounds inside the graph represent the amount of effort for that core process
during that iteration. The amount of area under a curve is an approximate indi-
cation of the amount of effort expended within an iteration with regard to a
particular core process. For example, in Figure 1-4, Iteration 1 appears to pri-
marily focus on identifying the problem and planning the project. Lesser
amounts of discovery, design, and build and test may also be done. For this iter-
ation, nothing is done with regard to deploying the system.
There are several benefits to iterative development. For one, portions of the
often system can sometimes be deployed sooner. If there are core functions that
provide basic support, these can be deployed in an early iteration. A second bene-
fit is that by taking a small portion and developing it first, many tough problems
can be addressed early in the project. Many of today’s systems are so large and
complex that it is impossible to remember and understand everything. By focusing
on only a small portion, the requirements are fewer and easier to grasp and solve.
Finally, developing a system in iterations makes the entire development process
much more flexible and able to address new requirements throughout the project.
A key element of iterative development is choosing a part of the solution
system that can be done in two to four weeks. During one iteration, often all
the core development processes are involved, including programming and
system-wide testing, so the result is a part of the working system, even though
it may only have a portion of the functionality that is ultimately required.
Developing RMO’s Tradeshow System
We will organize our sample project—the RMO Tradeshow System—for the
first iteration, and our goal is to have the iteration last six days. However, our
primary objective is to introduce you to the concepts and techniques of the six
core processes. Therefore, in some instances, we may go a little deeper into a
core process than we might do on the first iteration of a real project. It is a little
unrealistic to complete an entire iteration with all the necessary details in only
six days, but it should be a good learning experience. There will not be a one-
to-one correspondence with the six SDLC core processes and the six days of the
project, but we will include all the SDLC core processes within the project.
At the end of this chapter, we have provided a small case project that has
also been divided into a six-day project. Each day of the project has several pos-
sible assignments that can be completed to help you solidify your understanding
of systems analysis and design and the six core processes.
Most new applications require a project with several iterations. In the first
iteration, there are usually three major objectives. The first objective is to get proj-
ect approval. The second objective is to get a clear picture of the system’s overall
vision—all the major functions and data requirements. The third objective is to
determine the detail specifications and develop a solution for one portion of the
system (i.e., actually analyze, design, build, and test one part of the system).
In our project, we will touch on all these objectives. We will show an exam-
ple of a System Vision Document and then develop one portion of the overall
system. We have constrained the scope of the new system so we can complete it
in one iteration. It should be noted that the division of this project into days and
daily activities is somewhat arbitrary. There are numerous ways to partition and
organize the work. The following organization is quite workable, but it is not
the only way to organize the project.
Pre-Project Activities
Before the project actually begins, the head of RMO’s purchasing department
works with a systems analyst to identify and document the specific business
need as well as define a specific project objective. RMO’s management reviews
the primary project objective and provides budget approval. Every organization
has to give budget approval before a project can start. Some organizations have
CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 9

a formal process to get a project approved; other organizations have a less for-
mal process. Normally, there are two goals an organization must decide on to
get a project off the ground:
■ Identify the problem and document the objective of the solution system.
(Core Process 1)
■ Obtain approval to commence the project. (Core Process 1)
System Vision Document
As with all new projects within RMO, a System Vision Document is developed to
identify the benefits to the company and the functional capabilities that will be
included in the system. Frequently, this is done in two steps: developing a prelimi-
nary statement of benefits and then adding estimates of specific dollar costs and
dollar benefits. Figure 1-5 is the System Vision Document for this project.
Problem Description
Trade shows have become an important information source for new products, new
fashions, and new fabrics. In addition to the large providers of outdoor clothing and
fabrics, there are many smaller providers. It is important for RMO to capture information
about these suppliers while the trade show is in progress. It is also important to obtain
information about specific merchandise products that RMO plans to purchase.
Additionally, if quality photographs of the products can be obtained while at the trade
show, then the creation of online product pages is greatly facilitated.
It is recommended that a new system be developed and deployed so field purchasing
agents can communicate more rapidly with the home office about suppliers and specific
products of interest. This system should be deployed on portable equipment.
System Vision Document
RMO Tradeshow System
System Capabilities
The new system should be capable of:
• Collecting and storing information about the manufacturer/wholesaler (suppliers)
• Collecting and storing information about sales representatives and other key
personnel for each supplier
• Collecting information about products
• Taking pictures of products (and/or uploading stock images of products)
• Functioning as a stand-alone without connection
• Connecting via Wi-Fi (Internet) and transmitting data
• Connecting via telephone and transmitting data
Business Benefits
It is anticipated that the deployment of this new system will provide the following
business benefits to RMO:
• Increase timely communication between trade show attendees and home office,
thereby improving the quality and speed of purchase order decisions
• Maintain correct and current information about suppliers and their key personnel,
thereby facilitating rapid communication with suppliers
• Maintain correct and rapid information and images about new products, thereby
facilitating the development of catalogs and Web pages
• Expedite the placing of purchase orders for new merchandise, thereby catching
trends more rapidly and speeding up product availability
FIGURE 1-5
Tradeshow System Vision Document
10 PART 1 ■ An Introduction to Systems Development

As described earlier, RMO needs a portable system that can be used by its
purchasing agents as they attend various product and clothing fabric trade
shows. The system needs to fulfill two major requirements. First, it has to have
the functionality to capture information about suppliers and products. Second,
it needs to be able to communicate with the home office systems, and because
these trade shows are held in various venues around the world, various methods
of connectivity are needed.
Preliminary investigation considered various equipment options, including
laptop computers, iPad computing devices, and smartphones. Even though
smartphones appeared to have the best connection options, the small size made
viewing the details of photographs somewhat difficult; the iPad and other simi-
lar portable devices with advanced technology also appear to be viable options.
However, due to the similarity of the smartphones and tablets, it seems feasible
to develop an application that will execute on either device. Each purchasing
agent could use his or her preferred device.
Toward the end of the pre-project activities, a meeting is held involving all
the key persons, including a representative of executive management. The deci-
sion is made to move ahead with the project and budget the necessary funds.
Day 1 Activities
RMO—Supplier Information Subsystem
The project actually begins with Day 1, which is essentially a planning day.
Usually, the first activity is the project team reviewing the System Vision
Document and verifying that the preliminary work is still valid. It reviews the
scope of the project to become familiar with the problem to be solved, then it
plans the iterations and activities for the remainder of the project. The second
SDLC core process—planning the project—includes business analysis and proj-
ect management activities. All these topics will be treated in depth in later chap-
ters. These activities are completed on Day 1:
■ Determine the major components (functional areas) that are needed. (Core
Process 2)
■ Define the iterations and assigning each functional area to an iteration.
(Core Process 2)
■ Determine team members and responsibilities. (Core Process 2)
Planning the Overall Project and the Project Iterations
Myriad details need to be considered in a project plan. For our project, we will
only focus on the bare essentials. We will describe project planning more elabo-
rately in later chapters.
The project team meets with the users to review the overall business need
and the objectives of the new system. The System Vision Document serves as
the starting point for these discussions. As is often the case, the list of System
Capabilities provides the foundation information for determining the overall
project plan. The first step is to divide the system into several subsystems or
components. A subsystem is simply a portion of the overall system. Based on
the list of System Capabilities, the project team identifies these functional
subsystems:
■ Supplier Information subsystem
■ Product Information subsystem
The Supplier Information subsystem will collect and maintain information
about the manufacturers or wholesalers and the contract people that work for
them. The Product Information subsystem will capture information about the
various products, including detailed descriptions and photographs.
The next step is to identify which subsystems will be developed in which
order. Many issues are considered, such as dependencies between the various
subsystem an identifiable and partitioned
portion of an overall system
CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 11

tasks, sequential versus parallel development, project team availability, and proj-
ect urgency. In our case, the team decides that the project will proceed in a serial
fashion, with the Supplier Information subsystem scheduled as the first iteration.
Planning the First Iteration
Each iteration is like a systems development mini-project. The core processes
described earlier can all be applied, with the scope limited to the component
that is to be developed during the iteration. The planning process for an itera-
tion consists of these three steps:
■ Identify the tasks required for the iteration.
■ Organize and sequence these tasks into a schedule.
■ Identify required resources (especially people) and assign people to tasks.
The first step is to identify—or attempt to identify—all the individual tasks
that need to be done. As these tasks are identified, they are compiled and orga-
nized. Sometimes, this organized list of tasks is called a Work Breakdown
Structure. Figure 1-6 shows the Work Breakdown Structure for this iteration.
Part of the effort is trying to estimate how long each task will take. Because
this project has a very limited scope (only six days), all the estimates will be in
hours. These estimates do not include the time expended by those who are not
on the team. However, of those on the team, the estimates include the time for
the original work, the time for discussion, and the time for reviewing and check-
ing the Work Breakdown Structure for accuracy and correctness.
The next step is to get these tasks organized into a schedule. Again, we can
be very formal and use a sophisticated project-scheduling tool or we can just
list the tasks in the order we think they need to be done. An important part of
building the schedule is identifying any dependencies between the tasks. For
FIGURE 1-6
Sample handwritten Work Breakdown
Structure
12 PART 1 ■ An Introduction to Systems Development

example, it does not make sense to try to design the database before we have
identified the information requirements. But many tasks can be done in parallel.
Again, the great benefit of a single iteration is that we can make the sched-
ule informal, and we will be able to adjust the work day by day to respond to
specific complexities that occur.
For our project, we will not build a complete schedule. You will learn how
to do that in a later chapter. However, in order to organize our six-day project,
we have taken the tasks from the Work Breakdown Structure and placed them
on a day-by-day sequence that we call a work sequence draft, as shown in
Figure 1-7. To develop a formal schedule, the project leader will use this dia-
gram to assign people to the tasks as well as put the tasks on a specific schedule
chart with calendar dates.
You should be aware that the sequence of activities and the dependencies of
those activities are represented in this diagram with only partial accuracy. For
example, we show that programming does not start until design has finished.
However, in reality, there may be some overlap between the two activities.
0-1
Develop project plan
Day 1: Plan
project
Day 2: 12 hours
Day 3: 14 hours
Day 6: 12 hours
Start
I-1 3 hrs
Meet with purchasing manager
I-2 4 hrs
Meet with purchasing agents
I-3 3 hrs
Define use cases
I-5 6 hrs
Develop workflows
I-4 2 hrs
Define information requirements
II-1 8 hrs
Design screens
Day 5: 28 hours
IV-1 5 hrs
Perform functional tests
IV-2 7 hrs
Perform user acceptance test
II-2 4 hrs
Design and build database
II-3 4 hrs
Design overall architecture
II-4 6 hrs
Design program
details
III-1 14 hrs
Code and test
GUI layer
III-2 8 hrs
Code and test logic
layer
Morning of Day 4: 8
hours
FIGURE 1-7
Work sequence draft
CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 13

The benefit of a work sequence draft is threefold. First, it helps the team orga-
nize its work so there is enough time set aside to think through the critical
design issues before programming begins. Second, it provides a measuring rod
to see if the iteration is on schedule. For example, if meetings with the purchas-
ing agents take all day or more than a day, the team will know early on that
this iteration will take longer than expected. Third, the project leader can see
that programming may require more resources if the project is going to stay on
this schedule. Hence, the project leader can begin lining up resources early on
to help with that part of the project. It should be obvious that even this simple
dependency diagram can help a project manager plan and organize the work.
Day 2 Activities
Day 1 involved planning and organizing the project. Day 2 involves systems anal-
ysis activities that help us understand and document requirements. On Day 2, we
will specify the functions in more detail. These activities are included:
■ Do preliminary fact-finding tasks to understand the requirements. (Core
Process 3)
■ Develop a preliminary list of use cases and a use case diagram. (Core
Process 3)
■ Develop a preliminary list of classes and a class diagram. (Core Process 3)
Fact Finding and User Involvement
Before the project commenced, a preliminary, broad definition of functions was
developed. It is now time to examine the specifics of those functions and deter-
mine exactly what the user needs the system to do. The first step is to identify
the key users that will help define these details. Obviously, the manager of the
purchasing department will be one of the first ones to meet with. She will proba-
bly designate one or two knowledgeable purchasing agents who can work with
the team on an ongoing basis to develop the specifications and to verify that the
system performs as required. All successful projects depend on heavy user involve-
ment. In Chapter 2, you will learn more about identifying key stakeholders.
There are various techniques to ensure that the fact finding is complete and
thorough. These include interviewing the key users, observing existing work
processes, reviewing existing documentation and existing systems, and even
researching other companies and other systems.
Identifying Use Cases
A use case documents a single user-triggered business event and the system’s
response to that event. For example, let us say a purchasing agent goes to a
trade show and finds some new lightweight sports jackets that will work well
for RMO’s fall merchandise offerings. Maybe the first task the purchasing
agent needs to do is find out if this supplier has worked with RMO before.
Thus, the business event that requires the Tradeshow System might be “Look
up a supplier.” Activities leading up to the event of using the system are impor-
tant, but we do not identify them as business events until the Tradeshow System
is used—hence, the term use case—a case or situation where the system is used.
One good way to help you identify use cases is to say, “The purchasing agent
‘uses’ the system to ‘Look up a supplier.’”
There are multiple methods used to identify use cases, which you will learn
about later in this book. Figure 1-8 is a preliminary list of use cases for the
entire Tradeshow System. When the project team meets with the purchasing
agents in brainstorming sessions, they together identify every business event
in which a purchasing agent might use the system. However, because this first
iteration is focusing only on the Supplier Information subsystem, the project
team will also focus its attention on only the first four use cases on the list.
14 PART 1 ■ An Introduction to Systems Development

Identifying Object Classes
Object classes identify those things in the real world that the system needs to
know about and keep track of. In order to find object classes, we look for all
the objects, or things, that the system uses or captures. Objects come in all
types and variations, from tangible items (such as merchandise products that
you can see and touch) to more abstract concepts that you cannot touch (such
as an order), which, though intangible, definitely exist.
Object classes are identified in the discussions with purchasing agents by
looking for the nouns that describe categories of things. For example, the agents
will often talk about suppliers, merchandise products, or inventory items. More
details about how to identify object classes and their attributes are provided
later in this book.
Figure 1-9 illustrates which nouns have been determined to be fundamental
object classes for the Tradeshow System. The attributes are descriptors that help
define and describe an object class.
In addition to just providing a list of object classes, systems analysts often
develop a visual diagram of the classes, their attributes, and their relationships
to other classes. This diagram is called a class diagram. Figure 1-10 illustrates
a class diagram for the Tradeshow System.
Each box is a class and can be thought of as a particular set of objects that
are important to the system. Important attributes of each class are also included
in each box. These represent the detailed information about each object that will
be maintained by the system. Note that some classes have lines between them.
These represent relationships between the classes that need to be captured in
the system. For example, a contact is a person who works for a particular sup-
plier. A specific example might be that Bill Williams is the contact person for
FIGURE 1-9
List of object classes
Object Classes Attributes
Supplier supplier name, address, description, comments
Contact name, address, phone(s), e-mail address(es),
position, comments
Product category, name, description, gender, comments
ProductPicture ID, image
FIGURE 1-8
List of use cases
Use Case Description
Look up supplier Using supplier name, find supplier information and
contacts
Enter/update supplier
information
Enter (new) or update (existing) supplier information
Look up contact Using contact name, find contact information
Enter/update contact
information
Enter (new) or update (existing) contact information
Look up product
information
Using description or supplier name, look up product
information
Enter/update product
information
Enter (new) or update (existing) product information
Upload product image Upload images of the merchandise product
CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 15

the South Pacific Sportswear Company. Thus, the system needs to associate Bill
Williams and the South Pacific Sportswear Company. The relationship line
documents that requirement.
Class diagrams are a powerful and frequently used way to understand and
document the information requirements of a system. The Tradeshow System is
extremely simple, with only four classes identified—two of which belong to the
Supplier Information subsystem. Most real-life systems are much larger and
have dozens of classes.
Day 3 Activities
The purpose of Day 3 activities is to analyze in detail those use cases and classes
that were selected to be implemented in this first iteration. During Day 3, we are
still performing processes that are considered systems analysis. We are still try-
ing to understand the requirements at a detailed level for the system. Included
are these activities:
■ Perform in-depth fact finding to understand details. (Core Process 3)
■ Understand and document the detailed workflow of each use case. (Core
Process 3)
■ Define the user experience with screens and reports. (Core Processes 3 and 4)
It is important to note that the use cases help the project team organize its
work. These drill-down activities are done for each use case. As mentioned ear-
lier, these use cases pertain to the Supplier Information subsystem:
■ Look up supplier.
■ Enter/update supplier information.
■ Look up contact information.
■ Enter/update contact information.
The project team will develop a workflow for each use case to better under-
stand how it works and to identify what screens and possibly what reports will
need to be developed. As the team gets more into the details, it may discover
that some of the initial analysis is incomplete, if not incorrect. This is a good
time to make such discoveries—much better than after the programs have been
written.
Figure 1-11 illustrates a simple use case diagram. It shows the four afore-
mentioned use cases identified and the user who will be the primary person
name
address
description
comments
Supplier
productCategory
name
description
gender
comments
Productltem
1..*
1
1 1..*
name
address
phone(s)
emailAddress(es)
position
comments
Contact
pictureID
image
ProductPicture
1 0..*
FIGURE 1-10
Preliminary class diagram for the
Tradeshow System
16 PART 1 ■ An Introduction to Systems Development

performing that function. What the diagram means in detail and how to develop
one will be discussed in a later chapter.
Developing Use Case Descriptions and Workflow Diagrams
There are various methods for documenting the details of a use case. One that
you will learn later in this text is called a use case description. Another method
is developing a workflow diagram, which shows all the steps within the use
case. The purpose with either method is to document the interactions between
the user and the system (i.e., how the user interacts and uses the system to
carry out a specific work task for a single use case).
Let us develop a workflow for one use case. To develop a workflow, we
will use a simple type of diagram called an activity diagram. Figure 1-12 illus-
trates the workflow for the Look up supplier use case. The ovals in the diagram
represent the tasks, the diamonds represent decision points, and the arrows rep-
resent the sequence of the flow. The columns represent who performs which
tasks. Usually, workflow diagrams are quite easy to understand.
The arrows that cross the center line represent the interactions between the
system and the user. These are critically important because the developers must
provide a screen or Web page that either captures or displays information. The
arrows that cross the center line identify the data elements that become part of
the user interface.
Looking at Figure 1-12, we see that the top arrow indicates that the sup-
plier name enters into the system. Thus, we infer that the user must have an
online form in order to enter the supplier name for the initial lookup. The next
arrow indicates that there must be a form that displays all the details for an
individual supplier, including a list of existing contacts. The user may also want
to see more details about a specific contact person for this supplier, so the user
may request detailed information for a particular person. Because the user can
select one of the displayed results, it appears that we must design the form so
each entry on the list is either a hotlink or has some mechanism to select it.
Defining Screen Layout
User-interface design includes all those tasks that describe the look and feel of
the system to the user. Because the user interface is the window that the users
Look up supplier
Enter/update
supplier
information
Look up contact
Enter/update
contact
information
ManagerPurchasing
agent
FIGURE 1-11
Use case diagram
CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 17

work with to utilize the functionality of the system, the user interface is essen-
tially the system. If the interface is poorly designed, users will not be able to
take full advantage of the system; they may even consider the system to be less
than optimal. On the other hand, a well-designed user interface—one that is
intuitive and easy to use, with a full range of features to facilitate navigation,
and that provides good information—will enhance the utility of the system
tremendously.
Figure 1-13 illustrates the layout of the first screen used for the workflow in
the use case Look up supplier. The top portion of the screen provides the loca-
tions for the user to enter the supplier information, and the bottom portion of
the screen shows the results. When results are provided, the search box for data
entry will remain visible to allow the user to enter another search. Each entry in
the results will be built as a hotlink, so the user can click on any particular sup-
plier to retrieve more detailed information. This drill-down technique is a com-
mon method used in today’s systems and will be intuitively easy for the users.
Searches are conducted on the RMO database, resulting in such RMO
information as name, address, and contact information. An Internet-wide search
is also possible. This allows the purchasing agents to look for and view the sup-
pliers’ own Web sites, which can be helpful, as can looking at forums and dis-
cussions about the supplier. Note that this tangential activity is not captured in
the workflow of Figure 1-12. It is intended to assist in screen design, not docu-
ment everything the user can or will do.
Purchasing Agent Tradeshow System
Start
Enter supplier name
Return supplier information
not found
found
View supplier and
contact names
done
look up contact
Select contact name
Retrieve contact information
View contact information
End
FIGURE 1-12
Workflow diagram for the Look up
supplier use case
18 PART 1 ■ An Introduction to Systems Development

Day 4 Activities
The primary focus of Day 4 activities is to design the various components of the
solution system. Up to now, we have mostly been trying to understand the user
requirements. On Day 4, we carry out design activities that direct programming
efforts. In that sense, design activities can be considered somewhat of a bridge.
During analysis activities, the project team’s objective is to understand user
needs. During programming, the objective is to produce the solution. Thus,
design is the bridge between understanding and construction. It provides the
outline for how the solution will be structured and how it is to be programmed.
System design also tends to involve the technical people, with less need for user
participation.
Design can be a complex process. In our small project, we will limit
our design examples to only a few models and techniques. Later in this text-
book, you will learn additional design techniques. Day 4 Activities include the
following:
■ Design the database structure (schema). (Core Process 4)
■ Design the system’s high-level structure. (Core Process 4)
Database design is a fairly straightforward activity that uses the class dia-
gram as input and develops the detailed database schema that can be directly
implemented by a database management system. Such elements as table design,
key and index identification, attribute types, and other efficiency decisions are
made during this activity.
Designing the high-level system structure and the individual programs can
be an intricate and complex process. First, the overall structure of the system is
designed, including identifying the subsystems and connections to other systems.
Within each subsystem, decisions are made about individual programs, such as
user-interface programs, business logic programs, and database access programs.
Then, at the lowest level, the login within each program is defined, including
what program functions are required and what variables are used.
It is not uncommon for developers to begin writing program code as they
develop portions of the design. It is a good idea to complete most of the
Web Search
RMO Database Search
Supplier Name
Product Category
Product
Country
Contact Name
Supplier Name
Search Results
Contact PositionContact Name
GO
GO
Logo
FIGURE 1-13
Draft of screen layout for the Look up
supplier use case
CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 19

structural design before writing code. But as the lower levels of the system are
being designed, programming often begins. However, in the RMO Tradeshow
System project, we will list them as separate activities.
Designing the Database
Designing the database uses the information provided by the class diagram to
determine the tables, the columns in the tables, and other components. Sometimes,
the database design is done for the entire system or subsystem. At other times, it is
built piecemeal—use case by use case. To keep our project simple, we will just
show the database design for the two classes that are required for the Supplier
Information subsystem. Figure 1-14 shows the database schema for the Supplier
Information subsystem. Two tables are defined: Supplier and Contact.
Approaching High-Level Systems Design
There are fundamental design principles that will guide you through systems
and program design; they will be explained in detail later in this book. For
now, we will describe the general approach to design.
One of the first questions encountered in systems design is how and where
to start. So far, we have three types of documents that can provide specifications
to help answer that question. We have use cases, with their accompanying docu-
mentation, such as use case workflow diagrams. We have a class diagram that
will help us identify some of the object-oriented classes that will be needed in
the system. (In the previous section, we used the class diagram as the basis for
the database design. Those same classes are important in developing object-
oriented program classes.) Finally, we have screens and reports that also provide
specifications for program logic and display logic.
Before we jump into design, let us briefly discuss the objective of systems
design and what we expect to have as the output or result. Object-oriented pro-
grams are structured as a set of interacting classes. Therefore, in order to pro-
gram, we need to know what those programming classes are, what the logic is
within each class (i.e., the functions), and which programming classes must
interact together. That is the final objective of systems design: to define the clas-
ses, the methods within those classes, and the interactions between classes.
Supplier SupplierID: integer {key}
Name: string {index}
Address1: string
Address1: string
City: string
State-province: string
Postal-code: string
Country: string
SupplierWebURL: string
Comments: string
ContactID: integer {key}
SupplierID: integer {foreign key}
Name: string {index}
Title: string
WorkAddress1: string
WorkAddress2: string
WorkCity: string
WorkState: string
WorkPostal-code: string
WorkCountry: string
WorkPhone: string
MobilePhone: string
EmailAddress1: string
EmailAddress2: string
Comments: string
Contact
Table Name Attributes
FIGURE 1-14
Database schema for Supplier
Information subsystem
20 PART 1 ■ An Introduction to Systems Development

We perform this design by starting at the very highest level and then drilling
down to the lowest level until we have defined all the functions within each
class. Detailed design is the thought process of how to program each use case.
Later in the text, you will learn techniques to carry out detailed design. For
Day 4, we will focus only on the overall design.
Designing the Overall Architecture
Figure 1-15 shows the overall architecture or structure of the new system.
Although the figure itself appears rather simple, some important decisions have
been involved in the development of this design. First, note that the decision
was made to build this application as a browser-based system. A different and
very popular approach would have been to build smartphone or tablet applica-
tions. Browser-based systems sometimes do not provide the same connectivity
speed and control as smartphone or tablet applications, but they are more versa-
tile in that they can be more easily deployed on different equipment, such as
laptops, without modification.
These high-level design decisions will determine the detailed structure of the
system. A browser-based system is structured and constructed differently than
an application system that runs on a smartphone or a tablet computer.
Defining the Preliminary Design Class Diagram
Given that the Tradeshow System will be built by using object-oriented pro-
gramming (OOP) techniques, an important component of the design is develop-
ing the set of object classes and functions that will be needed for the system.
This process can become quite detailed, and we will not try to explain it for
this project. You will learn those techniques later in this book.
Figure 1-16 is a preliminary design class diagram for the Tradeshow
System. A design class diagram (DCD) identifies the OOP classes that will be
needed for the system. The set of design classes includes problem domain clas-
ses, view layer classes, sometimes separate data access classes, and utility classes.
In Figure 1-16, we show only the problem domain classes and the view layer
classes. Problem domain classes are usually derived from those classes that were
identified during analysis activities—hence, the name: problem (user need)
domain classes. You will also notice that they very closely correspond to the
Supplier
Information
subsystem
Product
Information
subsystem
Browser
Internet
Tradeshow System
Internet server
FIGURE 1-15
Tradeshow System architectural con-
figuration diagram
CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 21

database tables; in fact, in this simple project, they are almost exactly the same
as the database tables. On more complex systems, they will be similar but not
exactly the same. However, remember that programming classes are distinct
from database tables.
Other classes are required for the graphical user interface (GUI). In a
dynamic Web system, such as the Tradeshow System, they are the classes that
receive the input from the browser and format the output HTML files to be dis-
played by the browser.
The design classes in Figure 1-16 include the class-level variables that are
needed for the class. These classes also show method names of the important meth-
ods within each class. These methods are identified and specified during high-level
design and detailed design. One final element in the design class diagram are
arrows that show which classes can access the methods of which other classes.
Designing Subsystem Architecture
Once we have an overall structure and an overall approach for implementing
the new system, we begin to drill down to the subsystem design. Figure 1-17
illustrates the architectural design of the Supplier Information subsystem. Notice
that this subsystem is further divided into layers: a view layer and a model layer.
You will learn much more about multilevel design later in this textbook. One of
the advantages of partitioning the system into layers is that the system is much
easier to build and maintain with this kind of structure. For example, the system
will be browser based, but different browsers require different techniques. It is
better not to get these complexities mixed in with the basic program functions.
Hence, they are separated out into a distinct layer.
lookupSupplier ( )
displaySupplier ( )
SupplierView
lookUpContact ( )
displayContact ( )
ContactView
supplierID {key}
name: string
address: string
address2: string
city: string
state: string
country: string
URL: string
comments: string
Supplier
contactID {key}
name: string {index}
title: string
waddress1: string
waddress2: string
wcity: string
wstate: string
wpostal: string
wcountry: string
wphone: string
mobilephone: string
email1: string
email2: string
comments: string
Contact
getSupplierInfo ( ) getContactInfo ( )
FIGURE 1-16
Preliminary design class diagram
22 PART 1 ■ An Introduction to Systems Development

Figure 1-17 shows that the view layer has two PHP classes that process user
inputs from the browser and format output HTML files. It also contains various
JavaScript functions that will execute within the browser itself. The model layer
classes are those classes that perform the business logic as well as access the
database. Sometimes, the data layer and the business logic layer are further
divided.
Managing the Project
Design is a complex activity with multiple levels—from high-level structural
design to low-level detailed program design. In our project, we have separated
the tasks for designing the overall system structure from detailed design of the
programs themselves. However, these activities are often done concurrently.
The basic high-level architectural structure is defined first, but mid-level and
low-level design are often done concurrently with programming.
In Figure 1-17, we can see that detailed design and programming are quite
time-consuming activities. A project manager must decide whether to extend the
project or bring on additional programmers to help write the code. In our proj-
ect, we have elected to insert a half-day of free time to bring in two additional
programmers and train them. Of course, we could go ahead and begin Day 5’s
activities to ensure that we keep the project on schedule.
Day 5 Activities
Even though detailed design and programming may frequently begin earlier in
the project, we have identified it as a separate day’s activities. We do this for a
couple of very important reasons. First, we want to emphasize that it is not a
good practice to begin programming before critical information is obtained and
decisions are made. Often, novice programmers will begin to program before
lookUpSupplier ( )
displaySupplier ( )
SupplierView
getSupplierInfo ( )
Supplier
lookUpContact ( )
displayContact ( )
validateSupplierInput ( )
validateContactInput ( )
php
html/css
javascript
php
sql
Javascript
Functions
View layer
Supplier Subsystem
Model layer
ContactView
getContactInfo ( )
Contact
FIGURE 1-17
Supplier subsystem architectural
design diagram
CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 23

the users’ needs are adequately understood or even before the structure of the
overall system has been determined. But a much better approach is to under-
stand, design, and build small chunks of the system at a time. Agile Development
anticipates and plans for the expected changes and refinements to the problem
requirements that happen during detailed design and programming.
As the programmers write the code, they also perform individual testing on
the classes and functions they program. This textbook does not focus on program-
ming activities. However, we include an example of program code so you can see
how systems design relates to the final program code. Figure 1-18 is an example
of a class that receives and processes the request for supplier information.
Day 6 Activities
The focus of Day 6 activities is to do the final testing that is required before the
system is ready to be deployed. There are many types of testing that are
required. In this example, we mention only two types of testing: overall system
functional testing and user acceptance testing. Functional testing is usually a
system-level test of all user functions and is often done by a quality assurance
team. User acceptance tests are similar in nature, but they are done by the
users, who test not only the correctness of the system but its “fitness” to accom-
plish the business requirements.
Each of the various testing activities in Day 6 has a somewhat similar
sequence of tasks to perform. The tasks themselves highly depend on the test
data and on the method for testing a particular test case. In some instances, the
testing may be automated. In others, individuals may need to manually conduct
the tests. Many new systems are interactive systems with user activity. There are
some testing tools that automate that process somewhat, but it tends to be a
rather complex task.
theSupplier = new Supplier();
}
function lookupSupplier()
{
include(‘lookupSupplier.inc.html’);
}
function displaySupplier()
{
include(‘displaySupplierTop.inc.html’);
extract($_REQUEST); // get Form data
//Call Supplier class to retrieve the data
$results = $theSupplier->getSupplierInfo($supplier, $category,
$product, $country, $contact);
foreach ($results as $resultItem){
?>

FIGURE 1-18
Code for the SupplierView class
24 PART 1 ■ An Introduction to Systems Development

Figure 1-19 is a generalized workflow for testing the new system. In this
workflow, we have shown the different testing tasks as separate steps. In reality,
they all tend to be carried out together. However, any given test case will follow
this flow.
First Iteration Recap
Figure 1-20 is a screenshot of the browser page that is used in the Tradeshow
System to enter and view suppliers.
As stated previously, this is the first (six-day) iteration of a longer project.
Using Agile techniques and iterations within an overall project allows flexibility
in defining and building a new system. One of the Agile mandates is that the
user should be heavily involved in the development of the new system. In this
six-day project, the users have had major involvement during all days except
Day 4 and Day 5.
A primary problem in developing a new system is that as the project pro-
gresses, new requirements are often identified. This happens because the users
and the project team learn more about how to solve the business need. Agile,
iterative projects are structured to handle these new requirements—often by
adding another iteration to the overall project.
As a final step in a current iteration, or perhaps as part of the planning
process for the next iteration, there should be a review of the processes and
success of the current iteration. The lessons learned and issues to be carried
forward create an environment of continual improvement and refinement.
Iterative projects tend to improve and become more efficient during the life of
the project.
Start Create test data Conduct tests
End
Document errors
and issues
Fix errors
FIGURE 1-19
Generalized workflow of testing tasks
Web Search
RMO Database Search
Supplier Name
Product Category
Product
Country
Contact Name
Supplier Name
Search Results
Contact PositionContact Name
GO
GO
FIGURE 1-20
Screen capture for Look up supplier
use case
CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 25

Where You Are Headed—The Rest of
This Book
This sixth edition of Systems Analysis and Design in a Changing World includes
the printed textbook and supporting online chapters. The current printed text-
book provides a compact, streamlined, and focused presentation of those topics
that are essential for information systems developers. The online chapters extend
those concepts and provide a broader presentation of several topics. The online
chapters may be integrated into the course or simply used as additional reading
as prescribed by the instructor.
Part 1: Introduction to Systems Development
Part 1—comprising Chapter 1 and Online Chapter A—presents an overview of
systems development. The introductory chapter provides a detailed, concrete
example of what is required in a typical software development project. Of
course, many details had to be left out to keep this chapter at a reasonable
length. However, this chapter does present many processes, techniques, and dia-
grams. You are not expected to understand all the elements from this brief
introduction. However, you should have a general idea of the approach to
developing systems. You may want to refer back to this chapter from time to
time to help understand the big picture.
This first chapter begins by briefly explaining the objectives of systems anal-
ysis and systems design. Many students who take a programming class think
that programming is all you need to develop software and deploy a system.
This chapter and the rest of this book should dispel that myth.
Online Chapter A, “The Role of the Systems Analyst,” describes the many
skills required of a systems analyst. It also discusses the various career options
available to information systems majors. For those of you who are new to the
discipline of information systems, this chapter will provide interesting and help-
ful knowledge about information systems careers.
There are three major subject areas discussed in this book: systems analysis,
systems design, and project management. There is also one minor subject area,
which is no less important but not discussed in as much depth, and that is sys-
tems implementation, testing, and deployment. In addition, we have taken an
approach that is quite different from other texts. Because you already have a
basic understanding of systems analysis and design from Chapter 1, we can
immediately present in-depth concepts about systems analysis and design. We
present project management topics later in this text. This will allow you to
learn those project management concepts after understanding the elements of
systems analysis and design. We think it will be more meaningful for you at
that point in the course.
Part 2: Systems Analysis Tasks
Chapters 2 through 5 cover systems analysis in detail. Chapter 2 discusses tech-
niques for gathering information about the business problem. Developing the
right system solution is possible only if the problem is accurately understood.
The various people who are affected by the system (the stakeholders) are also
included in the development of the solution. Chapter 2 also explains how to
identify and involve the stakeholders and introduces the concept of models and
modeling. Chapters 3 and 4 present methods for capturing the detailed require-
ments for the system in a useful form. When discussing an information system,
two key concepts are particularly useful: use cases, which define what the end
users need the system to do, and the things, called data entities or classes, that
users work with while carrying out their tasks. These two concepts—use cases
and data entities/classes—are important no matter what approach to system
26 PART 1 ■ An Introduction to Systems Development

development is being used. Chapter 5 presents more in-depth models, such as
use case descriptions, use case diagrams, and system sequence diagrams.
Online Chapter B, “The Traditional Approach to Requirements,” presents
the traditional, structured approach to developing systems. To those instructors
and students who desire to learn about data flow diagrams, this chapter pro-
vides an in-depth presentation.
All these modeling techniques provide in-depth analysis of the user’s needs
and allow the analyst to develop requirements and specifications. Again, the
purpose of systems analysis is to thoroughly understand and specify the user’s
needs and requirements.
Part 3: Essentials of Systems Design
Chapters 6 and 7 provide the fundamental concepts related to systems design
and to defining and designing the user experience. Chapter 6 provides broad
and comprehensive coverage of important principles of systems design. It serves
not only as a broad overview of design principles but as a foundation for later
chapters that explain the detailed techniques, tasks, skills, and models used to
carry out design.
Chapter 7 presents additional design principles related to designing the user
interface and the system interfaces. Designing the user interface is a combination
of analysis and design. It is related to analysis because it requires heavy user
involvement and includes specifying user activities and desires. On the other
hand, it is a design activity because it is creating specific final components that
are used to drive the programming effort. The screens and reports and other
user interaction components must be precisely designed so they can be pro-
grammed as part of the final system. System interfaces occur when one informa-
tion system communicates or interacts with another information system without
human intervention. System interfaces are becoming increasingly important
because of Web services and cloud computing.
Part 4: Projects and Project Management
By this point, you will have a basic understanding of all the elements of systems
development.
Part 4 brings together all these concepts by explaining more about the pro-
cess of organizing and managing development projects. Chapter 8 describes dif-
ferent approaches to systems development in today’s environment, including
several important System Development Life Cycle models. It is an important
chapter to help you understand how projects actually get executed.
Chapter 9 extends these concepts by teaching foundation principles of proj-
ect management. Every systems analyst is involved in helping organize, coordi-
nate, and manage software development projects. In addition, almost all of you
will become team leaders and project managers. The principles presented in
Chapter 9 are essential to a successful career.
Online Chapter C, “Project Management Techniques,” goes into more
detail regarding the tools and techniques used by systems analysts and project
managers to plan and monitor development projects. For those instructors and
students who would like to learn specific project management skills, this is an
important chapter.
Part 5: Advanced Design and Deployment Concepts
Part 5 goes into more depth with respect to systems design, database design,
and other important issues related to effective and successful system develop-
ment and deployment.
Chapters 10 and 11 explain in detail the models, skills, and techniques used
to design software systems. As mentioned earlier in this chapter, systems design
is a fairly complex activity, especially if it is done correctly. The objective of
CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 27

these two chapters is to teach you the various techniques—from simple to
complex—that can be used to effectively design software systems.
Chapter 12 explains how to design the database from the information
gleaned during analysis and the identification of the object classes. Other related
concepts, such as controls and security, are also presented in this chapter.
Chapter 13 describes the final elements in systems development: final testing,
deployment, maintenance, and version control. Chapter 14 concludes this book
by looking toward the future of software development and assessing the current
trends that may eventually enhance and improve the approaches to software
development.
Chapter Summary
This chapter provided a quick overview of a particular
software system development project called the
Tradeshow System. The six core processes that control
software development were presented. Then, the various
activities that support the execution of these six core pro-
cesses were explained as we went through an implementa-
tion of the Tradeshow System. The six core processes are:
1. Identify the problem or need and obtain approval to
proceed.
2. Plan and monitor the project—what to do, how to do
it, and who does it.
3. Discover and understand the details of the problem
or the need.
4. Design the system components that solve the problem
or satisfy the need.
5. Build, test, and integrate system components.
6. Complete system tests and then deploy the solution.
In order to facilitate learning and to help you remember
the core processes and related activities, we divided the
project into pre-project activities and then six other
groupings, which we called project days. It should be
noted that there is nothing magical or mandatory about
this way of organizing a project. It was done in this man-
ner simply to help you understand the various activities
related to the core processes.
Key Terms
Agile Development 6
computer application (app) 4
information system 4
information systems development
process 6
iterative development 8
project 5
subsystem 11
systems analysis 5
systems design 5
Systems Development Life
Cycle (SDLC) 6
Review Questions
1. What is the difference between an information sys-
tem and a computer application?
2. What is the purpose of systems analysis? Why is it
important?
3. What is the difference between systems analysis and
systems design?
4. What is a project?
5. What are the six core processes for software systems
development?
6. What is meant by Agile Development?
7. What is the purpose of a System Vision Document?
8. What is the difference between a system and a
subsystem?
9. What is the purpose of a Work Breakdown
Structure?
10. What are the components of a Work Breakdown
Structure? What does it show?
11. What information is provided by use cases or a use
case diagram?
12. What information is provided by a class diagram?
13. How do a use case diagram and a class diagram
drive the system development process?
28 PART 1 ■ An Introduction to Systems Development

14. What is another way to describe an activity
diagram? What does it show?
15. How does an activity diagram help in user-interface
design?
16. What is the purpose of architectural design?
17. What new information is provided in a design class
diagram (more than a class diagram)?
18. What are the steps of system testing?
19. What is the purpose of user acceptance testing?
20. Why is it a good practice to divide a project into
separate iterations?
21. What should be the objective or result of an
iteration?
CHAPTER CASE
Keeping Track of Your Geocaching Outings
When Wayne Johansen turned 16, his dad bought him
a new Garmin handheld GPS system. His family had
always enjoyed camping and hiking, and Wayne was
usually the member of the family who monitored their
hikes with his dad’s GPS system. He always liked to
carry the GPS because he really enjoyed monitoring
the routes, distances, and altitudes of their hikes.
More recently, though, he had found a new hobby
by using his GPS system: geocaching.
Geocaching is akin to the treasure hunts that most
of us did when we were kids. The difference is that
geocaching is a high-tech version of a treasure hunt
that uses GPS but also calls on one’s basic treasure-
hunting skills.
As Wayne became more involved with his hobby,
he discovered that there are many different kinds of
activities for geocaching enthusiasts. The simplest
ones are those that involve caches that can be found
by using GPS coordinates, although even some of these
can be difficult if the caches are well hidden and well
camouflaged. Some of the activities involve multipoint
drops in which there is a set of clues at multiple loca-
tions that must be followed in order to arrive at the
final cache point. Some activities involve puzzles that
must be solved in order to determine the coordinates
and location of the final cache.
Before long, Wayne wanted to make his own
caches and post them for people to find. He discovered
that there were several Web sites, including individuals’
blogs, with geocaching information, caches, and mem-
berships. He joined one of the geocaching Web sites and
used it to log his finds. It was fun to log and publish his
finds and to post the geocaches that he created. But he
decided he would like his own little system for keeping
track of all the information he wanted to maintain
about his caches. Conveniently, Wayne’s older brother
Nick, a college student majoring in information sys-
tems, was looking for a semester project for one of
his programming classes. The two of them decided to
work together and develop a system to help Wayne
keep track of all his geocaching activities.
In this end-of-chapter case, you will go through
the various core processes of an SDLC and perform
some of the activities of a development project. Of
course, this is a very small project with very limited
requirements. The project and various assignments
are divided into days, as was our Tradeshow project.
You have not learned all the skills required to effec-
tively produce all the documents illustrated in the
chapter. Hence, the daily assignments for this case
should be considered as preliminary efforts and
rough drafts. The objective of these assignments is sim-
ply to help you remember the overall approach to soft-
ware development. Several assignments have been
listed for each day to allow your instructor to select
those that best meet the objectives of the course.
Day 0: Define the Vision
The primary purpose of pre-project activities is to
define a vision for the new system. Either by yourself
or with another class member, brainstorm all the neat
functions this geocaching system might do. Keep it at a
very high level. You just want to think of the major
functions that Wayne might want the system to do
for him. These activities closely relate to Core Process
1: Identify the problem or need and obtain approval to
proceed.
Assignment D0-1: Write a rough draft of the System Vision
Document based on your brainstorming ideas. [Hint: Think of
what Wayne wants the system to do and why this is a benefit
to him.]
Day 1: Plan the Project
Obviously, this is a small project and does not require
an elaborate project plan. Based on the scope and vision
you described in the System Vision Document, divide
the project into at least two separate subsystems or
(continued on page 30)
CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 29

sets of functions that can be done in two different itera-
tions. For example, perhaps a first version can run on a
laptop, with a second version that includes mobile com-
ponents for a smartphone. Or perhaps the first version
can maintain a history of past geocache hunts, and the
second version can allow Wayne to record geocaches
that he creates. Or the first version can create a simple
database system, and the second version can enhance it
by linking to photo albums and/or blog posts. As you
can see, there are often many different ways that a proj-
ect can be partitioned. These activities are related to
Core Process 2: Plan and monitor the project—what
to do, how to do it, and who does it.
Assignment D1-1: Divide the system into at least two separate
components or subsystems, which can be supported with two
iterations. Briefly describe each.
Assignment D1-2: Create a Work Breakdown Structure that lists
all the steps to complete the first iteration. Put a time estimate on
each step. [Hint: Use the one in this chapter as a model.]
Day 2: Define and Understand the
Requirements
We often describe the activities on Day 2 and Day 3
with the word understanding. On Day 2, we want to
get an overall view of what the system needs to do for
Wayne. As you learned in this chapter, there are two
primary areas we focus on to obtain this high-level
understanding of the system: a list of use cases and a
list of object classes. We could document this informa-
tion in lists, but diagrams provide a visual representa-
tion that is often easier to remember and understand.
These activities support Core Process 3: Discover and
understand the details of the problem or the need.
Assignment D2-1: Identify a few use cases that apply to one
subsystem. [Hint: Think of what Wayne plans to do with the
system. He will use the system to “do what”?]
Assignment D2-2: Try to identify the classes that apply to the
first project iteration. [Hint: Think of “information things” that
Wayne wants the system to “remember.”]
Assignment D2-3: Create a simple use case diagram from the
list of use cases. [Hint: Drawing by hand is fine. Use the one in
this chapter as a model.]
Assignment D2-4: Create a simple class diagram from the list
of classes. [Hint: Drawing by hand is fine. Use the one in this
chapter as a model. Think of some other pieces of information
that apply to each class.]
Day 3: Define the User Experience
These activities are a continuation of what we began in
Day 2. The objective here is to further understand
what Wayne will need and how he will actually use
the system. We will determine exactly how each use
case works—what steps and options are available
with the use case and even what the display and data
entry screens will look like. Unfortunately, this often
requires a lot of work. For this case, though, let us
keep it simple. These activities primarily support
Core Process 3: Discover and understand the details
of the problem or the need.
Assignment D3-1: Select a single use case and then identify
the individual steps required to perform the use case. [Hint:
Think of what Wayne does and how the system responds.]
Assignment D3-2: Make a workflow diagram of the selected
use case. [Hint: Drawing by hand is fine. Each step from D3-1
goes in an oval. Connect the ovals with arrows.]
Assignment D3-3: Sketch out one of the screens that will be
required to support a use case. The screen should allow for data
entry and display of information. [Hint: Don’t make it elaborate.
Focus only on the input and output data fields that apply to only
one use case.]
Day 4: Develop the Architectural Design
The high-level architectural design of the system gener-
ally includes decisions about how the system will be
built and what the database will look like. Design is
a technical activity that requires experience in pro-
gramming, database development, and system archi-
tecture. These activities support Core Process 4:
Design the system components that solve the problem
or satisfy the need.
Assignment D4-1: Design a preliminary database schema for
the classes in this iteration. [Hint: Each class becomes a table.
The attributes become table columns.]
Assignment D4-2: Decide whether you will build a desktop
system or a browser-based system. Write a couple of para-
graphs listing the pros and cons of each alternative in order to
defend your decision. [Hint: Either option is valid. Think of rea-
sons to support your decision.]
Day 5: Develop the Detailed Design and
Program the System
You have learned how to do these activities in your pro-
gramming classes. You probably have had many class
projects where you designed a system and then
(continued from page 29)
(continued on page 31)
30 PART 1 ■ An Introduction to Systems Development

programmed it. These kind of activities support Core
Process 5: Build, test, and integrate system components.
Assignment D5-1: Write a paragraph describing what program-
ming language(s) you would recommend and what development
environment you prefer. For this answer, draw on your previous
programming and development experiences. [Hint: There are
many valid solutions. Give reasons for your preference.]
Day 6: Test and Deploy the System
You may have had opportunities to perform compre-
hensive testing of your programming class projects,
especially if you have developed systems that inte-
grated with other systems. These activities support
Core Process 6: Complete system tests and then deploy
the solution. Obviously, you can only do this if you
have programmed the system.
Assignment D6-1: Write a paragraph describing the difference
between programmer testing and user testing. [Hint: Why is it
hard to test your own work? What do the users know that you
don’t know?]
Assignment D6-2: Write a paragraph describing all the issues
that might need to be addressed to deploy this system. [Hint:
You might want to search the Internet to learn about deploy-
ment issues.]
Assignment D6-3: Look at www.geocaching.com, which is a
commercial Web site. What other issues need to be addressed
to deploy this type of Web site? [Hint: Think about all the issues
related to security, robustness, financial protection, high
volumes, up-time, different browsers, and so forth.]
(continued from page 30)
CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 31

www.geocaching.com

This page intentionally left blank

PART 2
Systems Analysis Activities
Chapter 2
Investigating System
Requirements
Chapter 3
Use Cases
Chapter 4
Domain Modeling
Chapter 5
Extending the Requirements
Models
Optional Online Chapter B
The Traditional Approach
to Requirements
33

This page intentionally left blank

2
Investigating System
Requirements
Chapter Outline
■ The RMO Consolidated Sales and Marketing System Project
■ Systems Analysis Activities
■ What Are Requirements?
■ Models and Modeling
■ Stakeholders
■ Information-Gathering Techniques
■ Documenting Workflows with Activity Diagrams
Learning Objectives
After reading this chapter, you should be able to:
■ Describe the activities of systems analysis
■ Explain the difference between functional and nonfunctional requirements
■ Describe the role of models in systems analysis
■ Identify and understand different kinds of stakeholders and their contributions
to requirements definition
■ Describe information-gathering techniques and determine when each is best
applied
■ Develop activity diagrams to model workflows
35

OPENING CASE
Mountain Vista Motorcycles
Amanda Lamy, president and majority stockholder of
Mountain Vista Motorcycles (MVM), is an avid motorcycle
enthusiast and businesswoman. MVM is headquartered in
Denver and has locations throughout the western United
States and Canada. Since the late-1990s, the market for
motorcycles has grown tremendously. Amanda expects
that the market will continue to be strong throughout the
2010s, although she is concerned about the “graying” of a
significant portion of MVM’s customer base.
The demographics of the motorcycle market are an
interesting study in contrasts. At present, the majority of
customers are over 50 years of age, male professionals or
businesspeople, and partly or fully retired. They have sub-
stantial disposable income, lots of free time, and tend to
own multiple expensive motorcycles from such manufac-
turers as Harley-Davidson, Honda, Ducati, and Moto Guzi.
Older customers are generally comfortable with Internet
and Web technology but are not significant users of social
media technology. Although many own smartphones, they
tend to use them primarily for voice, e-mail, and texting.
Male customers under 30 years of age tend to buy
sport and dirt bikes, typically from such manufacturers as
Suzuki and Kawasaki. They buy less expensive bikes than
older customers and are more likely to buy parts and sup-
plies from MVM to service their own bikes. Female custo-
mers under 30 years of age tend to buy motor scooters
and smaller “commuter” motorcycles. Customers in the
30–50 age range include men and women who buy bikes
of many types from many manufacturers. Comfort with
and use of Internet technology, social media, and portable
computing devices such as smartphones and iPads is very
high with customers under 50 years of age, especially with
customers under age 30.
Amanda is convinced that the key to long-term suc-
cess in the motorcycle market is to build an active commu-
nity of motorcycle enthusiasts at each MVM location that
includes a broad spectrum of customers. In essence, each
location needs to be seen as a hub of local motorcycle-
related activity and information in physical and virtual
terms. On the physical side, MVM has added activity and
event-oriented pages to its Web sites, sponsored rallies
and clubs, added meeting rooms and small coffee shops
in some locations, and colocated with bars and restaurants
that feature motorcycle-related themes and entertainment.
These efforts have yielded good results with older custo-
mers but less so with younger customers.
Amanda is concerned about the lack of participation by
younger customers and is sure that MVM’s lack of pres-
ence in social media and virtual relationships is a signifi-
cant factor. She and her senior staff, most of whom are
older, are unsure how to attract younger customers. They
have little knowledge of and no experience creating mod-
ern technology-based virtual communities.
MVM’s chief information officer is starting to develop
a project plan for a virtual community oriented toward
younger customers. If the plan were for developing a tradi-
tional information system, she would use such standard
approaches as interviewing internal users and managers
and having her development staff write specifications,
generate storyboards and screen layouts, and develop pro-
totypes. But few of the intended virtual community users
are MVM employees, and none of her staff members fully
comprehends how to successfully use social media and
other techniques for building virtual societies. Traditional
methods of defining and refining requirements seem inad-
equate to the task.
Overview
In Chapter 1, you saw the System Development Life Cycle (SDLC) being
employed by Ridgeline Mountain Outfitters (RMO) for a small information
system application called the Tradeshow System. Development of that system
followed the six core processes of the SDLC:
1. Identify the problem or need and obtain approval to proceed.
2. Plan and monitor the project—what to do, how to do it, and who does it.
3. Discover and understand the details of the problem or the need.
4. Design the system components that solve the problem or satisfy the need.
5. Build, test, and integrate system components.
6. Complete system tests and then deploy the solution.
In this chapter, we start expanding the scope and detail of the SDLC pro-
cesses to cover a wider range of concepts, tools, and techniques. The extra
depth and detail are needed to tackle larger and more complex projects. This
chapter concentrates on systems analysis activities (the third core process listed),
and the next few chapters follow up on that with detailed discussions of models
36 PART 2 ■ Systems Analysis Activities

developed during those systems analysis activities. Subsequent chapters expand
the discussion of other core SDLC processes.
The RMO Consolidated Sales
and Marketing System Project
Ridgeline Mountain Outfitters has an elaborate set of information systems
applications developed over the years to support operations and management.
However, there is a growing gap between customer expectations, modern tech-
nological capabilities, and existing RMO systems that support sales and cus-
tomer interaction. This section reviews the existing system inventory and
introduces the proposed Consolidated Sales and Marketing System that will
update and enhance sales and marketing.
Existing RMO Information Systems and Architecture
RMO’s Information Systems Department has always been forward looking. In
past years, the department, in conjunction with corporate strategic plans, has
developed five-year plans for development and deployment of new technology
and information systems. The planning process has been an excellent tool to
help the organization stay current with new trends and technology capabilities.
However, the plans themselves have had mixed success. One of the complexities
with long-range IT and software development plans is that technology changes
rapidly and moves in unexpected directions. For example, the Tradeshow
System described in Chapter 1 was made possible by the availability of powerful
and flexible handheld devices and the widespread availability of Wi-Fi and
Internet connections. Both technologies reached a fairly mature level in just a
couple of years, which created an opportunity for RMO to optimize this impor-
tant business process.
Historically, RMO has adopted new technology as soon as it became cost-
effective. Past examples include adoption of smaller servers and desktop comput-
ing, interconnection of locations with dedicated telecommunications links, and
such Web-based technologies as customer-oriented Web sites and browser-based
user interfaces for internal systems. At present, RMO has a disparate collection
of computers dispersed across home offices, retail stores, telephone centers, order
fulfillment/shipping centers, and warehouses—everything connected by a complex
set of local area networks (LANs), wide area networks (WANs), and virtual pri-
vate networks (VPNs). The term technology architecture describes the set of
computing hardware, network hardware and topology, and system software—
such as operating and database management systems—employed by an organiza-
tion. RMO’s technology architecture is modern but not state of the art, which is
consistent with its goal of adopting only cost-effective technology.
The term application architecture describes how software resources are
organized and constructed to implement an organization’s information systems.
It describes the organization of software into modules and subsystems and
includes supporting technologies (such as programming languages and develop-
ment environments), architectural approaches (such as service-oriented architec-
ture), and user-interface technologies (such as mobile computing displays, touch
screen technology, and voice recognition).
Currently, the major RMO systems consist of:
■ Supply Chain Management (SCM)—This application was deployed five
years ago as a client/server application using Java and Oracle. Currently, it
supports inventory control, purchasing, and distribution, although integra-
tion of functions needs improvement. The new Tradeshow System will
interface with this system.
■ Phone/Mail Order System—A modest client/server application developed
12 years ago by using Visual Studio and Microsoft SQL Server as a quick
technology architecture a set of
computing hardware, network hardware and
topology, and system software employed by
an organization
application architecture the organiza-
tion and construction of software resources to
implement an organization’s information
systems
CHAPTER 2 ■ Investigating System Requirements 37

solution to customer demand for catalog phone and mail orders. It is
integrated with the SCM and has reached capacity.
■ Retail Store System (RSS)—A retail store package with point-of-sale proces-
sing. It was upgraded eight years ago from overnight batch to real-time
inventory updates to/from the SCM.
■ Customer Support System (CSS)—This system was first deployed 15 years ago
as a Web-based catalog to support customer mail and phone orders. Four
years later, it was upgraded to an Internet storefront, supporting customer
inquiries, shopping cart, order tracking, shipping, back orders, and returns.
All organizations—including RMO—face a difficult challenge keeping all
their information systems current and effective. Because development resources
are limited, an organization’s technology and application architecture and its
information system inventory will include a mix of old and new. Older systems
were often designed for outdated operational methods and typically lack mod-
ern technologies and features that some competitors have adopted to improve
efficiency or competitiveness. Such is the case with RMO’s existing customer-
facing systems, which have several shortcomings, including:
■ Treating phone, Web, and retail sales as separate systems rather than as
an integrated whole
■ Employing outdated Web-based storefront technology
■ Not supporting modern technologies and customer interaction modes,
including mobile computing devices and social networking
Rather than incrementally update the existing sales systems, RMO plans to
replace them, as shown in Figure 2-1.
FIGURE 2-1 Proposed application architecture for RMO
Supply Chain Management (SCM) Consolidated Sales and Marketing System (CSMS)
Suppliers
Customers
Buyers
Retail Stores
Retail Sales
Phone Sales
CustomersTrade Show System (TSS)
Warehouses
Shipments
Orders
Shipments
Orders
Shipments
Online Sales
38 PART 2 ■ Systems Analysis Activities

The New Consolidated Sales and Marketing System
The goals of the Consolidated Sales and Marketing System (CSMS) are to modern-
ize the technology and functionality of the CSS and to add more customer-oriented
functionality. On the technology side, the CSMS will incorporate current Web
standards and be built under the assumption of high-bandwidth customer Internet
connections and high-resolution displays. Updating the technology will enable a
higher degree of interactivity, richer graphics, and a streamlined interface.
Key additions to system functionality will be support for mobile computing
devices, incorporation of customer feedback and comments into product informa-
tion, and integration of social networking functions. Unlike the CSS, the CSMS
will support smartphones and tablet computers with interfaces specifically designed
for each platform and with downloadable apps. Customer feedback will be
captured directly through the Internet storefront, from RMO-supported comment
forums and blogs, and mined from Facebook and Twitter. RMO will develop a
complete presence in each social networking venue and enable system users to
share purchases, recommendations, coupons, and store credits using those venues.
The new CSMS will also have four subsystems:
■ The Sales subsystem provides such basic functions as searching the online
catalog and purchasing items and paying for them online. However, it has
many new capabilities to assist the shopper making purchases. The system
will provide specific suggestions about accessories that go with the pur-
chased item. Images and videos of animated models will be available to help
the customer see how various items and accessory packages will look
together. The system will also provide information to shoppers about
related purchases made by other shoppers. Customer ratings and comments
are available for viewing. Finally, key social networking components will
permit shoppers to network with their friends by sending messages to ask
their opinions about particular merchandise items.
■ The Order Fulfillment subsystem will perform all the normal tasks of ship-
ping items and allowing customers to track the status of their orders as well
as the shipments. In addition, as part of order fulfillment, customers can rate
and make comments about particular merchandise and their overall shopping
experience. They may also make suggestions directly to RMO about the
attractiveness of the Web site and the quality of the service they received.
■ The Customer Account subsystem provides all those services that enhance the
customer experience. Customers can view and maintain their account informa-
tion. They also can “link up” with friends who are also customers to share
experiences and opinions on merchandise. The system will keep track of
detailed shipping addresses as well as payment preferences and information.
RMO also instituted a Mountain Bucks program wherein customers accumu-
late credits that can be used to redeem prizes as well as purchase merchandise.
Customers may use these Mountain Bucks for themselves or they may transfer
them to other people in their family/friends group. This is a great opportunity
to combine accumulated bucks to obtain expensive merchandise.
■ The Marketing subsystem is primarily for employees to set up the informa-
tion and services for customers. In this subsystem, employees can enter
information about all the merchandise offered by RMO. This subsystem is
also fed by the SCM system to maintain accurate data on the inventory in
stock and anticipated arrival dates of items on order. Employees also set up
the various promotional packages and seasonal catalogs by using the func-
tions of this subsystem. RMO is experimenting with a new idea to enhance
customer satisfaction: It is building partner relationships with other retailers
so that customers can earn “combined” points with RMO purchases or a
partner retailer purchase. These points can be used at RMO or transferred
and used at the partner. For example, because RMO sells outdoor and
sporting clothing, it has partnered with various sporting goods stores.
CHAPTER 2 ■ Investigating System Requirements 39

That way, a person can buy sporting equipment at the sporting equipment
store and get promotional discounts for clothing at RMO. The success of
this new venture has yet to be proven, but RMO anticipates that it will
enhance the shopping experience of all its customers.
In later chapters, more details will be given about the capabilities of the new
CSMS system. Detailed explanations will also describe the information that
must be maintained in the database to support these functions.
Systems Analysis Activities
The callout on the left side of Figure 2-2 lists the activities of the third core
process, which is to discover and understand the details. This core process also
goes by the name systems analysis. By completing these activities, the analyst
defines in great detail what the information system needs to accomplish to pro-
vide the organization with the desired benefits. In essence, analysis activities are a
second and more thorough pass at defining the problem and need. The first pass
generates only enough detail to decide whether a new or upgraded system is war-
ranted and feasible. The second (analysis) pass assumes that the organization is
committed to the project. Thus, considerably more time and resources are
invested to produce a much more detailed description of what the system will do.
Although we concentrate only on analysis activities in this chapter, keep in
mind that they are usually intermixed with design, implementation, and other activ-
ities during the system development life cycle. For example, as shown in Figure 2-2,
analysis activities are most intensive in the second iteration but occur in varying
degrees during all project iterations except the last. This pattern is typical because
an analyst will often concentrate on one part of a system, defining requirements
only for that part and simultaneously designing and implementing software to sat-
isfy those requirements. Organizing development activities in this iterative manner
enables development to be broken into smaller steps and enables users to validate
requirements by testing and observing a functional system. The following sections
briefly describe analysis activities, and the remainder of this chapter expands the
discussion of information gathering and defining system requirements.
Gather Detailed Information
Systems analysts obtain information from people who will be using the system,
either by interviewing them or by watching them work. They obtain additional
information by reviewing planning documents and policy statements. Analysts
also study existing systems, including their documentation. They also frequently
obtain additional information by looking at what other companies (particularly
vendors) have done when faced with a similar business need. They try to
FIGURE 2-2 Analysis activities
Analysis activities
Gather detailed information
Define requirements
Prioritize requirements
Develop user-interface dialogs
Evaluate requirements with users
Core
Processes
1 2 3 4 5 6
Identify problem and obtain
approval
Plan and monitor the project
Discover and understand details
Design system components
Build, test, and integrate system
components
Complete system tests and deploy
solution
Iterations
40 PART 2 ■ Systems Analysis Activities

understand an existing system by identifying and understanding the activities of
all the current and future users and by identifying all the present and future loca-
tions where work occurs and all the system interfaces with other systems, both
inside and outside the organization. In short, analysts need to talk to nearly every-
one who will use the new system or has used similar systems, and they must read
nearly everything available about the existing system. Later in this chapter, we
discuss how to identify and extract information from all these people.
Beginning analysts often underestimate how much there is to learn about the
work the user performs. The analyst must become an expert in the business area
the system will support. For example, if you are implementing an order-entry
system, you need to become an expert on the way orders are processed (including
related accounting procedures). If you are implementing a loan-processing
system, you need to become an expert on the rules used for approving credit. If
you work for a bank, you need to think of yourself as a banker. The most
successful analysts become experts in their organization’s main business.
Define Requirements
The analyst uses information gathered from users and documents to define
requirements for the new system. System requirements include the functions the
system must perform (functional requirements) and such related issues as user-
interface formats and requirements for reliability, performance, and security
(nonfunctional requirements). We further discuss the distinction between func-
tional and nonfunctional requirements a bit later in this chapter.
Defining requirements is not just a matter of writing down facts and figures.
Instead, the analyst creates models to record requirements, reviews the models
with users and others, and refines and expands the models to reflect new or
updated information. Building and refining requirements models occupies much
of the analyst’s time. This chapter and the next two chapters explain in consid-
erable depth how to create requirements models.
Prioritize Requirements
Once the system requirements are well understood, it is important to establish
which requirements are most crucial for the system. Sometimes, users suggest
additional system functions that are desirable but not essential. However, users
and analysts need to ask themselves which functions are truly important and
which are fairly important but not absolutely required. Again, an analyst who
understands the organization and the work done by the users will have more
insight toward answering these questions.
Why prioritize the functions requested by the users? Resources are always
limited, and the analyst must always be prepared to justify the scope of the system.
Therefore, it is important to know what is absolutely required. Unless the analyst
carefully evaluates priorities, system requirements tend to expand as users make
more suggestions (a phenomenon called scope creep). Requirements priorities also
help to determine the number, composition, and ordering of project iterations.
High-priority requirements are often incorporated into early project iterations so
analysts and users have ample opportunity to refine those parts of the system. Also,
a project with many high-priority requirements will typically have many iterations.
Develop User-Interface Dialogs
When a new system is replacing an old system that does similar work, users are usu-
ally quite sure about their requirements and the desired form of the user interface.
But many system development projects break new ground by automating functions
that were previously performed manually or by implementing functions that were
not performed in the past. In either case, users tend to be uncertain about many
aspects of system requirements. Such requirements models as use cases, activity dia-
grams, and interaction diagrams can be developed based on user input, but it is
often difficult for users to interpret and validate such abstract models.
CHAPTER 2 ■ Investigating System Requirements 41

In comparison, user validation of an interface is much simpler and more reli-
able because the user can see and feel the system. To most users, the user interface
is all that matters. Thus, developing user-interface dialogs is a powerful method of
eliciting and documenting requirements. Analysts can develop user interfaces via
abstract models, such as storyboards (covered in more detail in Chapter 7), or
they can develop user-interface prototypes on the actual input/output devices that
users will use (e.g., a computer monitor, iPad, or cell phone). A prototype interface
can serve as a requirement and a starting point for developing a portion of the sys-
tem. In other words, a user-interface prototype developed in an early iteration can
be expanded in later iterations to become a fully functioning part of the system.
Evaluate Requirements with Users
Ideally, the activities of evaluating requirements with users and documenting the
requirements are fully integrated. But in practice, users generally have other responsi-
bilities besides developing a new system. Thus, analysts usually use an iterative
process in which they elicit user input, work alone to model requirements, return to
the user for additional input or validation, and then work alone to incorporate the
new input and refine the models. Prototypes of user interfaces and other parts of the
system may also be developed when “paper” models are inadequate or when users
and analysts need to prove that chosen technologies will do what they are supposed
to do. Also, if the system will include new or innovative technology, the users may
need help visualizing the possibilities available from the new technology when defin-
ing what they require. Prototypes can fill that need. The processes of eliciting require-
ments, building models and prototypes, and evaluating them with users may repeat
many times until requirements models and prototypes are complete and accurate.
What Are Requirements?
As you can see from the previous section, requirements and models that repre-
sent them are a key focus of analysis phase activities. Most of the analyst’s time
is devoted to requirements: gathering information about them, formalizing them
by using models and prototypes, refining and expanding them, prioritizing
them, and generating and evaluating alternatives. But to fully understand those
activities, you need to answer a fundamental question: What are requirements?
System requirements are all the activities the new system must perform
or support and the constraints that the new system must meet. Generally, ana-
lysts divide system requirements into two categories: functional and nonfunc-
tional requirements. Functional requirements are the activities that the system
must perform (i.e., the business uses to which the system will be applied). For
example, if you are developing a payroll system, the required business uses
might include such functions as “generate electronic fund transfers,” “calculate
commission amounts,” “calculate payroll taxes,” “maintain employee-dependent
information,” and “report tax deductions to the IRS.” The new system must
handle all these functions. Identifying and describing all these business uses
require a substantial amount of time and effort because the list of functions and
their relationships can be very complex.
Functional requirements are based on the procedures and rules that the
organization uses to run its business. Sometimes, they are well documented and
easy to identify and describe. An example might be the following: “All new
employees must fill out a W-4 form to enter information about their tax with-
holding in the payroll system.” Other business rules might be more obtuse or
difficult to find. An example from RMO might be the following: “Air shipping
charges are reduced by 50 percent for orders over $200 that weigh less than
two pounds.” Discovering such rules is critical to the final design of the system.
If this rule were not discovered, customers that had relied on it in the past might
become angry. Modifying the system after customers start complaining would
be much more difficult and expensive than building in the rule from the start.
system requirements the activities a
system must perform or support and the
constraints that the system must meet
functional requirements the activities
that the system must perform
42 PART 2 ■ Systems Analysis Activities

Nonfunctional requirements are characteristics of the system other than
those activities it must perform or support. It is not always easy to distinguish
functional from nonfunctional requirements. One way to do so is to use a
framework for identifying and classifying requirements. There have been many
such frameworks developed over time; the most widely used today is called
FURPS+ (see Figure 2-3). FURPS is an acronym that stands for functionality,
usability, reliability, performance, and security. The “F” in FURPS is equivalent
to the functional requirements defined previously. The remaining FURPS catego-
ries describe nonfunctional requirements:
■ Usability requirements describe operational characteristics related to
users, such as the user interface, related work procedures, online help, and
documentation. For example, the user interface for a smartphone app
should behave similarly to other apps when responding to such gestures as
two-finger slides, pinching, and expanding. Additional requirements might
include menu format, color schemes, use of the organization’s logo, and
multingual support.
■ Reliability requirements describe the dependability of a system—how
often a system exhibits such behaviors as service outages and incorrect
processing and how it detects and recovers from those problems.
■ Performance requirements describe operational characteristics related to
measures of workload, such as throughput and response time. For example,
the client portion of a system might be required to have a one-half-second
response time to all button presses, and the server might need to support
100 simultaneous client sessions (with the same response time).
■ Security requirements describe how access to the application will be
controlled and how data will be protected during storage and transmission.
For example, the application might be password protected, encrypt locally
stored data with 1024-bit keys, and use secure HTTP for communication
among client and server nodes.
FURPS+ is an extension of FURPS that adds additional categories, includ-
ing design constraints as well as implementation, interface, physical, and sup-
portability requirements—all these additional categories summarized by the plus
sign. Here are short descriptions of each category:
■ Design constraints describe restrictions to which the hardware and soft-
ware must adhere. For example, a cell phone application might be required
to use the Android operating system, consume no more than 30MB of flash
memory storage, consume no more than 10MB of system memory while
running, and operate on CPUs rated at 1 GHz or higher.
User interface, ease of use
Failure rate, recovery methods
Response time, throughput
Access controls, encryption
Hardware and support software
Development tools, protocols
Data interchange formats
Size, weight, power consumption
Installation and updates
Functional
Requirement
categories
FURPS +
categories
Nonfunctional Usability
Reliability
Performance
Security
+ Design constraints
Implementation
Interface
Physical
Support
Functions Business rules and processes
Example
requirements
FIGURE 2-3
FURPS+
nonfunctional requirements system
characteristics other than the activities it must
perform or support
FURPS a requirements classification
framework (acronym stands for functionality,
usability, reliability, performance, and security)
usability requirements operational
characteristics related to users, such as the
user interface, related work procedures, online
help, and documentation
reliability requirements requirements
that describe system dependability
performance requirements opera-
tional characteristics related to measures
of workload, such as throughput and
response time
security requirements requirements
that describe how access to the application will
be controlled and how data will be protected
during storage and transmission
FURPS+ an extension of FURPS that
includes design constraints as well as
implementation, interface, physical, and
supportability requirements
design constraints restrictions to which
the hardware and software must adhere
CHAPTER 2 ■ Investigating System Requirements 43

■ Implementation requirements describe constraints such as required
programming languages and tools, documentation method and level
of detail, and a specific communication protocol for distributed
components.
■ Interface requirements describe interactions among systems. For
example, a financial reporting system for a publicly traded company
in the United States must generate data for the Securities and Exchange
Commission (SEC) in a specific XML format. The system might also
supply data directly to stock exchanges and bond rating agencies and
automatically generate Twitter messages, RSS feeds, and Facebook
updates.
■ Physical requirements describe such characteristics of hardware as size,
weight, power consumption, and operating conditions. For example, a sys-
tem that supports battlefield communications might have such requirements
as weighing less than 200 grams, being no larger than 5 centimeters cubed,
and operating for 48 hours on a fully charged 1200 milliwatt lithium ion
battery.
■ Supportability requirements describe how a system is installed, config-
ured, monitored, and updated. For example, requirements for a game
installed on a home PC might include automatic configuration to maximize
performance on existing hardware, error reporting, and download of
updates from a support server.
As with any set of requirements categories, FURPS+ has some gray areas
and some overlaps among its categories. For example, is a requirement that a
battlefield communications device survive immersion in water and operate
across a temperature range of –20°C to 50°C a performance or physical require-
ment? Is a restriction to use no more than 100 MB of memory a performance
or design requirement? Is a requirement to secure communication between
workstations and servers with 1024-bit encryption a performance, design, or
implementation requirement? The answers to such questions are not important.
What is important is that all requirements be identified and precisely stated
early in the development process and that inconsistencies or trade-offs among
them be resolved.
Models and Modeling
Modeling is an important part of analysis and design. Analysts build models to
describe system requirements and use those models to communicate with users
and designers. By developing a model and reviewing it with a user, an analyst
demonstrates an understanding of the user’s requirements. If the user spots
errors or omissions, they are incorporated into the model before it becomes the
basis for subsequent design and implementation activities. Figure 2-4 summarizes
the key reasons for building and using models.
Designers construct high-level and detailed models to describe system com-
ponents and their interactions. Design models serve as a scratch pad for evaluat-
ing design alternatives and as a way to communicate the final design to
programmers, vendors, and others who will build, acquire, and assemble com-
ponents to create the final system. In general, models built during one SDLC
activity are “consumed” during other activities.
A model is a representation of some aspect of the system being built. There
are dozens of different models that an analyst or designer might develop and use
(see Figure 2-5). Although this book emphasizes models and techniques for
creating models, it is important to remember that system projects vary in the
number of models required and in their formality. Smaller, simpler system
projects will not need models showing every system detail, particularly when
implementation requirements
constraints such as required programming
languages and tools, documentation method
and level of detail, and a specific communica-
tion protocol for distributed components
interface requirements required
interactions among systems
physical requirements characteristics
of hardware such as size, weight, power con-
sumption, and operating conditions
supportability requirements how a
system is installed, configured, monitored, and
updated
model representation of some aspect
of a system
44 PART 2 ■ Systems Analysis Activities

the project team has experience with the type of system being built. Sometimes,
the key models are created informally in a few hours. Although models are
often created by using specialized software tools, useful and important models
are sometimes drawn quickly over lunch on a paper napkin or in an airport
waiting room on the back of an envelope! As with any development activity, an
iterative approach is used for creating models. The first draft of a model has
some but not all details worked out. The next iteration might fill in more details
or correct previous misconceptions.
Analysis and design models can be grouped into three generic types:
■ Textual models—Analysts use such textual models as memos, reports,
narratives, and lists to describe requirements that are detailed and are diffi-
cult to represent in other ways. The event list in Figure 2-5 is one example
of a textual model. Narrative description is often the best way to initially
record information gathered verbally from stakeholders, such as during an
interview. In many cases, narratives and other textual models are later con-
verted into a graphical format.
1 buy new car
2 sell car
3 get car serviced
4 make payment
5 trade in car
Event list Use case
description
Use case
diagram
Sequence
diagram
Communication
diagram
State machine
diagram
Class diagram
Location
diagram
FIGURE 2-5
Some analysis and design models
Learning from the modeling process
Reducing complexity by abstraction
Remembering all the details
Communicating with other development team members
Communicating with a variety of users and stakeholders
Documenting what was done for future maintenance/enhancement
FIGURE 2-4
Reasons for modeling
textual models text-based system mod-
els such as memos, reports, narratives, and lists
CHAPTER 2 ■ Investigating System Requirements 45

■ Graphical models—Graphical models make it easier to understand com-
plex relationships that are difficult to follow when described as a list or
narrative. Recall the old saying that a picture is worth a thousand words.
In system development, a carefully constructed graphical model might be
worth a million words! Some graphical models actually look similar to a
real-world part of the system, such as a screen design or a report layout
design. However, the graphical models developed during analysis activities
typically represent more abstract things, such as external agents, processes,
data, objects, messages, and connections.
■ Mathematical models—Mathematical models are one or more formulas
that describe technical aspects of a system. Analysts often use mathematical
models to represent functional requirements for scientific and engineering
applications and occasionally use them to describe business system require-
ments in areas such as accounting and inventory control. Analysts and
designers use mathematical models to describe requirements and operational
parameters such as network throughput or database query response time.
Many graphical models used in system development are drawn according to the
notation specified by the Unified Modeling Language (UML). In Figure 2-5, the
use case diagram, class diagram, sequence diagram, communication diagram, and
state machine diagram are UML graphical models. UML is the standard set of
model constructs and notations defined by the Object Management Group (OMG),
a standards organization for system development. By using UML, analysts and end
users are able to depict and understand a variety of specific diagrams used in a
system development project. Prior to UML, there was no standard, so diagrams
could be confusing, and they varied from company to company (and from book
to book).
We expand the discussion of models later in this chapter with a detailed
look at one type of graphical model: the workflow diagram. In later chapters,
you learn how to develop many of other types of analysis and design models.
Stakeholders
Stakeholders are your primary source of information for system requirements.
Stakeholders are all the people who have an interest in the successful imple-
mentation of the system. Depending on the nature and scope of the system, this
can be a small or a large, diverse group. For example, when implementing a
comprehensive accounting system for a publicly traded corporation in the
United States, the stakeholders include bookkeepers, accountants, managers and
executives, customers, suppliers, auditors, investors, the SEC, and the Internal
Revenue Service (IRS). Each stakeholder group interacts with the system in dif-
ferent ways, and each has a unique perspective on system requirements. Before
gathering detailed information, the analyst identifies every type of stakeholder
who has an interest in the new system and ensures that critical people from
each stakeholder category are available to serve as the business experts.
One useful way to help identify all the interested stakeholders is to con-
sider two characteristics by which they vary: internal stakeholders versus exter-
nal stakeholders and operational stakeholders versus executive stakeholders
(see Figure 2-6). Internal stakeholders are those within the organization who
interact with the system or have a significant interest in its operation or suc-
cess. You may be tempted to define internal stakeholders as employees of an
organization, but some organizations—such as nonprofits and educational
institutions—have internal users (e.g., volunteers and students) who are not
employees. External stakeholders are those outside the organization’s control
and influence, although this distinction can also be fuzzy, such as when an
organization’s strategic partners (e.g., suppliers and shipping companies) inter-
act directly with internal systems.
graphical models system models that
use pictures and other graphical elements
mathematical models system models
that describes requirements numerically or as
mathematical expressions
Unified Modeling Language (UML)
standard set of model constructs and notations
defined by the Object Management Group
stakeholders persons who have an
interest in the successful implementation
of the system
internal stakeholders persons within
the organization who interact with the system
or have a significant interest in its operation or
success
external stakeholders persons outside
the organization’s control and influence who
interact with the system or have a significant
interest in its operation or success
46 PART 2 ■ Systems Analysis Activities

Operational stakeholders are those who regularly interact with a system in
the course of their jobs or lives. Examples include bookkeepers interacting with
an accounting or billing system, factory workers interacting with a production
scheduling system, customers interacting with an Internet storefront, and patients
who interact with a health care Web site, Facebook page, or Twitter newsfeed.
Operational users are a key source of requirements information, especially as it
pertains to user interfaces and related functionality. Executive stakeholders
are those who do not interact directly with the system but who either use infor-
mation produced by the system or have a significant financial or other interest in
its operation and success. Examples include an organization’s senior managers
and board of directors, regulatory agencies, and taxing authorities.
Including such stakeholders in analysis activities is critical because the
requirements information they possess may not be obvious or widely known in
the organization. In addition, system requirements imposed by executive stake-
holders, especially external ones, often have significant legal and financial impli-
cations. For example, consider the potential effects of IRS regulations on an
accounting system or the effects of federal and state privacy laws on a social
networking system.
Two other stakeholder groups that do not neatly fall into the categories just
described deserve special attention. The client is the person or group that pro-
vides the funding for the project. In many cases, the client is senior management.
However, clients may also be a separate group, such as a corporation’s board of
directors, executives in a parent company, or the board of regents of a university.
The project team includes the client in its list of important stakeholders because
the team must provide periodic status reviews to the client throughout develop-
ment. The client or a direct representative on a steering or oversight committee
also usually approves stages of the project and releases funds.
An organization’s technical and support staff are also stakeholders in any
system. The technical staff includes people who establish and maintain the com-
puting environment of the organization. Support staff provide user training,
troubleshooting, and related services. Both groups should provide guidance in
such areas as programming language, computer platforms, network interfaces,
and existing systems and their support issues. Any new system must fit within
an organization’s existing technology architecture, application architecture, and
support environment. Thus, technical and support representatives are important
stakeholders.
Regulators
Partner organizations
Bookkeepers
Operational Executive
Accountants
Internal auditors
Internal
External
Customers
Investors
Board of directors
Senior managers
External
auditors
Operational
managers
FIGURE 2-6
Stakeholders of a comprehensive
accounting system for a publicly traded
company
operational stakeholders persons
who regularly interact with a system in the
course of their jobs or lives
executive stakeholders persons who
don’t interact directly with the system but who
either use information produced by the system
or have a significant financial or other interest
in its operation and success
client person or group that provides the
funding for a system development project
CHAPTER 2 ■ Investigating System Requirements 47

The Stakeholders for RMO
As a starting point for identifying CSMS stakeholders, it is helpful to develop a
list of CSS stakeholders, which include:
■ Phone/mail sales order clerks
■ Warehouse and shipping personnel
■ Marketing personnel who maintain online catalog information
■ Marketing, sales, accounting, and financial managers
■ Senior executives
■ Customers
■ External shippers (e.g., UPS and FedEx)
Because the CSMS will take over existing functions of the CSS, the list of
CSMS stakeholders includes all the stakeholders in the CSS list. However, there
are some subtle differences. For example, the inclusion of social networking
functions in the CSMS and the planned ability to share Mountain Bucks
expands the concept of who is a customer. While the old CSS was intended for
use by potential customers visiting the Web site, the new system potentially
interacts with a much larger group of external stakeholders, including friends
and family of existing customers and potentially all users of popular social net-
working sites. In essence, the stakeholder group “Customers” is much larger,
more diverse, and includes people who have not purchased from RMO.
Ensuring that the viewpoints and requirements of this diverse group are repre-
sented during analysis activities will be a considerable challenge.
Expanded functionality for sales promotions with partner organizations
creates an entirely new group of external stakeholders within those partner
organizations. At this point, it is unclear whether that group will include oper-
ational stakeholders, executive stakeholders, or both and exactly how those
stakeholders will interact with the system. Once again, ensuring adequate
input from those stakeholders will be a significant challenge, especially because
the portions of the system used by those stakeholders will not be based on an
existing system.
RMO is a privately held company; John and Liz Blankens are the owners,
and they hold two senior management positions. This is significant because the
key operational systems of any publicly traded company “inherit” many exter-
nal stakeholders due to the flow of information from those systems to the orga-
nization’s financial reports. RMO is audited by an external accounting firm,
primarily to ensure access to bank loans and other private financing.
As owners and senior managers, John and Liz are the primary clients,
but so are other senior executives who form a collaborative decision-making
body. In addition, existing technical and support staff are key stakeholders.
Figure 2-7 summarizes the internal managerial stakeholders in the form of
an organization chart.
Information-Gathering Techniques
Techniques for gathering detailed requirements information include:
■ Interviewing users and other stakeholders
■ Distributing and collecting questionnaires
■ Reviewing inputs, outputs, and documentation
■ Observing and documenting business procedures
■ Researching vendor solutions
■ Collecting active user comments and suggestions
All these methods have proven to be effective, although some are more efficient
than others. In most cases, analysts combine methods to increase their effectiveness
and efficiency and to provide a comprehensive fact-finding approach.
48 PART 2 ■ Systems Analysis Activities

Interview Users and Other Stakeholders
Interviewing users and other stakeholders is an effective way to understand busi-
ness functions and business rules. Unfortunately, it is also the most time-
consuming and resource-expensive option. In this method, systems analysts:
■ Prepare detailed questions.
■ Meet with individuals or groups of users.
■ Obtain and discuss answers to the questions.
■ Document the answers.
■ Follow up as needed in future meetings or interviews.
Obviously, this process may take some time, so it usually requires multiple
sessions with each of the users or user groups.
Jason Nadold
Manager
Warehousing/Shipping
John Blankens
President CEO
William Mcdougal
VP Marketing
and Sales
Genny Monson
AVP Retail
Sales
Brian Haddock
Director of
Operations
Karen Hansen
Director of
New Design
Henry Manwaring
Director of U.S.
Purchasing
Nathan Brunner
AVP
Production
Maryann Whitehead
Director of International
Purchasing
Elizabeth Blankens
VP Merchandising
and Distribution
Joann White
VP Finance and
Systems
April Sterling
AVP Accounting
and Finance
Joe Jones
AVP
Marketing/Advertising
Robert Schneider
Director of
Catalog Sales
Christine Roundy
Manager of Telephone
Sales
Mac Preston
Chief Information
Officer
John Macmurty
Director of System
Development
Ann Hamilton
Director of System
Support
FIGURE 2-7
RMO management stakeholders
involved in the CSS requirements
definition
CHAPTER 2 ■ Investigating System Requirements 49

Question Themes
Whether in informal meetings, formal interviews, or as part of a questionnaire
or survey, analysts ask questions. But which questions should analysts ask?
Figure 2-8 shows three major themes that guide the analysts when they are ask-
ing questions to define system requirements; it also shows sample questions that
arise from those themes.
What Are the Business Processes? The analyst must obtain a comprehensive list of
all the business processes. In most cases, the users provide answers in terms of the
current system, so the analyst must carefully discern which of those functions are
fundamental (i.e., which will remain and which may possibly be eliminated with an
improved system). For example, sales clerks might indicate that the first task they
perform when a customer places an order is to check the customer’s credit history.
In the new system, sales clerks might never need to perform that function; the system
might perform the check automatically. The function remains a system requirement,
but the method of carrying out the function and its timing are changed.
How Are the Business Processes Performed? Again, the focus starts with the
current system but gradually moves to the new system. The goal is to determine
how the new system should support the function rather than how it supports it
now. The analyst must be able to help the user visualize new and more efficient
approaches to performing the business processes made possible by new technology
or processes.
What Information Is Required? Some information inputs are formal; others are
informal. When questioning the user, the analyst should specifically ask about
exceptions or unusual situations in order to identify additional (nonroutine) infor-
mation requirements. In this theme and the previous one, detail is the watchword.
An analyst must understand the nitty-gritty detail to develop a correct solution.
Question Types
Questions can be roughly divided into two types:
■ Open-ended questions—questions such as “How do you do this function?”
that encourage discussion and explanation
■ Closed-ended questions—questions such as “How many forms a day do
you process?” that are used to get specific facts
Generally, open-ended questions help to start a discussion and enable a
large number of requirements to be uncovered fairly quickly. Note that all the
questions in the previous section are open ended. A discussion that starts with
open-ended questions usually shifts gradually to closed-ended questions that
elicit or confirm specific details of a business process.
Focus of Questions—Current System or New?
A significant question that faces all analysts is how much effort to expend
studying and documenting the existing system (if one exists). Excess attention to
Theme Questions to users
What are the business operations and processes? What do you do?
What information is needed to perform those
operations?
How should those operations be performed? How do you do it?
What steps do you follow?
How could they be done differently?
What information do you use?
What inputs do you use?
What outputs do you produce?
FIGURE 2-8
Themes for information-gathering
questions
open-ended questions questions that
encourage discussion or explanation
closed-ended questions questions
that elicit specific facts
50 PART 2 ■ Systems Analysis Activities

an existing system can consume considerable time and can result in simply
updating that system with newer technology. As a result, no matter how ineffi-
cient the current system is, system developers simply reimplement the procedures
that are already in place. On the other hand, if a new system inherits many or
all of the requirements of an existing system, then an analyst risks missing
important requirements through insufficient study of the existing system.
To minimize both risks, analysts must balance the review of current busi-
ness functions with discovery of new system requirements. It is still critical to
have a complete correct set of system requirements, but in today’s fast-paced
world, there is no time or money to review all the old systems and document
all the inefficient procedures. In fact, in today’s development environment, one
of the most valuable capabilities that a good system developer can bring is a
new perspective to the problem.
Interview Preparation, Conduct, and Follow-Up
Figure 2-9 is a sample checklist that summarizes the major points to be covered;
it is useful in preparing for, conducting, and following up an interview.
Preparing for the Interview Every successful interview requires preparation. The
first and most important step in preparing for an interview is to establish its
objective. In other words, what do you want to accomplish with this interview?
Write down the objective so it is firmly established in your mind. The second
step is to determine which stakeholders should be involved in the interview. A
small number of interviewees is generally best when the objective is narrow or
of a fact-finding nature. Larger groups are better if the objective is more open
ended, such as when generating and evaluating new ideas. However, it can be
difficult to manage a large group meeting to ensure high-quality input from all
participants. If possible, have at least two analysts involved in every interview,
and have them compare notes afterward to ensure accuracy.
The next step is to prepare detailed questions to be used in the interview.
Write down a list of specific questions, and prepare notes based on the forms
or reports received earlier. Usually, you should prepare a list of questions that
are consistent with the objective of the interview. Open-ended questions and
closed-ended questions are appropriate. Generally, open-ended questions help
Establish the objective for the interview.
Determine correct user(s) to be involved.
Determine project team members to participate.
Build a list of questions and issues to be discussed.
Review related documents and materials.
Set the time and location.
Inform all participants of objective, time, and locations.
Checklist for Conducting an Interview
Before
During
Review notes for accuracy, completeness, and understanding.
Transfer information to appropriate models and documents.
Identify areas needing further clarification.
Thank the participants.
Follow up on open and unanswered questions.
Arrive on time.
Look for exception and error conditions.
Probe for details.
Take thorough notes.
Identify and document unanswered items or open questions.
After
FIGURE 2-9
Sample checklist to prepare for user
interviews
CHAPTER 2 ■ Investigating System Requirements 51

get the discussion started and encourage the user to explain all the details of the
business process and the rules.
The last step is to make the final interview arrangements and then communi-
cate those arrangements to all participants. A specific time and location should be
established. If possible, a quiet location should be chosen, to avoid interruptions.
Each participant should know the objective of the meeting and, when appropri-
ate, should have a chance to preview the questions or materials to be used.
Interviews consume a substantial amount of time, and they can be made more
efficient if each participant knows beforehand what is to be accomplished.
Conducting the Interview The usual rules of workplace meetings apply during
stakeholder interviews: plan ahead, arrive early, and ensure that the room is
prepared and that needed resources are available. Limit the time of the interview
for the benefit of the analyst(s) and stakeholder(s); stakeholders have other
responsibilities, and the analysts can absorb only so much information at one
time. It is better to have several shorter interviews than one long interview. A
series of interviews provides an opportunity to absorb the material and then go
back to get clarification later.
Look for exception and error conditions. Look for opportunities to ask
“what if” questions. “What if it doesn’t arrive? What if the signature is missing?
What if the balance is incorrect? What if two orders are exactly the same?” The
essence of good systems analysis is understanding all the “what ifs.” Make a
conscious effort to identify all the exception conditions and then ask about
them. More than any other skill, the ability to think of the exceptions will help
you discover the detailed business rules. It is a hard skill to teach from a text-
book; experience will hone this skill. You will teach yourself this skill by consci-
entiously practicing it.
Probe for details. In addition to looking for exception conditions, the ana-
lyst must probe to ensure a complete understanding of all procedures and rules.
One of the most difficult skills to learn as a new systems analyst is how to get
enough details. Frequently, it is easy to get a general overview of how a process
works. But do not be afraid to ask detailed questions until you thoroughly
understand how the process works and what information is used. You cannot
do effective systems analysis by glossing over the details.
Take careful notes. It is a good idea to take handwritten notes. Usually,
tape recorders make users nervous. However, taking notes signals that you
think the information you are obtaining is important, and the user is compli-
mented. If two analysts conduct each interview, they can compare notes later.
Identify and document in your notes any unanswered questions or outstanding
issues that were not resolved. A good set of notes provides the basis for building
the analysis models as well as establishing a basis for the next interview session.
Figure 2-10 is a sample agenda for an interview session. Obviously, you do
not need to conform exactly to a particular agenda. However, as with the inter-
view checklist shown in Figure 2-9, this figure will help prod your memory on
issues and items that should be discussed in an interview. Make a copy and use
it. As you develop your own style, you can modify the checklist to the way you
like to work.
Following Up the Interview Follow-up is an important part of each interview.
The first task is to absorb, understand, and document the information that was
obtained. Generally, analysts document the details of the interview by construct-
ing models of the business processes and writing textual descriptions of non-
functional requirements. These tasks should be completed as soon after the
interview as possible and the results distributed to the interview participants for
validation. If the modeling methods are complex or unfamiliar to the users, the
analyst should schedule follow-up meetings to explain and verify the models, as
described in the last section of this chapter.
52 PART 2 ■ Systems Analysis Activities

During the interview, you probably asked some “what if” questions that the
users could not answer. They are usually policy questions raised by the new sys-
tem that management has not considered before. It is extremely important that
these questions not get lost or forgotten. Figure 2-11 shows a sample table for
tracking outstanding or unresolved issues for RMO. The table includes ques-
tions posed by users or analysts and responsibilities assigned for resolving the
issues. If several teams are working, a combined list can be maintained. Other
columns that might be added to the list are an explanation of the problem’s res-
olution and the date resolved.
FIGURE 2-11 Sample open-items list
ID Issue title Date identified
Target
end date
Responsible
project person
User contact Comments
1 Partial
shipments
6-12-2012 7-15-2012 Jim Williams Jason Nadold Ship partials or wait
for full shipment?
2 Returns and
commissions
7-01-2012 9-01-2012 Jim Williams William
McDougal
Are commissions
recouped on
returns?
3 Extra
commissions
7-01-2012 8-01-2012 Mary Ellen Green William
McDougal
How to handle com-
missions on special
promotions?
Discussion and Interview Agenda
Setting
Objective of Interview
Determine processing rules for sales commission rates
Date,Time, and Location
April 21, 2012, at 9:00 a.m. in William McDougal’s office
User Participants (names and titles/positions)
William McDougal, vice president of marketing and sales, and
several of his staff
Project Team Participants
Mary Ellen Green and Jim Williams
Interview/Discussion
1. Who is eligible for sales commissions?
2. What is the basis for commissions? What rates are paid?
3. How is commission for returns handled?
4. Are there special incentives? Contests? Programs based on time?
5. Is there a variable scale for commissions? Are there quotas?
6. What are the exceptions?
Follow-Up
Important decisions or answers to questions
See attached write-up on commission policies
Open items not resolved with assignments for solution
See Item numbers 2 and 3 on open items list
Date and time of next meeting or follow-up session
April 28, 2012, at 9:00 a.m.
FIGURE 2-10
Sample interview session agenda with
follow-up information
CHAPTER 2 ■ Investigating System Requirements 53

Finally, make a list of new questions based on areas that need further elabo-
ration or that are missing information. This list will prepare you for the next
interview.
Distribute and Collect Questionnaires
Questionnaires enable analysts to collect information from a large number of
stakeholders. Even if the stakeholders are widely distributed geographically, they
can still help define requirements through questionnaires. Questionnaires are often
used to obtain preliminary insight into stakeholder information needs, which helps
to determine areas that need further research by using other methods.
Figure 2-12 is a sample questionnaire showing three types of questions. The
first part has closed-ended questions to determine quantitative information.
FIGURE 2-12 Sample questionnaire
RMO Questionnaire
This questionnaire is being sent to all telephone-order sales personnel. As you know, RMO is developing a new
customer support system for order taking and customer service.
The purpose of this questionnaire is to obtain preliminary information to assist in defining the requirements for
the new system. Follow-up discussions will be held to permit everybody to elaborate on the system requirements.
Part I. Answer these questions based on a typical four-hour shift.
1. How many phone calls do you receive?_______________________________________________________
2. How many phone calls are necessary to place an order for a product?_______________________________
3. How many phone calls are for information about RMO products, that is, questions only?_________________
4. Estimate how many times during a shift customers request items that are out of stock.__________________
5. Of those out-of-stock requests, what percentage of the time does the customer desire to put the item
on back order?______________%
6. How many times does a customer try to order from an expired catalog?______________________________
7. How many times does a customer cancel an order in the middle of the conversation?___________________
8. How many times does an order get denied due to bad credit?______________________________________
Part II. Circle the appropriate number on the scale from 1 to 7 based on how strongly you
agree or disagree with the statement.
Question Strongly Agree Strongly Disagree
It would help me do my job better to have longer 1 2 3 4 5 6 7
descriptions of products available while talking
to a customer.
It would help me do my job better if I had the 1 2 3 4 5 6 7
past purchase history of the customer available.
I could provide better service to the customer if I 1 2 3 4 5 6 7
had information about accessories that were
appropriate for the items ordered.
The computer response time is slow and causes 1 2 3 4 5 6 7
difficulties in responding to customer requests.
Part III. Please enter your opinions and comments.
Please briefly identify the problems with the current system that you would like to see resolved in a new system.
_________________________________________________________________________________________
_________________________________________________________________________________________
_________________________________________________________________________________________
54 PART 2 ■ Systems Analysis Activities

The second part consists of opinion questions in which respondents are asked
whether they agree or disagree with the statement. Both types of questions are
useful for tabulating and determining quantitative averages. The third part
requests an explanation of a procedure or problem. Questions such as these are
good as a preliminary investigation to help direct further fact-finding activities.
Questionnaires are not well suited to helping you learn about processes, work-
flows, or techniques. Open-ended questions such as “How do you do this process?”
are best answered by using interviews or observation. Although a questionnaire can
contain a very limited number of open-ended questions, stakeholders frequently do
not return questionnaires that contain many open-ended questions.
Review Inputs, Outputs, and Procedures
There are two sources of information about inputs, outputs, and procedures.
One source is external to the organization—industry-wide professional organiza-
tions and other companies. It may not be easy to obtain information from other
companies, but they are a potential source of important information.
Sometimes, industry journals and magazines report the findings of “best prac-
tices” studies. The project team would be negligent in its duties if its members
were not familiar with best practice information.
The second source of inputs, outputs, and procedures is existing business
documents and procedure descriptions within the organization. Reviewing inter-
nal documents and procedures serves two purposes. First, it is a good way to
get a preliminary understanding of the processes. Second, existing inputs, out-
puts, and documents can serve as visual aids for the interview and as the work-
ing documents for discussion (see Figure 2-13). Discussion can focus on a
specific input or output, its objective, its distribution, and its information con-
tent. The discussion should also include specific business events that initiate the
use of an input or generation of an output. Several different business events
FIGURE 2-13 RMO mail-order form used as a visual aid during an interview
Ridgeline Mountain Outfitters—Customer Order Form
Name and address of person placing order.
(Please verify your mailing address and make correction below.)
Order Date
Description
Name
Address Apt. No
City State Zip
Phone: Day ( ) Evening ( )
Item No. Style Color Size
Sleeve
Length Qty Monogram Style
Price
Each Total
Method of Payment
Check/Money Order Gift Certificate(s) AMOUNT ENCLOSED $
Account Number
American Express MasterCard VISA
Signature
Other
Expiration Date
MO YR
Delivery Phone ( )
MERCHANDISE TOTAL
Regular FedEx shipping $4.50 per U.S. delivery address
(Items are sent within 24 hours for delivery in 2 to 4 days)
Please add $4.50 per each additional U.S. delivery address
FedEx Standard Overnight Service
Any additional freight charges
International Shipping (see shipping information on back)
Gift Order or Ship To: (Use only if different from address at left.)
Name
Address Apt. No
City State Zip
Gift Card Message
Gift Address for this Shipment Only Permanent Change of Address
CHAPTER 2 ■ Investigating System Requirements 55

might require the same form, and specific information about the event and the
business process is critical. It is always helpful to have screens and forms that
have been filled out with real information to ensure that the analyst obtains a
correct understanding of the data content.
Reviewing the documentation of existing procedures helps identify business
rules that may not come up in the interviews. Analyzing formal procedure docu-
mentation also helps reveal discrepancies and redundancies in the business pro-
cesses. However, procedure documents frequently are not kept up to date, and
they commonly include errors. To ensure that the assumptions and business
rules that derive from the existing documentation are correct, analysts should
review them with the users.
Observe and Document Business Processes
Firsthand experience is invaluable to understand exactly what occurs within
business processes. More than any other activity, observing a business process
in action will help you understand the business functions. However, while
observing existing processes, you must also be able to visualize the new system’s
associated business processes. That is, as you observe the current business pro-
cesses to understand the fundamental business needs, you should never forget
that the processes could and often should change to be made more efficient. Do
not get locked into believing there is only one way of performing the process.
You can observe a business process in many ways, ranging from a quick
walk-through of an office or plant to doing the work yourself. A quick walk-
through gives a general understanding of the layout of the office, the need for
and use of computer equipment, and the general workflow. Spending several
hours observing users at their jobs helps you understand the details of using the
computer system and carrying out business functions. Being trained as a user
and actually doing the job enables you to discover the difficulties of learning
new procedures, the importance of a system that is easy to use, and the stum-
bling blocks and bottlenecks of existing procedures and information sources.
It is not necessary to observe all processes at the same level of detail. A
quick walk-through may be sufficient for one process, whereas a process that is
critical or more difficult to understand might require an extended observation
period. If you remember that the objective is a complete understanding of the
business processes and rules, you can assess where to spend your time to gain
that understanding. As with interviewing, it is usually better if two analysts
combine their efforts in observing procedures.
Observation often makes the users nervous, so you need to be as unobtru-
sive as possible. You can put users at ease in several ways, such as by working
alongside a user or observing several users at once. Common sense and sensitiv-
ity to the needs and feelings of the users will usually result in a positive
experience.
Research Vendor Solutions
Many of the problems and opportunities that companies want to address with
new information systems have already been solved by other companies. In addi-
tion, consulting firms often have experience with the same problems, and soft-
ware firms may have already packaged solutions for a particular business need.
Taking advantage of existing knowledge or solutions can avoid costly mistakes
and save time and money.
There are three positive contributions and one danger in exploring existing
solutions. First, researching existing solutions will frequently help users generate
new ideas for how to better perform their business functions. Seeing how some-
one else solved a problem and applying that idea to the culture and structure of
the existing organization will often provide viable alternative solutions for busi-
ness needs.
56 PART 2 ■ Systems Analysis Activities

Second, some of these solutions are excellent and state of the art. Without
this research, the development team may create a system that is obsolete even
before it is designed. Companies need solutions that not only solve basic busi-
ness problems but that are up to date with competitive practices.
Third, it is often cheaper and less risky to buy a solution rather than to
build it. If the solution meets the needs of the company and can be purchased,
then that is usually a safer, quicker, and less expensive route.
The danger in exploring existing solutions is that the users and even the sys-
tems analysts may want to buy one of the alternatives immediately. But if a
solution, such as a packaged software system, is purchased too early in the pro-
cess, the company’s needs may not be thoroughly investigated. Too many com-
panies have purchased systems only to find out later that they only support half
the functions that were needed. Do not rush into a purchase decision until
requirements are fully defined and all viable alternatives have been thoroughly
investigated.
Collect Active User Comments and Suggestions
As discussed in Chapter 1 and earlier in this chapter, system development nor-
mally proceeds with analysis, design, and other activities spread across multiple
iterations. Portions of the system are constructed and tested during each itera-
tion. Users and other stakeholders perform the initial testing of system functions
during the iteration in which those functions are implemented. They also test
and use those same functions during later iterations.
User feedback from initial and later testing is a valuable source of require-
ments information. Interviews, discussions, and model reviews are an imperfect
way of eliciting complete and accurate requirements. The phrase “I’ll know it
when I see it” applies well to requirements definition. Users often cannot
completely or accurately state their requirements until they can interact with a
live system that implements those requirements. Based on those interactions,
users can develop concrete suggestions for improvement and identify missing or
poorly implemented requirements.
Documenting Workflows with Activity
Diagrams
As you gather information about business processes, you will need to document
your results. One effective way to capture this information is with diagrams.
Eventually, you may want to use diagrams to describe the workflows of the
new system, but for now, let us focus on how we would document the current
business workflows.
A workflow is the sequence of processing steps that completely handles one
business transaction or customer request. Workflows may be simple or complex.
Complex workflows can be composed of dozens or hundreds of processing steps
and may include participants from different parts of an organization.
An activity diagram describes the various user (or system) activities, the
person who does each activity, and the sequential flow of these activities.
Figure 2-14 shows the basic symbols used in an activity diagram. The ovals
represent the individual activities in a workflow. The connecting arrows repre-
sent the sequence between the activities. The black circles denote the beginning
and the ending of the workflow. The diamond is a decision point at which the
flow of the process will either follow one path or another. The heavy solid line
is a synchronization bar, which either splits the path into multiple concurrent
paths or recombines concurrent paths. The swimlane heading represents an
agent who performs the activities. Because it is common in a workflow to have
different agents (i.e., people) performing different steps of the workflow process,
workflow sequence of processing steps
that completely handles one business transac-
tion or customer request
activity diagram describes user (or sys-
tem) activities, the person who does each
activity, and the sequential flow of these
activities
synchronization bar activity diagram
component that either splits a control path into
multiple concurrent paths or recombines
concurrent paths
swimlane heading activity diagram col-
umn containing all activities for a single agent
or organizational unit
CHAPTER 2 ■ Investigating System Requirements 57

the swimlane symbol divides the workflow activities into groups showing which
agent performs which activity.
Figure 2-15 is an activity diagram that describes the order fulfillment pro-
cess for the current RMO CSMS. Processing begins when the customer has com-
pleted the order checkout process. The diagram describes the back-and-forth
flow of information and control between the Order subsystem, Inventory sub-
system, warehouse(s), and shipper. The diagram is simplified because it omits
many error-handling pathways, including what happens if enough item stock is
on hand to fulfill part of an order.
Figure 2-16 illustrates another workflow diagram, which demonstrates
some new concepts. In this example, a customer is ordering a product that has
to be manufactured specifically to match customer specifications. The salesper-
son sends the order to Engineering, and the diagram uses a new symbol to
emphasize the transmission of the document between Sales and Engineering.
After Engineering develops the specifications, two concurrent activities happen:
Purchasing orders the materials, and Production writes the program for the
automated milling machines. These two activities are completely independent
and can occur at the same time. Notice that one synchronization bar splits the
path into two concurrent paths and that another synchronization bar reconnects
them. Finally, Scheduling puts the order on the production schedule.
Creating activity diagrams to document workflows is straightforward. The
first step is to identify the agents to create the appropriate swimlanes. Next, fol-
low the various steps of the workflow and then make appropriate ovals for the
activities. Connect the activity ovals with arrows to show the workflow. Here
are a couple guidelines:
■ Use a decision symbol to represent an either/or situation—one path or the
other path but not both. As a shorthand notation, you can merge an activ-
ity (by using an oval) and a decision (by using a diamond) into a single oval
with two exit arrows, as indicated on the right in Figure 2-14. This notation
represents a decision (either/or) activity. Wherever you have an activity that
reads “verify” or “check,” you will probably require a decision—one for
the “accept” path and one for the “reject” path.
■ Use synchronization bars for parallel paths—situations in which both paths
are taken. Include a beginning and an ending synchronization bar. You can
also use synchronization bars to represent a loop, such as a “do while” pro-
gramming loop. Put the bar at the beginning of the loop and then describe
it as “for every.” Put another synchronization bar at the end of the loop
with the description “end for every.”
Ending activity
(Pseudo)
Activity
Transition arrow
Starting activity
(Pseudo)
Decision
activity
Another way
to show decision
Synchronization
bar (Split)
Synchronization
bar (Join)
Manager
Review
financials
Prepare
report
[yes][no]
Swimlane
heading
FIGURE 2-14
Activity diagram symbols
58 PART 2 ■ Systems Analysis Activities

FIGURE 2-15 Simple activity diagram for online checkout
Order subsystem
Order Fulfillment
Pick item from
stock
Prepare shipment
Generate tracking
record
Store shipment
record
Transmit shipment Receive shipment
Decrement item
stock count
Update order
status
Transmit
shipping details
Update order
shipment status
Inventory
subsystem
Warehouses
Shipping
company
Find location with
sufficient stock
Stock
found?
For each item in
completed order
No
Yes
End
for each
item
End for each item
Create back
order record
CHAPTER 2 ■ Investigating System Requirements 59

Chapter Summary
There are five primary activities of systems analysis:
■ Gather detailed information.
■ Define requirements.
■ Prioritize requirements.
■ Develop user-interface dialogs.
■ Evaluate requirements with users.
Functional requirements are those that explain the
basic business functions that the new system must sup-
port. Nonfunctional requirements involve the system’s
objectives with regard to technology, performance,
usability, reliability, and security.
Mathematical, descriptive, and graphical models are
developed to document requirements and as an aid in
evaluating requirements with users and other stake-
holders. Stakeholders include internal and external users
of the system and other persons or organizations that
have a vested interest in the system.
Analysts use many techniques to gather information
about requirements, including:
■ Interviews
■ Questionnaires
■ Documentation, input, and output reviews
■ Process observation and documentation
■ Vendor solution research
■ Active comments and suggestions from users
Workflow diagrams are a key modeling technique
often used as an early requirements model. Workflow
diagrams graphically model the steps of a business pro-
cess and the participants who perform them. Other mod-
els and diagrams are covered in later chapters.
FIGURE 2-16 Activity diagram showing concurrent paths
Salesperson Engineering Purchasing Production
Accept
order
Make
specifications
Buy
materials
Program
computer
Schedule
production
Scheduling
Order
60 PART 2 ■ Systems Analysis Activities

Key Terms
activity diagram 57
application architecture 37
client 47
closed-ended questions 50
design constraints 43
executive stakeholders 47
external stakeholders 46
functional requirements 42
FURPS 43
FURPS+ 43
graphical models 46
implementation requirements 44
interface requirements 44
internal stakeholders 46
mathematical models 46
model 44
nonfunctional requirements 43
open-ended questions 50
operational stakeholders 47
performance requirements 43
physical requirements 44
reliability requirements 43
security requirements 43
stakeholders 46
supportability requirements 44
swimlane heading 57
synchronization bar 57
system requirements 42
technology architecture 37
textual models 45
unified modeling
language (UML) 46
usability requirements 43
workflow 57
Review Questions
1. List and briefly describe the five activities of systems
analysis.
2. What are three types of models?
3. What is the difference between functional require-
ments and nonfunctional requirements?
4. Describe the steps in preparing for, conducting, and
following up an interview session.
5. What are the benefits of doing vendor research
during information-gathering activities?
6. What types of stakeholders should you include in
fact finding?
7. Describe the open-items list and then explain why it
is important.
8. List and briefly describe the six information-
gathering techniques.
9. What is the purpose of an activity diagram?
10. Draw and explain the symbols used on an activity
diagram.
Problems and Exercises
1. Provide an example of each of the three types of
models that might apply to designing a car, a house,
and an office building.
2. One of the toughest problems in investigating system
requirements is to make sure they are complete and
comprehensive. How would you ensure that you get
all the right information during an interview session?
3. One of the problems you will encounter during
your investigation is “scope creep” (i.e., user
requests for additional features and functions).
Scope creep happens because users sometimes have
many unsolved problems and the system investiga-
tion may be the first time anybody has listened to
their needs. How do you keep the system from
growing and including new functions that should
not be part of the system?
4. What would you do if you got conflicting answers for
the same procedure from two different people you
interviewed? What would you do if one was a clerical
person and the other was the department manager?
5. You have been assigned to resolve several issues on
the open-items list, and you are having a hard time
getting policy decisions from the user contact. How
can you encourage the user to finalize these policies?
6. In the running case of RMO, assume that you have
set up an interview with the manager of the
CHAPTER 2 ■ Investigating System Requirements 61

shipping department. Your objective is to determine
how shipping works and what the information
requirements for the new system will be. Make a list
of questions—open ended and closed ended—that
you would use. Include any questions or techniques
you would use to ensure you find out about the
exceptions.
7. Develop an activity diagram based on the following
narrative. Note any ambiguities or questions that
you have as you develop the model. If you need to
make assumptions, also note them.
The purchasing department handles purchase
requests from other departments in the company.
People in the company who initiate the original
purchase request are the “customers” of the pur-
chasing department. A case worker within the
purchasing department receives the request and
monitors it until it is ordered and received.
Case workers process requests for the purchase
of products under $1,500, write a purchase order,
and then send it to the approved vendor. Purchase
requests over $1,500 must first be sent out for bid
from the vendor that supplies the product. When
the bids return, the case worker selects one bid and
then writes a purchase order and sends it to the
vendor.
8. Develop an activity diagram based on the following
narrative. Note any ambiguities or questions that
you have as you develop the model. If you need to
make assumptions, also note them.
The shipping department receives all shipments
on outstanding purchase orders. When the clerk in
the shipping department receives a shipment, he or
she finds the outstanding purchase order for those
items. The clerk then sends multiple copies of the
shipment packing slip. One copy goes to
Purchasing, and the department updates its records
to indicate that the purchase order has been ful-
filled. Another copy goes to Accounting so a pay-
ment can be made. A third copy goes to the
requesting in-house customer so he or she can
receive the shipment.
After payment is made, the accounting depart-
ment sends a notification to Purchasing. After the
customer receives and accepts the goods, he or she
sends notification to Purchasing. When Purchasing
receives these other verifications, it closes the pur-
chase order as fulfilled and paid.
9. Conduct a fact-finding interview with someone
involved in a procedure that is used in a business
or organization. This person could be someone at
the university, in a small business in your neigh-
borhood, in the student volunteer office at the
university, in a doctor’s or dentist’s office, or in a
volunteer organization. Identify a process that is
done, such as keeping student records, customer
records, or member records. Make a list of ques-
tions and then conduct the interview. Remember,
your objective is to understand that procedure
thoroughly (i.e., to become an expert on that single
procedure).
10. Using RMO and the CSMS as your guide, develop
a list of all the procedures that may need to be
researched. You may want to think about the
exercise in the context of your experience with
such retailers as L.L. Bean, Lands’ End, or
Amazon.com. Check out the Internet marketing
done on the retailers’ Web sites and then think
about the underlying business procedures that are
required to support those sales activities. List the
procedures and then describe your understanding
of each.
Case Study
John and Jacob, Inc.: Online Trading System
John and Jacob, Inc. is a regional brokerage firm that has
been successful over the last several years. Competition for
customers is intense in this industry. The large national firms
have very deep pockets, with many services to offer clients.
Severe competition also comes from discount and Internet
trading companies. However, John and Jacob has been
able to cultivate a substantial customer base from upper-
middle-income clients in the northeastern United States. To
maintain a competitive edge with its customers, John and
Jacob is in the process of modernizing its online trading sys-
tem. The modernization will add new features to the existing
system and expand the range of interfaces beyond desktop
and laptop computers to include tablet computers and
smartphones. The system will add Twitter messaging in addi-
tion to continued support for traditional e-mail.
Edward Finnigan, the project manager, is in the pro-
cess of identifying all the groups of people who should
be included in the development of the system require-
ments. He is not quite sure exactly who should be
included. Here are the issues he is considering:
■ Users: The trading system will be used by customers
and by staff in each of the company’s 30 trading
offices. Obviously, the brokers who are going to use
the system need to have input, but how should this be
done? Edward also is not sure what approach would be
best to ensure that the requirements are complete yet
not require tremendous amounts of time. Including all
62 PART 2 ■ Systems Analysis Activities

the offices would increase enthusiasm and support for
the system, but it would take a lot of time. Involving
more brokers would bring divergent opinions that
would have to be reconciled.
■ Customers: The trading system will also include trade
order entry, investment analysis reports, trade confir-
mations, standard and customized reporting, and
customer statements. Edward wonders how to
involve John and Jacob customers in the develop-
ment of system requirements. Edward is sensitive to
this issue because many brokers have told him that
many customers are unhappy with the current sys-
tem, and customer complaints are sometimes posted
to the public comments area of the current Web site.
He would like to involve customers, but he does not
know how.
■ Other stakeholders: Edward knows he should involve
other stakeholders to help define system require-
ments. He is not quite sure whom he should contact.
Should he go to senior executives? Should he contact
middle management? Should he include such back-
office functions as accounting and investing? He is
not quite sure how to get organized or how to decide
who should be involved.
Answer the following questions:
1. What is the best method for Edward to involve the
brokers (users) in the development of the updated
online trading system? Should he use a questionnaire?
Should he interview the brokers in each of the com-
pany’s 30 offices or would one or two brokers repre-
senting the entire group be better? How can Edward
ensure that the information about requirements is
complete yet not lose too much time doing so?
2. Concerning customer input for the new system, how
can Edward involve customers in the process? How
can he interest them in participating? What methods
can Edward use to ensure that the customers he
involves are representative of John and Jacob’s entire
customer group?
3. As Edward considers what other stakeholders he should
include, what are some criteria he should use? Develop
some guidelines to help him build a list of people to
include.
RUNNING CASES
Community Board of Realtors
The real estate business relies on an extensive amount of
information used in the buying and selling of real prop-
erty. Most communities of real estate agents and brokers
have formed cooperative organizations to help consoli-
date and distribute information on the real estate profes-
sion, real estate trends, properties in the community,
historical records of property sales, and current listings
of properties for sale. These organizations are usually
referred to as the Community Board of Realtors.
Research your local Community Board of Realtors
to answer these questions:
1. Who are the stakeholders for the issues related to
real estate in your community, and what are their
main interests?
2. What types of information does the board collect
and make available to its members and to the
community?
3. Research the real estate industry in at least two
countries other than the United States. For each of
these countries, what are some of the cultural and
legal issues that differ from those in the United
States? If you were working on support for an
international real estate cooperative system, in
what ways would the information collection
activity process be complicated?
The Spring Breaks ‘R’ Us Travel Service
Spring Breaks ‘R’ Us (SBRU) is an online travel
service that books spring break trips to resorts for
college students. Students have booked spring break
trips for decades, but changes in technology have
transformed the travel business in recent years.
SBRU moved away from having campus reps with
posted fliers and moved to the Web early on. The
basic idea is to get a group of students to book a
room at a resort for one of the traditional spring
break weeks. SBRU contracts with dozens of resorts
(continued on page 64)
CHAPTER 2 ■ Investigating System Requirements 63

in key spring break destinations in Florida, Texas, the
Caribbean, and Mexico. Its Web site shows informa-
tion on each resort and includes prices, available
rooms, and special features. Students can research
and book a room, enter contract information, and
pay deposits and final payments through the system.
SBRU provides updated booking information, resort
information updates, and travel information for
booked students when they log in to the site.
The resorts also need access to information from
SBRU. They need to know about their bookings for
each week, the room types that are booked, and so
forth. Before the spring break booking season starts,
they need to enter information on their resorts, includ-
ing prices and special features. Resorts need to be paid
by SBRU for the bookings, and they need to be able to
report and collect for damages caused by spring-
breakers during their stay.
SBRU has recently decided to upgrade its system
to provide social networking features for students. It
is currently researching possibilities and collecting
information from prospective customers about desir-
able features and functions. From the business stand-
point, the idea is to increase bookings by enhancing
the experience before, during, and after the trip.
1. Who are the stakeholders for SBRU? For each type
of stakeholder, what aspects of the SBRU booking
system are of particular interest?
2. What are the main functional requirements for the
major subsystem areas (i.e., resort relations, stu-
dent booking, accounting and finance, and social
networking)?
3. Describe some usability requirements for students,
booking interactions, and social networking
interactions.
4. Assuming that social networking at the resorts will
require wireless communication and connection to
the Internet, what are some reliability requirements
that resorts might be asked to maintain? What are
some performance requirements? Is this a bigger
issue because resorts are in international locations?
5. What are some security requirements? Is there any
reason why students in Europe, Asia, or other
locations could not book rooms through SBRU?
What issues might be anticipated?
6. To collect information on functional requirements
for the social networking subsystem, what are
some techniques that might be used? Be specific
and include some sample questions you might ask
by using various techniques.
On the Spot Courier Services
As an employee of a large international courier and
shipping service, Bill Wiley met almost every day with
many companies that shipped and received packages.
He was frequently asked if his company could deliver
local packages on the same day. Over several months,
he observed that there appeared to be a substantial need
for courier services in the city in which he lived. He
decided that he would form his own courier delivery
company called On the Spot to fill this need.
Bill began by listing his mobile telephone number
in the Yellow Pages. He also sent letters to all those
companies that had requested same-day courier service
that his prior company had not been able to serve. He
hoped that, through good service and word-of-mouth
advertising, his business would grow. He also began
other advertising and marketing activities to promote
his services.
At first, Bill received delivery requests on his busi-
ness mobile phone. However, it was not long before
his customers were asking if he had a Web site where
they could place orders for shipments. He knew that if
he could get a Web presence he could increase his
exposure and help his business grow.
After he had been in business only a few short
months, Bill discovered he needed to have additional
help. He hired another person to help with the delivery
and pickup of packages. It was good to see the business
grow, but another person added to the complexity of
coordinating pickups and deliveries. With the addition
of a new person, he could no longer “warehouse” the
packages out of his delivery van. He now needed a cen-
tral warehouse where he could organize and distribute
packages for delivery. He thought that if his business
grew enough to add one more delivery person he
would also need someone at the warehouse to coordi-
nate the arrival and distribution of all the packages.
1. Who are the stakeholders for On the Spot? How
involved should On the Spot’s customers be in
system definition? As the business grows, who else
might be potential stakeholders and interested in
system functions?
2. If you were commissioned to build a system for
Bill, how would you determine the requirements?
Be specific in your answer. Make a list of the
questions you need answered.
(continued from page 63)
(continued on page 65)
64 PART 2 ■ Systems Analysis Activities

3. What technology and communication requirements
do you see? What are the hardware requirements, and
what kind of equipment will provide viable options to
the system? What would you recommend to Bill?
4. What are the primary functional requirements for
the system as described so far in the case?
Sandia Medical Devices
Medical monitoring technology has advanced signifi-
cantly in the last decade. Monitoring that once
required a visit to a health-care facility can now be
performed by devices located in a patient’s home or
carried or worn at all times. Examples include glucose
level (blood sugar), pulse, blood pressure, and electro-
cardiogram (EKG). Measurements can be transmitted
via telephone, Internet connection, and wireless data
transmission standards, such as Bluetooth. A particu-
larly powerful technology combination is a wearable
device that records data periodically or continuously
and transmits it via Bluetooth to a cell phone app.
The cell phone app can inform the patient of problems
and can automatically transmit data and alerts to a
central monitoring application (see Figure 2-17).
Health-care providers and patients incur signifi-
cant costs when glucose levels are not maintained
within acceptable tolerances. Short-term episodes of
very high or very low glucose often result in expensive
visits to urgent care clinics or hospitals. In addition,
patients with frequent but less severe episodes of high
or low glucose are more susceptible to such expensive
long-term complications as vision, circulatory, and
kidney problems.
Sandia Medical Devices (SMD), an Albuquerque
manufacturer of portable and wearable medical moni-
toring devices, has developed a glucose monitor
embedded in a wristband. The device is powered by
body heat and senses glucose levels from minute quan-
tities of perspiration. SMD is developing the Real-Time
Glucose Monitoring (RTGM) device in partnership
with New Mexico Health Systems (NMHS), a compre-
hensive health delivery service with patients through-
out New Mexico, The system’s vision statement reads
as follows:
RTGM will enable patients and their healthcare
providers to continuously monitor glucose levels,
immediately identify short- and long-term medical
dangers, and rapidly respond to those dangers in
medically appropriate ways.
SMD will develop the initial prototype software
for smartphones with Bluetooth capability running
the Google Android operating system. If successful,
(continued from page 64)
FIGURE 2-17 Data movement among devices and users
Cell phone app
routes date and
interacts with
patient for alerts
and monitoring
Wristband continuously
measures glucose level
Data sent to/from
server via
wireless Internet
Server archives
data and
generates alerts
Medical personnel
monitor levels/trends
and plan response
Communication with
patient via voice
or text messages
Data transmitted
to cell phone
via Bluetooth
(continued on page 66)
CHAPTER 2 ■ Investigating System Requirements 65

NMHS and its patients will have free use of the soft-
ware and SMD will resell the software to other health
systems worldwide.
1. Who are RTGM’s stakeholders? Should NMHS’s
patients be included in defining the system
requirements? Why or why not? Should RTGM
interact with medical professionals other than
physicians? Why or why not?
2. If you were the lead analyst for RTGM, how would
you determine the requirements? Be specific in your
answer. List several questions you need answered.
3. What are the primary functional requirements for
the system as described so far in the case?
4. Are the parameters for alerting patients and medi-
cal personnel the same for every patient? Can they
vary over time for the same patient? What are the
implications for the system’s functional
requirements?
5. Briefly describe some possible nonfunctional
requirements for RTGM.
Further Resources
Soren Lauesen, Software Requirements: Styles
and Techniques. Addison-Wesley, 2002.
Stan Magee, Guide to Software Engineering
Standards and Specifications. Artech House,
1997.
Suzanne Robertson and James Robertson,
Mastering the Requirements Process, Second
Edition. Addison-Wesley, 2006.
Karl Wiegers, Software Requirements. Microsoft
Press, 2003.
Karl Wiegers, More About Software Requirements:
Thorny Issues and Practical Advice. Microsoft
Press, 2006.
Ralph Young, The Requirements Engineering
Handbook. Artech House, 2003.
(continued from page 65)
66 PART 2 ■ Systems Analysis Activities

3
Use Cases
Chapter Outline
■ Use Cases and User Goals
■ Use Cases and Event Decomposition
■ Use Cases and CRUD
■ Use Cases in the Ridgeline Mountain Outfitters Case
■ User Case Diagrams
Learning Objectives
After reading this chapter, you should be able to:
■ Explain why identifying use cases is the key to defining functional requirements
■ Describe the two techniques for identifying use cases
■ Apply the user goal technique to identify use cases
■ Apply the event decomposition technique to identify use cases
■ Apply the CRUD technique to validate and refine the list of use cases
■ Describe the notation and purpose for the use case diagram
■ Draw use case diagrams by actor and by subsystem
67

OPENING CASE
Waiters on Call Meal-Delivery System
Waiters on Call is a restaurant meal-delivery service
started in 2008 by Sue and Tom Bickford. The Bickfords
worked for restaurants while in college and always
dreamed of opening their own restaurant. Unfortunately,
the initial investment was always out of reach. The
Bickfords noticed that many restaurants offer takeout
food and that some restaurants—primarily pizzerias—offer
home-delivery service. However, many people they met
seemed to want home delivery with a wider food
selection.
Sue and Tom conceived Waiters on Call as the best
of both worlds: a restaurant service without the high
initial investment. They contracted with a variety of
well-known restaurants in town to accept orders from
customers and to deliver the complete meals. After pre-
paring the meal to order, the restaurant charges Waiters
on Call a wholesale price, and the customer pays retail
plus a service charge and tip. Waiters on Call started
modestly, with only two restaurants and one delivery
driver working the dinner shift. Business rapidly
expanded, and the Bickfords realized they needed a
custom computer system to support their operations.
They hired a consultant, Sam Wells, to help them define
what sort of system they needed.
“What sort of events happen when you are running
your business that make you want to reach for a
computer?” asked Sam. “Tell me about what usually
goes on.”
“Well,” answered Sue, “when a customer calls in
wanting to order, I need to record it and get the informa-
tion to the right restaurant. I need to know which driver to
ask to pick up the order, so I need drivers to call in and tell
me when they are free. Perhaps this could be included as
a smartphone or iPad app. Sometimes, customers call
back wanting to change their orders, so I need to get my
hands on the original order and notify the restaurant to
make the change.”
“Okay, how do you handle the money?” queried
Sam.
Tom jumped in. “The drivers get a copy of the bill directly
from the restaurant when they pick up the meal. The bill
should agree with our calculations. The drivers collect that
amount plus a service charge. When drivers report in at
closing, we add up the money they have and compare it
with the records we have. After all drivers report in, we
need to create a deposit slip for the bank for the day’s total
receipts. At the end of each week, we calculate what we owe
each restaurant at the agreed-to wholesale price and send
each a statement and check.”
“What other information do you need to get from the
system?” continued Sam.
“It would be great to have some information at the
end of each week about orders by restaurant and orders
by area of town—things like that,” Sue said. “That would
help us decide about advertising and contracts with restau-
rants. Then, we need monthly statements for our
accountant.”
Sam made some notes and sketched some diagrams
as Sue and Tom talked. Then, after spending some time
thinking about it, he summarized the situation for Waiters
on Call. “It sounds to me like you need a system to use
whenever these events occur:
■ A customer calls in to place an order, so you need to
Record an order.
■ A driver is finished with a delivery, so you need to Record
delivery completion.
■ A customer calls back to change an order, so you need
to Update an order.
■ A driver reports for work, so you need to Sign in the
driver.
■ A driver submits the day’s receipts, so you need to
Reconcile driver receipts.
“Then, you need the system to produce information at
specific points in time—for example, when it is time to:
■ Produce an end-of-day deposit slip.
■ Produce end-of-week restaurant payments.
■ Produce weekly sales reports.
■ Produce monthly financial reports.
“Am I on the right track?”
Sue and Tom quickly agreed that Sam was talking
about the system in a way they could understand. They
were confident that they had found the right consultant
for the job.
Overview
Chapter 2 described the systems analysis activities used in system development
and then introduced the many tasks and techniques involved when completing
the first analysis activity—gathering information about the system, its stake-
holders, and its requirements. An extensive amount of information is required
68 PART 2 ■ Systems Analysis Activities