·-
#"" ' -
CENGAGE
': .. CENGAGE
Aus1ral1a • Brazol • Mexico · Singapore · United Kmgdom • Un11ed S1a1es
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
Thi\ i~ an clcctmnic vc,...ion of Lhc print 1cx1book. Due to electronic rights rc,1ricuons,
some third p:u1y conlcnt may be >uppressed. Edilorial review has deemed Lhat any suppressed
content doc> not materially affect the overall learning experience. The publil.her rc>crve~ the right
10 remove contem from thi• title at any time if sub11Cquent rights restriction• require it. For
valuable information on pricing. previou• editions. change• Lo current edilinn<. and al1ema1c
formats. please visit www.ccnu~<: com/bj~hen:d to search by ISBNll. author. 1ille. or keyword for
muccrial\ in your areas of interest.
lmponant oticc: Media contcnl referenced \nthin the produce descripuon or the product
text may not be available in the eBook \er..ion.
('.,.,...Jlt... ,..,........., "' . . . ..-..... ""' . . .................. . ......"""'."'"""<"' .,.. Dartn . . . . . . . . . ."'" •.-. . . . . ...., , . . . . ..., ... .,....,....,., ...... . , ,...~--. . ~~~
C.....""_..,...._..,...,.
....,....._.,.,...._•
... ._..,,,.. .. __ ........ _.. ., _.. ... 4 . . . . . . ,__........._• .,._.1111:
.._,. ......,~.n....-..-..ilk...,.~C~ ......_ __..
,: _ CENGAGE
Systems Analysls and Design, Twelfth Edition
Scott Tilley
SVP. Higher Educatton Prodlm Management:
Enn Joyner
VP. Product MaNgement Mike Schenk
Product Otre<tor.1.Auren Murphy
O 2020. 2017 Cengage learning. Inc
Unless otherwise noted, aH content ls Cl Cengage.
WCN: 02·300
ALL RIGHTS RESEl!VEO. No part of this work CO\lt!red by lhe copyright
herein may be reproduced or d1s111buted on any form or by any means.
except as permitted by U.S. copyright law. without the pnor written
pennissi<>n of the copyright owner
Product Team Manager Krosun McNary
Product Manager JaylT'Me Falconi
Product As5'Stant. Anna Goulart
Oire<1or, LHrnong Design Rebecu von Glllern
SenK>r Manager, learning Otsigr• Leigh Hefferon
Learning Designer· Emily Po~
Vice Preslden~ Marketing - Science, Technology,
& Math Jason Sakos
For product informatlOfl and technology asslsta~. contact us a1
Cengage Customer & Sales Support, 1-IOC>-3S4-9706or
support.cengage.com.
L
For permlss!On to use mateflal from this text or product.
submit all requests onlone at www.cengage.com/permlsslons.
Library of Congress Control Number PCN to come
Senior Marketing D1re<1or: Michele McTlghe
ISBN: 978-0-357· 11781-1
Execu1lve Marketing Monoger: Cossle Cloutier
Cengage
20 Channel Center Sueet
Boston, MA02210
USA
Product Speclallst: Mackenzie Paine
Director, Content Creation: Juliet Steiner
Senior Manager, Content Creation: Pauy S1ephan
Cement Manager: Michele Stulgo
Technical Editor: John Freitas
Director, Digital Producllon Services:
Krista Kellman
Digital Delivery Lead· Justin Maniaci
Designer: Uzz Anderson
Proctucuon ~rvlce/Compos.llon. Lum1na
Cengage is a leading provider of customized learning soludons with
employees residing in nearly 40 dlfferem coumrles and sales In more
than 125 countries around the world. Fond your local repre~ntatlve at
www.cengage.com.
Cengage pro<lucts are represented in Canada by Nelson Educallon, l td.
To learn more about Cengage platforms and services. reglste< or access
your on lone leamlng solution. or purchase materials for your course, Visit
www.cengage.com.
O..tamaiocs. Ltd.
Cover unage iStock.com/Nongkran_ch
Notice 10 the Reader
Publisher does not warrant or guarantee any or the produos descnbed herein or perform any Independent analySis in connecttOn Wlth
any of the product Information conta•ned herein. Publisher does not assume. and expressly disclaims. •"'I obliga11on 10 obtain and
Include riformatlon olher than that prOVlded to 11 by the manufacturer. The reader os expressly warned to consider and adopt all saftty
pre<auhons th.it might be •ndiC.lled by the actMties destnbed herein and IO a\IOid all po<enUal hazards By lolowrig the lll>tructions
conta1Md herein. the reader wi hngly assumes all rlsl<s In collllKtlorl With such instructooros. The pubftsher makes no repr~ntations or
warranties of a"J lund, 1nclud1ng but not lim ted 10, the warran11es of fimess fot parucular purpose or mercharGblltlY, nor are arty such
representations Implied with respect to the matenal set forth here•n. and the pubhsher takes no responsibility with re11>Kt to such
ma1erlat. The publisher shall noc be liable for any special consequenual, or exemplary damages resulting. In whole or p;in. from 1he
readers' use of, or rehanot upon. this material
Printed in 1he United S1a1es of America
Print Number: 01
Print Year: 20 19
r...,,,.._ a-oc,,.,..~ .u ._~.a "'' ·~ 11ir ......, ~ -~·-· ......,"'".,.. nw~•..-.. ,..."''"_..,.....,
,.....""..., tir ~,._._~
.,..., -<.....,._~~
__ .....,.__.t__.•.._a..,..
.......... ,......_...
..........
r.....l _ _ .._......,..,_..,.,............_.,.....,..._...,.....,_..,.,,_.,.._..~~a-.e.._..,...,.,,._.
iii
DEDll CATION
To all of my students - past, present, and future
c..., .... .31:8C....,:...._ Al~,,_~,..., •WGfd.~•~• ..... ••,__0.:•*'"-....... -61111,_,,..-_,-.c..........,.._ec ...lllil__.~.t
•......w~~-._....,..,.....,
........ _ ._ _..........,....,. ...
.-;11-...~~c-,,....i.__..~w._.._
........ __ ..,.._.,......,..._..,....._...., ..
~ JIJ»C....... ~ Al RlilfD
~ ... _
l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.: ......,_ . . . ,_.,~-.lit .......... .._.,._.__..,~•\
. . . _ . .... ..., ~...,.._,_..,..., J\&."9 ... --.11 ......... ~ C'dptl"~~d.tt ...... -
............ -
..... -
..........
-.-.....w--...-.11
v
BRIEF CONTENTS
PHASE I: SYSTEMS PLANNING
001
Chapter I Introduction co Systems Analysis and Design
002
Chapter 2 Analyzing the Business Case
044
Chapter 3 Managing Systems Projecrs
074
PHASE 2: SYSTEMS ANALYSIS
103
Chapter 4 Requirements Engineering
104
s Data and Process Modeling
144
Chapter
Chapter 6 Object Modeling
.1 80
Chapter 7 Development Strategies
200
227
PHASE 3: SYSTEMS DESIGN
p
Chapter 8 User Interface Design
228
Chapter 9 Data Design
268
Chapter 10 System Architecture
316
~
10
•
Chapter 11 Managing Systems Implementation
352
PHASE: · S STEMS SUPPORT AND SECURITY
399
Chapter 12 Managing Systems Support and Security
400
Glossary
453
Index
471
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
vi
TABLE OF CONTENTS
PHASE I : SYSTEMS PLANNING
I.9 The Systems Analyst
Introduction to Systems Analysis
and Design
A Question of Ethics
35
1.10 Summary
35
2
Key Terms
37
3
Exercises
42
Learning Objectives
I. I Information Technology
I. I.I The Changing Nature of Information Technology
1. 1.2 Synems Analysis and Design
1.1 .3 What Does a Systems Analyst Doi
1.9.1 Role
1.9.1 Knowledge. SIUlb. and Ecb::auon
l.9J Certification
1.9.4 c..reer Opportunities
1.9.5 Trends"' lnformabon Technology
28
28
29
31
32
33
3
4
"
1.2 Information System s
1.2.1 Hardware
4
5
5
1.2.2 Software
1.2.3 Data
1.2.4 Processes
1.2.S People
6
7
7
Analyzing the Business Case
Learning Objectives
44
2. I Strategic Planning
45
Case In Point I. I. Data B~. che
8
2.1 . 1 Strategic Planning Overview
1.3 Internet Business Strategies
8
Case in Point 2.1; Pets for Rent
45
1.3. 1 The lnttrnet Model
I .J 2 82C (BuS1ncsMo·Consumer)
I .J.3 828 (Business·tO· Buslness)
8
8
2.1.2 SWOT Analysis
2.1 J The Role of the IT Dep1rtmenc
45
46
9
2.1 Strategic PlanningTools
1.4 Modeling Business Ope rations
9
2.l The Business Case
1.5 Busines$ Informa t ion Systems
11
2.4 Systems Requests
2.5 Factors Affecting Syst e m s Projects
1.5 I Enterpriu Computing
l.S.2 Trmuccion Processang
I .SJ Business Support
l.S.4 Knowled&e Mana&e"*"
I .S.5 User Producov1ty
I .S 6 D1giul Assistants
1.5 .7 Systems lnteinuon
II
II
12
13
14
15
15
C..• ~ 1n P. t I 2: Au 1n• '"'° ~ h I •
1.6 Organiu.t ional Information Models
16
1.6 I Functions and Organlzadonal l.eve:s
1.6.2 Top Man~ers
1.6.3 Middle Maniiers •nd Know1ed&• Worker>
1.6.4 Supervisor> and Team Leaders
1.6.5 Operadonal Employees
16
16
17
17
17
5
2.5. 1 lntern>I Factors
2.5.1 Extern>! Factors
45
47
47
49
so
50
52
2.6 Processing Systems Requests
54
2.6.1 Sys<ems P.equen forms
2.6.2 Systems Request Tools
2.63 Systems Review Committee
54
54
54
Case 1n P"'nt 2 1: At '"' y A1r1 " , P.art On~
2.7 Assessing Request Feasibility
2.7. 1 Feuibtlity Studies
2.7.2 Operauon>l FeaS1bthty
2.7.3 Ecooom<e Feasib1l1ty
2.7.4 Teclvlical F<!asibillty
2.7.5 Schedule Feasfblllty
SS
56
56
57
57
58
58
1.7 Syst ems Deve lopment
17
1.7. 1 StructuredAnalysls
1.7.2 Object-Oriented Analysis
1.7.3 Agile Methods
1.7.4 Prototyping
1.7.5 Tools
18
21
22
24
24
2.8 Setting Priorities
2.8.1 Dynamic Priorities
2.8.2 F•«ors That Affect Priority
2.8.3 Discretionary and N ondlscretoonary Projects
S9
Case in Point 2.3: Attaway Airline , Part Two
26
2. 9 The Preliminary Investigation
60
60
1.8 The Information Technology Department
1.8.1 Appllcatlon Development
27
C;ue in Point 1.3 : Global Hotel~ and Momma's Motels 27
1.8.2 Systems Support and Security
1.8.3 User Support
1.8.4 D•toboseAdmlnt>trotJon
1.8.5 Network Adminlstrodon
1.8.6 Web Support
1.8.7 Qu>l1ty Assuranco (QA)
27
28
28
28
28
28
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, ..,...,.......,..~
r..a...w...,..._...., ..
2.9.1 Planning the Preliminary lnvesclgadon
2.9.2 Performing tho Preliminary lnvesdgatlon
2.9.3 Sumtmn•mg the Preliminary lnvestlg-.tion
59
59
60
61
61
68
2. 10 Summary
69
69
Ke:yTerms
70
Exercises
72
A Question of Ethics
Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
.................,.t11ru ..
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
vii
Ta ble o f Contents
111
113
4.2.2 Rapid Apphcadon Development
4.2.3 Agile Methods
4.3 Gathering Requirements
4.4 Gathering Requirements Through Interviews
Managing Systems Projects
Learning Objectives
74
75
3. 1 Overview of P roject Management
7S
7S
3.1 I Whn Sh>peS a Project•
3.1 2 What Isa Project Tnansfe'
3.1.3 What Does a Protect ~nager Do'
76
76
3.2 Creating a W o rk Breakdown Structure
3.2.1 Gontt Clwu
76
n
3.2.2 PERT/CPM Charts
3.2.3 ldent1fyi11g Tasks In a Wori< B<cakdown Structure
Ca•~ in Point l. I .
S onri
78
Sottw;i.n
80
80
3.2.4 Foctors Affecting Dul'O\don
3.2.S Displ;ay111g the Wori< Breakdown Structure
81
3.3 Task Patterns
82
3.3.1 Using Task Boxes to Create a Model
3.3.2 Task Pattem Types
3.3.3 Working with Complex Task Pattems
82
83
8"
Case In Point 3.2: Parallel Services
SS
3.4 The Crltica.I Path
85
114
116
116
4.4.1 The lnterv>ew Process
4.5 Gathering Requirements Using Other
Techniques
12 1
4.5.1 Document Review
4.S.2 Observation
4.5.3 QueJtionnaires ond Su~
4.S.4 Interviews Venus Quescionnaires
4.S.S S...ns«>rmin&
4.5.6 Sampling
4.S 7 Research
122
122
123
124
115
125
126
Case in Point 4.2: CyberStuff
127
4.6 Gathering Re q uirements In Aglle Projects
4.7 Representing Requirements
127
1.7.1 Natural Language
128
128
Case in Point 4.3: Digital Pen Transcription
129
...7.2 Diagrams
1.7.3 Models
129
13 I
85
4.9 Tool.s
Ill
134
3.5 Project Monit oring and Control
87
A Question of Ethics
137
3.S. I Monitori11g and Contra I Techniques
3.S.2 Malntolnin& • Schedule
3.S.3 Tasks and the Critical Poth
87
87
87
4. 10 Summary
Key Te rms
137
1)7
Exercises
88
88
88
Chapter S
3.4.1 Calculacing the Cntlcol Path
J.t Re porting
3.6 I Project Status M..anis
3.6.2 Project Statui Rtporu
3.63 0..long woth Problems
89
93
94
3.7 Project Management Software
3.8 Risk Management
3.9 Managing for Success
C.
P, 1t l
J
1me Software
95
3 9 I Buslnen luues
3.9.2 Budget Issues
3.9.3 Schedule Issues
95
95
96
A Question of Ethics
96
3. 10 Summary
96
Key Te rms
98
Exe r cises
100
PHASE 2 : SYSTEMS ANALYSIS
Chapter 4
104
Learning Objectives
4. 1 Syste m Req uirements
105
4.1.1 Types of Requoremenu
4.1.2 Requlremenu Challenges
4.1.3 Additional Conslderatlons
105
107
4. 2 Team-Based Techniques
108
106
4.2.I )olntAj>pl1ca11on 0..elopment
109
111
Case in Point 4.1: North Hills College
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ..............
__....
139
142
Data and Process Modeling
Leaming Objectives
5 .1 Logical Versus PhysicaJ Models
144
5 .2 Data Flow Diagrams
145
146
145
S.3 Data Flow Diagram Symbols
147
147
149
ISi
152
5 3 I Proun Symbol>
5.3.2 Data Flow Symbols
5.3.3 Data Store Symbols
5.3.4 Enticy Symbols
5.3S Usin& DFD Symbols
5.4 Drawing Data Flow Diagrams
5.5 Drawing a Context Diagram
152
5.6 Drawing a Diagram 0 DFD
155
S.7 Drawing Lower-Level DFDs
158
163
154
Case In Point 5.1 : Big Ten University
5.8 Data Dictionary
Requirements Engineering
.........""_.. ... .-.................
4.8 Validating and Verifying Requirements
164
161
165
166
167
167
167
5.8.1 Documenting the Data Eltmenu
5.8.2 Documentinc the Data Rows
5.8.3 Documenting the Data Stores
5.8.4 Documenting the Processes
5.8.5 Documentm& the En"tles
5.8 6 Documenung the Records
5.8.7 Data Dlcuonary Reporu
168
5.9 Process Description Tools in Modular Design
5.9.1 Procen Descnpcions 1n Obiect·Oriented [)eo.lelopmen1
S.9.2 Modubr Design
--
........... ......
. ,.. o-....._ ...... _ ... ,..,...,...,~..,._.. ........... ... ~..
~~·~----···---~~-.,.-"~
169
169
169
Table of Conte nts
viii
170
170
5.9.J Slt\ICtured En&hsh
5.9.4 Dec1si0n T~es
Case in Point 5 .2 : Rock Solid Outfitters (Part I)
5.9 .S DeclSlO!'I Trees
use in Point 5.3 : Rock Solid Outfitters (Part 2)
A Question of Ethics
5. 10 Summary
Key Terms
Exercises
174
175
175
176
176
177
179
Chapter 6
Case in Point 7 . 1: Doug's Sporting Goods
7 .4 Outsourcing
7.4. I The Growth ol Ouuourc"'I
7.4.2 Outsouran& Fees
7A3 Ouuourong Issues and Concerns
7.5 Offshoring
Case in Point 7.2: Turnkey Services
1.6 Software as a Service
7.7 Selecting a Devefopment Strategy
7.7. I The Systems Analysts Role
7.7.2 Analyzing Cost and Bcnefiu
7.7.3 Cost-Benef1tAnalysls Checkllot
Object Modeling
Learning Objectives
6.1 Object-Oriented Analysis
Case In Point 6. 1: Travel Biz
181
6.2 Objects
181
6.3 Attributes
6.4 Methods
183
183
6. 5 Messages
183
6.6 Classes
6.1 Relationships Among Objects a.n d Classes
6. 8 The Unified Modellng language (UML)
6.8. I Use Cue Mod~1n1
184
180
181
6.8.2 Use Cue Ofagnms
186
187
187
189
Case in Point 7.3: Ster1ingAssoclates
7.8 The Software Acquisition Process
Step I: Evaluate che Information Synem Requirements
Step 2: Identify PotentialVendors or Outsouroing Options
Step 3: Evaluate the Alternatives
Step 4: Perform Cost-Benefit Analysis
Step S: Prepare a Recommendation
7.9 Completion ofSyscemsAnalysisTasks
7.9. 1 System Requirements Document
7.9.2 Presentation to Management
7.9.3 Transition to Systems Des1&n
206
207
108
208
108
209
1 10
210
211
211
211
212
212
213
214
214
214
2I 6
217
219
219
219
219
220
221
A Question of Ethics
7. 10 Summary
KeyTefms
222
Exercises
226
222
224
189
Case in Point 6.l : Hilltop Moton
6.8..3 Cius 01ograms
l'JO
use in Point 6 .3: Train the Trainers, Inc.
191
192
6.8.4 Sequence O.airams
6.8.S State Transition Oiograms
6.8.6 Activity Diagrams
6.8.7 Susineu Process Modeling
192
193
194
6.9 Tools
A Question of Ethics
195
6.1 0 Summary
Key Terms
Exercises
195
195
197
199
Chapter 7
Development Strategies
Learning Objectives
7. 1 Traditional Versus Web-Based Systems
Development
200
201
7.1.I Traditional Oevelopmenc In a U'ldltlonal systems
development environment
7. 1.2 Web-Based Oevalopmenc: In a web-based systems
development environment
7.2 Evolving Trends
7.3 In-House Software Development Options
73.1 Make or Buy Decision
7.3 l Developing Softw1re In-House
733 Purclwin1 • ~ Pac.kage
201
201
202
203
203
204
205
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, ..,...,.......,..~
r..a...w...,..._...., ..
7.3.4 Custom1%1ng •Software Pad<ogc
7.3.S Cre.tlng User Appli<att0ns
PHASE 3 : SYSTEMS DESIGN
Chapter 8
User Interface Design
Leaming Objectives
8.1 User Interfaces
8.2 Human-Computer Interaction
Case in Point 8. 1: Casual Observer Software
228
8.3 Seven Habits of Suceessful Interface Designers
8.3.1 Undeni:and the Busman
8.3.2 Maxlml1e Graphical Effectiveness
8.3.3 Think like a User
8.3.4 Use Models and Prototype>
8.3.5 Focus on Usability
8.3.6 Invite Feedback
8.3.7 Document Everythln&
232
8.4 Guidelines for User Interface Design
8.4. 1 Create an Interface That Is Easy to Learn and Use
8.4.2 Enhance User Producuvlty
8.4.3 Provide Flexibility
8.4.4 Provide U1en wich Help and Feedback
8.4.5 Create an Atll'lctove Layout and Oesl&n
8.4.6 Enhance che Interface
8.4.7 Focus on Oaa Entry Screens
8.4.8 Use Validation Rules
8.4.9 Manoge Data Effectro'Oly
8.4.10 Reduce lnputVolume
234
234
235
236
236
137
238
240
143
245
145
229
230
232
232
232
233
233
233
233
234
Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
.................,.t11ru ..
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
ix
Ta ble o f Contents
2'46
Case in Point 8.l : Boolean Toys
8.5 Source Document and Form Design
146
8.6 Printed Output
2'47
8.6.1 Report ~'II'
8.6.2 Report ~lgn Pnndples
8.6.3 Tn- of R"'°ru
2'48
248
250
Ca.e in Point 8 .3: Luy Eddie
251
251
8.7 Technology Issues
252
8.7.1 Output Technology
8.7.2 Input TechnolocY
25'4
8.8. I 0uq>Vt Secumy and Control
255
255
8.8 2 Input Securtl}' and Control
156
8.8 Security and Control Issues
257
257
8.9 EmergingTrends
8.9. 1 Modulor Deslsn
8.9.2 Re•pon•lve Web Design
8.9.3 Prototyp1n1
158
258
260
260
262
A Question or Ethics
8.10 Summary
Key Terms
Exercises
266
Chapter 9
Data Design
268
269
269
Learning Objectives
9. 1 Data Design Concepts
9.1.1 O.ta Scructures
9.1.2 Mano and o.,,.ca: Ao.a cnsiin Ex.omple
9.1.3 Database Manaaement Systems
269
271
272
9.1 DBMS Components
9.2. I lnU!rfaces lor Usen, Database Administrators. and
Related Systems
9.2.2 Schema
9.2.3 Physical Data Repository
273
2n
273
274
275
9.3 Web-Based Design
9.4 Data Design Terms
9.5 Entity-Relationship Diagrams
Case In Point 9. 1: TopText Publishing
9.6 Data N ormalii.ation
9.6. I Saindard N otation Format
9.6.2 First Normal Form
9.6.3 Second Normal Form
9.6.'4 Third Normal Form
Case In Point 9.2: CyberToys
9.6.S Two Re>l-World Examples
9.7 Codes
.........""_.. ... .-.................
9.9 Data Control
A Question or Ethics
305
306
9. 10 Summary
306
KeyTe,.ms
Exercises
308
313
Chapter 10
System Architecture
316
317
Learning Objectives
I 0. 1 A,.chitecture Checklist
I0.1.1 Corporat0 Organludon and Culture
I0.1.2 Enterprise Resource Planning (ERP)
I 0. 1.3 lnltQI Cost and TCO
I 0. 1.'4 Sal•b•lity
I0. 1.S Web Integration
I 0.1.6 Legacy Systems
10. 1.7 Processing Options
I 0. 1.8 Security Issues
10. 1 9 Corporote Portals
317
317
318
319
319
319
320
320
320
32 1
Case in Point 10.1 ABC Sy.terns
I O.l The Evolution of System Architecture
321
321
322
I0.2.1 Mainframe Arch1tec:wre
IO.l.l Impact of the Ptrsonal Computer
I0.2.3 Network Evoluuon
322
I 0.3 Client/Server An:hitecture
323
324
325
326
326
327
10.3 I The Client's Role
I 0.3.2 OoentJSeM1er Tiers
I 0.3.3 M1ddleware
10.3.'4 Cost-Benefit luues
10.3.S Ptrformanco Issues
276
279
I 0.5 E-Commerce Architecture
329
I 0.5. 1 In-House Solutions
I 0.5.2 Packaged Solu11ons
I0.5.3 Service Providers
183
Case in Point I O.l . Small Potatoes
284
284
285
I 0.6 Processing Methods
330
33 1
33 1
332
332
332
286
I0.6. 1 Online Processing
I0.6.2 Batch Processing
I0.6.3 Example
287
10.7 N etwork Models
334
290
291
291
I 0.7. 1 The OSI Model
10.7.2 NetworkTopology
10.7.3 Network Devices
335
337
297
I 0.8 W ireless Networks
338
299
333
333
331
I 0.8.1 Stand•rds
338
I 0.8 2 Topolog1u
1083 Trends
339
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
302
303
328
328
329
298
_..__ ...................
301
327
297
9.7. 1 Ottrv.-ofCodes
9.7.l Types of Codes
9.1.3 Designing Cod.s
9 8.1 Tools and Techniques
9.8.2 Logial Venu• Phytical Storage
9 8.3 O.ta Cod•ng
10.4 .I lntemet·BuedArchiteca.o,.
I 0.'4 2 Cloud Computing
10.4 .3 Web 2.0
280
180
180
9.5. 1 Drawing an ERO
9.5.2 Typos of Refadon•hlps
9.5.3 Cardinality
300
301
I 0.4 The Impact of the Internet
175
9.'4. 1 Definitions
9.'4.2 Key Field•
9.'4.3 Refttential Integrity
Case 1n Point 9.3= Madera Tools
9.8 Data Storage and Access
339
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~----···---~~-.,.-"~
Table of Contents
x
340
Case In Point I 0 .3: Spider IT Services
'--
I
382
383
387
I l.93 Dati Conve.-..on
11.9.4 Training
11.9.S Post-lmplementadon Tasks
10.9 Systems D esign Completion
10.9.1 System DHlgn Speclflcauon
I0.9.2 Us..-ApprCMI
10 9.3 PreS4'lc11lons
341
341
3'12
342
A Question of Ethics
3 43
A Q uestion of Ethics
391
I 0.1 0 Summary
343
I I. I0 Summary
391
Key Terms
346
Key Terms
394
Exercises
350
Exercises
398
~
tdwtrica
PHASE S : SYSTEMS SUPPORT
AND SECURITY
PHASE 4 : SYSTEMS
IMPLEMENTATION
Managing Systems Support
and Security
Managing Systems Implementation
Le arning Objectives
352
Lear ning O bjectives
400
11 .1 Quality A ssurance
I I. I. I Softw.lre Englneerlnc
I 1.1.2 Systems Engineering
I 1.13 International Organization for St»ndardlution
353
353
3S3
355
12. 1 U ser Support
12.1 .1 UserTralnlng
12.1.2 Help Desks
12.1.3 Outsourcing Issues
401
I 1.2 Application D evelopment
11.2.1 Review the System Design
I 1.2.2 Application De..lopment Tuks
I l.2J Syncms Development Tools
356
356
356
403
I I .3 Structured Deve lo pment
11.J. I Strvcture Chuts
I I 3.2 CohesK>n .nd Coupl 111
11.3.3 Drawing a StrvCture Chart
359
12.2 Maintenance Tasks
12.2.1 Types of Maintenance
12.2.2 Correctl\'e Maintenance
12.2.3 Adaptm: Mimt~ncc
12.2.4 P..-fectrVe Maintenance
12.2.S ~ntive Maintenance
11 .4 Object-Orie nted Developme nt
11.4.1 Charactenstlcs of Object-Onented De-ttlopment
11.4.2 lmplementadon of Obtect-Onented Designs
114.3 Object-Oriented Cohesion and Couplin&
3 64
365
366
366
I 1.5 Agile D e velopment
11 5.1 en.- Programml11g
11 S 2 UJ1r Scones
11.5.3 Iterations and Releases
367
368
369
369
11 .6 Coding
369
I I.7 Testing
11.7.1 Unlt Teulng
11.7.2 Integration Tesung
11.7.3 System Tesdng
370
357
360
361
362
Case n Po
12
0
0
12.3 Maintenance Management
12.l. I The Mimtenance Te"'"
12.3.2 Maintenance Requests
12.33 Establishing Pnorrt1u
12.l.4 Configuration Management
12.l.S M•intemnce Releases
12.l.6 VersK>n Control
12.3.7 Basehnes
401
401
403
404
404
406
406
407
1n:lng, Inc,
7
408
408
409
410
411
412
412
414
12.4 System Pe rformance Manage ment
12.4. I fault Management
12.4.2 Performance and Workload Measurement
12.4.3 Cap•clty Planning
4 14
3 l
12. 5 System Security
12.S. I System Security Concepts
12.S.2 Risk Management
12.S.3 Attacker Promos and Attacks
419
419
420
421
11.8 D ocum entation
11.8. 1 Program Documcntodon
11.8.2 System Documentation
11.8.3 Operations Documentition
11.8.4 User Documentitlon
I 1.8.5 Online Documentation
373
374
12.6 Security Levels
12.6.1 Physical Security
423
423
I I •9 Installation
11.9.1 Operational andTest Environments
11.9.2 System Changeover
3 78
Case in Point 12.2: Outer B;mks County
12.6.2 Network Security
12.6.3 Application Security
12.6.4 Ric Security
12.6.S User Security
12.6.6 Procedur.ll Security
426
426
429
431
432
434
C:...
I
370
372
372
M...,., lnc.
374
375
375
376
378
379
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, ..,...,.......,..~
r..a...w...,..._...., ..
414
416
417
Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
.................,.t11ru ..
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
xi
Ta b le o f Contents
c.
l'uw
17
C
on L
1
Consulting, Inc.
4)4
435
12.7 Backup and Recovery
12.7.1 Global Terrorism
12.7.l Backup f>ojKoes
12.7.3 Business ContJnUtty Issues
12.8 System Re tirement
435
435
436
437
438
12.9 Future Challenges and Opportunities
12.9.1 T..-.nds and Predoc:tJOns
12.9 l Strateiic Ptann•f\g for IT Pro(euionals
12.9.3 IT Credentials and Cerofoc:aaon
.........""_.. ... .-.................
A Question of Ethics
443
11.10 Summary
443
Key Terms
Exercises
446
438
Glossary
452
453
+40
Index
471
+41
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
442
442
12.9.4 CnocalThonkln&Skills
12.9.S Cybcretllla
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~----···---~~-.,.-"~
~ JIJ»C....... ~ Al RlilfD
~ ... _
l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.: ......,_ . . . ,_.,~-.lit .......... .._.,._.__..,~•\
. . . _ . .... ..., ~...,.._,_..,..., J\&."9 ... --.11 ......... ~ C'dptl"~~d.tt ...... -
............ -
..... -
..........
-.-.....w--...-.11
xii i
PREFACE
The Shelly C:ishman Series~ offers the finesr rexes in compurer education. \Ve are
proud char our previous editions of Systems Anafysis and Design have been so well
received by insrructors and srudenrs. Systems Analysis and Design, 12th edition
continues with the innovation, qualiry, and reliabiliry you have come to expect.
T he Shelly Cashman Series dcvelopmenr ream carefully reviewed our pedagogy and
analyzed its effectiveness in reaching roday's srudenr. Conremporary srudents read les~
but need to retain more. As rhey develop and perform skills, students must know how co
apply the skills ro different ~errings. Today's students need co be continually engaged and
challenged to rerain whar they're learning. With chis book, we continue our commitment
to focusing on the user and how the)' learn besr.
Facing a c hallenging global markerplace, companies need strong IT resources ro 5ur·
vive and compete effecrivcly. Many of today's students will become the systems analysts,
managers, and lT professionals of tomorrow. This text will help prepare them for rh o e
ro les.
Overview
Systems A nalysis and Design, 12th edition offers a practical, streamlined, and
updated approach to information systems development. Systems analysis and design is a
disciplined process for creating high-qualiry enterprise information systems. An information system is an amalgam of people, data, and technology to provide support for business furn'tiom
..
•. As technology evolves, so docs systems analysis. The book cmphasi.i:es
the role of the systems ana lyst in a dynamic, business-related environment. A !.ystcms
analyst ii. a valued team member who helps plan, develop, and maintain information
systems. Analysrs must be exccllenr communicators with st rong analytical and crincal
thinking skills. The y must also be business savvy, technically competent, and be cquall)'
comfortable working with managers and programmers. Throughout the book, realworld examples emphasize critical thinking and l T skills.
I\1any two· and four-year colleges and schools use this book in information systems
and computer science curriculums. The 12th edition includes expanded coverage of
emerging technologies, such as agile methods, cloud computing, and mobile applications. Thi!> new marcrial complements the updated treatment of traditional approaches
to systems analysis and design.
Using chi~ book, ~tudents learn how to translate business requirements into informa·
tion systems char support a compan y's strategic objectives. Case srudies and assignments
teach analytical reasoning, critical thinking, and p roblem-solving skills. Numerous projects, assignments, and end-of-chapter exercises are provided, along with detailed instructor support material.
Objectives of This Text
Syst ems Analysis and Design, 12th edition is inrended for a three credit-hour introductory systems analysis and design course. This rexr is designed ro:
•
explain systems analysis and design using an appealing full-color format, numerous
scrcenshors and illusrrarions, and an easy-to-read srylc that invites students ro learn.
•
introduce project managemenr concepts early in the systems development process.
•
challenge students with a Question of Ethics mini-case in each chaprer that a ks
them to respond to real-life ethical issues in an IT environment.
c..., .... .31:8C....,:...._ Al~,,_~,..., •WGfd.~•~• ..... ••,__0.:•*'"-....... -61111,_,,..-_,-.c..........,.._ec ...lllil__.~ .t
•......w~~-._....,..,.....,
........ _ ._ _..........,....,. ...
.-;11-...~~c-,,....i.__..~w._.._
........ __ ..,.._.,......,..._..,....._...., ..
xiv
Preface
•
provide multi-method coverage, including a comparison of structured, objectorientcd, and agile systems development merhods.
•
explain how IT supporcs business requirements in todays intensely competitive environment, and
•
d~ribc major IT devclopmcntS and trends.
Ne w and Updated Feature s in This Edition
Systems Analysis and Design, 12th editio11 offers these exciting new and updated
features:
•
Reexamined strucrure and subject coverage to ensure studentS can identify and focus
on the main content readily. Confirmed chat related content has been aligned under
comprehensive section headings to maintain a clear flow of topic and reduce distraction.
•
A renewed emphasis on aligning learning objectives with chapter content and assessments. The learning objectives have been updated and carefully reworded so that
instructors know what m focus 011, and studencs know what is expected of them.
T he questions, discussio n t<>pics, and projects have all been updated to better assess
student mastery of the material.
•
Updated or replaced many Case in Point mini-cases ro ensure learners arc exposed to
relevant and current examples of real-world business applicanons of key concepts.
•
Updated examples of CASE tools reflecting web-based and/or open source offerings.
These cools are often free and are representative of modern systems analysis
solutions.
•
Updated screenshots to Microsoft Office 2019 products and Visible Analyst 2016.
Organizatio n of This Text
Systems Analysis and Design, 12th edition contains 12 chapters that reach valuable
cross-functional skills. The chapters are organized into five phases: planning, anal ysis,
design, implemenrarion, and support and security. A four-part S)•stems Analyst's Toolkit,
now available as an online appendix, reflects the most recenc changes in today's syscems
analysis tools and a lso includes invaluable resources. Cross-functional toolkits provide
scudents with che basic skills soughc after by o rganizations hiring systems analysts.
Phase I: Systems Planning
•
Chapter 1 - Introduction to Systems Analysis and Design: Chapter l provides an
introduction ro systems analysis and design by describing the role of information
teclmology i.n today's dynamic business environment.
•
Chapter 2 - Analyzing the Business Case: Chaprer 2 explains how syscems projects
gee srartcd and how co evaluate a projecc propost1l co determine ics feasibility.
•
Chapter 3 - Managing Systems Projects: Chapter 3 describes how to use project
management tools and techniques, and how to plan, schedule, monicor, and report
on n· projects.
c..,....lla'c......,........,
A1..,....ai-.en...
... ...,,..,.., ..,.......,,,... ........
~-..,.~·----·~••klk<9i11,..,_0w.~,,...
a:.a.ww~
.. - ... ,...,•_....,.._....,,..._.t._.,doA..,._~•.
.. ., ...cn11.,.__..........,,..-:&-c~..,.--:c--•.,,. .. -~....._.....,.. .... ..,,, ......... ,... ........... ..,._.._
_.._...,~
xv
Preface
Phase 2: Systems Analysis
•
Chapter 4 - Requirements Engineering: Chapter 4 describes the requirements engineering process: gathering facts about a systems project, preparing documentation,
and creating models char will be used to design and develop the S)Stem.
•
Chapter 5 - Data and Process Modeling: Chapter 5 discusses data and process
modeling techniques that analysis use to show how the system transforms data into
w.eful information.
•
Chapter 6 - Object ModcUng: Chapter 6 discusses object modeling techniques rhar
analysts use ro crc:irc a logic:il model.
•
Chapter 7 - Development Strategies: Chapter 7 considers various development strategies for the new system and plans for the transition to the systems design phase.
Phase 3: Systems Design
•
Chapter 8- User In terface Design: Chapter 8 explains how to design an effective
user interface :ind how m handle data security and control issues.
•
Chapter 9 - Oaca Design: Chapter 9 focuses on the data design skills that arc necessary for a systems analyst to construct the physical model of the information system.
•
Chapter l 0 - System Architecture: Chapter I0 describes system architecture, which
translates the logical design of an information system into a physical blueprint.
Ph
I
•
Chapter 11 - Managing Systems Implementation: Chapter 11 describes application
development, documentation, testing, training, data con,·ersion, and system changeover.
Phoue 5 S !>
•
St.. p - and Securit"
Chapter 12 - Managing Systems Support and Security: Chapter 12 describes systems
support and sccunry casks char continue throughour the useful file of rhe system,
includmg maintenance, sccuriry, backup and disaster recovery, performance mcasurcmcnr, and system renremenr.
Online Appendix:The Systems Analyst's Toolkit
•
Toolkit Part A - Conuuwiication Tools: Part A of the toolkit discui.ses coinmunication tools that can help the analyst write clearly, speak effectively, and deliver powerful presentations.
•
Toolkit Part B - CASE Tools: Part B describes CASE tools that be can used co
design, cnn~truct, and document an information system.
•
Toolkit Part C- Financial Analysis Tools: Part C demonstrates financial analysis
tools that can used ro measure project feasibility, develop accurate cost-benefit estimates, and make sound decisions.
•
Toolkit Part D - Internet Resource Tools: Part D describes Internet resource cools
chat can be used co locate information, obtain reference material, and monitor IT
trends and developments.
c..., .... .31:8C....,:...._ Al ~ ,,_~,..., •WGfd.~•~• ..... ••,__0.:•*'"-....... -61111,_,,..-_,-.c..........,.._ec ...lllil __.~.t
•......w~~ - ._...., ..,. ....,
........ _ ._ _..........,....,. ...
.-;11-...~~c-,,....i.__..~w._.._
........ _ _..,.._.,......,..._..,....._...., ..
Features
xvi
FEATURES
CHAPTER LEARNINGTOOLSAND HOWTHEYWILL HELPYOU
Case In Point: Each chapter includes th.rec brief cases thar provide a comextual business
example for students focused on the key issues covered in the chapter.
A Q uesrion of Ethics: A realistic ethical issue is presented at the end of each chapter.
These examples force you to examine your reactions and how you would respond to
common workplace situations.
Chapter Exercises: The chapter exercises are direct!)• related to the learning objectives.
Your answers to the 10 questions will show that you understand the key points. Five
discussion topics and five projects offer opportunities to dig deeper and learn even more.
MINDTAP FOR SYSTEMS ANALYSIS AND DESIGN
MindTap for Systems Analysis and Design, 12th edition is a personalized, fully onl ine,
digital learning platform of content, assignments, and services that engages students and
encourages them to thi nk critically whlle allowing instn1ctors to easily set their course
through simple customization options.
MindTap is designed to help students master the skills they need in today's workforce. Research shows employers need c ritical thinkers, troubleshooters, and creative
problem-solvers to stay relevant in our fast paced, technology-driven world. MindTap
helps sn1denrs achieve this with assignments and activities that provide hands-on prac·
rice and real-life relevance. They are guided through assignments rhar help them master
basic knowledge and undersranding before moving on to more challenging problems.
i\1indTap is designed around learning objectives and provides the analytics and
reporting to easily see where the class stands in terms of progress, engagement, and
completion rates. Students can access eBook content in the ~l indTap Reader, which
offers highlighting, note-taking, search and audio, and mobile access. learn more at
www.cengage.com/mindrap.
Co11ceptClips: ConceptClip videos focus learners on a key concept in each chapter and
arc designed ro deepen their understanding of the topic.
Running Case: Based on feedback from readers and instructors, we've created a new
running case to replace the SCR Case from previous editions. The case challenges learners to apply key systems analysis and design concepts and skills to a realistic scenario
they would encounter in the workplace. The case brings the key concepts and skills of
the chapter rogether in an authentic assignment. The look and feel of rhe case tool has
also been updared ro be an authenric, immersive experience for students.
INSTRUCTOR RESOURCES
We are dedica ted to providing you all the tools yo u need ro make your class a success.
information on all supplementary inaterials can be found on the password-protected
website at logi11.ce11gage.com. If you need help accessing this page, please contact your
(engage representative.
The Instructor Resources include the fo llowing:
•
Online Appendix: The Systems Analyst's Toolkit: A 4-parr online appendix reflects
rhc mosr recent changes in today's systems analysis tool .
c..,....lla'c......,........,
A1..,....ai-.en...
... ...,,..,.., ..,.......,,,... ........
~-..,.~·----·~••klk<9i11,..,_0w.~,,...
a:.a.ww~
.. - ... ,...,•_....,.._....,,..._.t._.,doA..,._~•.
.. ., ...cn11.,.__..........,,..-:&-c~..,.--:c--•.,,. .. -~....._.....,.. .... ..,,, ......... ,... ........... ..,._.._
_.._...,~
x v ii
About The Author
•
Instructor's Manual: Contains lecture notes summarizing the chapter sections, figures
and boxed elemenrs found in ever>' chapter, teacher tips, classroom activities, and
quick quives in ,\ilicrosoft Word files.
•
PowerPoint Presentations: A multimedia lecture presentation system provides slides
for each chapter, based on chapter objectives.
•
Figure Files: Illustrations for every figure in the text in electronic form.
•
Solutions to Exercises: Includes solutions for end-of-chapter exercises.
•
Test Bank and Test Engine: Test banks include questions for every chapter, featuring
objective-based and critical thinking question types, page number references, and figure references when appropriate. Cengage Leanling Testing powered by Cognero is a
flexible, online S)•Stem that allows you to:
•
author, edit, and manage test bank content from multiple Cengage Leaming solutions.
•
create multiple test versions in an insranr.
•
deliver rests £rom your LMS, your classroom, or wherever you want.
ABOUT THE AUTHOR
Willi the 12th edition, Scott Tilley becomes the sole author of Systems Analysis and
Design in the Shelly Cashman Series. Dr. Tilley is an emeritus profcs~or at the Florida
Institute of Technology, president and founder of the Center for Technology & Society,
president and co-founder of Big Data Florida, president of the Space Coast chapter of
the international Council of Systems Engineering (IN COSE), and a Space Coast \X'riters'
Guild f ellow. In addirion to this book, he is the author or editor of numerous other publications, including Software Testing in the Cloud: Migration 6r Execution (5pnnger,
2012), Testing iOS Apps with Hadoop Unit: Rapid Distributed GUI Testing ( ~1organ
& Claypool, 20 14), The Vicious SUJans (And Other Tall Tales) (Precious Publishing,
2017), Dreams (Antholog) Alliance, 2018), and Technical justice (CTS Press, 2019). He
wrote the weekly "Technology Today" column for Florida Today (Gannett) from 2010
to 2018. l le holds a Ph.D. in computer science from the University of Victoria.
ACKNOWLEDGMENTS
A book like Systems Analysis and Design would not be possible without rhc help and
support of a great many people, both past and present. Harry Rosenblarr's contributions
to previous editions of rhe book provided the foll!lldarion for the current edition. His
foresight made updating the material much easieir than it might otherwise have been.
Textbooks these days arc much more than just printed books; they arc educational
platforms that have many moving parts. This means purring together an updated edirion
of a book like this, particularly on an aggressive schedule, is a challenge. I'm pleased to
say that the entire production ream rose to the occasion. Thanks to Jaymie Falconi,
Michele Srulga, Emily Pope, and Maria Garguilo at Cengage for all of their help. Thanks
to John Freitas for providing new screenshors of programs and applications. An>' errors
or omissions in this edition of the text are purely my responsibility.
Finally, sincere thanks to the insrn1ctors and students who offered feedback and comments. We have tried to address your concerns and incorporate your suggestions. As this
field is constantly evolving, we srrongl)' encourage your participation in helping us provide
the freshest, most relevant information possible. We will cenainly continue to listen carefully.
If }'OU have an)' que tions or comments, please contact us through your local representative.
c..., .... .31:8C....,:...._ Al~,,_~,..., •WGfd.~•~• ..... ••,__0.:•*'"-....... -61111,_,,..-_,-.c..........,.._ec ...lllil__.~.t
•......w~~-._....,..,.....,
........ _ ._ _..........,....,. ...
.-;11-...~~c-,,....i.__..~w._.._
........ __ ..,.._.,......,..._..,....._...., ..
~ JIJ»C....... ~ Al RlilfD
~ ... _
l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.: ......,_ . . . ,_.,~-.lit .......... .._.,._.__..,~•\
. . . _ . .... ..., ~...,.._,_..,..., J\&."9 ... --.11 ......... ~ C'dptl"~~d.tt ...... -
............ -
..... -
..........
-.-.....w--...-.11
PHASE
Systems planning is the first of five phases in the systems development life cycle. It's always a
good idea to know whether a project fits the company's overall strategy.A systems project that
does not align with corporate strategies should not be approved. The role of an information
system is to support business goals.
Chapter I focuses on an introduction to systems analysis and design by describing the role
of information technology in today's dynamic business environment.This includes information
systems, lntemet business strategies, modeling business operations, business information
systems, organizational information models, systems development, the information technology
department. and the role of the systems analyst.
Chapter 2 focuses on analyzing the business case, explains how systems projects get started, and
describes how to evaluate a project proposal to determine its feasibility.This includes strategic
planning and strategic planning tools, the business case, systems requests, factors affecting
systems projects, processing systems requests, assessing request feasibility, setting priorities, and
the preliminary investigation.
Chapter 3 focuses on managing systems projecu.This includes an overview of project
management, creating a work breakdown structure, task patterns, the critical path, project
monitoring and cont.rel, reporting, project management so~ware, risk management, and
managing for success.
r..,,...J1DOr-..1-.. 4• 11_.. • ...__. ~....... .,...~ • ........._ . ....._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
Chapter I
Introduction to Systems Analysis and Design
Introduction to
Systems Analysis
and Design
Chapter I is the first of three chapters in the systems planning phase. This chapter explains the role of
information technology In today's dynamic business
environment. This chapter describes the development
of information systems. systems analysis and design concepts. and various systems development methods. This
chapter also summarizes the role of the information
technology department and its people in the enterprise.
The chapter includes three "Case in Point" discussion questions to help contextualize the concepts
described in the text. The "Question of Ethics" invites
examination of the ACM's code of ethics and those of a
developing systems analyst.
LEARNl"IG OB ECT VES
When yo11 fi11ish this d1apter, you should be able to:
CONTENTS
1. Describe rhe impact of informario n rechnology
on soc1ery
2. Describe che five main components of an
informarion sysrem
3. Explain lnrerner business srratcgies and
relationships, including B2C and B2B
4. Explain how rouse business profiles and models
S. Undersrand rhe seven rypcs of information
systems used in business
6. Describe the types of inform:i rion Lhe four
classes of users need
7. Distinguish among struccured ana lysis, objeceorienccd ana lysis, and agi le systems development
methods
8. Lise rhe tools chat enable rhc syseems ana lyse
to develop, manage, and mainrain large-scale
information systems
9. Explain the seven main functions of rhe
information technology department
10. Describe the roles and responsibiliries of a
systems analrst within the enterprise
I . I Information Technolog)
I .2 Information Systems
Case in Point J. J: Data Breaches
1.3 Internet Business Strategies
1.4 Modeling Business Operations
1.5 Business lnformarion Systems
Case in Point 1.2: Autonomous Vehicles
1.6 Organiz.arional Information Models
1.7 Systems Development
1.8 The Information Technology Department
Case in Point 1.3: Global Horels m1d Momma 's
Morels
1.9 The Systems Analyse
A Question of Ethics
I. I 0 Summary
Key Terms
Exercises
r..,,...JmDr-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
Phase I
Systems Planning
3
I. I Information Technology
I. I INFORMATION TECHNOLOGY
Information technology (IT) refers to the combination
of hardware, software, and services that peop le use to
manage, communicate, and share information. Companies use information as a way to increase productivity,
deliver quality products and services, maintain customer
Social Media
loyalty, and make sound decisions. In a global economy
Explodes!
with in tense competit ion, information technology can
mean the difference berween success and failure.
l\1ore than ever, business success depends on inforAnother Home Run
Fh c More Sillies Ban
for Apple'!
mation technology. IT is driving a new digital economy,
Driver Toting
where advances in hardware, software, and connectivity
1Math: 1Pod +
can provide enormous benefits to businesses and indiDigital Cure fo r
i Phone + 1Pat! =
viduals. Although economic trends affect IT spending
Health Care Costs SS$
levels, most companies give IT budgers a high priority, in
good rimes or bad. The reason is simple: during periods
of growth, companies cannot afford co lag behind the
FIGURE 1- 1 These headlines Illustrate the enormous
impact
of information technology on our lives.
IT curve. Conver&ely, when the economy slows down,
firms often use IT co reduce operating costs a nd improve
efficiency.
lnforn1Jtion technology a lso has profound infl uence on modern li fe. Although
fictitious, the headlines in Figure l -1 offer dramatic examples of how information
technology issues such as data privacy, mobile devices, and social media affects our
society. We live in a world where we can be traced , analyzed, and survei lled without
our knowledge. This raises many important questions, such as how to secure personal
dara while still providing useful functionality an d business value.
The following sections provide a sense of IT history, an overview of systems
analysis and design, and a description of the syst ems analyst's role.
---·
1. 1. 1 The Changing Nature of Information Technology
ll1e history of IT is a fascinating srudy of human progress and achievemenr. \Ve are
dazzled by the latest and greatest technology, just as our parents and grandparents
were astonished by the arrival of television, space flight, and personal compuring.
It is imporrant for IT professionals, w ho live a nd work in this exciting world, to
realize rh~1t each technology advance is part of a long-term process that often brings
dramatic change hut never really ends. The story of IBM is a good example.
As its name suggesrs, International Business l\1achines was a major supplier of office
equipment a nd rypewriters long before the modern computer era. Herman Hollerith,
who invented a card th at identified characters by the location of punched holes,
founded IBM's predecessor company in 1896. A deck of hundreds or even thousands of
th ese cards cou ld store data that was easily sorted , queried, and printed by machines.
This system sc)llnds archaic now, but punch card technology was a huge advance that
revolu tionized the business world and was in use into th e 1960s and beyond.
Today, IBM is a globe-spanning company with several hundred thousand employees.
It has succeeded in part by constantly adapting to its changing business environment.
For example, while it was once known primarily as a hardware company, today IBM
makes a significant part of its revenue from software and services. It also inveMs in
its people and tries to hire the best talent available. The result is that IBM has more
parents and more Noble Prize winners than any other IT company in history.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I
Introduction to Systems Analysis and Design
1.2 Info r mation Systems
4
1. 1.2 Systems Analysis and Design
S)stcm s anal ysi~ and design is a s tep-by-step process for developing high-quality
information syscems. An information system combines technology, people, and darn
to pro\•ide support for business funcrions such as order processing, invencory control,
human resources, accounting, and man)' more. Some information systems handle
routine da y-to-day rasks, while ochers can help managers make bener decisions, spot
marketplace trends, and reveal patterns that might be hidden in srored darn.
Talented people, including a mix of managers, users, nerwork administrators, web
designers, programmers, and systems analysts, typically develop information systems.
Capable IT professiona ls like these a re always in demand, even in a slow economy.
For example, norice how many positions related to information technology and information systems arc available in the Melbourne, Florida area, as shown on Monster.
com's job search website in Figure 1-2.
[ Q. Information l ecltnology & ~ F Melboume. FL_ _ _ __.
MONSTER
.
Find Jobs •
Post a Resume
Caree< Resource• •
., ...
C<lmpany Profiles
Information technology & Information systems J obs In Melbourne, Florida (1081 Jobs Found)
FIGURE I · 2 Monscer.com is an example of an online job search w ebsite that IT professionals can use.
Sourc.r.
nI
en
1.1 .3 What Does a Systems Analyst Do?
A ~yMems analy~t is a valued member of the IT department ream who helps plan,
develop, and maintam information systems. Analysts mus t be excellent communicators wirh strong analytical and critical thinking skills. Because S)'Stems analysts transform business requirements into IT projects, they must be busmess-savvy as well as
technically competent and be equally comfortable with managers and progranlmcrs,
who sometimes have different points of view.
:Vlost companies assign systems analysts to the IT department, but analysts can
also report to a specific user area such as marketing, sales, or accounting. As a member of a functional team, an analyst is better able to understand the needs of that
group and how IT supports rhe department's mission. Smaller companies often use
consultants to perform sysrems analysis work on an as-needed basis.
On any given day, an analyst mighr be asked to docwuent business processes, rest
hardware and software packages, design input screens, train users, and plan e-commerce
websites. A systems analyst n1ay occasionally manage IT projects, including tasks,
resources, schedules, and costs. To keep managers and users informed, the analyst conducts meetings, delivers presentations, and writes memos, reports, and documenta tion.
Section 1.9 lists typica l skills and education requirements, certifications, career
opportunities, and the possible impacr. of future IT trends for systems analysts.
1.2 INFORMATION SYSTEMS
A system is a set of related components that produces specific results. For example, specialized systems route lnternet traffic, manufacture microchips, and control
complex entities like the Hubble telescope, which took the amazing image shown in
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
s
1.2 Information Systems
Figure 1-3. A mission-critical ~stem is one that is vital to a
company's operations. An order processing srsrem, for example, is mission-critical because the company cannot do business
without it.
Every system requires input data. For example, a computer
receives data when a key is pressed or when a menu command
is selected. In an information system, data consisrs of basic
facrs that are the system's raw material. lnfonnation is data
that has been transformed into output that is valuable to users.
An mformarion system has five key componenrs, as shown
in Figure 1-4: hardware, software, dara, processes, and people.
1.2.1 Hardware
Hardware consists of everything in the physical layer of the
information &ystem. For example, hardware can include
servers, workstarions, networks, telecommunications
FIGURE 1-l Consider the amazing technology
that enabled the Hubble telescope to capture this
equipment, fiber-optic cables, mobile devices, scanners, digital
Image.
capture devices, and other technology-based infrastructure.
Sourcet Co..rt y of it,.. I "'-j,j
A l::irge concentration of networked computers working
together is called a data center. As new technologies emerge,
/
/
.
I
manufacturers race to market the innovations and reap the rewards.
Hardware purchasers today face a wide array of technology choices and I 1111111 •• •
s
decisions. In 1965, Gordon Moore, a cofounder of Intel, predicted that the
y
number of rransisrors on an inregrared circuir chip would double abour
'
every 24 months. His concept, called Moore's law, has remained valid for
s
'
over 50 )'Cars. Fortunately, as hardware became more powerful, it abo
[
•
became much less expensive. Large businesses with thousands or millions
T
of sales rranc;actions require company-wide infor mation systems and pow. . 111111 <
erful servers, which are often now in the cloud, such as those shown in
E
Figure 1-5.
~
l 8ol••
.,...
I
I
.....
~
T
1.2.2 Software
M
I.ii
Soh\\arc refers to the programs rhar control the hardware and produce the
FIGURE 1-4 An Information
desired information or resulrs. Somvare consists of S)'Stem sofrware and
system needs these components.
application software.
System software manages the hardware components, which can include
a single computer or a global network with many tho usands of c(jents. Either the
hardware manufacturer supplies the system software or a company purchases it
from a vendor. Examples of sysrem software include the operating system, security
software rhat protects the computer from intrusion, device drivers that communicate
with hardware such as printers, and utility programs that handle specific tasks such
as dara backup and disk management. System software also controls the flow of darn,
provides darn security, and manages network operations. In today's inrerconnected
busines!> world, network sofrware is virally importanr.
Application software consists of programs that support day-to-day busines~
functions and provide users with the information they need. Example!> of company-wide
applications, called l.'llterpri\e application~. include order proces!>ing !>y!>tems, payroll
systems, and company conununications networks. On a smaller scale, individual users
can boost productivity with tools such as spreadsheets, presentation software, and
databa~e management systems.
.........""_.. ....-.................
_..__ ...................
("..,_..., llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ·· · ---~~-.,.- " ~
Chapter I
Introduction to Systems Analysis and Design
1.2 Information Systems
6
FIG URE 1-S Cloud compudng provides the enormous storage and speed that modern IT systems need.
(
ry
~
I/I
"°'- <Orr"
Applic:nion software includes horizontal and vertical systems. A hori1ontal sy~ tem
is a sysrem, such as an inventory or payroll application, that can be adapted for use in
many differenr rypes of companies. A verrical system is designed to meer rhe unique
requiremencs of a specific business or industry, such as an online rerailer, a medical
practice, or an au to dealership.
~l ost companies use a mix of software that is acquired at various rimes. When
planning an information system, a compan)' must consider how a new system
will interface with older systems, which are called legacy systems. For example, a
new human resources sysrem might n eed to exchange data with a legacy payroll
application.
1.2.3 Data
Data is the raw material that an in.formation system transforms into useful information. For exa mple, an information system using a relational database can store data
in various locations, called rabies. By linking the tables, the system can display the
specific information that the user needs-no more and no less. Figure 1-6 shows a
payroll system that stores data in foLJr separate tables. Notice that the linked rabies
work together to supply 19 different data items. A user c:.in display any or all darn
items and filter the data ro fit defined limits. In this example, the user requested a list
of employees who live in a certain city and worked more rhan 40 hours in the last
pay period. Jane Doe's n:.ime was the first ro display.
The growth of big data has given rise to new ways of scoring, sea rching,
:ind managing data. Tradirional relational models are srill used, but so-called
NoSQI databa~cs are gaining in popularity due to their ability ro scale to extremely
large and unstrucrured datasets.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
7
1.2 Information Systems
CUAAENTOfDUCTIONS
O!OUCTION OPTIONS
9 Employet No
fmplQYet No
t Oedu<:llon Code
Otpt
Ply Rott
I Otduruon Codt
Otsalpllon
fMPl,OVff
P>yl'tnod
Hoors Wotlrtd
Amount
frtqvtn()'
f1rs.tNlMt
Ml
ltrt N1mt
Strt:tt
CllY
FIGURE I ·6 In a typial payroll system using a relational model, daa is st0ttd on separate ables that are hnked to
fonn an overall daabase.
1.2.4 Processes
Processes de cribe the tasks and business functions that users, managers, and IT sraff
members perform LO achieve specific results. Processes are the building blocks of an
ioforn1ation system because they represent actual day·to-day business operations. To
build a successful information system, analysts muse understand business processes
and document them carefully.
1.2.5 People
People who have an interest in an information system are called stakeholders. Stakeholders include che management group responsible for the system, the users (sometimes called end users) inside and outside the company who will interact with rhe
system, and IT sea ff members, such as systems analysts, programmers, and network
administrators, who develop and support the syscem.
Each stakeholder group has a viral interest in the information system, bur
most experienced IT professionals agree that chc success or failure of a system
usually depends on whether it meets the needs of irs users. For that reason, it is
essential to understand user requiremenrs and expectations rhroughout the development process.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ...............,..
__....
--
........... ......
o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I
Introduction to Systems Analysis and Design
1.3 Internet Busin ess Strategies
8
A data breach occurs when a hacker gains illegal access to a system and steals personal data.
such as credit card numbers or home addresses. With more of our information stored in
the cloud. data breaches are becoming increasingly common. Research recent news articles
about large-scale data breaches. summarize why they occurred, and suggest how they might be
prevented in the fuwre.
I J INTERNET BUSINESS STRATEGIES
To design successful systems, systems analysts must understand a company's business
operations. Each situation is different. For example, a retail ~tore, a medical practice,
and a hotel chain all have unique informarion systems requirements. As the business
world changes, systems analysts can expect to work in new kinds of compan ies tha t
will require innovative IT solutions.
Business mday is being shaped by rhree major trends: rapidly increasing globalization,
technology integration for seamless informatio n access across ::i wide v::iriety of devices
i.uch ::is laptop~ and smartphones, and the rapid growth of cloud-based computing and
software services. These trends are being driven by the immen~c power of the Internet.
1.3. 1 The Internet Model
Internet-based commerce is called e-commerce (electronic commerce). Internet-based
systems involve various hardware and software designs, but a typical model is a series of
web pages rhat provides a user interface, which communicates with database management sofnvare and a web-based data server. On mobile devices, the user mceracrs wich
the system with an app, bur che same back-end services are accessed. As Internet-based
commerce continues ro grow, career opportunities will expand sigmficanrly for IT profes!.1onals such as web designers, database developers, and systems analyses.
1.3.2 B2C (Business-to-Consumer)
Using che Internee, consumers can go online to purchase an enormous variety of product) and services. This new shopping environment allow~ custome~ to do research,
compare prices and features, check availability, arrange delivery, and choose payment
methods in a single convenient session. Many companies, such as airlines, offer incentives for o n line cr::insactions because web-based processing cost~ are lower than traditional methods. By making Aight informa tion available online to lase-min ute travelers,
some airlines also offer special discounts on seats that might otherwise go unfilled.
B2C (business-to-consumer) is changing traditional business models and creating
new ones. For example, a common business model is a retail store that sells a product
to a customer. To carry o ut that same transactio n 0 11 the Internet, che company must
develop an onl ine score and deal with a totally different set of marketing, advertising,
and proficabilicy issues.
Some companies have found ne'v ways to use established business models. For
example, Airbnb and VRBO have transformed chc traditional hospitality service
industry into a popular and successful way for individuals to rent chcir properties.
Ocher retailers seek to enhance che oulinc shopping experience by offering gift advisors, buying guides, how-co clinics, and similar fcarures. In the e-commerce battles,
the real winners are on line consumers, who have more information, better choices,
and chc convenience of shopping ac borne.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Phase I
Systems Planning
9
1.4 Modeling Business Operations
1.3.3 B2B (Business-to-Business)
Alrhough rhe bu~mess-ro-consumer (B2C) sector is more familiar to rerail cu~romer;,
the volume of B2B (bu~iness-ro-busine~s) transactions is many rimes greater. Industry
observers predict that 828 sales will increase shar ply as more firms seek to improve
efficiency and reduce costs.
Initially, electronic commerce berween two companies used a darn sharing arrangement called electronic data interchange (EDI). EDI enabled computer-to-computer
dara transfer, usually over private telecommunications lines. Firms used EDI to
plan production, adjust inventory levels, or stock up on raw materials usmg dara
from another company's information system. As B2B volume soared, compan)'·tocompany transactions migrated to the Internet, wbich offered srandard protocols,
universal ::wailability, and low communication costs. The main advantage of the web
is that it offers seamless communication between different hardware and software
environments, anywhere and anytime.
Because ir allows companies ro reach the global marketplace, B2B is especially
i1nporrant to smaller suppliers and cusromers who need instant information about
prices and avai lability. In an approach that resembles an open marketplace, some 82B
sites invite buyers, sellers, distributors, and manufacturers to offer products, submit
specifications, and transact business.
r..~osr large firms and government agencies use supply chain managemenc (SCM )
software. A supply chain refers to all the companies who provide materials, services, and
functions needed m provide a product to a custon1er. For example, a Sherwin-Williams
customer who buys a gallon of paint is at the end of a chain that includes the raw mate·
rial sources, packaging suppliers, manufacturers, transporters, warehouses, and rerail
srores. Because SCM is complex and dynamic, specialized software helps businesses
manage invenrory levels, costs, alternate suppliers, and much more.
1.4 MooFUNG Bus1~ess OPERATIONS
Sysrems analysts U!.C modeling to represent company operations and informatton needs.
Modeling produces a graphical rcpresenration of a concept or process that systems
developers can analyze, cest, and modify. A S)'Stems analyst can describe and sunpltfy an
information syscem by using a set of business, data, object, network, and process models.
A business profile is an overview of a company's mission, functions, organizanon,
products, services, customers, suppliers, competicors, constraints, and future direction.
Although much of this informarion is readily available, a systems analyst usually
needs co do additional research and fact-finding co fill our missing or incomplete
infonnation. A business profile is the starting point for the modeling process, and
a systems analyst can describe and simplify an infonnation syscem by using a set of
business models and business process models.
A business model describes the information that a system must provide. Analysts
also create models to represent data, objects, oenvorks, and other system components.
Although the models might appear to overlap, they actually work together to describe
the same environment from different poincs of view.
Business process modeling involves a business profile and a set of models that
document business operation~. Model-based systems engineering (MBSE) is one of
the leading methods used by systems analysts co develop informacion systems.
A bu~ines\ process is a specific set of rransactions, events, and result<i that can be
described and documented. A business process model (BPM) graphically displays one
or more business processes, such as handling an airline reservation, filling a producr
order, or updating a customer account. The sales order example in Figure 1-7 shows a
simple model that includes an evenc, rbree processes, and a result.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I
Introduction to Systems Analysis and Design
1.4 Modeling Business Operations
10
Ched< Customer
Status
P1ocess
Verily Customer
Veriy Customer
Credit
Cred~
Process
Enter Customer j
Enter Customer
Order Data
Order Data
FIGURE I· 7 A simple business model might c:onsist
of an event, three processes, and a result.
FIGURE I · 8 This sample uses business process
modeling nocation (BPMN) to represent the same
events, processes, and workllow shown In Figure 1-7.
$ourcet Or.iwo
-n
A rough skecch might be sufficient to document a simple business process. For
complex models, analyses can choose computer-based tools thac use bu ~i ness process
modeling notation (BPMN). BPMN includes standard s hapes and symbols to
represenr evenrs, processes, workflows, and more . .Vlulcipurpose application such as
Microsoft Visio or online diagramming tools such as draw.io can be used to create
BPNIN models. Notice that tbe draw.io model in Figure 1-8 use:. BPMN symbols to
represent the same sales order process shown in Figure 1-7.
_____ ... _
--
· - - g Q.
..
=====================··
........__
_....
~- · - ·
-·-
·-
0 0 00
0000
oooa
001
(
...
I
OciCJO
Cl
. -·
..
00011
11==
0
'
C=i
....
o.i:.c:..o
0000
QoO•
fcoOo
0 -A><>
;:
__ _
-·-
.._..
V0(9@
•
•
-
.,_
0000
0
..
. .
~
•
·- -·-·
.
FIGURE I · 9 Lucidchart allows you to drag and drop various symbols and connect them to model a business process.
Sowc.« Lu.. ,iJ s.... .,..,_
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f •,...
..,...,...... .,..~
__.~~ c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
II
1.5 Business Information Systems
Systems developers often use multipurpose charring tools such as Lucidchart to
display business-related models. Lucidchart is a popular tool that systems analysts
can use to create business process diagrams, flowcharts, organization charts, network
diagrams, floor plans, project timelines, and workflow diagrams, among others.
Figure 1-9 shows how to drag and drop various symbols from the left pane into the
drawing on the right and connect them to show a business process.
1.5 8USINS::SS INFORMATION SYSTEMS
In rhe past, IT managers identified an information system based on its primary
users. For example, administrative staff used office systems, operational people
used operational systems, middle managers used decision support systems, and rop
managers used executive i11for111atio11 systems.
Today, those traditional labels no longer apply. For example, all employees,
including top managers, use office productivity systems to do their jobs. Similarly,
operational users often require decision support systems to do their jobs. As business
changes, information use also changes, and now it makes more sense to identify a
system by its functions and features, rather than by its users. A new set of system
definitions includes enterprise computing systems, transaction processing systems,
business support systems, knowledge management systems, user productivity systems,
digital assisranrs, and systems inregrarion.
1.5. 1 Enterprise Computing
Enterprise computing refers to information systems that supporc company-wide
operations and dara management requiremenrs. Walman's inventory control system,
Boeing's production control system, and Hilcon H otels' reservation system arc examples of enterprise computing systems. The main objective of enterprise compuring is
ro integrarc a company's primary functions (such as production, sales, ervices, inventory control, and accounting) ro improve efficiency, reduce coses, and help managers
make key decisions. Enterprise computing also improves data ecuriry and rcliahiliry
by imposing a company-wide framework for data access and storage.
In many large companies, applications called e nterprise re~ource planning
(ERP) i.ystcm!> provide cosr-effecrive support for users and manageri. throughout
the company. For example, a car rental company can use ERP to foreca~t cu~tomer
demand for rental cars at hundreds of locations. Because of its growth and potentia~ many hardware and sofrware vendors target the enterprise computing marker
and offer a wide a rray of produces and services. For example, Figure 1-10 highlights
SAP's leading ERP solutions. SAP is a Germany company that is a market leader in
enterprise application software.
By providing a company-wide computing environment, many firms have been able
to achieve dramatic cost reductions. Other companies have been disappointed in the
time, money, and commitment necessary to implement ERP successfully. A potential
disadvanrage is rhat ERP systems genera Uy impose an overall strucn1re rhar might
or might not march the way a company operates. ERP is described in more detail in
Chapter 7, which discusses development strategics.
1.5.2 Transaction Processing
Transaction processing (TP) systems process data generated by day-ro-dar business
operations. Examples of TP systems include customer order processing, accounts
receivable, and warranry claim processing.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I
Introduction to Systems Analysis and Design
12
1.5 Business Information Systems
What is ERP?
ERP stands for Enterprise Resource Planning
What is the simplest ERP definition? Think about all the core processes needed to run a company:
finance, HR, manufactur ing, supply chain, services, procurement, and others. At its most basic level,
ERP integrates these processes into a single system . But new ERP systems are anything but basic.
They provide intelligence, visibility, analytics, and efficiency across every aspect of a business. Using
the latest technologies, ERP systems facilitate the flow of real-time information across departments
and ecosystems, so businesses can make data-driven decisions and manage performance - live.
F IGU RE 1-1 0 SAP is a leading vendor of ERP solutions that can boost productivity.
s...r...
Check
Credit
Status
Verify
Customer
Data
TP sysrems perform a series of casks whenever a specific transaction occurs. In
the example shown in Figure 1-11, a TP syscem verifies the cuscomer's darn, checks
the customer's credic starus, checks the stock starus, poses to accounts receivable,
adjusts the inventory level, and updates the sales file. TP S)'Stems typically involve
large amounts of data and are mission-critical syscems because the enterprise cannot
function without them.
T P syscems are efficient because they process a
set of transacrion-relatt:d command~ as a group
Check
Post to
Accounts
Stock
rat her than individually. To protect darn incegrity,
Status
Aece1vabla
however, TP systems ensure that if any single
elemenc of a crans~1 ctio11 fai ls, the system does not
Adjust
Inventory
process the rest of the transaction.
~\
•
,.,.
1
Levels
E.5.3 Business Suppo rt
6
Sates
nsactlon
Update
Sales Fie
F IGURE I · I I A single sales transaction consius of six separate
tasks. which the TP system processes as a group.
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
Business support system~ provide job-related
information support to users at all levels of a
company. These systems can analyze transactional
data, generate information needed to manage and
control business proces~es, and provide information that leads to better decision making.
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
13
1.5 Business Information Systems
The earliest business computer systems replaced manual tasks, such as payroll
processing. Companies soon realized that computers also could produce valuable information. The new systems we re called manageme nt info rma tion 'Y~ tem s
( ~US) because managers were the primary users. Today, emplO)'ees at all levels
need informanon to perform their jobs, and they rely on informanon system~ for
that support.
A business support system can work hand in hand with a TP sy tern. For example, when a cornpan)• sells merchandise to a cusromer, a TP system records the sale,
updates the customer's balance, and makes a deduction from inventOf)'. A related business support system highlights slowor fast-moving items, customers
with past-due balances, and inventory levels that need adjustment.
To compete effectively, firms
must collect production, sales,
and shipping data and update the
compan>r-wide business suppo rt
system immediately. Auto ma ted
data acquisition is possible using
technology such as radio frequency
identificatio n (RFJD), which uses
high-frequency radio waves to track
physical objects, such as the shirt
shown in Figure 1- 12. Major retailers such as Walmart, which requires
its suppliers co add RFlD rags to
all item , have fueled RFlD's dramatic growth by tracking produces
throughout the retail process.
FIGURE 1- 1l With an RFID tag. items can be tracked and monitored throughout
An imporrant feature of a
the retail process.
~
b~mess supporr system is decision
support capability. Decision supporr
helps users make dec1 ions by creating a computer model and applying a sec of
variables. For example, a truck Oeet dispatcher might run a series of what-if scenarios
to determine the impact of increased shipments or bad weather. Alcernacively, a retailer
might use what-if analysis to decermine the price it must charge co increase profits by a
specific amount while volume and costs remain unchanged.
1.5.4 Knowledge Management
Knowledge management systems use a large data base called a knowledge base that
alJows users to find information by entering keywords or questions in normal English
phrases. A know ledge ma nagement system uses inference rules, which are logical rules
char identify data patterns and relationships.
The WolframAlpha website, shown in Figure 1-13, describes itself as a "computational knowledge engine." Ir has a sophisticated na tural language front end that
understands user queries in several domains. As shown in the figure, these domains
include mathematics, science and technology, society a nd culnire, and everyday life.
WolframAlpha relics upon a large knowledge base spanning multiple websites and its
own proprietarr algorithms ro provide users witb detailed answers to rheir questions
on many different topics. The results are displayed using a mix of multimedia, including mathematical equations if appropriate.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I
Introduction to Systems Analysis and Design
1.5 Business Information Systems
14
• WolframAlpha - -
•I
_..,_
Matte• a:1 ••
1...
•
~Ult
.!:! - · -
s
1
.a
. . """"
>: 1 -
. •:. L._..'*'t
rt' ........ ._..
~
J ... t ...............
[). C::...,,nt.oqo; Sclfl'ICll
·-
~
.. \
~1'9"1i.tll•.. •'Hll'll
11111
,._,,~
~
.,_,
..,,,,, !C.""1CM
-·
"':!JI( f•1o''*POtUt1Clrl
..
... "
---
Sodo!y & Culluze •
.,.,...,._
1
• -·-
Sdnn & '!echnclagy •
..
... ......
m
\v;
O.tnll.Tima
v
..,...,~,
~ ._.,,rtNl>Q
•
t.:
FM 4' Nl.0'•1 •tfl.
•• .....
Poll*'lfAOtrt""J'
-
IMPo"lllWWIW
•
tto.fh<ll41 ~
Ho!.lw1014IV1W\
:.:..i · -
• ....
T.clfly tWllll1d
..... .
FIGURE 1- 13 WolframAlpha describes itself as a "computational knowledge engine."
Soun:•: IM. ,.,,., "' plu
l.
I .S.S User Productivity
Companies provide employees at alJ levels with technology that improves
productiviry. Examples of user productivity system s ioclude email, voice mail, video
and web conferencing, word processing, automated calendars, database managemenc,
spreadsheets, desktop publishing, presentation graphics, company inrranets, and integrated mobile computing systems. User productivity systems also include group ware,
which enables users to share dara, colJaborate on projects, and work in teams. One
popular groupware product is Slack, shown in Figure 1- l 4. Slack provides common
app integration and unified communication channels for distributed teams.
Slade Is where work happens
·-··-·" - _
-·-----...---------............--.....,.
-
-----..-·----·-··-·-
FIGURE 1- 14 Slack Is a popular groupware application that provides common app
Integration and unified communkation channels for distributed teams.
Sou~..
~- )U,
-Woip-M ._..,..
r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
..
(....,..... J:gi( . . . . .
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
.........,..,. ..
._.,.,.,.......c:-..•~-".....-""'*"....,.._...,..
..
Phase I
Systems Planning
IS
1.5 Business lnforma cion 5yscems
\'V'hen companies first installed word processing systems, managers expected ro
reduce the number of employees as office efficiency increased. Thar did nor happen,
primaril) because rhe basic nature of clerical work changed. With computers
performing the reperirive work, office personnel were able co handle tasks char
required more judgment, decision making, and access to information.
Computer-based office work expanded rapidly as companies assigned more
responsibility co employees at lower organizational levels. Relatively inexpensl\·e
hardware, powerful networks, corporate downsizing, and a move coward employee
empowerment also conrribured ro this rrend. Today, administranve assistants and
company presidents alike are nerworked, use computer workstations, and share corporate data co perform their jobs.
1.5.6 Digital Assistants
Rapid advanceb in na tura l language processing have made a
new rype of business information system possible: the personal
digital ab5i!.tant. T hese i.ysrems a re combinations of knowledge
management systems a nd user productivit y systems, enhanced
with artificial intelligence and machine learning capabilities.
They are typica lly cloud based and can be embed ded in
hardware devices of vario us sizes a nd types.
Digita l absisrants are exemplified by products such as
Amazon.com's Alexa, Apple's Siri, a nd Google Assistant. Users
speak to these applications just as they would speak to a real
person. The device replies in a human-sounding voice. These
services increase their capabilirics over rime. They can integrate with other software applications and actual hardware,
such as controlling lights ar home or the rempera·r ure ar the
office. An image of the Amazon Echo Dor, which is a sman
speaker powered by Alexa, is shown in Figure 1-15.
FIGURE 1-15 Amazoncom·s Echo Dot.a digital
assistant embedded 1n a smart speaker powered
by Alexa.
Sow«<
1.5.7 Systems Integration
Most large companies requi re systems that combine transaction proce sing, business support, knowledge managcmenc, and user productivity features. For example, !tuppose an
international customer makes a warranty claim. A customer service representative enters
the claim into a TP system, which updates rwo other systems: a knowledge management
S)'!ttem that tracks produce problems and warranry activity a nd a quali ty control system
with decision support capabiliries. A qualiry control engineer uses what-if analysis to
determine if the firm should make prod uct design c hanges to reduce warranty claims.
lo this example, a TP system is inregrated with a knowledge management sy!ttem and a
business support system with decisio n suppo rt features.
Imagine you work for a large automotive company. Your manager asks you to look into integrating a digital as.sistant into a new vehicle for the next production year. How would understanding
your company·s business profile help you complete chis task?
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Chapter I
Introduction to Systems Analysis and Design
I .6 Organizational Information Models
16
1.6 ORGANIZATIONAL INFORMATION MODELS
Corporate organizationa l strucn1re has changed considerably in recent years. In an
effort to increase producriviry, many companies reduced the number of managemenr
levels and delegated responsibility ro operational personnel. Although modern organization charts rend to be flatter, an organizational hierarchy still exists in most firms.
1.6. 1 Functions and Organizational Levels
A rypica I organizarional model identifies business functions and organizational levels,
as shown in Figure 1-16. Within the functional areas, operational personnel report to
supervisors and team leaders. The next level includes middle m:inagers and knowledge workers, who, in turn, report to top managers. In a corporate srrucrure, the top
managers reporr to a board of directors elected by the company's shareholders.
Top
Managers
Middle Managers
and
Know edge
Workers
SupervlSOl'S and Team
LeadatS
Operabonal Efr4>toyees
Business Functions
Organizational Levels
FIGURE 1-1 6 A typical organizational model identifies business functions and organiutional levels.
A systems analyst must understand the compan)''s organitational model to recognize who is responsible for specific processes and decisions and ro be aware of what
information is required by whom.
1.6.2 Top Managers
Top managers develop long-range plans, called srrategic plan~, which define the company's overall mission and goals. To plot a future course, top managers ask questions
such as " How much should the company invest in information technology?", " How
much will Internet sales grow in the next five years?", or "Should the company build
new factories or conrract out production functions?"
Strategic planning affects the company's future survival and growth, including
long-term IT plans. Top managers focus on the overall business enterprise and use IT
to set the company's course and direction. To develop a strategic plan, top managers
also need information from outside the company, such as economic forecasts, technology trends, competitive threats, and governmental issues.
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
17
1.7 Systems Development
1.6.3 Middle Managers and Knowledge Workers
Jusr below rhe rop management level, most companies have a layer of middle managers and knowledge workers. Middle managers provide direction, necessary resources,
and performance feedback ro supervisors and ream leaders. Becau e they focus on a
omewhat shorter time frame, middle managers need more detailed informarion than
top managers but somewhat less than supervisors who oversee da)'-to-day operations.
For example, a middle manager might review a weekly sales summary for a threestare area, whereas a local sales team leader would need a daily report on customer
sales at a single location.
In addition to middle managers, every company has people called knowledge
workers. Knowledge workers include systems analyses, programmers, accountants,
researchers, tramers, human resource specialists, and other professionals. Knowledge
workers also use business support systems, knowledge management systems, and user
productiviry systems. Knowledge workers provide support for the organization's basic
functions. J ust as a mi litary unit requires logistical support, a successful company
needs knowledge workers to carry out its missio111.
1.6.4 Supervisors and Team Leaders
Supervisors, often called team leaders, oversee operational employees ;'Ind carry out
day-to-day functions. They coordinare operational tasks and people, make necessary
decisions, and ensure that the right rools, materials, and training are avai lable. Like
other managers, supervisors and team leaders need decision support information,
knowledge management systems, and user productivity systems to carry out their
responsibilities.
1.6.5 Operational Employees
Operational emplo)'ees include users who rely on transaction processing systems ro
enter and receive dara they need to perform their jobs. In many companies, operational U)ers also need mformation ro handle tasks and make decisions t hat were
assigned previously to supervisors. lliis rrend, called empo\\'erment, gives employees
more responsibiliry and accounrabiliry. ~1any companies find char empowerment
improves employee morivarion and increases customer sarisfactio11.
I. 7 SYSTEMS DEVELOPMENT
Many options exist for developing information systems, bur the most popular
a lternative~ are !itructurcd analysis, which is a traditiona l method that scill is widely
used, object-oriented (0-0) analysis, which is a more recent approach thac many
analysts prefer, and agile methods, which incl ude t he laresc trends in software development. Figure 1-17 provide~ an overview of the th ree methods, which are discussed
in the following !.Cccions.
Although most projects utilize one approach, it i!> not unusual for systems developers to mix and match methods to gain a better perspective. [n addition tO rhese
three main development methods, some organiza1tions choose to develop their own
in-house approache!> or use techniques offered br software suppliers, cool vendors, or
consultants. Manr alternatives exist, and IT experts agree that no single development
method is bei.c in all cases. An approach that works well for one project might have
disadvantages or risks in another situation. The imponant thing is to understand the
various methods and the srrengths and weaknesses of each approach.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I
Introduction to Systems Analysis and Design
I. 7 Systems Development
18
Description
STRUCTURED
ANALYSIS
OBJECT-ORIENTED
ANALYSIS
AGILE
METHODS
Represents !he system in terms
Views the system in terms
of objects that combine
data and processes. The
objects represent actual
people, things, transactions.
and events. Compared to
structural analysis, 0-0
phases tend to be more
interactive. Can use the
waterfall model or a model
that stresses greater
iteration.
Scresses intense team-based
effort. Breaks development
into cycles. or iterations,
that add functionality. Each
cycle 1s designed. built. and
tested in an ongoing process.
Attempts to reduce ma1or
risks by incremental steps In
short time intervals.
al daa and !he processes !hat
act upon that data.System
de< elcpment IS organized
into phases. with deMrables
and milestones to measure
pi ogi ess.The watemll model
typically consists al five
phases: requil el IM!l ltS. desipl.
ConstruCOOl'I. testing. and
mamtenanee & e\IOlution. Iteration
is possible among !he phases.
Mode ling
Tools
Data flow diagrams (DFDs) and
process descriptions, which are
described In Chapter S. Also,
business process modeling.
Various object-oriented
diagrams depict system
actors, methods, and
messages, which are
described in Chapter 6.
Also, business process
modeling.
Tools that enhance
communication, such as
collaborative software,
brainstorming. and
whiteborads. Business
process modeling works well
with agile methods.
Pros
Traditional method that has
been very popular over time.
Relies heavily on written
documentation. Frequent phase
iteration can provide flexibility
comparable to other methods.
Well-suited to traditional
project management tools and
techniques.
Integrates easily
with object-oriented
programming languages.
Code is modular and
reusable, which can reduce
cost and development
time. Easy to maintain
and expand because new
objects can be created using
inherited properties.
Very flexible and efficient in
dealing with change. Stresses
team lnteraroon and reflects
a set of community-based
values. Frequent deliverables
consandy v.ahdate the
project and reduce risk.
C o ns
Changes can be cosdy,
especially in later phases.
Requirements are defined
early, and can change during
development. Users might not
be able to describe their needs
until they can see examples of
features and functions.
Somewhat newer method
might be less familiar
to development team
members. Interaction of
objectS and classes can be
complex in larger systems.
Team members need a
high level of technical
and communications
skills. Lack of structure
and documentation can
Introduce risk factors.
Overall project might be
subject t0 scope change as
user requirements change.
FIGU RE 1-17 Comparison of structured, object-oriented, and agile development methods.
Regardless of rhe devclopmenr stra tegy, people, tasks, rimerables, and cosrs must
be managed effectively. Complex projects can involve dozens of people, hundreds of
ra~ks, and many thousands of dollars. Project management is the process of planning,
scheduling, monitoring, controlling, a nd reporring upon the devclopmcnr of an informarion system. Chapcer 3 describes projecc management rools and rcchniques in derail.
I. 7. I Structured AnaJysis
Srrucrured anal)•sis is a traditional systems developmenr rechniquc rhac is rime
rested and easy co undersrand. Srrucrured analysis uses a series of phases, called rhe
('...,...., Jlt.'lit(ftllllpl. . . . . " ' It............. \I _,-
"'"""«iflN ~- .............. .... ,,......_ ........ _ ... ,..y... .., . . ...,.....,.4 .._ ........ -··~~
............w. .................................. ......., . . . . . ....-i .......~.
c:...a.-..---•"'• · ............... - .....
- 4 ............... ~ ..... .
Phase I
Systems Planning
19
1.7 Systems Development
~ys tems develo pment life cycle (SDLC), co plan, analyze, design, implement, and
support an information system. Although structured analysis evolved many years
ago, it remains a popular systems development method. Structured analysis is based
on an overall plnn, similar to a blueprint for constructing a building, so it is called n
predictive nppro:ich.
rrucrured :innl)•sis use a sec of process models co describe a system graphically.
Because it focu~e~ on processes that transform data into useful mformarion,
structured anal)'sis 1s called a process-centered technique. In addition ro modeling
the processes, srrucrured analysis also addresses data organization and structure,
rel:uional database design, and user interface issues.
A process model shows rhe data that flows in and our of system processes. Inside
each process, input data is transformed by business rules that generate the output.
Figure 1-18 shows a process model that was ere-aced with the Visible Analyst CASE
tool. The model, which represents a school registration system, is a called a data flow
diagram (DFD) because it uses various symbols and shapes to represent data flow,
processing, and storage. DFDs are discussed in more detail in Chapter 5.
41 V•,.blt 4n4'y11 · IRfGIST RATION PROCESS MODEU>FD)
li F~t
[d< Vo<w
CJC!J:.l
°"''°"'
1~ vj •4 14,
I .J
-"
Rq>OMt"')' 0..gftm Tools W.ndow - " Help
W .J1' ~ '1.a ia l •
4
•
x
[J
~ o""'a "'
ol
.. ,"\ ..,, , T
.
I
SCHOOL REGISTRATIO~ SYSTEl\1
OUTPUT
Sl\JDENTS
REGI STRATIOll Oo\TA
R£CIST£R 1 - - - - - - - - -M
.....--------1.t ~DC..''TS
COURS{OATA
CL\.SS ROSTERS
C'Ol'RS£S
>
<
I~ ISOiOOL REGlS-
F IG URE 1- 18 This Visible Analyst sc:reen shows a process model for a sc:hool registration system.The REGISTER STUDENTS process
accepts Input data from two sources and transforms it into output data.
Source:: V" ! ,,.
t"" ("'Pl~
11(~1
Structured analysis uses the SDLC to plan and manage the systems development
process. The SDLC describes activities and functions that all systems developers perform, regardless of which approach they use. In the waterfall model, the result of each
phase is called a deliverable, which flows into the next phase.
Some analysts see a disadvanrage in rhe built-in structure of rhe SDLC because
the waterfall model does not emphasize interacriviry among the phases. This criticism
can be valid if the SDLC phases are followed too rigidly. However, adjacent phases
can and do interact, as shown by the circular arrows in Figure 1-19, and interaction
among several phases is nor uncommon. Used in chis manner, the traditional model is
not as different from agile methods as ir might appear ro be.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~----···---~~-.,.-"~
Chapter I
Introduction to Systems Analysis and Design
20
1.7 Systems Development
The SDLC model usually includes five seeps,
which are described in the following sections: systems
planning, systems analysis, systems design, systems
implemencarion, and systems support and security.
SYSTEMS PLANNING: The sy~tem \ planning phase
usually begins wi th a formal request to the IT department, called a systems request, which describes problems or desired chaDges in an information system or
• System
teqUitements
a business process. In many companies, IT systems
document
planning is an integral part of overall business planDing. When managers and users develop their business
plans, they usually include lT requirements thar generate systems requests. A systems request can come
• Systrim
from a rop manager, a planning team, a department
design
spec1ftcat1on
bead, or the IT department itself. The request can be
very siignificant or relatively minor. A major request
might involve a new info rmarion system or the
upgradi ng of an existing system. In contrast, a minor
request might ask for a new feature or a c hange to the
• Functioning
system
user interface.
The purpose of this phase is m perform a
prelimina ry investigatio n co evaluate an IT-related
business opportunity o r problem. The preliminary
Systems
• Fully
investigation is a critical step because the outcome will
Security and
operahonaJ
affect the entire development process. A key part of
system
S u pport
the preliminary investigation is a feasibility Mudy that
reviews anticipated COM~ and benefits and recommends
a course of action based on operational, technical,
economic, and time factors.
FIGURE 1-1 9 Development phases and deliverables are
Suppose a systems analyst receives a request for
shown in the waterfall model.The circular symbols indie1te
a system change or improvement. The first step is to
Interaction among the phases.
determine whether it makes sense co launch a preliminary investigation at a ll. Before a conclusion can be
reached, more information about the business operations may be needed. After an
investigation, the systems analyst n1ight determine that the information system functions properly, bur users need more training. ln some situations, a business process
review may be recommended rather than an IT solution. ln o ther cases, a fu ll-scale
systems review may be necessary. U tbe development process continues, the next step
is the systems analysis phase.
SYSTEMS ANALYSIS: The purpose of the systems analysis phase is to build a logical
model of the new system. T he first step is requirements engineering, where the a nalyst
invc~tigates business processes a nd dlocuments what the new system must do to satisfy users. Requirements engineering continues the investigation that began during the
system~ planning phase. To understa nd rhe system, fact-finding using techniques such
as interviews, surveys, document rev iew, ob:.ervacion, and sampling is performed. The
fact-finding results a re used to build business models, data and process models, and
object models.
The deliverable for the systems analysis phase is the ~>~tern req uirements
document. The system requiremencs document describes management and user
requirements, costs, and benefits and outlines alternative development strategies.
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
21
1.7 Systems Development
SYSTEMS DESIGN: The purpose of the systems design phase is to create a physical
model thar will satisfy all documented requiremenrs for the system. At this srage, che user
interface is desii,'lled, and necessary outputs, inpucs, and processes are idenrified. In addirion, internal and external controls are designed, including computer-based and manual
features, to guarantee that the system will be reliable, accurate, maintainable, and -;ecure.
During the systems design pbase, the applicarion a rchirecrure is also determined, which
programmers will use ro cransform the logicaJ design into program modules and code.
The deliverable for this phase is the system de5ign specifica tion, which is presented
to management and users for review and approval. Management and user involvement are critical to avoid any misunderstanding about what the new system will do,
how it will do 1r, and what it will cost.
SYSTEMS IMPLEMENTATION: During the syste ms implementation phase, the new
system is constructed. Whether the developers use structured analysis or 0-0 methods, the procedure is the same-programs are written, tested, and documenced, and
the system is installed. rf the system was purchased as a package, systems analysts
configure the sofrwarc a nd perform any necessary modifications. The objective of the
systems implementation phase is to deliver a completely functioning and documented
informa tion system. Ac the conclusion of this phase, the system is ready for use. Final
preparations include converting data to the new system's files, training users, a nd performing the actual transirion to the new system.
The systems implementation phase a lso includes a n assessment, called a systems
evaluation, to determine whether the system operates properly and if co~ts and benefits are within expecrarions.
SYSTEMS SUPPORT AND SECURITY: During che systems ~ uppo rt and security
phase, the IT staff maintains, enhances, and proteccs the system. M aintenance
changes correct errors and adapt to changes in the environment, such as new rax
races. Enhancements provide new features and benefits. The objective du ri ng this
phase is to maximize return on the IT investment. Security controls safeguard the
system from both external and internal threats. A well-designed system must be
secure, reliable, maintarna ble, and scalable. A scalable design can expand to meet
new business requirements and volumes. lnfom1ation systems development is always
a work in progress. Business processes change rapidly, and most information systems
need to be updated significantly or replaced after several years of operation. For
example, a web-based sysrem may need more servers added to cope with increased
workJoad.
I. 7 .2 Object-Oriented Analysis
Whereas structured a nalysis rreats processes and data as separate componenrs,
object-oriented analysis combines data and the processes that act on the data as
objects. Systems analysts use 0-0 to mode l rea l-world business processes and operatio ns. The result is a set of softwa re objects that represent actual people, things, rransactions, and events. Usi ng an 0 -0 programming la nguage, a programmer then writes
the code rhat creates the objects.
An object is a member of a class, which is a collection of similar objects. Objects
possess characteristics called properties, which the object inherits from its class or
possesses on its own. As shown in Figure 1-20, the class called PERSON includes
I STRUCTOR and STUDENT. Because the PERSON class bas a property called
Address, a STUDENT inherirs the Address propeny. A STUDE1'.'T also has a property
called Nla1or thar is nor shared by ocher members of the PERSON class.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I
Introduction to Systems Analysis and Design
1.7 Systems Development
22
In 0-0 design, built-in processes called
nzethods can change an object's properties. For
Name
example, in an online catalog store, a n ORDER
Address
o bject might have a properry called STATUS that
Date of S.rih
changes when a CUSTOMER object clicks to
place, confirm, or cancel the order.
One objecr can send information to another
object by using a message. A message requests
STUDENT
INSTRUCTOR
specific behavior or information from another
lnhefll&d
Name
Name
object. For example, an ORDER object might send
Address
properties
Address
a
message to a CUSTOM ER ob1ect that requests
Dale of Birlh
Dale ol Bir1h
a shipping address. When it receives the message,
the CUSTOMER object supplies the information.
Otlice Location
GPA
Other - { Adv<SOr
The ORDER object has the capability to send the
Olllce Phone
properties
message, and the CUSTOMER object knows what
Email
actions to perform when it receives the message.
0-0 analysis uses object models to represent data
FIGURE I · 20 The PERSON class includes INSTRUCTOR and
STUDENT objects. which have Inherited properties and their own
and behavior and to show how objects affect other
properties.
objects. By describing the objects and methods
needed to suppon a business operation, a systems
developer can design reusable components that speed up
system implementation and reduce development cost.
Object-oriented methods usually follow a series of
analysts and design phases that arc simil:ir to the SDLC,
although rhere is less agreement on rbe number of phases and
their names. In an 0-0 model, the phases tend ro be more
interactive. Figi1re 1-21 shows an 0-0 development model
where planning, analysis, and design tasks interact ro produce
procotypes that can be rested and implemented. The result
is an interactive model that can accurately depict real-world
business processes.
0-0 merhodolog)' is popular because it provides an easy
transition to 0-0 programming languages ~uch as C++,
Java, and Swift. Chapter 6 covers 0-0 analysis and design,
with a detailed de cription of 0-0 terms, concept!., tools,
and techniques.
PERSON
I. 7.3 Agi ~e Methods
FIGURE 1-21 In a cyplc:al o.o development model.
planning. analysis. and design tasks Interact continuously
to generate protocypes that can be tested.
Development tcchnjques change over time. For example, structured analysis is a traditional approach, ~md agile methods are
the newest development. Structured analysis builds an overall
plan for the information system, just as a conn·actor might use
a blueprint for constructing a building. Agile methods, in conrmsr, attempt ro develop a
system incrcmcntall)' by building a series of prototypes and constantly ad justing them to
user rcquircmcnrs. As the agile process continues, developers revise, extend, and merge
earlier versions into the final product. An agile approach emphasizes continuous feedback, :ind each incremental step is affected by what was learned in rhc prior steps.
Although relatively new to software development, the norion of iterative development can be traced back to Japanese auto firms that were able ro boost productivity
by using a flexible manufacturing system, where team-based effort and short-term
milestones helped keep quality up and costs down. Agile methods have attracted a
wide following and an entire community of users, as shown in f igure 1-22.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
23
1.7 Systems Development
....,
____
lQ Scrum.org
EVENTS
The Scrum.org community is Large and active! Here is a list of some
of the events that members of our community are participating in.
Scot.So~
-
1. 2018
9 Edncugn
ScolScft Is tno ~ teen conll!nlnce in~ ts on anruat fes!NDI
d Ideas end Wlo\latlOn that ShowCases the best cf!Jle ~
tlldviology S«10r and llrtl'gS you saugnt all8r si: eaha rs from tar lb.ing
IOC4~
International Conference on Data Science, £-learning
and ln(ormot/on Systems 2018
0 0t lob.< I Z018
READ MORE
9 Mi\dnd
Don t miss ScNm org CEO Dave West as he is a keynote speaker fO< lhlS
....,•nl
FIG URE I 022 Scrum.org is a popular website supporting the agile community.
,.,,.,, 1
s~.l ~
Agile merhods typically use a ~piral model, which represents a series of itcrarions,
or revisions, based on user feedback. As the process continues, the final product gradually evolves. An agile approach requires intense interacrivity between developers
and individual users and does not begin with an overall objective. Instead, the agile
process determines the end result. Proponents of the spiral model believe that this
approach reduces risks and speeds up software development.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. ........... ... ~..
~~·~---- ···---~~-.,.-"~
Q
Chapter I
Introduction to Systems Analysis and Design
24
1.7 Systems Development
Barry Boehm, a noted sofrware eagineering professor, initially suggested spiral
models in the 1990s. He seated that each ireration, or phase, of the model musr have
a specific goal char is accepted, rejecced, or changed by rhe u'er or clienr. Thu , each
irerarion produces feedback and enhancemenrs, which enable the ream ro reach the
overall project goal. Typically, each iteration in a spiral model includes planning,
risk analysis, engineering, and evaluation. The repeated irerarions produce a series of
procorype~. which evolve inco the fin ished system. orice that rhese phases re emble
SD LC rasks, which also can be icerative.
Numerous orher adaprive variarions and related methods exi~t, and most TT
developers expect this trend ro continue in che future. Two examples arc Scrum,
which is discussed in Chapter 4, and Extreme Programming (XP), which is discussed
in Chapter 11.
Alchough agile methods are becoming popular, ana lysts should recognize char
these approaches have advantages and disadvantages. By their nature, agile methods
can a llow developers co be much more flexible and responsive bur can be riskier than
more tradition::il methods. For example, without a derailed set of system requirements, certa in features requested by some users might not be consistent with the company's larger game plan.
Other potential disadvantages of agile methods can include weak documentation,
blurred lines of accountabiJity, and too little emphasis on the larger business picture.
Also, unless properly implemented, a long series of iterations might accually add ro
project cost and development time. The bottom line is that sysrems analysrs should
undcrsrand the pros and cons of any approach before selecting a devclopmenr merhod
for a specific projecr.
I . 7.4 Pro totyping
Srrucrured analysii., object-oriented analysis, and agile merhods can all employ
protoq·ping as a supporting sysrem s development method. ProtOt)·ping resrs system concepts and provides an opportunity to examine input, ourput, and user
in terfaces before final decisions are made. A pro to t}pe is an early working version
of ::in information sysrem. Jusr as an ai rcrafr manufacturer resrs a new design in
a wind tunnel, sysrems analysts construct and study informarion system protorypes. A protorype can serve as an initial model thar is used as a benchmark ro
evaluarc rhe finished system, or the prototype irself can develop into the final
version of the system. Either way, prototyping speeds up the development process
significantly.
A possible disadvantage of prototyping is that imporrant decisions might be made
too early, before business or IT issues are undersrood thoroughly. A prototype based
on careful fact-finding and modeling rechniques, however, con be an extremely valuable tool.
1.7.S Tools
All systems development methods must be supported by tools to en:.ible the systems
analyst to develop, manage, and maintain large-scale information systems. These tools
go by various names, including a pplication lifecycle management (ALM), a lso called
prod uct li fccycle management (PLM ); integrated development environments (IDE);
::ind computer-a ided systems enginee ring (CASE), also called computer-a ided software
engineering. CASE tools provide an overall framework for systems development and
support a wide variety of design methodologies, including structured analysis and
objcct-orienred analysis.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
25
1.7 Systems Development
Tools make ir easier ro build an informarion system, t hereby boosring IT
productiviry and improving rhe qualiry of the finished product. After developing a
model, many CA E rools can generare program code, which speeds che implemenrarion
process. Figure 1-23 shows the wehsire for Polarion, an ALtvl solution from iemens
that 1~ part of cheir larger ~uire of offerings. Figure 1-24 shows the website for
Microsoft Visual cudio, a leading IDE. Figure 1-25 shows che web ite for Cameo
Systems Modeler, a leading MBSE CASE cool.
Polarion® application lifecycle management solutions overview
Polarion
Po&lnon & a u,,1fted appl.c-•tion tiftc)<t. 11\11"1i19f"Wf\t so' ... hon YrNte )Vt'
an d e -. bl.ltd lftl Ind "'IN99 ...,.,pla tcftwllt• S)"lle!M on I un.lltd
Dl..O 10M- lNl W"4S llNll leltnl «
100 pert8'l -
of users
"'°""'"°'
lnnowtr, pn>blem solw, and untodt syntfg~es woss d1str1bult'd teams
fl«Jcoble 1rd1lte<W,. end ll<ltM•ng en1bl., organlz•tlans 10 go H tlwy
grow.
Po anon ALM
Polarion REQUIREMENTS
Polarlon QA
.. fHt«r - mo<e , _ , M1ilt
~nmg- lr«Nblr.ty ond
~ty lr>•o your oppll(11.,., 1 let)dc
Ehoiwfy ~'-· ..,.,_• •W-ond
,.,.._,_.,_II
for complu SJ"I_,.
ondtnt>ng~
"°"ides comclle•~ IOI...,_ qunty .....,_..
K1otS ........ pqea lifK)'des
D
D
D
Variants Add-on
Polanon Pro
Polarlon Reviewer
ll<ipidly INI el!.ttiwfy o..ign. ~Ind
~· complu f1mlfies CJf ptodUtl _...,,,.
1NI va-11 wilh lndintty lffcf"'ll - l o g y
1NI lr-tegrll"'"'
unify Chl"llO .......met'I. llSli & is....
trodJoog 11'<! _
,_.."9 KrOU 111 P'O)KI
[Nble ln~nll •nd Ule<nel It.I~ IO
,....,...""and COftVT1iil"M on ""°'t. ,..,... M'ld
piOlllcle lndunry-complio<U t l « -
contribt.itof5 Kf'Cl55 tre entefp\M
D
D
lill""""" ond ll'PfOli'll\.
D
FIGURE 1-ll Polarton ,. a unified application lifecycle management (ALM) solution from Siemens.
5-<s
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ··----~~-.,.-"~
Chapter I
Introduction to Systems Analysis and Design
1.8 The Information Technology Department
26
--·- -
Visual Studio IDE
-
·············.·---·-:==:...
•
·-·
·-·
···-===::....
.. -
Fully-featurtd 1ntt.'9rak-d o.:vdoprrn:t l t:riwonment
(IOE)
fo< Android. 10S. rnacOS, web, and doud
···-
Download Vo~ual Studio for Mac .!.
.
·-·I' ..---
--
t
•
•
••
••
,,,,,_.' - ,..
- - - -· ·
--I"------··
t ' , 7111 I • .._
I
-
-
.......... =----............................--..
·-....
-·-·oo=
-- -·-
.-
r".
-
~
........
-~
~=~- ­
• -~ J
-
-
FIGURE I · 2 4 Microsoft Visual Studio is a fully-feawred integrated development environment (IDE).
Sour<e: """ •o • tt Co• p• ..
1
No Magic
Cameo Systems Modeler
c - ~.... MrDllllw.." . . ~" . . . . .cnw.--~ CClllabar•Nit Modllt B.wlofld ..,.,.... (• . . . . . .
~lllillltbiilll &
--..--.....-·..........
I ......a..,-°""*'~,....Wld~"'feoolsto . . . . tne*.lftel~.al---bOI
tt'AWIR thtMGAM
a d cx....Srr'IMlmidelSD...,.,lllt••••w•••...................
.• c.........,_
... ~
... -<v
'••CNdl
......
• Trn. . . .....-n~b-.ntl
~~c..tlt ~"'~' 4
'
1H Jl~M ....... XMI ~ 0t(IUbill1fkld to~ "ffllt.
..... ---·---~
FIGURE I ·25 Cameo Systems Modeler is a cross-platform collaborative Model-Based Systems Engineering
(MBSE) environment.
SOYrc:•: " ' ""ltt ·( n:
1.8 THE INFORMATION TECHNOLOGY DEPARTMENT
The IT department develops and maintains information systems. The IT group
provides technical support, which iodudes seven main functions: application
development, systems support and securiry, user support, database administration,
network administration, web s uppon, and quality assurance. These functions overlap
considerably and often have different names in different companies.
The structure of the IT department varies among companies, as does its name
and placement within the organization. In a small firm, one person might handle
~- )U,
-Woip-M ._..,..
r..a...w...,..._...., ..I_,.. 4111.,.. .................,.t11ru
..
(....,..... J:gi ( . . . . .
..,...,...... .,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~ c.....,..~
.........,..,. ..
._.,.,.,.......c:-..•~-".....-""'*"....,.._...,..
..
Phase I
Systems Planning
27
1.8 The Information Technology Department
all computer support activities and services, whereas a large corporation might
require many people with peciali1ed skills co provide information systems support.
Figure 1-26 shows a typical IT organization in a company char has networked PCs,
enterprise-wide databa~es, centralized processing, and web-based operations.
IT Departme nt
Otrector
lnlonnation Technology
I l
Apphcauoo
Development
I_
Syslems Support
and Secunty
I
User
Support
I ~'- _ I_
Database
AdminlstrallOn
Network
Administration
Web
Support
I
Ouahty
Assurance (QA)
FIGURE 1-26 Depending on its size, an IT department might have separate organization units for these
functions. or they might be combined Into a smaller number o f ceams.
1.8. I Application Development
The IT application development group typically provides leadership and overall guidance,
but teams consisting of users, managers, and LT staff members develop the systems themselves. A popular model for information systems development is a project-oriented ream
with IT professionals providing overall coordination, guidance, and technical support.
Suppose you work in the IT department of Global Hotels. a multinational hotel cham. Global
Hotels runs several specialized business support systems. induding a guest reservations system
that was developed in-house to meet the requirements of a large company with worldwide
operations. Guests can make one-stop online reservations by visiting Globals website, which has
links to all major vavel industry sites.
Global Hotels fust acqu ired Mom ma's, a regional chain of 20 motels. Momma 's uses
a vertical reservations package suitable for small- to medium-sized businesses and a
generic accounting and finance package. Should Momma's use Global Hotels' information
systems or continue with its ownl In your answer, consider issues such as business
profiles, business processes, system interactivity, and e-commerce.What addit ional
informat ion would be helpful to you in making a recommendation?
1.8.2 Systems Support and Security
Systems support and security provides vital protection and maintenance services for
system hardware and software, including enterprise computing systems, networks,
transaction processing systems, and corporate IT infrastructure. The systems support
and security group implements and monitors physical and electronic security hardware,
software, and procedures. This group also installs and supports operating systems, telecommunications software, and cencralized database management systems. ln addition,
systems support and security technicians provide technical assistance to ocher groups
in the IT department. If a site has a large number of remote clients, the systems support
group often includes a deplorment ream that installs and configures the workstations.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Chapter I
Introduction to Systems Analysis and Design
I. 9 The Systems Analyst
28
1.8.3 Use r Support
User support provides u ers with technical informarion, training, and produccivicy
support. The user su pport function usually is called a help de\k. A help desk's staff
crams u~crs and managers on application sofnvare such as email, word processing,
spreadsheets, and g raph ics packages. User support specialists answer questions, croubleshooc problems, and serve as a clearinghouse for user problems and solutions.
1.8.4 Database Administration
Dara base administration involves data design, management, sccurit)', backup, and
access. In small- and medium-sized companies, an IT support person performs chose
roles in addition to other duties. Regar d less of company size, mission-critical database
applications require continuous attention and technical support.
1.8.5 Ne twork Administration
Business operations depend on networks chat enable compa ny-wide informa tion systems. Network administration includes hardware and so~wa re mai ntena nce, support,
and security. In addition to controlling user access, netwo rk administrato rs insrall,
config ure, m::inage, monitor, and maintain ne twork a ppl ications. Nerwork a dministration is discussed in more d etail in Chapter 10.
1.8.6 Web Support
\'V'cb ~upporr is a vital technical support function. Web support spccialisrs design and
construct web pages, monitor traffic, manage hardware and sofnvare, and link webbased ::ipplic::irions to the company's information systems. Reliable, high-quality web
support is especia ll y critical for companies engaged in e-commerce.
1.8.7 Quality Assurance (QA}
Many la rge IT deparrments also use a quality assurance (QA) team thac reviews
a nd tests all applicarions and systems changes to verify specifications and software
quality standards. The QA team usually is a separate umr that reports directly ro IT
management.
I. 9 THE SYSTEMS ANALYST
A systems analyse invest igates, analyzes, designs, develops, insralls, evalua tes, and
maintains a company's information s ystems. To perform chose tasks, a sysrcms analys t constan tl y interacts with users ai!ld managers within and o utside rhe compan y.
The fo llowing sections describe a systems analyst's ro le, knowledge, skills, ed ucation,
certifications, a nd career opportunities.
1.9. 1 Role
A systems analyst helps d evelop IT systems rha r s upport business requirements. To
succeed, ana lysts often mus t ace as translato rs. For exam ple, when chey descri be
business processes to programmers, t hey muse speak a language thar programmers
will undersrand clearly. Typically, the analyse build s a series of models, diagrams,
and decision rabies and uses other descriptive cools and technique . Similarly, w hen
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
29
1.9 The Systems Analyst
communicating with managers, the analyst often must cranslate complex technical
issues into words and images thar nontechnical people can grasp. To do this, the analyst uses various presentation s kills, models, and communication methods.
Analyse arc often che company's best line of defense against an IT disaster-a <tystcm
that is rcchnically sound bur fail s because it does not meet the needs of u<;e~ and managers. \Xlhen thil> occur<;, poor communication i usually to blame. For an analyst, the most
valuable skill i<t the ability to listen. An effective analyse will involve users in every <ttcp of
the development process and listen carefully ro what they have to say. As the process continue , the analyse will seek feedback and comments from the users. This mput can provide a valuable early wammg system for projecrs chat might otherwise go off the crack.
1.9.2 Knowledge, Skills, and Education
A successful systems analyst needs technical knowledge, oral and written commu·
nication skills, an understanding of business operations, and critical thinking skills.
Educational requiremenrs vary widely depending on the company a nd the position.
In a rapidly changing fT marketplace, a syste1ns analyst must manage his or her own
career and have a pla n for professiona l development.
TECHNICAL KNOWLEDGE: Sracc-of-the-a rt knowledge is extremely import·
an t in a rapidly changing business and tech nical environment. T he Internet offers
numerous opportunities to update technical knowledge and skills. M any IT pro·
fcssionals go online ro learn about technical developments, exchange experiences,
and get answers co qucsrions. For example, the International Council on Systems
Engineering (I COSE), shown in Figure 1-27, is one of the leading organizations
offering ystems analysts a wealth of information, news, training, supporr communities, and more. Analysrs also maintain cheir skills by actending training courses, borh
I
~
E
-~-- ~ , -
. -- -
WHAT ts S¥SltMS CNGIN((llllNG1
L.. ,, • .ai.u1 1hit .._,..nr..e .......
r
.
'
GIOW IN SYSTCMS £NGINClllllHG
V..pe lh• •~Id en4 .tw..w-e ,_., C•t..-t
IMCOSl"S IMPACT
l•Mlf\& t~ rwtt.1.r• of 5"'i•m'
En1•1'\ff_rif'1g
)
rltOM me CUTIING lDGE
lll'lpeictfwl ,'9d«.b end Mat.... the--.,,,
nHO YOUA COMMliNIT't
ltwol"4 toc.ify •tit INCOS["" yow
,-~...-ch.
FIGURE 1-27 INCOSE Is one of the leading organizations offering systems analysts a w~lth of lnfonnation.
news. training. communities, and more.
.........""_.. ....-.................
_..__ ...................
("..,_..., llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ...............,..
__....
--
........... ......
o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I
Introduction to Systems Analysis and Design
I. 9 The Systems Analyst
30
on-site and online. Nerworking with colleagues is another way to keep up with new
developments, and membership in professional associations also is important.
COMMUNICATION SKILLS: A systems analyst need~ s rrong oral and written
communication ~kills and che ability to interact with people at all levels, from operational staff to senior executives. Often, the analyst must work with people outside
the company, such as sofrware and hardware vendors, customers, and government
official s. Analysts often coordinate IT project teams, where they use commumcation
skills co guide and motivate team members.
BUSINESS SKILLS: A systems analyst works closely with managers, supervisors, and
operational employees. To be effective, be or she must understand business operations
and processes, communicate clearly, and translate business needs into requirements
that can be understood by programmers and systems developers. A successful analyst
is business-oriented, curious, comfortable with financial cools, and able ro sec the big
picture. Chapter 2 describes some basic concepts, including strategic planning, SWOT
analysis, and feasibility tests.
CRITICAL THINKING SKILLS: Most educators agree that critical thinking skills
include Lhe abi lity co compare, classify, evaluate, recognize patcerns, an3 lyt.e cause and
effect, and apply logic. Critical thinkers often use a what-if approach, and they have
rhe ability to evaluate rheir own thinking and reasoning.
Critical thinking skills are valuable in the IT industry, where employers seek
job candidates who can demonstrate these skills and bring them to the workplace.
Figure 1-28 shows the website for Critical Thinking Community, a nonprofit
organization rhat provides encouragement and resources for critical thinkers.
Defining Critical Thinking
Cnmi.i tJ•li"tl....141 •-.U.., qfIM W<ll«t IO ... ,..q ofUH~
Cn~cel u.ntono,. a ncn conoept 1na1 ha been cM•alopng throughout the pat 2500 )'Mf'I. The !Mm "cnbelf
thinking" ha• lb IOOls In the mid-late 20lll century. We olret here O'tet1apping o.flnillonl, lDgellle< wl1ich lorm
• IUbllantllle, lre"8Clladplinaly concel)Clon of Ctfticlal thinking
Crltlcal Thinking• Defined by llM -
Coundl tor Eacetlen. . In Cttu..1Thinking,1117
Aatalement by MlcllMi Sa1ven & Rlctlard Pa!A. ~ at 11>8 80> Annual ln.,,,.tlcnal C o n - on
en~ce1ri.n1c1no anc1 e - . i fWorm. s-1oe1.
Critical I~ Is 11>8 ~ualy disdc>lned proceM ol ~ and alclllul1y concec>CUallZJl'IO. applylng,
·~~and/or ..,.bating inl'o11118fiongalhatad Imm. otgane,.led by,~
1eftadlol1, IMIOllfng, ot ~ H •~IO belef and •clan. ln 1111 .......ry fotm , l
le on u n i - 01111 ;t• lt>at Itel-id oubj9ct dMelont doallly. 9CCUtaeY I" oclal<>ot
--18-.
--..Y. ••••""'· - - - g o o d -, do!#>. blMdth. IRI r--.
FIGURE 1-28 The Critical Thinking Community Is a nonprofit organlzadon that provides encouragement and
resources for critical thinkers.
Soun:.
(....,..... J:gi( . . . . .
0
..r
,~,..."'
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
31
1.9 The Systems Analyst
EDUCATION: Companies rypically require systems analysts to have a college degree
in information systems, compurer science. or business, and some IT experience usually
is required. For higher-level posirions, many companies require an advanced degree.
Sometimes, educarional requirements can be waived if a candidate has significant
experience, skills, or profcs~ional certifications.
1.9.3 Certification
~1any hardware and software companies offer certification for IT professionals.
Certification 'erifies that an individual demonstrated a certain level of knowledge and
skill on a standardized test. Certification is an excellent way for IT professionals to
learn new skills and gain recognition for their efforts. Although certification does not
guarantee competence or abtliry, many companies regard certification as an import·
ant credential for hiring or promotion. Certification is discussed in more detail in
Chapter 12.
In addition to traditional hardware and software certifications, some firms :.ire
exploring ways to assess critica l thinking skills, as shown in Figure 1-29. These ski lls
include perception, organization, analysis, problem solving, and decision making.
Whether or not form:.i l certification is involved, these skills are extremely valuable ro
IT professiona ls and the employers who hire thetin.
THINK Watson
-
-
,..,.. I
'nloU-
I - · I ... I - I c.ua
The Gold Standard Critical Thinking Test
•
menti
There ,. 1 ,.,....., wny IM W.tson·u.-r Ct1Ucal T1llnlOl!g Apprals&i ts w
mo.t w1c1r1y used tool for Wlecu,. creat manaeers aod de\'elopin& Min
!Hden: lt worb. ~In 1925. tod.y IM Watson-Glaser Is t"4! premier
tool for rvaluatlnt w a11ni1;.,. abtltty ~ l)<Ofess10N1ls.
.- =-- -.._________ _
---.-------------- -·
- ..==-----====---·--=:.------- ==-----· _, ------·--- --:::-----~-~"'"'=='--
':···~ii!!'
- ...----::---..--=---::.
·-
W
-..._~==--
:::-::::::::..~
-
-
r
.:-.:---a.:;::_:::
•
1111 _
•
ic,_
_., !!O>rt
ll>"ll\Jo'f Cn11<o!lv
-.>•uQln>""'°""'
• fllrecilcll JUOrttnt. ~ to1"""1. CNlllmtty, GPrMm io c;cpc •w» I "'°'9
• ~ '-ttary of UM tft Mlf'IJ'll. F' I '""* It, WICI ~r:iort
• c.r.i..t" '#ftl'I
IOCtty Md Pl"'O'll'''Y t-.i
ot•'-d'i,.
• °'4
.,.......,.,._flClfl It -ltfl~
. "*"
4
·--·
1bp Scat .. on W G twlp "odlCt
• _,......,. Ct1ttcll tfll"9 ... ltlfllty 1'1111 dldCD\ ll'IUi"I
CDtl • !?Br;~ t!!!ll p.tl\ utnWW;
"IM'I ""'-..,,,. C1'mla mt -.tth """"'twpxt. . ciptfon&
.... itudr. lill " ... " . . ret'WI\
•
l*'fca WWW l (at!W ,,...,, U'IC9 ~
kDfftl 1111 h ...... ~ ..,. ~
........
efW.tliDr't-GIM« ............ ..
F I GURE 1- 29 Employers lllce co hire people who can think logically and effectively.
Sourc.,.
lu
_
....-................. ..__ __.. ...................
("..,_...,llll!Ot ...... 1.--s .\) ....... ~ "->-"'Allf'W ~- ...............,.. o-....._ ...... _
.......,..""_..
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~----··----~~-.,.-"~
Chapter I
Introduction to Systems Analysis and Design
I. 9 The Systems Analyst
32
1.9.4 Career Opportunities
The demand for sysrems analyses is expected co remain srrong. Companies will
need S)'SCems analysrs co apply new informacion rechnology, and che explo!>ion in
e-commerce will fuel IT job growth. The sysrems analyse position is a challenging and
rewarding one that can lead to a cop managemenr posirion. \Vith an understanding
of technical and business issues, a sysrerns analyse has an unlimited horizon. ~!any
companies have presidents and senior managers who srarted in IT departments as
systems analysts.
The responsibiliries of a systems analyst at a small firm are different from those
ar a large corporarion. Working ar a small or large company is a marcer of personal
choice.
Firsr, do nor rely on job rides alone. Some positions are called sys rems
analysts bur involve only programming or rechnical support. In ocher cases, sysrcms
analyst responsibilirics a re found in positions rirled computer specialist, programmer,
programmer/analyse, sysrems designer, software engineer, and variou~ ochers. Be sure
rhc responsibi lities of the job are stated clearly when considering a position.
JOB TITLES:
COMPANY ORGANIZATION: Find our everything about the company and where
the IT department fits in the organizarion chart: Where are IT functions performed,
and by whom? A firm n1igbr have a central IT group bur decentralize the systems
development function. This situation sometimes occurs in large conglomerates, where
rhe parcnc company consolidates information char actually is developed and managed
at the subsidiary level.
COMPANY SIZE: A smaller firm migbr provide more variety. However, a larger com-
pany wirh scare-of-the-arr sysrems provides opportuniti~ for speciah.mrion. Alrhough
there mighr be more responsibiliry in a smaller company, rhe promorional opporrunines and financial rewards could be grearer in larger companies. Working as an independent consulraor is also an option. l\1aoy consuJring firms have been successful in
offering rheir services ro smaller business enterprises that do nor have the experrise co
handle systems development on their own.
SALARY, LOCATION,AND FUTURE GROWTH: Finally, consider salary, location,
and the company's prospecrs for future growth and success. Initial impre sions from
employment interviews with the company and its people are important. lvlosr importantly, review shore- and long-term goals very carefull y before deciding which position is most suirablc.
CORPORATE CULTURE: fn addition to having goals, methods, and information
systems requirements, every firm has an underlying corpo ra Lc culLure. A corpora re
culture is the set of beliefs, ru les, traditions, values, and attitudes char define a company a nd influence its way of doing business. To be successful, a systems ana l)1St must
understand rhc corporate culture and how it affects the way informarion is managed.
Companies sometimes include statements about corporate culrurc in rheir mission
sraremenrs, which are explained in Chapter 2.
A systems analyse must undersrand the firm's culture and find it comforrable. If
the company encourages personal growth and empowerment, work is much more
enjoyable. For example, consider the Salesforce corporare culture described in
Figure 1-30. A company like Salesforce is likely ro attract, rerain, and morivare the
besr and brighrest people. In fact, Salesforce ranked# I in Fortune's 21st annual list of
rhe country's grearesr places to wor k.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
33
1.9 The Systems Analyst
Our Salesforce culture.
M~..._Ol.At°*'"f/llMl. Wl..., . .Gllllft.....,,,Mll . . . . llf. . . ~~W ... ~ew---.9'11t......,,,_MfN•
..... Ow ....... ..w-.-ONflllM,,_.li a
IS ZW-
M,~Md ......... to~'ftlf"*--._
Our Ohana blazes trails
¥111>W artM•1' . . . . ,....,_ ....-:1MWOft.
9
,..., ................ ...._._..
~ · f~ LlMHMC*•
Our values connect and 1nsp1re us
Trust
_,..,,,,......_,.,.. ........
~
..................."
.....,.,. . _°"'ONN
............
lnnOlr.ltlOll
OJ<,t~r Sore@S.~
.....
0...---... ...-
,_.,. _..,,.. .,_DNA
Oii. :pl ,.. . . . . . .ra-
--·-
0wr weiw....,, w p I
~.,,,~.,.,
,,...,,.,.,., to_....
.. ......
...
__
... ......... .. .,..
Equo ty
~·,,.,.·-~·
MON ..... w' t' I Cl llNll worid
FIGURE 1-30 A corporate culture like Salesforce is likely to attract. retain. and motivate the best and
brightest people.
,_..,
1.9.5 Trends in Information Technology
Systems analysts need to rrack trends in information technology because technological changes affect business operations, career opponunities, and enterprise strategies.
Very few areas evolve as fast as information technology. Each year sees evolutionary
developments in current technology, such as faster processors, wider network bandwidth, and increased storage capabilities. Once in a while, a truly transformative
cbange occurs, such as the injection of artificial intelligence applications across the
enterprise o r a revolution in the basic tenets of computation with the nascent introduction of quantum computing.
Some of the key trends that are disrupting information tech11ology include agile
methods, artificial cloud computing, data science, mobile devices, service orientation,
and social medio networks. These trends can affect education and training needs, give
rise to new certifications, and open lucrative career opportunities.
Agile methods have a lready been discussed in this chapter and are covered in
more derail later in the book. The agile movement is a significant trend in information technology thot all systems analysts should follow. It scarred as a response to
the heavyweig ht process models ::ind was iniri:.tlly used for smaller teams, bur interest
in agile methods has grown to encompass almost all application areas and business
organizations.
Cloud computing is in many ways a rerum to the past: a model of shared computing and data storage resources accessed from remote clients, rather like the mainframe era. Howe,·er, cloud computing is different in that it offers virrualiled re~ources
that can grow to accommodate increased requirements as needed. It'~ abo different in
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I
Introduction to Systems Analysis and Design
I. 9 The Systems Analyst
34
that buying capaciry on demand from a thriving vendor marketplace can reduce the
capital co ts needed for in-house computing infrastructure. It also present<> addi tional
securiry needs to address.
If cloud computing represencs the computational aspect of processing, data ~ciencc
represents the data aspect. The world is producing more and more data at an
incredible rate. New cools and techniques are being developed to manage these large
datasets. Areas such as machine learning and predictive analyncs are expericncmg
tremendous growth as companies try to apply artificial intelligence techniques ro the
problem of big darn. As depicted in Figure L-3 I, many of the developments related
co big data arc driving trends in information technology-trends rhe S)'5tems analyst
must follow to stay current.
FIG U RE 1-3 1 Big data is driving many new developments 1n information ttthnology.
I ('<
~
Mobile devices and the app ecosystem that goe!> with them are a revolurionary
development in information technology. The shift of computing capabilities ro "the
edge" of rhe network has put unprecedented power in the hands of end users. Smartphones are rhe most common computing device on the planet, and ~ystems analysts
will need to know about the role of apps and the effect of the bring your own device
(BYOD) movement in the enterprise.
Traditionally, IT companies were identified as product-oriented or serviceoriented. Prod uct-o riented firms manufactured computers, routers, or microchips,
while service-oriented companies included consultants, vendors, software developers, and service providers. Today, those distinctions are gone. Most successful
IT companies offer a mix of products, services, and support. Value-added services
such as consulting, software, and technical support often are more profitable than
hardware sales.
Social media rides on some of the trends mentioned earlier, such as cloud
computing, darn science, mobile devices, and service orientation. 1lowever, social
media has had arguably the most profound influence on sociery. \'Vitness the popularity
of Facebook, with over 2 billion users worldwide. Companies tap into the power of
social media, coupled with location-aware apps, to create truly innovative solutions
that arc chnnging the face of information technology.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I Systems Planning
I. I0 Summa ry
You are enjoying your job as a summer intern in the IT department of a local company.
At lunch yesterday, several people were discussing ethical issues. You learned that some of
them belong to IT organizations that have ethical codes to guide members and set professional standards. For example. your supervisor belongs to the Association for Computing
Machinery (ACM), which has over 100,000 members from more than 100 countries and a
website at ocm.org.Your supervisor said that the ACM code of ethics is important to her
and would definitely influence her views. On the other hand, one of the senior programmers believes that his own personal standards would be sufficient to guide him if ethical
questions were to arise.
Because you are excited about your career as an IT professional, you decide to
visitACM's website to examine the code of ethics and make up your own mind.After
you do so, would you tend to agree more with your supervisor or with the senior
programmer!
I . I 0 SUMMARY
Information technolog)' (IT) refers to the combina tion of ha rdware, software, and
services rhat people use to manage, communicate, and share informarion. Technology
is changing rapidly, and IT professionals must prepare for the future. IT suppor~
business operations, improves productivitr, and helps managers make decisions.
Systems analysis and de 1gn is the process of developing information systems that
rransform data into useful information, and systems analysts are IT team member
who help plan, develop, and maintain information systems.
The essenrial components of an informarion system are hardware, software, data,
processes, and people. Hardware consists of everythi ng in the physical layer of the
informanon system. Sofrware consists of system software, which manages the hardware components, and application software, which supports day-to-day business
operations. Data is rhe raw material chat an information system transforms into useful information. Processes describe the tasks and functions char users, managers, and
IT staff members perform. People who interact with a system include users, from both
within and outside the company.
M ost s ucces~ful companies offer a mix of produces, technical and financia l
services, consulting, and customer support. A rapidly growing business category
is the Internet-dependent fi rm, which relies solely on Internet- based operations.
E-commerce includes business-to-consumer (B2C) sales, and business-to-busi ness
(B2B) transactions that use Internet-based digital marketplaces or private electro nic
data inte rchange (EDI) systems.
A systems analyst starts with a business profile, which is an overview of company
fu nctions, and then he or she creates a series of busi ness models that rep resent business processes, which describe specific tra nsactions, events, tasks, and results. Analysts use business process modeling rools to document complex operarions. Systems
analysts u e modeling, prototyping, and computer-aided systems engineering (CASE)
tools. Modeling produces a graphical representatio n of a concept or process, whereas
prototyping involves the creation of an early working model of the information or its
components.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
35
Chapter I
Introduction to Systems Analysis and Design
I. I0 Summary
36
Based on their functions and features, business information systems are identified
as enterprise computing systems, transaction processing systems, business support
systems, knowledge management systems, user productivity systems, digital a5sistants,
or systems integration. In most companies, significant overlap and integration exists
among the various types of information systems.
A typical organization structure includes top managers, middle manager5 and
knowledge workers, supervisors and team leaders, and operanonal employees. Top
managers develop strategic plans, which define an overall mission and goals. Middle
managers provide direction, resources, and feedback to supervisors and team leaders.
Knowledge workers include various professionals who function as support staff.
Supervisors and ceam leaders oversee operational employees. Each organi1arional
level has a different set of responsibi Ii ties a nd information needs.
Three popular system development approaches are structured analysis, which is a
tradi tional method that still is widely used, object-oriented analysis (0-0), which is a
more recent approach chat many analysts prefer, and agile methods, which include the
latest trends in software development.
Structured a nalysis uses a series of phases, called the systems development lLfe
cycle (SDLC) that usually is shown as a waterfall model. Structured a nal ysis uses a n
overall plan, similar to a blueprint for construc ting a building, so it is called a predicti ve approach. This method uses a set of process models co describe a system graphically and also addresses data o rganization and structure, relational database design,
and user inrerfacc issues.
Objecr-orienred anal ysis combines data and the processes that act on the data inro
things called objects chat represent people, things, transactions, and events. Objects
have characccrisrics, called properties, and built-in processes, called methods, and can
send information to ocher objects by using messages. Using an 0-0 programming
language, a programmer then writes the code that creates the objects. Object-oriented
methods usual!)' follow a series of analysis and design phases similar co the SDLC,
but the phases arc more interactive.
Agile methods are the newest development approach and anempt co develop a
system incrementally by building a series of prototypes and con5ranrly adjusting them
to user requirements. Agile methods typically use a spiral model, which reprcsenn, a
!>ertes of iteration , or revisions, based on user feedback. The repeated 1terauons produce a series of prototypes, which evolve into the finished system.
Regardless of the development stra tegy, people, tasks, timetables, and costs must
be managed effectively using project management tools and techniques, which are
described in derail in Chapter 3.
The IT department develops, mai11tains, and operates a company's information
systems. IT staff members provide technical support, including application development, systems suppo rt, user support, database administra tion, network administratio n, web support, and quality assurance. These functions overlap considerably and
often have different names in different companies.
In addition to technical knowledge, a systcn1s analyst must understand rhc business, chink critically, and commUI\icace effectively. Valuable credentials such as certifications arc available to systems analysts. A systems analyst's responsibilities depend
on a company's o rganization, size, and culture. Systems analysts need to consider salary, location, a nd future growth potential when making a career decision.
Some of the key trends in information technology include agile methods, artificial
cloud computing, data science, mobile devices, service orientation, and social media
networks.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
37
Key Terms
Ke y Te rms
agile method\ Sy\ttms de' clopmcnr methods char arrempr 10 de,·elop a sys1em incrementally by build·
ing a senc> of prOIOt) pes and cons13Jltly ad1usliog them to user requiremems. Rela1ed to ad.iptin•
methods.
app A soff\, are appltc.mon th.it runs on a mobtle dence. such as a smartphone or tablet.
applocat10n hftC)dt mana11cmcnt (ALM) Acrivitie\ 1ha1 co,·cr rhe entire SDLC, indudmg requ1remen1>,
dc"11n, de,•dnpmcnr, tc,nn11, and dcplopncnr and management of ~nftware appli~non\.
apphcaunn ,oftwarc Sofn.arc program\, such as email, word proc~'o", .,prcad,hecr-. and graphic'
packages. u..ed hy emplo)'ce<. in rypica I office o;cenarios.
artificial intelligence The atrempr co recreate narural inreUigence through software in machines.
B2B (busincss·to bu1ineu) A commercial exchange (e.g., producrs or services) bcn,een businesses, typi·
cally enabled by tlw lmernet or electronic means.
B2C (bu•it11.'\ \·to-co111umcr) A commercial exchange (e.g., produces or service,) between bu\inc\\eS and
con•umeri. conducted over the Internet.
hi11 d:ll,\ F.xircmcly laq.\c datnsct\ (c.11., pctahytcs) requiring no ntraditiona l ~ppruache, to deal wi th
them. Snmcrime\ chnracrcri1.cd hy three term<: volume, variety, and velocity.
bring your own de, ice (B\'Ol>) An equipmenr managemenr model where employees arc in charge of
their devices (e.g .. computers, 1ablets, smartphones) ac work, noc 1he lT deparrmcm. Tlus includes
device selecuon Jnd Sl'lup. progum installation and updating. and network connecti' ity (indudmg
security).
busineu model A graphica l representauou of business functions that consist of busin~s processes, such
.1s s.iles, .1ccoun11ng, and purch.1S1ng.
hu'1nC\\ prncc" A dC'lc,.iprion of •pecific event<, ra<ks, and dc<ircd rc<ult<.
bu,inc" pr!ICC\\ model RPM ) A graphical reprco;enratiun of one or more bu<inc" procc,'>C<.
businC'ls proce<< modeling no1a11on (BPM:-:) A srandard sec of shapes and symhols used to repr~nt
e\ enrs. processes. and work flows m computer-based modeling cools.
business profile A definition of a company's overall functions, processes, organiunon, product>, servic~. customer.. >upphtrs, compernon., constramt>, .md furure drrecuoo.
bu,ine<,\ rule\ How a » •tcm handle> data and produces U5Cful informauon. Busincs;, rule\, al;o ~allcd
hu>incs' logic, rcflcct the operational requirements of the busincs>. Fxamplc, 1ndudc adding the
proper amount of <ale< tax m invoices, calculating customer balances and finance charge<, and dc1cr·
mining whether a c:usmmcr is eligihlc for a ,·olume-ba\Cd discounr.
bu\ine-.\ \upport \Y\IClll\ Provide job-related informarion support co user< at all lt'vel\ of a company.
CASE 1ools Powerful software used in computer-aided S)'Stems engineering (CASE) ro help systems ana·
l)'St> develop Jnd mamrn in information S)''tetus.
certificauon A credenii.11 Jn individual earns by demonstrating a certam level of knowll'dge .ind skill on
a sta11dard1ted tcsr.
das~ A term u\cd 111 object-oriented modeling to indicate a collection of ~iniilar objc"'·
computcr-a1dcd \Oftwarc cngmccring (CASE) A technique that use< powerful program< ca lled CA ~r.
tool< co provide an overal l framework for systems development. T he tools ~upport a wide varicry of
design methodologie,, including srrucnired analysis and objecr-orienced analysis. Also referred to a'
compmcr-aidcd ;y;1e1m engineering.
computer-.udcd >>Stem; cn111neet1nR 1CM.£) See compmer-aided software engmeermg (<..A~E).
wrporatc culture A >et of beliefs, rul~. 1radmons, \alues. and attitude~ that define J cornpau) and mflu·
em:e 1r< wa) of doing business.
~ JD» (".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_ ._.... ~~
...
. ..............
_ .... ~---11rt~
-,..~---~ ~
.... . _
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Chapter I
Introduction to Systems Analysis and Design
Key Terms
38
critical Lhinl.mg ~I.ill> The abilif} to compare, dassif), evaluJte, rccognne panem>. anal) Lt cause and
effect, and apply logic. Such skills are valued m the IT mdusrry.
dat.t The ra\\ m.11erial or basic facts used by informauon S) stem>.
d.ua center A !Jrgc ton~cntrarion of ncrworkcd computer' working together.
data no\\ d1a11ram (Df D) Graphical rcprC\cnlation of the \)>Lem, \hem mg II \tore\, prnu:"e', and tran>form' Jara mm u-cful information.
data ~ocnce lnrerd1~1pltnary field rhar blends computer science, math and stausucs, and bu~iness merhods 10 anal)'Zc large darasers. Involves artificial imelligcnce. machinc learning .ind prcdicn"c analytics,
and v1sualitation techniques.
Jell\ crabl~ A polished, fu1al product, suitable for its intended use. £nd product> or del1verJbles often
cornc1de wnh the complenon of each SDLC phase.
e·commcf(C tclccironic conuncrcc) Transactions (e.g., buying anti ,cllinµ of l\(X>U\ and onfnrmaunn) that
c><:cur on the Internet. Includes both businc~-to-consuoncr and bu,ine.-· to· l)l1'inc,s.
clcc1ronic dnra inrcrchanJle (FDT) A process that involve' computer-co-computer transfer of darn
bcrwccn companies.
cmpo"ermcnt A business prnccice chac places more responsibility and ,1ccoumuhiht) rhrougbour all levels of .Ill org.mizaliou.
enterprise applic.mons Comp.tn)·wide applications, such as order processwg systems. pJyroll systems,
Jnd compJn) communicanons networks.
c:nterpri\c rnmpurini: Information 'YMcms char >t1pport lompany-w1Je data ma11a11emcnt requirement\,
,uch a• airline rc<;crvanon' or credit card billing sy.tcms.
cntcrpri\e re\our'c planning (FRP A process that cstablishc, an cnccrpri-c-w1Je \trnrei:y for IT
rc,ourccs. FRP defines a <pecific archirccrure, including ''andard< for data, procc,,ini;. network, and
u-er imcrfol-C d<'\1gn.
fcasibilm study An mmal in\'esrig;uion to clearly identify the n.uure and scope of the business opporrnmr) or problem. Also called preluninary 1.Dvestigauon.
groupn.ire J>r~ams thar run on a necwork chat enable users to share data, collaborate on pro1«ts, and
work m teams. Also called workgroup sohware.
hardnarc The phy<ical layer of rhc information system, to include computer\, network\, communication< equopmenr, and orher rcchnolo&>y·hased infrastructure.
help dc\k A cenrrali1cd resource miffed by TT professionals that provide' U\Cr' with che \upporr rhey
need to do 1he1r job>. A help de>k h,.,., three main objel"tivc~: to ~how people: how to U\c ~y,ccm
re.uur~C> more dfc:ctivcly. to provide an~wcn. to 1,-chnical or opcrarion,11 quc.,1 io11~, and to make
user\ more productive by reaching rhcm how to mcer their own mformation need<.
horiiontal sy\Ccm A basic sysrcm, such as an inventory or payroll packap,e, that 1s commonly used by a
vnricry of companies.
inference rule' lnsrructions that direct a knowledge management sys1em ro idcmify data pat1crns and
rdanonsh1ps.
information Dnm rhar has been changed inro n useful form of outpur.
informauon S)\lcon A combination of infom1arion 1cdinology. people, and data co '>upport bminc~s
requirements. Ilic five key components a~e hardware. software, data, proccs.es, and people.
1nforma11on tcchnoloiiy (IT ) A combination of hardware, software, and telecommun1c.111on< S)>lem'i
that support business operations, improve producuvitl, and help manager\ make decisions.
intCjlr.ued dc\Clopmcnr environments (IDE) An application for hu1lding orhcr \Oft" .ire appli~tions.
T)·picall> includes a visual code editor, an integrated compiler, a debugger. a configuration manageme111 ~)Mem, and a rest framework.
~ JD» (".............. .-\l ........... .,.... _.,."'flllll.~-....-.. - "*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_ ._.... ~~
...
. ..............
_ .... ~---11rt~
-,..~---~ ~
.... . _
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Phase I
Systems Planning
39
Key Terms
i1aa1ht: An ;idapme method I) pictll) use,, a spiral de,·elopmenr model, which builds on J series of
ncrauoru..
I.no\\ ledge b.i\c A popular ws1cm\ dn·elopmem 1echnique that uses a group of ~r.. man.igcr~. and IT
profc:,~1onal\ who work t<>gc1hcr to gather mformanon, <l~u~ bu~mess need>, and define the new
\y~rcm rcqu1rcment'\.
lcitaq. '}"tern An older 'l)'\tcm rhat is rypically less rechnologically advanced than currcnrly available 'Y'rcm\.
machine learning An application of compurer science and anifkial intelligence thar uses automattd
approaches 10 pattern recognition and predictive analytics based on large darJsets.
management informauon ~)>tern (MlS) A computer-based information system used in business plJnnmg,
control, decision making, and problem solvmg.
mi"ion-criuul \)'\lcm An information 'Y'tcm rhar i> vital to a company'~ upt:rauons.
mc>dt:l-ha,cd 'Y'lcm' c1111incc1 ing (MBSE) An approach to ,,.ystcm' engineering that relit' on doma111
models, rather than rrnd inona l documcn r., to dc<ii;n la rg:e·,calc <rtcm' and convey information
hctwccn cnginee rs.
modeling J\ process th,11 produces a graphical representacion of a concept or process tbtlt systems developers can analy tc, test. a nd modify.
Moore's l.i" A prediction 1h,11 compuring power would double every 18 to 24 months due 10 wcreJsed
nuui.1rurw11011 of elecrron1c components.
NoSQl. dataha\c) Da1.1ba"' 'y>tcrn' that use a flat, nonrabular (nonrdarional) \lrULlur" 10 'tore :ind
procc" largc-..calc da ra,cr\.
objc.:t In obJl-Ct-oricntcd analy<;i• or programming, an object rcprcscnr- a real pcrwn, place, event, or
rra0\act1on.
objcct-oritntcd 0-0J ;inal~s1s The act of understanding an information S)Stem b) rdenufymg things
c.tlled ob1m~. An ob1ec1 represents a real person, place, event. or transaction. Obiecr-onemed analysis
~ .i popul.u .1ppro.1ch 1h.1r ;ees .i S)>tem Crom the viewpoint of the obiect> tbetrueh cs .I) the> funcuon
and interact wuh the sysrem.
personal d1g11al assistant A progr.im rhat responds rouser requesrs through a natural interface, such as
regular speech, to provide assmancc to general-purpose queries. Often embedded m devices such JS
lmemet<Onnl'Cted )peaJ..ers and smarrphones.
prdiminal} imc\Ugaunn 1\n cnirial analy)is ro de:trly idenri fy the narure and scope of the hu,ine,~
opponumty or problem. /\l'o called fca>ibility >tUd).
procl~\ PrQ\cuore or ta'k 1ha1 user>, managers, and IT sraff member) perform. Al;o, the logkal rules
of a 'Y'tcm that arc applied m rran5fonn dara mro meaningfu l infom1anon. ln data Aow diagram5, a
pmce'~ receives input darn and produces nurput tha r has a d ifferent content, form, o r hoch.
produc1 lifccycle management (Pl .M) See application lifocycle management (A LM.).
product oriented Comp,mie~ that manu facture computers, routecs, or microchips.
projccc management The proccs5 of planning, scheduling, mo ni roring, conrrolling, a nd reporting upon
the development of nn informarion sys1cm .
propcrtic' In oh1t.'Ct·o riemcd (0·0) analysis, characteristics rha t objects inherit from their da>S or po~­
>css on their own.
prototH>C An c.1rly, rJp1dl) constructed workmg version of the proposed uuorm.ition >y>tcm.
radio frequency idcnt1fic.111on (RI Ill) Technology rh.~r uses high-frequency radio waves to tr.1ck physical
ob1c•·ts.
requirement\ en11mccring Used m the systems planning phase of the SDLC. It invoh·cs using various
focr-finding techniques, such as interviews, 5urvers, observation, and samplmg, ro d~nt>c the current
system and ident1f) the requ1rcmcni> for the new sysrem.
~ JD» (".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_ ._.... ~~
...
. ..............
_ .... ~---11rt~
-,..~---~ ~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Chapter I
Introduction to Systems Analysis and Design
Key Terms
40
SL-.alablc Ille abihry of a S)»tem to expand ro meer new business requirements and 'olumes.
;en ice-oriented A comp:my that primarilr offers information or o,erviu:·~ or .,.,11, i;0<xh produced b}
other\.
\ofc"arc A proi;ram run h)· computer. for a >pec1Fic functmn or ta.>k.
>p1r.tl modd A developmem modd wub a series of iterations. or rev1s1oos. ba.cd on user feedback.
s1akcholdu An)·one who 1s affected by cbe companr's performance, sud1 as customers. emplO)'ttS, suppliers. srockholdcrs. and members of the comrnuruty.
\tratt111c plan' The loni;-rani;c plans thar define t he corporate mis,ion and goal\. Typically defined by
top manni;cmcnt, with inpuc from all le,·els.
\trucmrcd anal)~;, A trndirional sysrems developmenr cechnique that U'>e'> phase; ro plan, analpc,
de,ii;n, 1mplemenr, and \ uppon on information sysrem. Proces•es and cla1a Jrc treated a' scpara1t
component•.
supply cb.un A rradm on,11 systems developmenr ceduuque th.ir uses phases to pl.111, analyze, design,
implenienr. and supporr ;rn information sysrem. Processes and data .ire treated as scp.iratc
componcn1s.
suppl> chain management (SCM! The coordination. integracion, and man,1gemenr of ma terials, infor·
ma11on. and finances as they move from suppliers to customers, both w1dun and between comparues. In a rornlly 1megr.1ted supply chain, J. customer order could CJ use J production planrung
system to schedule a work order, which in rum could mgger a call for certam pJrtS from one or
more suppliers.
\)'tern \ o;et of related componcnrs thac produces specific re~uJt.,.
')\tern dc-.1gn 'fl"ofic:uion A document that preo;encs the complece design for the new information'>"'tem, along with derailed ccMs, ~mffing, and scheduling for completing chc next SDL.C pha\c, \)\tern<.
implemcm.atson. Also called the technical d~'h'" \pc<:1fo:at1un ur the dct:ulcd de,1i;n 'pcc1fica11on.
>)>tCm requirement> document A docwnent !hat conram> the reqwremelll> for the new S) >tern. describes
the .iltern.im ts th.ii were considered, and makes a specific r«ommend.mon to mana~ement. It 1s the
end product of the systems aoal)·s1s phase.
S}Stcm softwa re Programs that control the comp uter, including chc opcranng sysrcm. de' ice drive~ that
commumca1e \~uh hardware, and lo"·level utilities.
\)>IClll\ anal)\I\ and dcsii;n The process of developing information sy\rems that eff1.-crively uo;e hard-
ware, wftware, data. proces~cs, and people to support the cumpany'; bussn""' obje... uvc,.
');tcm\ anal)\i\ pha\c The >ewnd SDLC phase. The purpose of this ph.i;e I> to build a log"a l model of
rhc new sr,rcm.
systems anal) st A person who pla ns, analyzes, and implemcnrs mformanon systems. T hey 111.1y work
im crnall y within a compan) 's IT department o r be hired b) a company as an independent consultant.
~>SICm\ design pha~c The third SDLC phase. Thie purpose of syotems design is to creme a bl ueprint for
the new S)'\tem that will sacisfy all documented requirements, whether the syMem is being developed
in-how.e or purchased os a package.
~)>lcm; Jc•cloprncnt life C)dc (SDI C) Activiti~ and fum:rions that ;ystcm> developers t)pically per·
form, rci;a rdlc's of how t ho•c acnvirics a nd foncrions fit mro a partku lar mcthodolofly. The SD I C
model include~ five phaws: ( I) sysccms planning, (2) systems analysis, Pl sy\tcms dcsifln, (4) sy,tcms
implementation, and (5) systems support and securiry.
')\!Cm' implcmcntauon phase The fourth phase of the SDLC. During this pha;c, the ne'~ &)Stem is con·
sm1ctcd-pr~rams arc wmtcn, tested, and documented, and the ;ystcm is ms1,1llcd.
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
...............
_ .... ~---11rt~
-,..~---~ ~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Phase I
Systems Planning
41
Key Terms
S}Stcms pbnntng pha~c lhc first phase of the SDLC. During this phase, che S)>tems prOJl'Ct get> starred.
rhc proic.:t propo•.il is C\,ilu.ued to determine its fea.ibility. lhe project managemem pl.in 1s formu-
1.itcd, w11h the help of <...ASL rooh where appropnatc.
~}~tcm• requc\t
A form~! rcquc\t to the IT department that describe~ problem' or dc\ircd .:hangc\ tn an
information \)'\tcm or bu\inc\s process. It might propose enhancements for an cxi~nng >)'Stem, the
correctmn of problem,, or the development of an entirely new S)"'item.
rr
\}~ICm\ \uppon and ~Cl'Urit) pha,c During the sysrems support and !>CCUriry pha..e of the SDLC, the
\laff maintain\, cnhan.:o:\, and protect' the .,y;rcm.
techni,aJ support Tcchmcal supporr is neces>ar)' ro supporr che wide \Jtiet) of 11 S)Stellli .ind u>ers. lt
mdudes six mam funcuons: applicanon developmenr, systems support, user support, d.11JbJse .1dmtnis1ra11on, nttwork admin1strarion, and web support. These functions ovcrl.ip cons1dr.rably and often
have diffcrrnr names 111 different companies.
transaction proccssiog !Tl') S)'Stcnt~ Operational systems used co process day-10-day recurnng business
cransacuons, such as cusromer billing.
u.,..,r produl!i' ity '}'lcnh Applkation' 1hm provide employet:s of :ill levch n wide array of tool, to
improve jnh performance. Fxamplc' indudc email, word prcx:c,;in11, graphic~, nnd comp.111y inrrnncc-.
met\ 'irakcholdcr- in,idc and out~idc the company who wil I mrc:ract with the 'YMcm.
vertical S}SlCUI A S)'Srem designed to meet the unique requirements of a spectf1c busmess or mdustry,
such as a wtb-based retailer or nuro-supplr srore.
warcrfall model The tradmonal model of soft\vare de,·elopmenr. A graph that depicts the result of each
5DLC phase £lowing do,~o mto the nei.r phase.
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
...............
_ .... ~---11rt~
-,..~---~ ~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Chapter I
Introduction to Systems Analysis and Design
Exercises
42
Exercises
Questions
1. Whac is information rechnology, and why is it imporranr co socicry?
2. What are the five main components of an information S)'Stem?
3. Explain how ndcsharing services such as Uber and Lyft are disrupting rradir1onal raxicab business
models.
4. Describe the busine~s profile of a home improvemenr srore like Home Depot or Lowe's and how it i~
used.
5. What are the seven types of information systems used in business?
6. What cypes of informacion do the four organizational levels common ro many businesses need?
7. Compare three sysrems dcvelopmenr merhods.
8. Name rhe too ls rhar enable che sysccms analyst to deve lop, manage, and maintain large-sca le informa·
tion systems.
9. Sumrn:irizc the seven main functions of rhe IT department.
I 0. Whar arc the ro les and respons ibilities of a sysrems analysr in a modern business?
Discussion Topics
1. Some experts believe rhar rhc growrh in e-commerce will cause states and local governments ro lose
rax revenue, unless lmcrner transactions are subject ro sales rax. Whar is one argument rhar supports
this view and one rhar opposes ir?
2. When team memberl> .ire geographically dispersed, communication bccomcl> more challenging.
Explain how groupware can increase user producrivicy in chis contexc.
3. Under whac circumsrances should a systems analyse recommend an agile merhodology over Struccurcd
devclopmenr or ob1ecr-orienced analysis?
4. Should che IT dirccror reporc co che company presidenc or somewhere else? Does it marrer?
5. Rapid advancements in areas such as machine learning and predictive analycics in dara science are
affecting the daily operarions of many IT deparnnenrs. What should a syscems analyst do ro stay
currenr?
Project s
1. Contact three people ac your school who use informacion systems. Lise cheir positions, the mformacion
they need, the sysrems they use, and the business functions they perform.
2. Visir rhree websites ro learn more about agile system deve lopment. Prepare a lisr of the sires you visited and a ~ummary of the results.
3. Model-based systems engineering (MBSE) is one of che leading methods used by systems ana lyses to
develop informarion systems. Cameo Systems Modeler is one of the leading cools supporting MBSE.
Research magazine articles and the web ro learn more about th is tool's capabi lities. Identify three of
its srrengrhs in terms of improving rhe qualiry of the finished product.
4. Explore the Critical Thinking Community website ac criticalthinki11g.org. Identify three importanr
topic~ currencly being di~cussed and describe your findings.
5. Compare the corporate culrure of three leading IT companies and show how rheir ~tarement of values
could atcracr (or repel ) sysrems analysts from joining their organization.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
~ JIJ»C....... ~ Al RlilfD
~ ... _
l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.: ......,_ . . . ,_.,~-.lit .......... .._.,._.__..,~•\
. . . _ . .... ..., ~...,.._,_..,..., J\&."9 ... --.11 ......... ~ C'dptl"~~d.tt ...... -
............ -
..... -
..........
-.-.....w--...-.11
Chapter 2 Analyzing the Business Case
Analyzing the
Business Case
Chapter 2 explains how to analyze a business case.This
chapter also explains why it is Important to understand
business operations and requirements, how IT projects
support a company's overall strategic plan, how systems
projects get started, and how systems analysts conduct
a feasibility study and perform preliminary investigations, which concludes with a report to management.
Fact-finding techniques that begin at this point and carry
over into later development phases are also described.
The chapter includes three "Case in Point"
discussion questions to help contextualize the concepts
described in the text. The "Question of Ethics" asks the
systems analyst to consider the Implications of granting
preferential treatment to a system enhancement
request when the request originates with a friend of the
project's manager.
LEARNING OB ECTIVES
Wl1e11 you fi11isb this d1apter, you s/Jould be able
to:
CONTENTS
I . Describe the strategic planning process.
2. Conduct a SWOT analysis.
3. Explam how cools can support strategic
planning.
4. Explain the concept of a business case.
5. Summarize the ~ix main rea~ons for systems
requests.
6. Describe the two factors affecting systems
projects.
7. Explain how systems requests are processed.
8. Explain how systems request feasibility is
assessed.
2. 1 Strategic Planning
Case in Point 2. 1: Pets for Rent
2.2 Strategic Planning Tools
2 .3 The Business Case
2 .4 Systems Requests
2 .5 Factors Affecting Systems Projects
2 .6 Processing Systems Reque~cs
Case in Point 2.2: Actaway Airlines, Part One
2 .7 Assessing Request Feasibility
2 .8 Setting Priorities
Case in Point 2.3: Arra way Airlines, Parr Two
2 .9 The Preliminary Investigation
A Question of Ethics
2 . 10 Summary
Key Term~
Exercises
9. Explain how systems requests arc prioritized.
I 0. Conduct a preliminary invesrigarion.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,...... 111>_... ........ _ .. ~ ........................._ .... ._
Phase I
Systems Planning
2.1 Strategic Planning
2 I
45
STRATEGIC PLANNING
Strategic planning is the process of identifying long-term organizational goals, strategies, and resources. A strategic plan looks beyond day-to-day activities and focuses on
a horizon that is three, five, ten, or more years in the forure. The IT ream must deliver
IT resources ro support the firm's long-term strategic goals. Therefore, IT managers
and systems analysts must understand and participate in strategic planning acriviries.
IT managers ha\'e ro prepare for long-range needs, such as a new darn warehouse,
even as they handle immediate problems, such as a logic bug in the payroll system. In
mosr companies, the IT ream reviews each IT-rela ted proposal, project, and systems
request ro determine if it presents a strong business case, or justification.
T he following sections provide an overview o f strategic planning, a description of
SWOT analysis, and a look at the role of the IT d epartment.
2. 1. 1 Strate gic Planning Ove rview
Strategic plan ning starts with a missio n ~tatemen t that reflects rhe firm's vision, purpose, and v:ilues. Mission statements usually focus o n lo ng-term cha llenges and goa ls,
the importance of the firm's stakeholders, :rn d a commitment to the fi rm's ro le as a
corporate citizen. For example, Google's mission statement posted on their website is
stated succinctly as," ... to organize the world's information and make it universally
accessible and useful."
\Vi ch the mission statement as a backdrop, a f'irm develops short-ter m goals and
objectives. For example, the company might establish one-year, three-year, and fiveyear goals for expanding market share. To achieve those goals, the company might
develop a list of shorter-term objecrives. lf it wants to increase online orders by
30% next year, a company might sec quarterly objectives with monthly milestones.
High-priority objectives arc called crirical success factors. A critical success facto r is
one that must be achie\'ed to fulfill the company's mission.
Objccti\•cs also might include tactical plans, such as creating a new website and
training a special customer support group to answer email inquiries. Finally, the objectives translate into day-to-day business operations, supported by IT and other corporate
resources. The outcome is a sec of business resulcs thar affect company stakeholders.
Pets for Rent is an innovative company that brings puppies to corporate meetings.
The company's CEO says that having puppies in a room with employees in an informal setting
helps break down communication barriers and fosters. a greater sense of teamwork and comradery. Since this is a new company, the CEO has asked you if a mission statement is necessary.
After you review the chapter material, write a brief memo with your views. Be sure to include
good (and not-so-good) examples of actual mission statements that you find on the web.
2. 1.2 SWOT Analysis
The letters SWOT stand for st rengths, weaknesses, opportunities, and threats. A SWOT a na lysis can focus
on a specific product or project, an operating division, the entire company, or the mission statement itself.
The overall aim is to avoid seeking goals that are unrealistic, unprofitable, or unachievable.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Chapter 2 Analyzing the Business Case
2.1 Strategic Planning
46
An enterprise SWOT analysis us ually begins with these questions:
•
•
•
•
What are our strengths, and how can we use them to achieve our business goals?
What are our weaknesses, and how can we reduce or eliminate chem?
\'Qhac arc our opportunities, aod how do we plan ro rake advanragc of them?
\'Qhat are our threats, and ho\V can we assess, manage, and respond m the possible risks?
STRENGTHS
A SWOT analysis examines a
firm's technical, human, and financial resources. In Figure 2-1, the
butlered lists show samples of rypical
strengths, wca kncsscs, opportu nities,
and threats for an organization considering cxp:tnding their web-based
online operations.
As the SWOT process conrinues, management reviews specific
resources, business operations, and
valm1blc assets. For example, suppose
rhat the company owns an imporranr
patent. A SWOT review for rhe parent
might resemble Figure 2-2.
There is no srandard approach to
WEAKNESSES
• Excellent web design staff
• low systems analyst
• Still using 58\/eral legacy
turnover
• Recently upgraded notwork
• Budget Increase was turned
down
• Documentation needs updaUng
OPPORTUNmES
THREATS
• Well-pos1Uoned for expansion
• Can be first with new
software
• High potenbal tor B2B
growth
• Aggressiv e new web
competition
systems
• Impact ol new FCC rules
strategic planning. Some managers
• Other firms oller bener
benefits
believe that a firm's mi sion sratement !.hould contain an inspirational
message to its stakeholders. Others
feel that unless a firm starts with a
FIGURE 2 - 1 A SWOT analysis might produce l"e$Ults similar to those
realistic SWOT assessment, ic might
shown here.
develop a mission statement that is
unachievable. Most companies view
the strategic planning process as a dynamic iorcraction, where the company's mission
statement reflects a long-term horizon, but sets forch goals that arc achievable and
consistent with real-world conditions.
2. 1.3 The Ro le of the IT De partme nt
A systems analyst should be interested in strategic planning because it reflects a
higher level of involvement in supporring the direcrion of rhe project. For example,
while working on rhe same project, one analyst might say, "I am using a CASE cool,"
while another might say, "I am helping the company succeed in a major new business
venture." Systems ana lysts should focus on the larger, strategic role of the IT department even as they carry out their day-to-da y technical tasks.
Experienced analysts know that planning is essentia l for IT project success, and it
must srarr as early as possible. Ca reful planning can help assure chat:
• The proiect supports overall business strategy and operarional needs.
• The project scope is well defined and clearly stated.
• The project goals are realistic, achievable, and tied ro specific statements,
assumptions, constraints, factors, and other inpucs.
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
47
2.3 The Business Case
SWOT Analysis of a Corporate Patent
During the planning process, management and IT should be closely linked. In
the past, a typical IT department handled
Strengths
Weaknesses
all aspects of systems development and
• Our patent has a hmrted Me
• Our patent covers valuable
consulted uc;er~ only when, and if, the
Whetl 11 expires. the technology
technology that we can use in
depamnent wanted user input. Today,
will no longer be prot8C1ed
popular products
systems development 1c; much more
team-onenred. New approaches to systems
Patent
development, such as agile methods,
typically involve groups of users, managers,
Opportunities
Threats
and IT staff working together right from
• We can use the technology on
• A compehtor might develop
the start of the project.
more products, license 11 to
similar technology thal does
Although ream-oriented development
others, or seek more patents.
not legally lnfnnge our patent.
is the norm, some companies still sec the
role of the IT department as a gatekeeper,
responsible for screening and evaluating
FIGURE 2-2 This SWOT analysis example focuses on a specific asset: a
systems requests. Should the IT department
company patent.
perform the initial evaluation, or shouJd
a cross-functional team do it? The answer
probably depends on rhc company's size, the nature of the system request, and the
scale of the project. For example, in smaller companies or firms where only one person has IT skills, that person acts as a coordinator and consults closely with users and
managers to evaluate systems requests. Larger firms are more likely to use an cvaluarion team or a srsrems review committee.
2 2 STqATEGIC PLAl'INING TOOLS
Irrespective of the development strategy used, many organizations still rely on the IT
group to provide guidance when it comes to selecting tools to support strategic planning activities. Some analyses srick to tradicional text-based methods, using tvl icrosofc
\'(lord rabies, to pro,•ide srrucrure and clarity. Ochers prefer a spreadsheet, such as
t..1icrosoft Excel, because it is easy to display prioriries and the relative importance of
planning assumptions.
A more sophisticated approach is co use a CASE tool to define and document the
overall environment. Such tools can integrate various statements, entities, data elemencs, and graphical models into an overall structure. The result is more consistency,
better quality, and much less effort for the system analyst. Figure 2-3 shows a cloudbased road mapping software product from Aha! chat provides inccgraced support for
product scracegy visioning and strategy develop1nent.
There arc other strategic planning "cools" that are not CASE tools, bur more techniques that ore sometimes supported by software programs. For example, mind maps,
balanced scorecards, and gap analysis are all valuable techniques thac can be parr of strategic planning in an organizarion. An imporrant role for the systems ana lyst is to know
when each of these rools and cechniques can best be used in particular project conwxcs.
2.3 THE BUSINESS CASE
During the systems planning phase, the IT ream reviews a request co determine if
it presents a strong businesc; case. The term business case refers co the reasons, or
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 2 Analyzing the Business Case
2.3 The Business Case
48
Ahal - - _, -
_,, .....
- -0
-
Strategy first
-- -
.. ...,............. .,,... ... .......... I"'
....
· -~--
-
....-.;,~
-=---
·- - .--
••• • •
=
-
. ._..,_,
............
_.,.
..........
.,_, ..
,_
~
-.. ....
--
...,., -"«.,...
.,............, ......
c.....
FIGURE 2-l Aha! provides Integrated support for product strategy visioning.
·~• .&.1\. 1
,_
jusrificarion, for a proposal. To perform rhe review, the analysr muse consider rhe
company's overall mission, objectives, and IT needs.
A business case shouJd be comprehensive yet easy to understand. It should
describe rhe project clearly, provide the juscificarioa to proceed, and estimate the project's financial impact. SpecificaUy, che business case should answer questions such as
the following:
•
Why are we doing this project?
•
What is the project about?
•
How docs this solution address key business issues?
•
•
I low much will it cost and how long will it rake?
Will we suffer a productivity loss during the transition?
•
What is the return OJl investment and payback period?
•
What arc the risks of doing rhe project? What are the risks of nor doing the
projccr?
•
How will we measure success?
•
What alternatives exist?
Examples of business cases, borh good and bad, can be found on line. Just search
for "sample business case" and examine the structure and content of some of rhe samples available. It is particularly instructive to compare and contrast business cases for
different areas, such as chose for go\•emmenr contracts versus private enterprises.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
49
2.4 Systems Requests
2.4 SYSTEMS REQUESTS
Stronger
The starting point for most information
systems projects is called a systems request,
which is a formal way of asking for IT
support. A srsrems requesr might propose
enhancements for an existing system, the
correction of problems, the replacemenr
of an older sy rem, or rhe developmenr of
an enrirel)• new informarion sysrem char is
needed ro support a company's cur renr and
future busine s need .
As Figure 2-4 shows, rhe six main reasons
for ~ystems request are stronger controls,
reduced cost, more information, bener performance, improved service to customers, and
more support for new produces and services.
STRONGER CONTROLS: A system must
Controls
Reduced
Cos1
More
Suppo<1
Systems
Request
Improved
Service
t/
More
_J
I
lnlormatt~
Better
Performance
J
FIGURE 2-4 Six main reasons for systems requests.
have effective controls to ensure that data
is secure and accurate. This is becoming
increasingly important given the number
of darn breaches that seem to occur on a
daily ba!.i . ome common securiry con-
trols include passwords, various levels
of user acces~, and encryption, or coding
data to keep it safe from unauthorized
users. l lardware-based security conrrols
include biometric devices that can identify
a person by a retina scan or b>• mapping
a fingerprint pattern. The technology uses
infrared scanners that create images with
thousands of measurements of personal
physical characteristics, as shown in
Figure 2-5, which displays Apple's Face ID
security mechanism on the iPhonc.
In addition to being secure, data also
must be accurate. Controls ~hou ld minimize data entry errors whenever possible.
For example, if a user enters an invalid
FIGURE 2-5 Apple Face ID uses advanced machine leamirig co recognize users.
customer number, the order processing
system should reject the entry immediately and prompt the user to enter a valid
number. Darn entry controls must be effective without being excessive. If a !.)'Stem
requires users to confirm every item with an "Are you sure? YIN" message, internal
users and customers might complain that the system is not user-friendly.
REDUCED COST: The current system could be expensive ro operate or maintain
as a result of rechnical problems, design weaknesses, or the changing demands of che
busine s. Ir might be possible to adapr the system co newer technology or upgrade
it. On the other hand, cost-benefit analysis might show that a new system would be
more cost effective and provide bener supporr for long-term objectives.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 2 Analyzing the Business Case
so
2.5 Factors Affecting Systems Projects
MORE INFORMATION: The syscem mighc produce informacion char is insuf-
ficienc, incomple re, or unable ro supporc the company's changing informarion
needs. For example, a syscem chat tracks customer orders mighr nor be capable of
analy1.1ng and predicring marketing rrends. In the face of intense compericion and
rapid product development cycles, managers need the best po~s1ble informacion
to make major decisions on planning, designing, and marketing new products and
services.
BETTER PERFORMANCE: The current system mjght not meec performance require-
mencs. For example, ic n1ighc respond slowly co data inquiries at certain times, or it
mighc be unable co support company growth. Performance limicarions also result
when a system that was designed for a specific hardware configuration becomes
obsolete when new hardware is introduced.
IMPROVED SERVICE: Systems requests often are aimed ac improving service ro cus-
tomers or users within the company. For instance, allowing mutual fund investors ro
check their acco unt balances on a website, storing data on rental car customer preferences, or creating an online college registration system arc all examples of providing
valuable services and increased cusromer satisfaction.
MORE SUPPORT FOR NEW PRODUCTS AND SERVICES: New products and
services often require new types or levels of IT supporc. For example, a sofrware
vendor might offer an a utomacic upgrade service for subscribers; or a package delivery company might add a special service for RFID-tagged shipment!>. In situations like
rhe!>e, it is most likely that addjtional IT support will be required. At the other end of
the speetrum, product obsolescence can also be an important factor in IT planning. As
new products enter the marketplace, vendors often announce that they will no longer
provide support for older versions. A lack of vendor support would be an important
consideracion in deciding whether or not to upgrade.
2.5 f ACTORS AFFECTING SYSTEMS PROJECTS
internal and external factors affecc every business decision that a company makes,
and IT projects are no exception. Figure 2-6 shows internal and external factors that
shape corporate IT choices.
2.S. I Internal Factors
Internal focrors include the strategic plan, top managers, user requests, information
technology deparcment, existing systems and data, and company finances.
STRATEGIC PLAN: A company's srrategic plan sets the overall direction for the
firm and has an importa nt impact on IT projects. Company goals and objectives rhat
need IT support will generate sysrems requests and influence IT priorities. A strategic
plan that stresses technology rends to create a favorable climate for IT projects that
extends throughout the organization.
TOP MANAGERS: Because significant resources arc required, top management usu-
ally initiates large-scale projects. Those decisions often result from strategic business
goals that require new IT systems, more information for decision making processes,
or better supporr for mission-critical information systems.
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, ..,...,.......,..~
r..a...w...,..._...., ..
Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
.................,.t11ru ..
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
51
2.5 Factors Affecting Systems Projects
External Fact ors
Lr------...
Teclinology
l..__ _ _ _~J
Suppliers
Government
The Economy
l.
------
Custome~
Competitors
JL- - - - - -
FIGURE 2·6 Internal and CKternal factors that affect IT projecrs.
As users rely more heavily on information systems to perform
their jobs, they arc likely to request even more IT services and support. For example,
USER REQUESTS:
sales rep might request improvemencs to the company's web ire, a more powerful
sales analysis report, a network ro link all sales locations, or an on line S)'Stem that
allows customers to obrain the status of their orders instantly. Or, users might nor
be satisfied with the current system because it is difficult to learn or lacks flexibtliry.
They might want 111formation S)'Stems support for business requirement!> that did nor
even exist when the S)'Stem was first developed.
Systems project requests come also
&om the IT department itself. TT staff members often make recommendations based
on their knowledge of business operations and cechno1ogy trends. IT proposals might
be strictly technical matters, such as replacement of certain nenvork components, or
suggestions might be more business oriented, such as proposing a new reporting or
data collection srstem.
INFORMATION TECHNOLOGY DEPARTMENT:
Errors or problems in existing systems can trigger
requests for sysrcms projects. When dealing with older systems, analyses sometimes
spend coo much rime reacting ro day-to·day problems without looking at underlying
causes. This approach can curn an iniormarion system into a patchwork of corrections and changes that cannot support the company's overa ll business needs. This
problem typically occurs with legacy systems, which are older systems rhat are less
technologically advanced. When migrating ro a new system, IT pl:inners must plan
the conversion of existing data, which is described in detai l in Chapter I I.
EXISTING SYSTEMS AND DATA:
COMPANY FINANCES:
A company's financial status can affect systems projects.
If rhe company is going through a difficult time, the project may be postponed until
there is more cash available to finance the effort. On the other hand, if the company
is enjoying financ ial success, the decision ro embark on a new project may be easier to
make.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
--
........... ......
"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ..... ...... ... ~..
__....
~~·~---- ···---~~ - .,.-" ~
Chapter 2 Analyzing the Business Case
52
2.5 Factors Affecting Systems Projects
2.S.2 External Factors
Exrernal facrors include technology, suppliers, cusromers, comperiror<;, the economy,
and government.
Changing technology is a major force affecting business and society in general. For example, the rapid growth of telecommunications, coupled with
increased computing power and continuous miniaturization of electronic components, has created entire new industries and technologies, including the proliferarion
of smarrphones and the app ecosysrem.
Technology also dramatically reshapes existing business opcrarions .
The success of scanner technology resulted in universal bar coding rhat
now affects vi rtually all products. Some industry experts predict that
bar code technology, which is over 40 years o ld, will be overshadowed
in the furure by electronic product code (EPC) technology that uses
RF ID rags to identify and monitor the movement of each individual
product, from the factory floor to the rernil checkout counter.
Quick Response codes (QR Codes), as shown in Figure 2-7, are like
bar codes bur square in shape. T hey contain more information than
traditional ba r codes, but less than RF ID rags. T hey do ha vc the advantage of being less expensive to use than RFID rags, and they can be
printed o n a lmost an ything-including online advertisements.
The Internet-of-Things (JOT) is a newer development that involves
almost all electronic devices con1municating with one another over a comFIGURE 2·7 QR Code.
puter network. The communication can use radio signal~, as with RFID
cags, digical messages, or other means. loT devices can act as sensors, sending important information to centralized data storage and procetising nodes. IoT devices
also raise new security and privacy concerns that the systems analyst must coru.ider.
TECHNOLOGY:
•
SUPPLIERS: With the growth of clcctroaic data interchange (EDI), relationships with
suppliers arc crirically importanr. For example, an automobile company might require
t hat suppliers code their parts in a certain manner to march rhc auto company's inventor)' conrrol system. EDI also enables just-in-time UIT ) inventory ystems that rely on
computer-to-computer data exchange to minimize unneces ary inventory. The purpose
of a JIT system is to provide the right products at the right place at rhc right rime.
Blockchain technology is a promising mechanism for managing upply chains more
powerfully rhan before. Blockchain provides a distributed ledger ysrem that is efficient, secure, transparent. Large companies such as 181\ll are already using blockchain
to improve operarions for their customers, such as the Food Trust product shown in
Figure 2-8 rhar \'<'almart uses for tracking food safety from grower to consumer.
IBM Blockchaln at work
......
,....~.....nc:rwe,..;
-..............
---·--
__...._,.,._...,..,.
----~-----
_........
,.._..___,.
......._.___..........
._.. ...__
..__ .......
...
._
FIGURE 2·8 IBM 81ockcha1n.
-------..... ......
.....--------.
_,..._
. ..............
....-......."..__
-
.-
Sourt• »1(
(....,..... J:gi ( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,...... .,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
__.~~ c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
53
2.5 Factors Affecting Systems Projects
Customers are virally important 1to any business. Information S)'Stcm
that interact with customers usually receive top prioriry. Many companies implement
customer relationship management (C RM ) systems char integrate all customer-related
event<; and transactions, including marketing, sales, and customer service acnvines.
Vendor-oriented CRNI systems often interconnect with supply chain management
(SCM) systems, which were discu sed in Chapter 1. CR;\it components can provide
automated responses to sales inquiries, online order processing, and inventory tracking. Some suppliers use robots for order fulfillment, such as the Kiva robots shown in
Figure 2-9 rhar Amazon.com uses in their warehouses.
CUSTOMERS:
FIGURE l -9 Amnon Roboucs' Krva robots.
Another RFID application is called electronic proof of delivery (EPOD). Using
EPOD, a supplier uses RFID tags on each crate, case, or shipping unit ro create a digital shipping list. The customer receives the list and scans rbe incoming shipment. If a
discrepancy is detected, iris reported and adjusted automatically. Because they would
be expensive ro invesrigare manually, small shipping inconsistencies might nor otherwise be traced. This is an example of technolog)r- related cost control.
Competition drives many information systems decisions. For
example, if one cellula r telephone provider offers a new cype of digiral service, orher
firm s musr match rhe plan in order to remai n competitive. New product research and
developmcnr, marketing, sales, and service all require IT support.
COMPETITORS:
Economic activity bas a powerful influence on corporate
information management. In a period of economic expansion, firms need to be rea<ly
with i.calable systems that can handle additional volume and growth. Predicting the
business cycle is not an exact science, and careful research and planning are important.
THE ECONOMY:
Federal, stare, and local government regulations directly affect
the design of corporate information systems. For example, up-to-dare fRS reporting
requiremenrs must be designed into a payroll package.
GOVERNMENT:
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 2 Analyzing the Business Case
2.6 Processing Systems Requests
54
2.6 PROCESSING SYSTEMS REQUESTS
In most organizacions, che IT deparcment receives more systems requests than it can hancUe.
Many organizations assign responsibility for evaluating systems requests to a group of
key managers and users. tvlany companies call this group a systems rC\ iew com mince
or a computer resources committee. RegardJess of che name, che objective 1s to use the
combined judgn1ent and experience of severaJ analysts co evaluate project requests.
2.6. 1 Systems Request Forms
Many organizations use a special form for systems requests, similar to the online sample hown in Figure 2-10. A properly designed form streamlines che request process and
ensures consistency. The form must be easy to understand and include clear instructions. It shou ld include enough space for all required information and )hould indicate
what supporting documents
Tech Support Request Sysleni
1/••r1,.:.. ·"~' ::..·, ~· ,,, "'·'"''· 1
are needed. Most companies
use onJine systems request
Submit Roqueet
forms rh:H users submit electronically because the form can
be processed automatically.
When a systems request
form is received, a systems analyst or IT manager examines it
o-awio . . ~
_ _ ., olllllO Cl•
co determine what IT resources
arc required for the preliminary
investigation. A designated
person or a committee then
decides whether m proceed
wirh a prelimmary inve tigation. omerimes, a situation
o a - .... o ...
requires an immediate response.
For example, if the problem
involves a mission-critical sysFIGURE 2- 10 Example of an onhne systems request form.
tem, an IT maintenance team
must restore normal operacions
immediately. \'Qhen the sysrem is functioning properly, die ream conduce a review and
prepares a systems request to docwnent the work that was perfom1ed.
7
•
)
2.6.2 Systems RequestTools
\Xfhen the number of requests su bmitted throug h automated fo rms becomes significant,
or if the requests can origi nate from intern al sou rces as well as extern a I customers,
special-purpose systems request tools can be used to help manage t he work flow. For
example, Figure 2-'l 1 ill ustrates the service request capa bilities from l'nregrify that captures, manages, a nd routes requests to systems analysts based on definable business
rules. In th is way, req uests are tracked and analyzed for improved performance.
2.6.3 Systems Review Committee
Most large companies use a systems review comminee to evaluate systems requests.
Instead of relying on a single individual, a committee approach provides a variety of
experience and knowledge. \Vith a broader viewpoint, a committee can establish priorities more effectively t ban an individual, and one person's bias is less likely ro affect
the decisions.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gl( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
SS
2.6 Processing Systems Requests
A rypical committee consists of
C
.
··• •' "'
.... c
•
•
• •
'·'
the IT director and several managers or representarives from other
Service Request Management
departmencs. The IT dirccror usuall)' serve:. as a technical consultant
co ensure that committee members
are aware of crucial issues, prob~
....
&"!ilil• ~ ---·-----~---- .... · - lems, and opportunities.
- ........ - - -..... ,..._ ...................... ~o..
...,.._,___...,
_..
,...
_...
Although a committee offers
._
many advantages, some disadvan--~
s..1.....-r .. tagei. exist. For example, action
.........
on requescs must wait unri l the
committee meets. Another potential disadva ntage of a committee is
that members might favor projects
req uested by their own departments,
and internal polit ical differences
could delay important decisio ns.
M any sma ller companies re ly
FIGURE 2- 11 A service request management system from lntegrify.
on one person to evaluate sysrem
requests instead of a committee. If
only one person has the necessary IT skills and ex perience, t hat person must consult
closely with users and managers throughout t he company to ensure that bu5iness and
operational needs arc considered carefully.
p
::::.
GM11o.rno
-·----_...................
...........
.... .............. ......
---
.. ............. ........ -.........................
...
~
. . . . . . . . . ;ill . . . . . . . . . _ . . . . . . . . . . . ..,.
_ __
--
-- -
--
\Vherher one person or a commitrec is responsible, the goal is to evaluate the
requests and ser priorities. Suppose four requests must be reviewed:
1. The marketing group wanes to analyze current customer spending habits and
forecast future trends.
2. The technical supporr group wanes a cellular link, so sen•ice representatives can
download rechnical dara instantly.
3. The account ing department wanes ro redesjgn customer starements and allow
Internet access.
4. The producrion sraff wants an inventory control system that can exchange dara
wirh major suppliers.
\'<lhich projects should che firm pursue? What criteria should be applied? I low
should p riorities be determined? To answer chose questions, the individual or the
commirtce m use assess rhc feasibiliry of each request.
__ ,
.
.
.
.CASEJN;.P.OINfl:,.2.2:
..
.
,ATITAWAY AIRLINES, ~ RART:: O;,a·>
~
--
----
'
·.:4
You are the IT director at Attaway Airlines, a small regional air carrier.You chair the
company's systems review committee. and you currently are dealing with strong
disagreements about two key projeets. The marketing manager says it is vital to have a new
computerized reservation system that can provide better customer service and reduce operational costs.The vice president of finance is equally adamant that a new accounting system
is needed immediately because it will be very expensive to adjust the current system to new
federal reporting requirements.The VP outranks the marketing manager. and the VP is your
boss.The next meeting, which promises to be a real showdown, is set for 9:00 a.m. tomorrow. How will you prepare for the meeting! What questions and issues should be discussed!
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
-
Chapter 2 Analyzing the Business Case
56
2. 7 Assessing Request Feasibility
2. 7 ASSESSING REQUEST FEASIBILITY
As described in Chapter 1, a sysrerns request must pass several tests to see whether
it is worthwhile to proceed further. The first step is to identify and weed out systems requests that arc not feasible. For example, a request would not be feasible if it
required hardware or software that the company al ready had rejected.
Even if the request is feasible, it might not be necessary. For example, a request
for multiple versions of a report could require considerable design and programming
effort. A bencr alternarive might be to download the server dara ro a personal compurerbased sofnvare package and show users how to produce their own reports. In this
case, rraming users would be a bener investment than producing reports for them.
Somerimes assessing request feasibility is quite simple and can be done in a few
hours. If rhc request involves a new system or a major change, however, extensive
fact-finding and investigation in rhe form of feasibility studies are reqwred.
2.7. I Feasibility Studies
As shown in Figure 2- 12, a feasibi lity study uses four main yardsticks ro measure a
proposal: operational feasibi lity, eco111omic feasibi lity, technical feasibility, and schedule fcasibil icy.
How much effort should go into a feasibility study depends on nature of the
request. For example, if a deparunent wants an existing report sorted in a different
o rder, the analyst can decide quickly whether the request is feasible. On the other
hand, a proposal by the marketing department for a new market research system to
predict sales trends would require much more effort. Jn either case, the systems analyst should ask these important questions:
•
ls the proposal desirable in an operational sense? Is it a practical approach char will
soh·e a problem or rake advantage of an opporruniry to achieve company goals?
•
Is the proposal technically feasible? Are the necessary technical resources and
people available for the project?
• Is rhe proposal economically desirable?
What are the projected saving~ and costs?
Are ocher intangible factors involved, such
as customer satisfocrion or company image?
ls the problem worrh solving, and will
the request result in a sound business
investment?
0pe1"8tlonal
• WiH If be easy to
team and vse?
Schedule
• Can we do 11in
time?
Fualble?
=:=a •
Economic
Will b enefits
e'Kceed costs?
Technlcel
• Do we have the
tech resources?
FIGURE l -1l A feasibility study examines operational, technical, economic,
and schedule factors.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
• Can the proposal be accomplished
within an acceptable rime frame?
To obtain mo re information about a
systems request, ini tial fact-finding migh t
be accomplished by stud ying o rganization
charts, performing interviews, reviewing
current d ocumentation, observing operations, and surveying users. Sometimes,
developing prototypes can provide additional insight into the feasibility of the
request. If the systems request is approved,
more intensive face-finding will continue
during the systems analysis phase.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
57
2.7 Assessing Request Feasibility
2.7.2 O perational Feasibility
Operational feasibi lity means that a proposed system will be used effectively after ir
has been developed. If users have difficulry with a new sysrem, it will nor produce the
expected benefits. Orgamtarional culture can also affect operational feasibility. For
instance, a system that works well in a highly structured workplace might be very
unpopular in a more relaxed corporate culture. Operational feas ibility is difficult ro
measure wirh precision but must be studied very carefully. The follo·wing questions
would help predict a system's operational feasibility:
•
•
•
•
•
•
Does management support the project? Do users support the pro1ecr? ls rhe current !>yi.cem well liked and effectively used? Do users see the need for change?
\Xfill the new system result in a workforce reduction? lf so, what will happen to
the affected employees?
Will the new system require training for users? lf so, is the company prepared
to provide the necessary resources for training current employees?
Will users be involved in planning rhe new system right from the start?
Will rhc new system place any new demands on users or require any operaring
changes? For example, will any information be less accessible or produced less
frequencly? Will performance decJjne in any way? lf so, will an overall gain co
the organizarion outweigh individual losses?
Will customers experience adverse effects in any way, either temporarily or
permanently?
•
Will any risk co rhe company's image or goodwill resulc?
•
Does the development schedule conflict with other company priorities?
•
Do legal or ethical issues need to be considered?
2.7.l Economic Feasibility
Economic feasibility means thar the projected benefits of the proposed !>ystem outweigh the est11nated coses usually considered the total cost of o wnenhip ( fCO),
whic h includes ongoing support and maintenance cosrs, as well as acquisition co~ts.
To determine TCO, the analyst must estimate coses in each of the folio\\ mg a reas:
•
People, including IT staff and users
•
J lardwarc and equipment
•
Software, including in-house development as well as purchases from vendors
•
Formal :.tnd informal craining, including peer-to-peer support
•
•
Licenses and fees
Consulting expenses
•
Facility costs
•
The e~timatcd cost of not developing the system or postponing the project
Tangible co~ts, such as those listed above, usually can be measured in dollars. But
intangible co~ts also must be considered. For exainple, low employee morale might not
have an immediate dollar impact, bur certainly will affect the company's performance.
In addition to costs, tangible and inrangible benefits to the company must be assessed.
The systems review commirtee will use those figures, along with the cost estimates, to
decide whether ro pursue rhe project beyond the preliminary investigation phase.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 2 Analyzing the Business Case
2. 7 Assessing Request Feasibility
58
Tangible benefi ts are benefits that can be measured in dollars. Tangible benefits
result from a decrease in expenses, an increase in revenues, or both. Examples of tangible benefits include the following:
•
•
•
A new scheduling l>ysrem that reduces overtime
An online package tracking system that improves service and decreases the
need for clerical staff
A sophisticated inventory control system that curs excess inventory and eliminates production delays
lniangible benefits are advantages tbat are difficult to measure in dollars but are
important to the company. Examples of intangible benefits include rhe following:
•
•
A user-friendly system that improves employee job satisfaction
A sales tracking system that supplies berter information for marketing decisions
•
A new website that enhances the company's image
The development timetable must also be considered, because some benefits mighr
occur as soon as rhe system is operational, but others might not rake place until later.
2.7.4 Technical Feasibility
Technical feasibility refers to the technical resources needed to develop, purchase,
install, or operate the system. When assessing technical feasib ility, an analyst should
consider the following points:
•
Does the company have the necessary hardware, software, and network
resources? If not, can those resources be acquired without difficult)•?
•
Docs the company have the needed technical expertise? If not, can it be acquired?
•
Does rhe proposed platform have sufficient capacit} for future needs? If not,
can it be expanded?
Will a prototype be required?
•
•
\Xfill the hardware and software environment be reliable? \Xfill tt integrate with
ocher company information systems, both now and in the future? Will ir mrerface properl y with external systems operated by customer~ and suppliers?
•
Will the combination of hardware and software supply adequate performance?
Do clear expecta tions and performance specifications exist?
•
Will rhe system be able to handle future transaction volume and company
growth?
Keep in mind that systems requests that are not currently technically feasible cao
be resubmitted as new ha rdware, software, or expertise becomes available. Development costs might decrease, or the val ue of benefits might increase enough that a systems request eventua lly becomes feasible. Conversely, an initially feasible project can
be rejected later.
2. 7 .S Schedule Feasibility
Schedule feasibility means rhar a project can be implemented in an acceptable rime
frame. \'V'hen assessing schedule feasibility, a systems analyst must consider the inter·
action between time and costs. For example, speeding up a project schedule might
make a project feasible, but much more expensive.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
59
2.8 Setting Priorities
Other issues that relate ro schedule feasibiliry include the following:
•
•
•
•
•
•
Can the company or the IT ream control the factors chat affect schedule
feasibiliry?
Has management established a firm cimetable for the project?
\Xlhar condition~ must be satisfied during the development of the system?
\Xlill an accelerated schedule pose any risks? If so, arc the risks acceptable?
\Xl11l project management techniques be available to coordinate and control the
project?
Will a project manager be appointed?
Chapter 3 describes various project management tools and techniques.
2.8 SFTTING PRIORITIES
After rejecting systems requests that are not feasible, the systems review committee
must establish priorities for the remaining items. lf tools are used as part of the review
process, the requests may already be in a partially or fully sorted order. The highest
priority goes to project requests that provide the greatest benefit, at the lowest cost, in
the shortest period of rime. Many faccors, however, influence project evaluation.
2.8.1 Dynamic Priorities
It's important to note that many projects are dynamic in nature. For example, projects
chat have adopted an agile merhodology are prone ro rapid changes rhroughout the system development lifecycle. These changes can cause request priorities to change as well.
For example, acquisition costs mighc increase over time, making the project more
expensive than anticipated. This can affect the economic feasibility of a number of
requests. In addition, managers and users somecimes lose confidence in a project. For
all those reasons, feasibiliry anal)•sis and priority setting are ongoing rask that must
be performed throughout the S)'Stems development process.
2.8.2 FactorsThatAffect Priority
When assessing a project's priority, a systems analyst should consider the following:
•
•
•
•
•
•
•
Will the proposed system reduce costs? Where? When? How? By how much?
Will the system increase revenue for the company? Where? When? How? By
how much?
Will the systems project res ul t in more information or produce better results?
I low? Are the results measurable?
Will rhe system serve customers better?
\'(fill the system serve the organization berrer?
Can the project be implemented in a reasonable time period? How long will
the results last?
Are the necessary financial, human, and technical resources available?
Few projects will score high in all areas. Some proposals might not reduce costs
but will provide important new features. Other systems might reduce operating costs
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 2 Analyzing the Business Case
2.9 The Preliminary Investigation
60
substantially but require che purchase or lease of additional hardware. Some systems
might be very desirable but require several years of development before producing
significant benefits.
\'<lhenever possible, the analyst should use tangible costs and benefits that can be
measured in dollars. However, the proposal might invoh·e intangible benefits, such as
enhancing the organization's image, raising employee morale, or improving customer
service. These examples are harder to measu re but should aJ50 be considered.
2.8.3 Disc~tionary and Nondiscretionary Projects
Pro1eccs where management has a choice in implementing chem are called
di~crecion ary project!;. Projects where no choice exists are called nondiscretionary
projects. Creating a new report for a user is an example of a discretionary project;
adding a reporc required by a new federal law is an example of a nondiscretionary
project.
If a particular project is not discretionary, the systems analyst should ask if it is
really necessary for the systems review committee to evaluate it. Some people believe
th:i t waiting for com111irtee approval delays critical nondiscrecionary projects unnecessarily. Others believe t bat submitting all requests to the systems review keeps the committee aware of all projects that compete for IT resources. As a resul t, the committee
can review priorities and create realistic schedules.
Many nondiscrerionary projects are predictable. Examples include annual updates
ro payroll, cax percentages, or quarterly changes in reporting requirements for an
insurance processing system. By planning ahead for predictable projects, the IT
department manages its resources berrer and keeps the systems review committee fully
informed without needing prior approval in every case.
Back at Ar.u.way Airlines, the morning meeting ended with no agreement between the VP
of finance and the marketing manager. In fact, a new issue arose.The VP now says that the
new accounting system is entided to the highest priority because the federal government
soon will require the reporting of certain types of company-paid health insurance premiums. Because the current system will not handle this report. the VP insists that the entire
accounting system is a nondiscretionary project. As you might expect. the marketing
manager Is upset. Can pare of a project be nondiscretionary? What issues need co be
discussed/ The committee meets again tomorrow. and the members will look to you. as the
IT director, for guidance.
2. 9 THE PRELIMINARY INVESTIGATION
A systems analyst conducts a prelimina ry investigation to study the systems request
and recommend specific action. After obtain ing an authorization to proceed, the
analyst interacts wirh managers, users, and other stakeholders, as shown in the
model in Figure 2-13. The analyst garhers faces about the problem or opportunity, project scope and constraints, project benefits, and estimated development
rime and coses. T he end produce of the preliminary investigation is a report to
management.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Phase I
Systems Planning
61
2.9 The Preliminary Investigation
2.9.1 Planning the Preliminary Investigation
Before starting a preliminary inve rigarion, iris importanr co let
Problem or
people know about chc invcstigarion and explain the role of the
Benefits
Opportunity
system analyst. 1\lleetings with key managers, users, and ocher
stakeholders such as the rT staff should be scheduled, to describe
the proiect, e'<plain roles and responsibilities, answer questions,
and invite comments. Interactive communication with users
starts at this point and continues throughout the development
Projec1 Scope
Costs
and Cons1ra1nts
process.
A systems project often produces significant changes in
company operarions. Employees may be curious, concerned, or
even opposed to those changes. It is not surprising ro encounter some user resistance during a preliminary investigation.
Report to Management J
Employee attitudes and reactions arc important and must be
considered.
FIGURE 2- 13 Model ofa preliminary
When interacting with users, use t he word problem careInvestigation. Note the Importance of fact-finding
fully, because ir has a negative meaning. When users are asked
In each of the four areas.
about problems, some will stress current system limita tions
rather than desirable new features or enha ncements. Instead
of focusing on difficulties, question users about additional capabi lity they would
like to have. This approach highlights ways to improve the user's job, provides a
better understanding of operations, and builds better, more positive relationships
with users.
2.9.2 Pe rforming the Preliminary Investigation
During a preluninary investigation, a systems analyst typically follows a series of
steps, as ~hown in Figure 2-14. The exact procedure depends on the nature of the
request, the size of the project, and the degree of urgency.
Step I: Understand t he Problem or O pportunity
lf the systems request mvolves a new informacion system
or a substantial change 111 an existing syscem, sysre1ns
analysts might need co develop a business profile chat
descnbes current business processes and funcrioos, as
explained in Chapter I. Even where the request involves
relatively minor changes or enhancements, how chose
modifications will affect business operations and ocher
information systems must be understood. Often a change
in one system has an unexpected ripple effect on another
system. When a systems request is analyzed, which
departmen ts, users, and business processes are involved
must be determined.
Jn many cases, the systems request does not reveal
the underlying problem, bur only a symptom. For
example, a request to invest igate centralized processing delays might reveal improper scheduling practices
rather than hardware problems. Similarly, a request
for analysis of customer complaints might disclose a
lack of sales representative training, rather than problems with the product.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
•
•
•
0
Undersland the problem or opponun11y
_J
Dehne fhe pro1ect sc;ope and consframts
Perform lact-fond1ng
• Analyze organlzauon charts
• Review documentauon
• Observe operaflons
• Conducf a user survey
Study usablhty, cost, benefit. and schedule data
Evaluate feaslbllity
0
• Operational
• Technical
• Economic
• Schedule
FIGURE 2- 1 ~ Five main steps in a typical preliminary
invesug~uon.
--
........... ......
"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ..... ...... ... ~..
__....
~~·~---- ···---~~ - .,.-" ~
Chapter 2 Analyzing the Business Case
2. 9 The Preliminary Investigation
62
A popular rechnique for investigaring causes and effecrs is called a fi 5hbone
diag ram, a shown in Figure 2-15. A fishbone diagram is an analysis cool rhar
represenrs the possible causes of a problem as a graphical ourline. \Vhen using a
fish bone diagram, an analyse firsr scares rhe problem and draws a main bone wirh
sub-bones chat rcpresenr possible causes of rhe problem. In rhe example shown in
Figure 2-15, rhe problem is Low M orale, and rhe analyst has identified four areas
to investigate: £11vironme11t, People, Management, and Mac/1111es. In each area,
the analyst idenrifies possible causes and draws chem as horizontal sub-bones.
For example, Temp too hot or cold is a possible cause in rhe £11viro11me11t bone.
For each cause, the analyse muse dig deeper and ask rhe quesrion: Whar could be
causing this symprom co occur? For example, why is it too hoc? If the answer is a
Faulty thermostat, rhe analyst indicates this as a sub-bone co rhe Temp too hot or
cold cause. In ch is manner, the anal yst adds addirional sub-bones to the diagram,
until he or she uncovers root causes of a problem, rather than just the symptoms.
fl!
••
~- -
---~--
·-
_....... ·--·-
:.
....
•
-
--
•
•• , ••
-
...
FIGURE l - 1S A fishbone diagram displays the causes of a problem.Typically, you must dig deeper to identify
anual causes rather than just symptoms
Step 2: Define the Project Scope and Constraints
Determining the project scope means defining the specific boundaries, or extent, of
the project. For example, a statemen't that, payroll is not being produced accurate/)'
is very general, compared with the statement, overtime pay is 1101 being calc11/ated
correctly (or production workers on the second shift at the Yorktown pla11t. Similarly,
the statement, the project scope is to modify the accounts receivable system, is not
as specific as the sta tement, the project scope is to allow customers to inquire 011/i11e
about acco1111t balances and recent transactions.
Some analysrs find it helpful ro define project scope by creating a list with sections
called Nfust Do, Should Do, Could Do, and W/011't Do. T his list can be reviewed
later, during the systems analysis phase, when the systems requirements document is
developed.
Projects with very general scope definitions are at risk of expanding gradually,
without specific au thorization, in a process called project creep. To avoid thi~
problem, project scope should be defined as clearly as possible. A graphical model
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
63
2.9 The Preliminary Investigation
that shows the systems, people, and business processes that will be affected is sometimes useful. The scope of the project also establishes the boundaries of the preliminary investigation itself. A systems analyst should limit the focus to the problem at
hand and avoid unnecessary expendirure of time and money.
Along with defining the scope of the project, any constraincs on the '>)'Stem must
be identified. A con~traint is a requirement or condition that the system must .,arisfy
or an outcome that the system must achieve. A constraint can im·olve hardware,
software, rime, policy, law, or cosr. System constraints also define project cope. For
example, if the system must operate with cxisring hardware, that is a constraint that
affects porential solutions. Other examples of consrraincs are:
•
The order entry sy!.rem must accept input from 15 remote site .
•
The human resources information system must produce statistics on hiring
practices.
The new website must be operational by March 1.
•
When examining constraints, their characteristics should be identified, as follows.
PRESENTVERSUS FUTURE: Is t he constraint something that must be met as soon as
the system is developed or modified, or is the constraint necessary ar some fucure time?
Ls the consrrainr due ro a requirement within the
organization, or docs some external force, such as government regulation, impose it?
INTERNAL VERSUS EXTERNAL:
MANDATORY VERSUS DESIRABLE: Is the coosuaint mandatory? ls it absolutely
essential to meet rhe constraint, or is ir merely desirable?
Figure 2-16 shows five examples of constraints. Notice rhar each constraint has
three characterisrics, which arc indjcarcd by ics position in the figure and by the srmbol thac represents the consrrainr, as follows:
Sample Constrai nts Shown byTlming, Type, and Urgency
("'E;';'mple A: New IRS
I ~must be used 1n
!he payroll system as
I
Example B: Sometime neX1
year our largest cus1omer wdl
require a seounty code for all
onhne transactlOlls
as poSSlble
Future
Present
I • Mandatory constraint
•
£ • Desirable constraint
Internal
Example C: Managemen1
prefers that the project be
completed now rather
than next quarter
Example 0 : Starting next
week, the marketing system
must track all repeat visits
to the webslle.
Example E: To reduce raw material
costs. we should build supply chain
management capabthty Into lhe next
versoo of our purcnasmg system
FIGURE l - t 6 Examples of v.1nous types of constraints.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 2 Analyzing the Business Case
2. 9 The Preliminary Investigation
64
•
•
The consrraint in Example A is presenr, external, and mandatory.
The constraint in Example B is future, external, and mandatory.
•
The constraint in Example C is present, internal, and desirable.
•
The constrJint in Example D is present, internal, and mandatory.
•
The con rrainr in Example Eis future, interna~ and desirable.
Regardless of the type, all constraints should be identified as early as possible
to avoid future problems and surprises. A clear definition of project scope and constraints avoids misunderstandings that arise when managers assume that the system
will have a certain feature or support for a project, but later find that the feature is
nor included.
Ste p 3: Pe rform Fact-Finding
The object ive of face- finding is to gather data about project usability, costs, benefits, ;ind schedules. Fact-finding involves various techniques, which arc described
below. Depending on what info rmation is need ed to investigate the systems
request, fact-finding mig ht cons ume several hours, days, or weeks. For example, a
change in a report forma t o r data entry screen might requ ire a single telephone call
or emai l message to a use r, whereas a new inventory system wou ld involve a series
of interviews. During fact- finding, the analyst might analyze organization charts,
conduct interviews, review current d ocumentation, observe operations, and carry
out a user survey.
ANALYZE ORGANIZATIO N CHARTS: An analyst will not alway~ know the organi-
.tational structure of departments involved in the study. Organization charts should be
obtained to understand the functions and identify people to interview.
If organization charts are not available, or are out-of-date, the necessary information should be obtained from department personnel and construct the charts, as
shown in Figure 2-17.
Even when c harts are available, their accuracy should be ve rified. Keep in mind
t hat an organization chart shows formal reporting relationships but nor the informal
alignment of a group, which also is important.
CONDUCT INTERVIEWS: The
Customer Service Department
primary merhod of obraining
informatio n during the preliminary
investigation is the interview. The
interviewing process involves a
series of steps:
1. Determine the people to
interview.
2. Establish objecri vcs for t he
interview.
-
3. Develop interview questions.
~
FIGURE 2- 17 Specialo:z.ed tools such as MlcrosoftVisoo an be used to draw
organizational charu. but general purpose presentation tools such as Microsoft
PowerPoint shown here can also be used.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
4. Prepare for the interview.
5. Conduct the interview.
6. Document the interview.
7. Evaluate rhe interview.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
65
2.9 The Preliminary Investigation
These seven steps arc discussed in derail in Chapter 4, which describes fact-finding
techniques that occur during the systems analysis phase of the SDLC.
Rememher that the purpose of the interview, and of che preliminary mvestiganon itself, is co uncover facts, nor ro convince others char che project is justified. The
analyst's primary role in an interview is co ask effective questions and listen carefully.
If several people will be asked about the same topic, a standard set of questions for all
the interviews should be prepared. Also be sure to include open-ended que ttons, such
as " \Xlhat else do you think I should know about the system?" or .. Is there any other
relevant information that we have not discussed?"'
\'(!hen conducting interviews during the preliminary investigation, interview managers and supervisors who have a broad knowledge of the system and can provide an
overview of the business processes involved. Depending on the situation, talking to
operational personnel to learn how the system functions on a day-to-day basis may
also be helpful.
REVIEW DOCUMENTATION: Although interviews are an extremely important
method of obtaining information, investigating the current system documentation is
also useful. The documentation might nor be up ro dare, so check with users co confirm that the informa tion is accurate a nd complete.
Another fact-finding method is to observe the current
system in operation. Observe how workers carry out typical tasks. Trace or follow
the actual paths taken by input source documents or output reports. ln addition to
observing operations, consider sampling the inputs or outputs of the system. Using
sampling techniques described in Chapter 4, valuable information about the nature
and frequency of the problem can be obtained.
OBSERVE OPERATIONS:
Interviews can be rime consuming. Sometimes information from a larger group can be obtained by conducting a user survey. In this
case, design a form that users complete and reru rn for cabularion. A survc}' is nor as
Aexible as a series of interviews, bur ir is
less expensive, generally rakes less time,
and can involve a broad cross-secrion of
Pareto Chart: Inventory System Errors
people.
CONDUCT A USER SURVEY:
ANALYZE THE DATA: Systems analysts
use many techniques to locate the source
of a problem. For example, the Pareto
chart is a widely used tool for visualizing
issues that need attention. Named for a
nineteenth century economist, a Pareto
chart is drawn as a vertical bar graph, as
shown in Figure 2- J 8. The bars, which
represent various causes of a problem, are
arranged in descending order, so the team
can focus on the most important causes.
ln the example shown, a systems analyst
mighr use a Pareto chart to learn more
about the causes of inventory system
problems, so that necessary improvements
can be made.
.........""_.. ... .-.................
-
.....
FIGURE l -18 A Pareto chart displays the causes ofa problem. in priority
order. so an analyst can tackle the most lmpon:ant cases first. In this example.
the part number issue would be the obvious starting point.
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
-- - --
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 2 Analyzing the Business Case
2. 9 The Preliminary Investigation
66
The XY chart, somerimes called a scatter diagnim, is anorher problem-solving root.
Often, an :malysr looks for a correlation becween two variables. For example, suppose complainrs are received about network response time, and rhe cause needs robe
derermined. The analyst would rry to identify variables, such as rhe number of users,
to see whecher there is a correlation, or pan ern. Figure 2- 19 shows rwo XY charts
wirh dara samples. The firsr chart sample would suggest thar rhere is no corrclacion
__ .. .• ..
.
... ~- ............... --..._
- ·•
..
0-. .... _
•
-
.A
.
II
-
'•
-
...........
- .... .. •
•
- ·- p
I
~
•
Network Response Time vs. Number of Users
.. .
..
••
..
••
---
n ...... t
•
n...,...1
•
.,..
---
•
•
•
--
••
• p
I
. ...
• •
......_
Network Response Time vs. Number of Users
..
..
•.....
-1
...
..
"
•
•
- - ..
... r -
•
•
-~·
•
..
FIGURE 2- 19 An XY chart shows correlation between variables, which is very important in
problem solving. Conversely, a lack of correlation suggests that the vari:lbles are independent.
and that you should look elsewhere for the cause.
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gi ( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,...... .,..~
__.~~ c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
67
2.9 The Preliminary Investigation
between the delays and the number of users, so the analyst would look elsewhere for
the source of the problem. However, if the data resembles the second XY sample, it
indicates a strong relationship between the number of users and the longer response
rimes. Thar informanon would be extremely valuable in the problem-solving process.
Step 4:Analyze Project Usability, Cost, Be nefit, and Schedule Data
During fact-finding, data is gathered about the project's predicted cosrs, anticipated
benefits, and chedule issues that could affect implementation. Before feasibilit y can
be evaluated, this data must be analyzed carefuUy. If interviews were conducted or
surveys used, the data should be tabulated to make it easier to understand. If current
operations were observed, the results should be reviewed and key facts that will be
useful in the feasibihry analysis highlighted. If cost and benefit data were gathered,
financial analysis and impact statements can be prepared using spreadsheets and
other decision-support tools.
Also, time and cost estimates should be developed for the requirements modeling
tasks for the next SDLC phase, systems analysis. Specifically, the following should be
considered:
•
What informa tion must be obta ined, and how will it be gathered and analyzed?
•
Who will conduct the interviews? How many people will be interviewed, and
how much time will be needed to meet with the people and i.umnrnrize their
responses?
\'(fill a survey be conducted? Who will be involved? How much time will it cake
people to complete it? How much rime will it take to tabulate the results?
•
•
How much will it cost to :rnalyze che information and prepare a report with
findings and recommendations?
Step S: Evaluate Feasibility
At chis point, the problem or opportunity has been analyzed, the proiect scope and
consrraincs have been defined, and fact-finding has been performed ro evaluate
project usab1liry, costs, benefits, and time constraints. The next step is to as ess the
project'!> feasibility, beginning wi th reviewing che answers to the questions listed in
Section 2.7. The following guidelines should also be considered:
OPERATIONAL FEASIBILITY: Fact-finding should have included a review of user
needs, requirements, and expectations. When this data is analyzed, look for areas that
might present problems for system users and how chey might be resolved. Because
operational feasibility mea ns that a system will be used effectively, this is a vital area
of concern.
ECONOMIC FEASIBILITY: Using che fact-findi ng data, financia l ana lysis tools can
be applied to :i~sess feas ihiliry. The cost-benefit da ra will be an important factor fo r
management co consider. Also, a cost estimate for the project development ream wi ll
be built into the project management plan.
TECHN ICAL FEASIBILITY: The fact-finding data should identify the hardware, soft-
ware, and network resources needed co develop, install, and operate the system. \~ith this
data, a checklist can be developed that will highlight technical costs and concerns, if any.
SCHEDULE FEASIBILITY: The fact-finding data should include stakeholder expec-
tations regarding acceptable timing and completion dares. As mentioned previously,
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 2 Analyzing the Business Case
2. 9 The Preliminary Investigation
68
often a trade-off exisrs berween a project's schedule and its cosrs. For example,
compressing a projecr schedule mighr be possible, but only if the budget is increased
accordingly co add ext ra personnel. The schedule data will be incorporated into the
pro1cct plan in che form of task durations and milestones.
At rhis stage of the preliminary investigation, there are several alrernarives. It
might be rhat no action is necessary or thar some other srrateg)', such as addirional
training, is needed. To solve a minor problem, a simple solurion might be chosen
wirhour performing further analysis. In other situations, it will be recommended that
rhe project proceed to the next phase, which is systems analysis.
2.9.3 Summarizing the Preliminary Investigation
The fina l cask in the preliminary investigation is to summarize the results and recommendations, which can be conveying to management in a report and/or in a presentation. The written report and the oral presentation are examples of the need for
systems analysts to develop strong conu11unicacions skills. The report includes an
evaluation of the systems request, ao estimate of costs and benefits, and a case for
actio n, which is a summary of che pi:oject reques t and a specific recommenda tion.
T he spcci fie format of a preliminary investigation report varies. A typical report
might consist of the fo llowing sections:
•
/ntroductio11-tbe fi rst section is an overview of che reporc. The introduction
contains a brief description of the system, the name of the person or group
who performed the investigation, and the name of the person or group who
initiated the investigation.
• Systems Request Summary-the summary describes the basis of the systems
request.
•
•
•
•
•
•
findings-the findings section contains the res ults of che preliminar)' investigation, including a descriptjoa of the project's scope, constraints, and
feasibiliry.
Recommendations-a summary of the project request and a specific recommendation. Management will make the final dec1s1on, but the IT department's
input is an important factor.
Pro1ect Roles-this section lists the people who will participate in the project
and describes each person's role.
Time and Cost Estimates- this section describes the cost of acquiring and
installing the system, and che coral cost of ownership during the system's useful
life. Intangible costs a lso shou ld be noted.
Expected Benefits-this section incl udes anticipated tangible and intangible
benefits and a timetable that shows when they are to occur.
Appendix- an ap pendix is included in the report if supporting information
must be attac hed. For example, the interviews conducted might be listed, the
documencacion reviewed, and other sources for the information obtained.
Detailed interview reporrs do not need to be included, but those documents
that support t he report's findings should be retained for future reference.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
2. 10 Summa ry
As a new systems analyst at Premier Financial Services. you are getting quite an education.
You report to the IT manager, who also chairs the systems review committee. Several
months ago. the committee rejected a request from the finance director for an expensive
new accounts payable system because the benefits did not appear to outweigh the costs.
Yesterday. the IT manager's boss asked the IT manager to reconsider the finance director's request. and to persuade the other members to approve it. The IT manager wanted
to discuss the merits of the request, but the discuss ion was cut off rather abruptly. It turns
out the IT manager's boss and the finance director are longtime friends.
The IT manager is now very uncomfortable meeting with her boss. She believes the
directive to reconsider the finance director's request would undermine the integrity of the
systems review process. She feels it would be unethical to grant preferred treatment just
because a friendship is involved. She is thinking of submitting a request to step down as
review committee chair, even though that might harm her career at the company.
Is this an ethical question, or just a matter of office politics? What would you do if you
were the IT manager!
2. I 0 SUMMARY
Systems plann ing is rhe firsr phase of rhe systems development life cycle. Effective
information systems help an organization support irs business processes, carry out its
mission, and serve its stakeholders. During strategic planning, a company examines
its purpose, vision, and values and develops a mission scacement, which leads to goals,
objecttve!>, day-to-day operauons, and business resulcs that affect compan)' stakeholders. SWOT analysis exammes strengths, weaknesses, opponumries, and threats.
S\XIOT analysis can be u ed at the enterprise level and for mdividual pro1ect~.
During the }'Stems planning phase, an analyse reviews the busines~ case, which is
the basis, or reason, for a proposed system. A business case should de cribe the project clearly, provide the jusrificarion to proceed, and estimate rhe project's financial
impact.
Sy~tem~ projects are initiaced co improve performance, provide more information,
reduce costs, strengthen controls, or provide bener service. Various internal and external factors affect syscems projects, such as user requests, top management directives,
existing sy~tems, the IT depa rtment, software and hardware vendors, technology, cu~­
tomers, competitors, the economy, and government.
Duri ng the preliminary investigation, the analyst evaluates the systems request and
determine~ whether the project is feasible from an o perational, technical, economic,
and schedule standpoi nt. Analysts evaluate systems requests on the basis of their
expected costs and benefits, both tangible and intangible.
The steps in the preliminary in vestigation are to understand the problem or opportunity; define the project scope and constraints; perform fact-finding; analyze project
usability, cost, benefit, and schedule dara; evaluate feasibility; and present results and
recommendations to management. During the preliminary investigation, analysts
often use investigative rools such as fishbone diagrams, Pareto charts, and XY charts.
The last cask in a preliminary invescigarion is to prepare a report to management. The
report must include an estimate of time, staffing requirements, cosrs, benefits, and
expected results for the next phase of the SDLC.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
69
Chapter 2 Analyzing the Business Case
Key Terms
70
Ke y Te rms
biomclric de' kes A mech3ntSm used co uniquely identify a per~n by J rcuna scan or b> mJpping J
fa"al panern.
blod..-h.un A distributed ledger srstem. The technology underl}1ng B11corn.
bu'"''"'' ""'" Refer' to the rca>On>, or ju.cification, for a propo"11.
ca\c: for a•"l1on A part of the prd1m111ary 1n\'e>t1gat1on report to mdna11c:ment that \ummar11e> pro1c.t
rcque\r. and make> ,pcxific recommendation,.
computer resources commim~e A group oi key managers and users responsible for cvaluanng systems
requests. Inc rcrm "systems review commircee ~ is also used.
constraint A requirement or a condirion rhar rhe sysrem must satisf>' or an ourcomc chat 1he system muse
achieve.
critical \Uccc" focwrs Viral objectives that mu>t be achieved for rhe entcrpri>e m fulfill ir' mi,,,ion.
cu,ttuncr rdatiomhip nurna11ement (CRM) l\fany companie; implement 'Y'len1' to mtci;rotc all
cU\lomer·rdarcd event> and tran,action'> including mnrkcrin11, >ale,, and ""l<>mer wrvicc activitics.
discrc1i0Mry projects Where managemenr has a cboice in implementing a pro1ect, rhey arc c;11ied d1screrionJry. l·or example, cre:iring a new reporr for a user is .111 example of .1 discreuonary pro1ccr.
economic fcas1b1lit)' Achieved if the projecred benefits of rhe proposed system ou1we1gh rhc csrirnarcd
cosrs involved in acquiring, installing, and operating ir.
clcccrnnic darn interchange !EDT) The exchange of busine's document\ hctwccn compute" ll'ing a scan·
Jard clcctronk format.
dcuronic produu ~ode (EPCJ Technology char U!>l"> RFID la);) co idcntit) and monicor chc movement of
each 1nd1ndual product, from rhc factory Aoor ro the retail chc~kolll counter.
dcctron1c proof of dcli''l'f} (U'OO) A supplier uses RHD t.igs 011 e.ich cr.ite. case, or shipping unu ro
crearc J d1giral shipping hsr ro verify receipt oi goods.
cncrypuon A process where data is coded (oonverted into unrc.idable char.1cters) so char only those wnh
the required authorization can access the da1a.
fi,hhonc diagram \n analy-;is rool rhar represenrs rhe pos'>ible cau<e<> of a problem a< a graphical nm·
line. ""'.:ailed an bhikawa <liah'l"am.
intang1hlc hencfih Po\1ll•c ouKomcs that a~ difficult to mea~ure 1n dollars. Howc\'cr, intangible hcne·
fib can he very important m che calculation of economic fca>1b1hry. An c'<amplc of an intan111blc hen·
cfir m1ghr he a new wch<ite rhar improve-; a company'' ima11e.
intangible co-.s lrems that are difficulr ro measure in dollar remlS, such a~ employee d1~sa11~focnon.
ln1emc1 of Thing~ (IOT) Devices connected to one anorhcr over a computer nerwork.
j1M m·rimc (]TT) The exchange or dclh·ery of informanon when and where It i< needed. For c-camplc,
just·m·rimc 11wcntory sysrcms rely on compmer-co-compurer darn exchange rn minimize unncccs"3ry
111ven1ory.
111i,)io11 ~1a1c111cnt 1\ documcnr or >ratcmenr rbar <lc;c1·ibes 1hr.: company for Ill• stakeholder; and bricny
' rare' the company's overall purpose, produces, services, and value,.
nond1scrctionary pro1ccts Where managemem has no choice in 1mplemcnt111g a pro1ccr, they ore called
nond1screrionar)'· For example, adding a report required by a new fedcrJI law.
operational fca~ib1lit)' A •y,rcm char that will be used effecth•cly afrcr i1 has hccn developed.
Parero chart \vertical har graph named for a nineceench century economist. The bar<, which rcpre<cm
'arn>u., cau~e~ of a problem, are arranged in descending order, o;o rhe reJm can focu< on rhc mmr
11nport.1nt cau>e>.
prd1minal"} 10\C\llga11on An mmal :malysIS to clearly 1dennfy the namre and scope of the business
opportumry or problem. Al,o called a feasibilicy study.
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
...............
_ .... ~---11rt~
-,..~---~ ~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Phase I
Systems Planning
71
Key Terms
pro1cct cr•-ep !"he procco~ b> which projects with ,.et) general scope definirions exp.ind gradual!)." 11h·
out ~pcc1ftc .1u1horua11on.
proi«t \.:ope A ~pc..1fic dctcrmmanon of a pro1en's boundaries or extent.
\c.ttter diagram A tool u\cd hy 'Y'lem anal)\"' co graphicall) show the corrd;mon between two variabl~. Al'-<> c..1llcd an XY chart.
\cbcdulc fcas1biliry A proiect can be 1mplcmemed in an acceptable rune frame.
str.1t1:111c planomg Inc process o( 1dennfy1ng long-rerm orga nizanonal goals. s1rateg1es, and resource.
'iWOT analy\1' An c~ammarion of a company'• srreni,'ths (S), wcaknc•scs (W ), oppnrruni11c' (0), and
threat• (T).
\}'>tern\ rcquc•t A formal appeal m rhe IT departmem rhar describes problem\ or de\ired chanitc' in an
information •>''lean ur hu\lnes• proces;. Ti mighr propose t.>nham:emenl:!> for an exi;uni; 'Y>tem, the
corrcx:1iun of problem,, 01 the devdvpment vf an entirely new system.
systems renew commiuee A group of key nunagers and users responsible for cvalu.11mg systems
requests. The term computer resources committee is somerimes J!so used.
tangible benefit~ Pomivc o utcomes that can be measured in dollars. The)' can resulr from ,1 decrc.1se 1n
expenses. an increase in revenues, or botb.
tangible cmi. f.xpen•cs that haven ~pecific dollar value. Examples include employee o;al.iric• and hard
ware pun.. ha>c,.
U!thnital fca.,ihilil) \Vhcn an ori:ani1:1ri11n ha~ the resources to develop or purcha_,e, 1mtall, and operate
rhc ~JMcm.
101.il co~1 of o" ocrsh1p (TCO) A number used in assessing costs. which tndudes oogomg suppon .ind
numrenJnct costs, .1s well a~ acqu1sinon cosrs.
XY chart A tool used b> S)Stcm analysts 10 graphie<1lly show rhe corrcla1ion between mo \ar1.1hlcs. Also
called J scancr diagram.
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
...............
_ .... ~---11rt~
-,..~---~ ~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Chapter 2 Analyzing the Business Case
Exercises
72
Exercises
Questions
1. Why should a S)'Stems analyst be interested in strategic planmng?
2. Lisr the four factors invoked in a S\'V'OT analysis.
3. Describe how CASE rools can support strategic planning.
4. List five que~tions rhe business case should answer.
5. What arc the six main reasons for sysrems requests?
6. Explain the two main factors affecting systems requescs.
7. Describe the role of rhc sy~rems review committee in processing systems requests.
8. Define operational, economic, technical, and schedule feasibility.
9. List seven questions the sysrcms analyst should consider when assessing project priorities.
10. What are rhe five seeps of :i prel iminary investigation?
Discussion Topics
1. One of your coworkers says, "Mission statements are nice, but rhey really don'r change things down
here where rhc work gets done." How would you reply?
2. Discuss how a company's financial status can affect systems projects.
3. The vice prc~idenr of accounting ~ays to you, the IT direcror, "This request procedure takes too long.
My people know what they are doing, and their systems requests are necessary and important." She
~uggcsts char the IT deparrmenr bypass rhe initial seeps and immediately get ro work on her requesrs.
What would you say ro her?
4. When setting prioriries for system requests, the highest priority goes to projects that provide rhe great·
e~t benefit, at the lowest cost, in rhe shortest period of time. H ow would you reconcile projects thar
can produce good results in che shorr rerm versus projects rbac can produce excellent resulcs in rhe
long term?
5. The final cask 1n rhe preliminar)' invesngation is to summan1e chc r~ults and recommendations in a
report and/o r 1n a presenrarion. Which form of communicarion, wrirren or oral, do you chink is rhe
most effci.-ri'e for come)·ing your findings co managemenc?
Projects
1. Use rhe lnrcrncr rn find rluec examples of corporare mission stacemcncs.
2. Prepare a SWOT anal)·sis of your school or your employer.
3. A mind map is a diagram used ro visua ll y organize information. ldencify a tool rhat supports the crcacion of mind maps and explain how they can be a valuable part of srraregic planning.
4. Visit che website for an IT magazine and find an article chac discusses business cases. Summarize rhe
article and what you learned from it.
5. Think of a problem you have experienced ar school or at work and draw a sample fishbone diagram
with at lease two levels.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
~ JIJ»C....... ~ Al RlilfD
~ ... _
l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.: ......,_ . . . ,_.,~-.lit .......... .._.,._.__..,~•\
. . . _ . .... ..., ~...,.._,_..,..., J\&."9 ... --.11 ......... ~ C'dptl"~~d.tt ...... -
............ -
..... -
..........
-.-.....w--...-.11
Chapter 3
Managing Systems Projects
Managing
Systems Projects
Chapte r 3 is the final chapter in the systems planning
phase of the SDLC. This chapter describes project
management and explains how to plan, schedule,
monitor, and report on IT projects.
LEARNING OBJECTIVES
When you fi11ish this chapter, you shottld be able
to:
1. Wustrate pro1ect priorities in the form of a project triangle
2. E..xplain project planning, scheduling, monitoring, and reporting
3. Create a work breakdown srrucrure
4. Identify cask pattern~
5. Calculate a project's crirical parh
6. Describe project monitoring and concrol techniques Lo keep a project on sc hedule
7. Explain how project starus is reported
8. Describe project management sofrware and how
it can be of assisrance
9. Create a risk m:magcmcnt plan
10. Describe why projects sometimes fail
The chapter includes three "Case in Point" discussion
q,uestions to help contextualize the concepts described
in the teXt. The "Question or Ethics" considers the
implications of raising awareness of a project going astray
even when the project manager Is reluctant to do so.
CONTENTS
3.1 Overview of Project Nlanagemcnt
3.2 Creating a Work Breakdown Structure
Case in Point 3.J: Sunr1~e Software
3.3 Task Patterns
Case in Point 3.2: Parallel Sernces
3.4 The Critical Path
3 .5 Project Monitoring and Control
3.6 Reporting
3 .7 Project ~1anagement Software
3 .8 Risk Management
3 .9 Managing for Succes~
Case in Point 3.3: Ju ~r-in-lime Software
A Question of Ethics
3.10 Summary
Key Terms
Exercises
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
Phase I
Systems Planning
75
3.1 Overview of Project Management
3.1
OvERv1cw OF PROJECT MANAGEMENT
Many professionals manage business and personal projects every day bur do nor
always give it much thought. The management process for developing an information
system or working on a construction project is much the same. The only difference is
the nature of the project. To manage a large-scale IT project, specific tools and techniques arc needed. A project manager is also needed, someone who is responsible for
overseeing all relevant tasks. Project management for IT professionals includes planning, scheduling, monitoring and controlling, and reporting on information S)'Stcm
development.
A project manager will break rhe project dow11 into individual tasks, determine the
order in which the tasks need to be performed, and figure out how long each task will
take. \Xlith this informarion, Gantt charts or PERT/CPM charts can be used to schedule and manage the work. Microsoft Project is a popular project management roof
that can help create and then monitor the project plan, report progress, and u~e risk
management to make rhc whole process easier for everyone.
3. 1.1 W hat Shapes a Project?
A succe~sful project must be completed on time, be within budget, and deliver
a quality product that satisfies users and meets requirements. Project management techniques can be used throughout the SDLC. Systems developers
can initiate a formal project as early as the preliminary investigation stage, or
later on, as analysis, design, and implementarion acrivities occur.
Systems development projects tend to be dynamic and challenging. There
is always a balance between constraints, which '-\'as discussed in Chapter 2,
and interactive clements such as project cost, scope, and time.
3. 1.2 W hat Is a ProjectTriangle?
Figure 3-1 shows a very simple example of a project triangle. for each
PICK ANY TWO
FIGURE l· I You can't get
everything you want; you have to
make chokes.
project, it must be decided what is most important, because the work
cannot be good and fast and cheap.
When it comes to project management, things are not quite
so simple. Decisions do nor need to be all-or-nothing but recognize that any change in one leg of the triangle "rill affect the
other two legs. Figure 3-2 represents a common view of a
project triangle, where the three legs are cost, scope, and time.
The challenge is to find rhe optimal balance among these factors. Most successful project managers rely on personal experience, communication ability, and resourcefulness. For example,
if an exrremely time-critical project starts to slip, the project
man~1gcr might have to rrim some features, seek approval for
a budget increase, add new personnel, or a combination of all
three actions.
On its website, Microsoft offers an interesting suggestion for
project managers who h:ive a project at risk: Find the "stuck
side" of the triangle. Microsoft states that in most projects, at
Time
least one side of the triangle is fixed and unlikely co change.
It might be a budget cast in stone, a scope that is inflexible,
FIGURE l·l A typical project triangle includes
or a schedule driven by factors beyond the firm's control.
coSt. scope. and time.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 3
Managing Systems Projects
76
3.2 Creating a Work Breakdown Structure
\~hi chever side is fixed is probably crirical co rhe projecr's success. The leg where the
problem re ides must also be identified: cost, scope, or rime.
3. 1.3 What Does a Project Manager Do?
\~hether a pro1ect involves a new office building or an informauon system, good
leadership is essential. In a sysrems project, rhe project manager, or pro ject leader,
usually 1s a senior sy rems analyst or an IT department manager 1f the project 1s large.
An analyst or a programmer/analyst might manage smaller projects. In addition
to the project manager, mo t large projects have a project coordinator. A project
coordinator handles administrative responsibilities for the ream and negotiates with
users who might have conflicting requi rements or want changes that would require
additional time or expense.
Project managers typically perforn1 four activities or functions: planning, scheduling, monitoring, and reporti11g:
•
•
Project planning includes identifying all project rasks and esrimaring rhe completion rime and cost of each.
Project scheduling involves the creation of a specific timetable, usually in the
form of charrs that show tasks, task dependencies, and critical casks thar might
delay the project. Scheduling also involves selecting and staffing rhe project
rea m and assigning specific tasks co ream members. Project scheduling uses
Gantt charts and PERT/CPNl charts, which are explained in rhe following
sections.
• Project moniroring requires guiding, supervising, and coordmaring the project
•
team's workload. The project manager must monitor the progress, evaluate the
results, and rake corrective action when necessary to control the project and
stay on target.
Project rcponing includes regular progress reports to management, users, and
the project team itself. Effective reporting requires srrong communication skills
and a sense of what others want and need to know about the pro1ect.
The following sections describe the project planning and scheduling steps: how ro
create a work breakdown structure, identify task patterns, and calculate the project's
critical parh.
3.2 CREATING A WORK BREAKDOWN STRUCTURE
A work breakdown structure (WBS) involves breaking a project down into a series
of smaller tasks. Before creating WBSs, the two primary chart types should be understood: Gantt charts and PERT/CPM charts.
3.2.1 G antt Charts
I lenry L. Gantt, a mechanical engineer and management consultant, developed Gantt
charts almost I 00 years ago. His goal was to design a chart that could show planned
and actual progress on a project. A Gann chart is a horizontal bar chart chat represents a sec of tasks. For example, the Gantt chart in Figure 3-3 displays five casks
in a vertical arra y, with time shown on the horizontal axis. The position of the bar
shows the planned starti ng a nd ending time of each task, and the length of rhe bar
indicates it~ duration. On the horizontal axis, time can be shown as elapsed rime
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
77
3.2 Creating a Work Breakdown Structure
from a fixed starting point or as actual calendar dates. A Gantt chart also can simplify a complex project by combining several acriviries into a wsk gro up that contains
subsidiary tasks. This allows a complex project to be viewed as a set of integrated
modules.
...,
.
.....
.'·-·-·
.....
. -·
-
- --·- ·-- -.... -
.
- --·
·- -
- ... .._ - -c-•-- ... -
~
-----~'"'
--
-- ..
--· - --- --· - --·--
i.ao-.... ::. --=-~
m........... "'-;-'
.
.
• •
,_..,.. .._....,....._
FIGURE 3-3 In this Gantc chart. note the yellow bars that show the percentage of task completion.
A Gantt chart can show task starus by adding a contrasting color to the horizontal
bars. For example, a vertical red arrow marks the current date in Figure 3-3. With a
fixed reference point, it is easy to see that Task I is way behind schedule; Task 2 is
on ly about 80% done and is running behind schedule; Task 3 should have started,
bur no work has been done; Task 4 actuall y is running ahead of schedule; and Task )
will begin in several weeks.
Gantt charts can present an overview of the project's status, but they do not provide enough detailed information, which is necessary when managing a complex project. Some project managers ma> find char PERT/CPM charts, which are discussed in
che followmg section, are better cools for managing large projects.
3.2.2 PERT/CPM Charts
The Program Eval uation Re' iew T echniq u e (PERT) was developed by the U.S.
Navy ro manage very complex project , such as rhe construction of nuclear
submarines. Ar appro'<imately the same time, the C r itical Path M eth o d (C PM )
was developed by private industry to meet simLlar project management needs. The
distinction between the two methods has disappeared over time, and today the
technique is called either PERT, CPM, or PERT/CPM. This text will u~e the term
PERT chart.
PERT is a b ou om-up ccchn iq ue because it analyzes a large, complex projecr as a
series of individual tasks, just as a pyramid is builr from the borcom up using individual blocks. To create a PERT charr, first identify all the project cask~ and esrimatc
how much time each cask will rake to perform. Next, determine the logical order in
wh.icb the tasks must be performed. For example, some tasks cannot start Lmtil other
casks bave been completed. In o th er siruations, several tasks can be performed at th e
same rime.
Once the tasks arc known, their durations, and the order in which they must be
performed, calculate the time that it will take to complete the project. The specific
casks that will be critical to the project's on-time completion can also be identified.
An example of a PERT chart, which ~1icrosoft calls a network d iagran1, is shown in
che lower screen in Figure 3-4.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 3
Managing Systems Projects
3.2 Creating a Work Breakdown Structure
78
- -
. . .... .. - --- =--.
Although a Gantt charr offers a
valuable snapshor view of the proj- - L.:
ecr, PERT charts are more useful for
scheduling, moniroring, and controlling
the actual work. \'(.lith a PFRT chart,
_ ,c.... .. _
Ii . ....__..._ _ _
a projec t manager can converr task
I
..,,..._.............,..
-·-----~
start and fini sh rimes to acrual dates
• ....c..... ........
.,. . (_...._...........
= .
by laying our the entire pro1ect on a
,.. .... -. ._. ,.._ ..._ ..._
......
calendar. Then, on any given day, the
manager can compare what should be
happening wirh what is raking place
and react accordingly. Also, a PERT
'-+ •
•
chart displays complex task patterns
and relationships. This in formarion is
......
valuable to a manager who is trying ro
address high priority issues. PERT and
'""' S kNI out lntorvlow t<hedulo
Gaorr charts are not mutually exclusive
Stut Tuo 9/3/19 10 5
recltniques, and project managers often
fon11h Tue t/S/19 Dut I d• v
use both methods.
Ars
FigLtre 3 -4 shows both chart types.
FIGURE 3-4 The top screen shows a Gantt chart with six tasks.The PERT
T he top screen is a Gantt chart with six
chart in the bottom screen dlsplnys an easy-to-follow task pattern for the same
t asks. T he PERT chart below it shows
project. When the user mouses over the summary box for Task 5, the derails
become visible.
rhe same project, using a separate box
for each rask instead of a horizontal bar. Alrhough rhey borh show rhc rask pancrns and flow, rhc PERT chart boxes
can provide more information, such as task duration, start dare, finish date, and the
names of resources assigned co cbe cask. The PERT chart in Figure 3-4 would be too
small ro view the acrual derails, which are shown in the expanded rexr box ac che bottom of che figure. How co create PERT charts is explained in a later section.
w
.. ... ·-·
~---
-
---
...
-
...
--
~
~-
...·---- .
--- ---·- .
-
-
a
1
-
3.2.l Ide ntifying Tasks in a Work Breakdown Structure
A WB musr clearly identify each task and include an estimated duration. A task,
or an acrivi t y, is an y work char has a beginning and an end and requires che use of
company resources such as people, time, or money. Examples of casks include conducting interviews, designing a report, select ing software, waiting for the delivery
of eq uipment, or training users. Tasks are basic units of work that the project
manager plans, schedules, and mon itors-so they should be relatively small and
manageable.
In add ition ro rasks, every project has events, or mile~tones. An event, or a milestone, is a recognizable reference point that can be used to monitor progress. For
example, an event might be the start of user training, the conversion of system data,
or the completion of interviews. A m.ilestone such as "complete 50% o f program testing" would not be useful informat ion unless it could be determined exactly w hen that
even c wi II occur.
Figure 3-5 shows casks and events chat might be invo lved in che creation, distribution, and tabulation of a questionnaire. Note that the beginning ::tnd end of
e::1ch cas k are marked by a recognizable eveor. It would be virtually impossible
to manage a projecr as one large cask. Instead, the project is broken down into
smaller tasks, creating a WBS. The first step in creating a \'(.!BS is to list all che
tasks.
(....,..... J:gi ( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,...... .,..~
-·~•-fllllie<'f •,...
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
__.~~ c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
79
3.2 Creating a Work Breakdown Structure
All
Start work oo
ques110no8"•
Tabulate
Prepare
quesbonnaire
Prepare repon
Awart return of
questionnaJre
00
questioma&res
responses
quesbOMalre
resuhs
e
Evoot or Milestone
. . Task
FIGURE l -S Using a questionnaire requires a series of ta.sks and eventS to crack the progress.The 1ilustration
shows the relationship between the tasks and the eventS, or milestones, which mark the beginning and end of
each task.
While this step so unds simple, it can be c hallenging because
the rasks might be embedded in a document, such as d1e one shown in the first
version of Figure 3-6. One crick is ro srarr by highlighting the
individual casks, as !>hown in the second version. Adding bullets
makes the tal>k~ stand our more clearly, as shown in the rbird
version. The next step is to number rhe casks and create a cable,
First, reserve the meeting room Then order
the marketing materials and brief the
similar to the one shown in Figure 3-7, with columns for cask
managers After the bne~ngs. send out
number, description, duration, and p redecessor ca sks, which
customer emails and upload program to the
LISTING THE TASKS:
muse be compleced before anocher rask can scan.
ESTIMATING TASK DURATION: Task duration can be hours,
days, or wceks--dependmg on the project. Because che following
example uses days, the units of measurement arc called person-days.
A pcrson-da) represents the work char one person can complete in
one day. This approach, howe\re~ can present some problems. For
example, if it will cake one person 20 days to perform a particular
cask, it might not be t rue that two people couJd complete chc same
task in 10 days or that I0 people could perform tbe task in two
days. Some tasks can be divided evenly so it is possible to use different combinations of time and people--up to a point-bur not
all. in most sysrems analysis rasks, rime and people are not inter·
changeable. If one ana lyst needs two hours to interview a user, two
analysrs a lso will need two hours co do the same interview.
Project managers often use a weighted formula for estimating
the durarion of each cask. T he project manager fixst ma kes three
time esrimatcl> for each cask: an optimisric, or bes t-case e~ timatc
(B), a prob ablc-ca\c e~ timate (P), and a pessimisric, or wo rse-case
e~ timatc (W ). T he manager rhen assigns a weight, which is an
importance value, to each estimate. The weight can vary, bur a
common approach i'i to use a ratio of B = 1, P = 4, and W = J.
Tbe expected task duration is calculated as follows:
(B+4P+W)
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ..............
__....
Firs1. rr;
ve t
t>
'"'9 ,..,
o.... Then orcJer
and b · I the
manat "' After lhe bnefings, nd out
cus:onn r m s and ''' IOad progrNn to It>"
app store. When the emails are soot and the
program is available on the a.pp store ready,
ioad tt>e ne,. ul!wa,,. When the marketing
erials have amved and the software 1s ready.
a dr'"' rthearsal.
,.,.
mr
-----
• First, reserve tho mooting room.
• Then order rhe mar~ellflg materi&/$ and brief
the manage1S.
• Aller the briefings, sand out customer omalls
and upload program to the app store.
• When the emails are sent and the program is
available on the opp store ready, load !he
now solrware.
• When the mart<ehng materials have arrived
and the software Is ready, do a dre~s rohearsal.
FIGURE l-6 The three versions show how to
transform a wk scatement into a list of specific
casks for a work breakdown strucwre.
6
.........""_.. ... .-.................
app store When lhe emails are sent and lhe
program is available on the app store ready,
load the new software. When the mar!(ebng
materiats have emved and the software is ready,
do a dress rehearsal.
--
........... ......
. ,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
~~·~---- ···---~~-.,.-"~
Chapter 3
Managing Systems Projects
3.2 Creating a Work Breakdow n Structure
80
•
Description
Duration
(Days)
Predecessor
Tasks
Reserve the meeting room
2
O rder the marketing materials
3
4
Brief the managers
5
Send out customer emails
Upload program to the app store ......._ _ ___.._ _ _ __.....
6
Load the new software
7
Do a dress rehearsal
FIG URE 3-7 In this table, columns hM! been addl!d for wk number,descripuon.
duration. and predecessor casks, which mun be completed before another task can start.
For example, a projecr manager mighr estimare rhar a file-conversion task could be
completed in as few as 20 days or could take as many as 34 days, bur most likely will
require 24 days. Using the form ula, the expected task dura rion is 25 days, calculated
as follows:
(20 + (4 *24) +34 ) = 25
6
A lively discussion is under way at Sunrise Software, where you are a project manager.
The main question is whether the person-days concept has limitations. In other words.
if a task will require I00 person-days. does it matter whethe r two people in SO days,
five peo ple in 20 days, ten people in I 0 days, or some other combination that adds up
to I 00 performs the work?
Two programmers on the project seem to think it doesn't matter. O n the other hand,
o ne of the project's systems analysts says it is ridiculous to think that any combination
would work.To support his point, this extreme example was offered: Could 100 people
accomplish a task estimated at 100 person-days in one day?
Is the systems analyst correct? If so. what are the limits in the "people versus days"
equat ion?Taking the concept a step further. is there an optimum numbe r of people to be
assigned to a task! If so, how would that number be determined? You need to offer some
guidance at the next project team meeting.What will you say!
3.2.4 Factors Affecting Duration
When developing duration estimates, project managers consider fou r factors:
I . Project size
2. 1luman resources
3. Experience with similar projects
4. Constraints
PROJECT SIZE: As described in Chapter 1, infom1acion systems have various charactcr-
iscics char affect their complex:iry and cost. ln addition to considering chose factors, a project manager must estimate rhc time required to complete each proje<.1: phase.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Phase I
Systems Planning
81
3.2 Creating a Work Breakdown Structure
To develop accurate esrimaces, a project manager must identify all project tasks, from
initial fact-finding to system implementation. Regardless of the systems development
methodology used, the project manager must determine how much time will be needed
to perform each task. In de,·eloping an estimate, che project manager must allow rime
for meetings, project re\'iews, craining, and any ocher factors (e.g., scheduled vacations or
unscheduled medical leave) that could affect che productivity of the development team.
HUMAN RESOURCES: Companies muse invest heavily in cutting-edge technology to
remain competici\'e in a connected world. ln many areas, skilled IT profes ionals arc
in greac demand, and firms must work hard to attract and retain the talent they need.
A project manager must assemble and guide a development team that has the skill and
experience to handle the project. lf necessary, additional systems analysts or programmers
111ust be hired or crained, and this must be accomplished within a specific time frame.
After a project gets under way, rhe project manager muse deal with curnover, job vacancies, and escalating salaries in rhe redu1ology sector-all of which can aHect whether che
project can be completed on time and within budget. The project manager also has to
accommodate official holidays, family emergencies, and other events that may affect the
schedule.
EXPERIENCE WITH SIMILAR PROJECTS: A project manager can develop rime and
cost estimates based on the resources used for si1nilar, previously developed information systems. The experience merhod works besc for small- or medium-sized projeccs
where the two systems are similar in size, basic content, and operating environment.
In large systems with more variables, the estimates are less reliable.
CONSTRAINTS: Chapter 2 explained chat constraints are defined during the prelim-
inary investigation. A constraint is a condition, restriction, or requirement chat the system must sarisfy. For example, a constraint might involve maximums for one or more
resources, such as time, dollars, or people. A project manager must define system requirements that can be achieved realistically within the required constraints. In the absence of
constraints, the project manager simply calculates the resources needed. 1lowever, if constraints arc presenr, the project manager must adjust other resources or change the scope
of the project. TI1is approach is similar to the what-if analysis described in Chapter 12.
3.2.S Displaying the Work Breakdown Structure
After the task durations are entered, the \X'BS will look like Figure 3 -8. Task
groups can be used to manage a complex project with many tasks, just as with a
Description
Duration
(Days)
Predecessor
Tasks
Reserve the meeting room
Order the marketing materials
9
Brief the managers
Send out customer emails
2
3
3
6
Upload program to the app store
Load the new software
7
Do a dress rehearsal
2
3
"s
2
FIGURE 3·8 Task duraoons have been added, and the WBS is complete except for
predecessor ask information.The predecessor tasks will determine task ~tterns and
sequence or performance.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
--
........... ......
"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
__....
~~·~---- ···---~~ - .,.-"~
Chapter 3
Managing Systems Projects
3.3 Task Patterns
82
Gantt chart, to simplify the list. Nore rhat the WBS shown in Figure 3-8 is still
incomplete: It does nor show fields such as Starr Date, End Dare, Tas k ame,
Duration, and Predecessors-fields thar can be ke)' for project managers. \Vith
~1icrosoft Project, the \VBS (i ncluding some of these missing fields) might resemble Figure 3-9.
·--- ·-·-. .. _____
.,_ ,_ _
....
. ---·-- ......
.......
....
- - - :=,.::..--- ... ·..................... .... ........
...
_
..
_
.....
.....
_____
I
·..... ...
·I ...................
...............
............... ·.... ...
..
....
..
--·.
.
·- ·-
-... ..
.. e.. •
ct:= "-:- #,_,.,'- I
I
t
~ • · ~.I -
.
..
.
"'\
• o • ....,_
::--- ::.
:J .....
...,_
B
, ::
--:::~
;
•
-
.....
,,_...... .......,........,
• •
FIGURE 3-9 This Microsoft Project screen displays the same WBS, including task number. task name, duration.
and predecessor tasks.
3.3 TASK PATTERNS
Tasks in a WBS must be arranged in a logical sequence called a ta\k pattern. In
any project, la rge or small, casks depend on each other and must be performed in a
sequence, not unlike the commands in a software program. Task patterns can involve
dependent rasks, multiple successor tasks, and mulciplc predecessor rasks. In larger
projecrs, these patterns can be very complex, and an analyst must study the logical
flow carefully. This section explains how to understand and create graphical models
of these patterns.
3.3. 1 Using Task Boxes to Create a Mode l
In a PERT/CPM chart, project tasks a re shown as rectangular boxes, arranged in the
sequence m which they must be performed. Each rectangular box, called a w k box, has
five sections, as shown in Figure 3- J 0. Each section of the task box contains important
infon11ation about the task, including the Task Name, Task ID, Task Duration, Start Day/
Date, and Finish Day/Date.
TASK NAME: The task name should be brief and descriptive, bur it
docs not ha ve to be uJlique in the project. For example, a cask named
Conducr Interviews might occur in several phases of the project.
TASK BOX FORMAT
TASK ID: The task ID can be a number or code that provides unique
id en ti ficati<>n.
Task Name
Start Day/Date
TASK DURATION: The duration is the amount of time it will rake to
Task ID
Finish Day/Date Task DuratlOO
FIGURE 3-10 Each section of the task
box concains important Information
about the cask. including the Task Name.
Task ID. Task Duration. Start Day/Date.
and Fmish Day/Date.
(....,..... J:gi( . . . . .
complete a task, which is not necessarily the same as rhe e lapsed rime.
For example, a cask that takes eight botirs of effort to complete would
be done in o ne day by a person dedicated lOOo/o, but if the person
assigned this task is only working 50% on this project, the task would
take rwo days elapsed time to complete. All tasks must use the same
time units, which can be hours, days, weeks, or months, depending on
the project. An actual project scans on a specific date bur can also be
measured from a point in rime, such as Day J.
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,...... .,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
__.~~ c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
83
3.3 Task Patterns
START DAY/DATE: The stan day/date is the time that a rask is scheduled to begin. For
example, suppose that a simple project has cwo tasks: Task 1 and Task 2. Also suppose
that Task 2 cannot begin until Task 1 is finished. An analogy might be that a program
cannot run until che compurer is turned on. If Task 1 begins on Day 1 and has duration of
three days, it will finish on Day 3. Because Task 2 cannot begin until Task I is completed,
the start rime for Ta~k 2 is Day 4, which is the day after Task 1 is finished.
FINISH DAY/DATE: The finish day/date is the time that a task is scheduled for com-
pletion. To calculate the finish day or date, add tbe duration to the start day or date.
\Vhen doing this, be very careful not to add too many days. For example, if a task
starts on Day I 0 and has duration of five days, then the finish date would be on Day
14-not Day 15.
3.3.2 Task Pattern Types
A project is based on a pattern of casks. In a large project, the
overall parrern would be quire complex, bur it can be broken
down inco three basic rypes of parrerns: dependent casks,
multiple i.uccessor rasks, and multiple predecessor tasks.
When casks must be completed one
after another, like the relay race shown in Figure 3-11 , they are
called dependent task~ because one depends on the other. For
example, Figure 3-12 shows that Task 2 depends on Task 1,
DEPENDENT TASKS:
FIGURE l - 11 In a relay race. each runner is
dependent on the preceding runner and cannot start
because Task 2 can nor start unril Task 1 is completed. In this
until me earlier finishes.
example, the finish time of Task 1, Day 5, controls the start dare of Task 2, which is Day 6.
Y-
MULTIPLE SUCCESSOR TASKS: \Xlhen Se\•eral
tasks can start at the same time, each 1s cilled a
concurrent ta~!.. . Often, rwo or more concurrent
tasks depend on a single prior task, which is called
a predeces~or cask. In this situation, each concurrent task is called a ~ucc~sor task. In the example
shown in Figure 3 -13, ~ucces or Tasks 2 and 3 both
can begin as soon as Task I is finished. ore that
the finish time for Task l determines the start time
for both Tasks 2 and 3. In other words, the earliest
that Task l can finish is Day 30, so Day 31 is the
earliest that Tasks 2 and 3 can start.
Suppose
t hat a task requires two o r more prior tasks to
be completed before it can start. Figure 3- 14
shows that example because Task 3 cannot begin
until Tasks 1 and 2 arc both completed. Since
the rwo tasks might not finish at the same time,
the longest (larcsr) predecessor rask becomes the
controlling factor. Note char rhe srarr for Task 3
is Day 16, nor Day 6. \'V'hy is chis so? Because
Task 3 depends on two predecessor tasks, Tasks 1
and 2, Task 3 cannot begin until the later of those
MULTIPLE PREDECESSOR TASKS:
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
Fn
E XA~I PLE OF A DEPEN DE NT TASK
Prepare Oull"'8
Start Day 1
ID 1
Finish. Day S
Dur S
CtNlllOocumenl
..
Start Day6
ID. 2
An1sh Day 14 Dur 9
FIGURE l-12 This example of a dependent iask shows that the fontsh
cme ofTask I. Day s. controls me start date of Task 2. which tS Day 6.
EXAMPLE O F MULTIPL E SUCCE SSOR TASKS
Arrange Interviews
Develop Plan
,J4 S1ar1: Day 31
Finish· Day 60
Slart Day 1
ID: 1
Finish: Day 30
Dur 30
~
ID: 2
Dur30
Design Survey
Start Day 31
ID 3
Finish Dey 40
Dur 10
FIGURE 3- 1l This example of multiple successor wlc.s shows that me
finish ame for Task I detennines the Start ome lo<' both Tasks 2 and 3.
--
........... ......
"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ..... ...... ... ~..
__....
~~·~----···---~~ - .,.-" ~
Chapter 3
Managing Systems Projects
3.3 Task Patterns
84
EXAMPLE OF MJLTIPLE PREDECESSOFl TASi<S
aic.ri Authonullon
Start Day 1
10 1
Fi111Sh; Day 15
°"'
[\
Conduct 1i .........
15
Start Day 16
Cnlale Job Oeecripl!On
ID 3
~ Anlsh: Day 45 Our30
Slllrt Day 1
10 2
Aoish Oay5
0urs
tasks is complete. Therefore, the start time for a
successor rask must be the latest {largest} finish
time for any of its preceding rasks. In the example
shown, Task I ends on Da)' 15, while Task 2 ends
on Day 5, so Task 1 control~ the srarr time for
Task 3.
Task pattern type~ are idenufied by looking carefully at the wording of the task sratemcnt. Words
like then, when, or and are action words that
signal a sequence of events. Here are three simple
examples:
• Do Task 1, then do Task 2 describes dependent
tasks char must be completed one after rhe
ocher.
• When Task 2 is finished, start rwo tasks: Task
3 and Task 4 describe multiple successor tasks
that can both start as soon as Task 2 is finished.
W/Jen Tasks 5 and 6 are done, starr Task 7 indicates that Task 7 is a multiple
predecessor task bec3use ir ca11't srarr until rwo or more previous tasks all are
completed.
FIGURE 3· 14 This example of multiple predecessor tasks shows
that the start umc for a successor cask must be the latest (largest)
finish dme for any of lcs preceding tasks. In the example shown, Task I
ends on Day IS. while Task 2 ends on Day S, so Task I controls the
start time for Task 3.
•
3.3.3 Working with Complex Task Patterns
When several task patterns combine, rhe facts must be studied very carcfullr rounderstand the logic and sequeDce. A project schedule will nor he accurate if the underlying
rask pattern is incorrect. For example, consider the following three foct statements
and the rask patterns they represent. Examples of the task patterns are shown in
Figures 3-15, 3-16, and 3- 17.
1
1
I ·I
2
4
2
FIGURE 3 - 1S Dependent tasks.
1
FIGURE 3 - 16 Dependent tasks and multlple successor tasks.
2
FIGURE 3 - 17 Dependent tasks, muldple successor wks. and multiple
predecessor tasks.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
85
3.4 The Critical Path
DEPENDENT TASKS:
Perform Task 1. \Vhen Task 1 is complete, perform Task 2.
Perform Task I. \Xlhen
Task I is complete, perform Task 2. \Xlhen Task 2 is finished, start rwo tasks: Task 3
and Task 4. \Vhen Task 3 1s complete, start two more tasks: Task 5 and Task 6.
DEPENDENT TASKS AND MULTIPLE SUCCESSOR TASKS:
DEPENDENT TASKS, MULTIPLE SUCCESSORTASKS, AND MULTIPLE
PRED ECESSO R TASKS: Perform Task 1. When Task 1 is complete, perform Task 2.
When Task 2 is finished, start cwo Tasks: Task 3 and Task 4. When Task 3 is complete, srart rwo more rasks: Task 5 and Task 6. When Tasks 5 and 6 arc done, srarr
Task 7. Then, when Tasks 4 and 7 arc finished, perform Task 8.
The project management team at Parallel Services is having a debate about how to define casks
In the WBS.The project manager wants to break wks down into the smallest possible units. For
example, she objected to a broad task statement called "Develop a training schedule.'' Instead,
she suggested three subwks: (I) "Determine availability of training room," (2) "Determine availability of attendees," and (3) "Select specific dates and training times.''
Another project team member disagrees. He feels that the broader task statement
is better because It allows more flexibility and will produce the same result. He says
that if you break tasks Into pieces that are too small, you r isk overmanaglng the work
and spending more t ime on mon itoring than actually performing the tasks. As a member of the team, wh ich approach do you agree with more? What are the pros and cons
of each?
3.4 T!-iE CRITICAL PATH
Task patterns determine rhe order in which rhe casks are performed. Once rhe rask
sequence has been defined, a project manager can schedule the rasks and calculate rhe
critical path. A critical path is a series of tasks chat, if delayed, would affect the completion dare of the overall projecr. If any cask on rhe critical path faUs behind schedule, the entire projecr will be delayed.
For example, suppose that Joan and Jim are invited to someone's home for dinner. Joan arrives on time, bur Jim arrives 30 minures !are. Jim's arrival is part of the
critical path because the host does not wane to start without him, so the meal will be
served 30 minutes later than originally planned.
Project managers always muse be aware of che critical parh, so they can respond
qu ickly co keep the project on track. Microsoft Project and other project management
software can highlight the series of tasks that forn1 the critical path.
3.4. 1 Calculating the Critical Path
Figure 3- J8 shows a rraining project with five tasks. Note that the analyst has
arranged the tasks and entered rask names, IDs, and durations. The task patterns
should be reviewed firsr. In this example, Task 1 js followed by Task 2, which is a
dependent task. Task 2 has nvo successor tasks: Task 3 and Task 4. Tasks 3 and 4 are
predecessor tasks for Task 5.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ . ....._.,.,.. o-... ..,._.,,.,.. _ ..,.~ ,........., ................. .._... .., .,. ..,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Chapter 3
Managing Systems Projects
3.4 The Critical Path
86
Plan Training
ID: 3
)"
Hire Analysl
Obtain Authorization
~
ID· 1
Dur : 5
~
Announce Training
tD· 5
ID: 2
Dur: 10
Arrange Logistics
Dur: 30
\.
ID: 4
Dur: 30
V'
Dur: 25
FIGURE 3 - 18 Example of a PERT/CPM chart with five tasks.Task 2 is a dependent task that has multiple successor tasks.Task S has
multiple predecessor tasks. In this figure, the analyst has arranged the casks and entered task names, IDs. and durations.
The next step is ro derermine srart and finish dates, which will determine the crirical path for rhe project. The following explanation outlines a step-by-srep process.
The result is shown in Figure 3-19.
• Task I starts on Day 1 and has duration of 10 days, so the finish date is Day 10.
• Task 2, which is dependent 011Task1, can start 011 Day 11-the day afcer Ta~k
I ends. Wirh duration of 30 days, Task 2 will end on Day 40.
• Tasks 3 and 4 are multiple successor tasks that can start after Task 2 is done.
Task 2 ends on Day 40, so Tasks 3 and 4 both can stare on Day 41. Task 3 has
duration of five days and wiU end 011 Day 45. Task 4 has duration of 25 days
and will nor end until Day 65.
• Task 5 depends on Tasks 3 and 4, which are multiple predecessors. Because
Task 5 depends on both tasks, it cannot srart until the later of the two tasks is
complete. In this example, Task 3 ends earlier, but Task 4 will not be completed
until Day 65, so Task 5 cannot srarr until Day 66.
Plan Training
Obtain Authorization
Start: Day 1
ID. 1
Finish: Day 1O Dur: 10
_.
Day 41 ID: 3
)" Start:
~
Finish: Day 45 Dur: 5
Hire Analyst
Start. Day 11
Announce Training
Start Day 66
ID:2
Arrange Logistics
Finish: Day 40 Our: 30
\.
Start: Day 41
ID: 4
ID: 5
Finish: Day 95 Dur: 30
V'
Finish: Day 65 Dur: 25
CRITICAL PATH:1·2·4·5
FIGURE 3- 19 Now the analyst has entered the start and finish times, using the rules explained in this section. Note that the overall
project has duration of 95 days.
Recall char the critical path is a series of tasks chat, if delayed, would affccr rhc final
complcrion dace of rhe overall project. In this exan1plc, Tasks 1 and 2 arc the first casks
on rhc crirical path. Now look ar Task 5, which cannot start until borh Tasks 3 and 4
arc done. In chis case, Task 4 is the controlling factor because Task 4 finishes on Day 65,
which is 20 days larer than Task 3, which is completed on Day 45. Therefore, rhe start
dare for Task 5 is determined by the finish date for Task 4.
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
87
3.6 Reporting
In contrast, Task 3 has slack rime and could be delayed up to 20 days wirhour
affecting Task 5. Slack rime is the amount of rime rhar the rask could be late without
pushing back the completion dare of the entire project. Tasks 1, 2, 4, and 5 repre ent
the critical path, which i highlighted with red arrows in Figure 3-19.
3.5 PROJECT MONITORING A~D CONTROL
Regardless of whether the project was planned and scheduled wirh projccr management
software or in some other manner, the project manager mUSt keep track of rhe casks and
progress of ream members, compare acrual progress with the project plan, verify the completion of project milestones, and set standards and ensure thar they are followed.
3.S. I Monitoring and Control Techniques
To help en!.ure rhar qualiry standards are met, many project managers institute
structured walk-th roughs. A structured walk-through is a review of a project team
member's work hy orher members of rhe ream. Generally, systems analysts review the
work of other sybtems analysts, and programn1ers review the work of other programmers, as a form of peer review. Structured walk-throughs take place throughout the
SDLC and are called de!.ign reviews, code reviews, or testing review!., depending on
the phase in which they occur.
3.S.2 Maintaining a Schedule
Mainraimng a project schedule can be challenging, and most projccrs run into at least
some problems or dela ys. By monitoring and controlling the work, the project manager tries to anticipate problems, avoid them or minimize their impact, ide ntify potential solutions, and select the best way to solve the problem.
The better the original plan, the easier it will be to control the project. If clear,
verifiable milcsrones exist, ir will be simple ro determine if and when rhosc rargcts
arc achieved. If enough milestones and frcquenr checkpoints exist, problems will be
dcrccted rapidly. A project chat is planned and scheduled wirb PERT/CPM or in a
\'(18$ with Gantt charr can be tracked and controlled using these same techniques. As
work continues, the project manager revises che plan ro record acrual times for completed casks and revises rimes for tasks that are nor ycr finished.
3.S.3 Tasks and the Critical Path
Project managers spend mosr of rheir time cracking rhc tasks along rhe critical path
because delays in rhose rasks have rhe greatest porenrial to delay or jeopardize the project.
Orhcr tasks cannot be ignored, however. For example, suppose that a rask nor on the critical path rakes roo long and dcpleres the allotted slack time. Ar that point, the rask acruall)•
becomes part of rhe crirical path, and any further delay will push back the overall project.
3.6 REPORTING
Members of the project team regularly report their progress ro che project manager,
who in rurn reports ro management and users. The project manager collcccs, verifies,
organizes, and evaluates the information he or she receh·es from the ream. Then the
manager decides which information needs to be passed along, prepares a summary
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 3
Managing Systems Projects
3.6 Reporting
88
that can be undersrood easily, adds comments and explanations if needed, and s ubmits it to management and users.
3.6.1 Project Status Meetings
Project manager , like the one shown in Figure 3-20, schedule regular meermgs to
update the ream and discuss project status, issues, problems, and opportunitie .
Although meeting can be time consuming, most pro1ect managers believe they are
worth the effort. The sessions give team members an opportunity to share information, discuss common problems, and explain new techniques. The meetings also
give the project manager an opportunity to seek input and conduct brainstorming
sessions.
FIGURE 3·20 Project managers schedule regular meetings to update the project team and discuss
project staws. Issues. problems. and opportunities.
t
~....
llf~
3.6.2 Project Status Reports
A project manager must report regularly co hjs or her immediate s upervisor, upper
management, and users. Although a progress report might be given verha lly co an
immediate supervisor, reports to management and users ui.ually are written. Ganrr
chartS often are included in progress reports to show project status graphically.
3.6.3 Dealing with Problems
Deciding how to handle porenrial problems can be difficult. At what point should
management be informed about the possibility of cost overruns, schedule delays, or
technical problems? At one extreme is the overly cautious project manager who alerts
management to every potential snag and slight delay. The danger here is that the manager loses credibility over a period of time, and management might ignore potentially
serious situations. At the other extreme is the project manager who tries to handle all
situations single-handedly and does not alert management until a problem is serious.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
89
3.7 Project Management Software
By the rime management learns of the problem, linle time might remain in which to
react or devise a solution.
A project manager's best course of action lies somewhere berwcen the rwo extremes
but is probably closer co the first. If the con.sequences are unclear, the analy t hould err
on the ide of caution and warn management about the possibility of a problem.
\Xlhen the s1ruarion 1 reported, explain what is being done to handle and monitor
the problem. If the siruarion is beyond the analyst's control, suggest possible acnons that
management can rake to resolve the siruarion. Most managers recognii.e that problems do
occur on mo t project ; 1t is berrer to alen management sooner rather than later.
J. 7 PROIECT MANAGEMENT SOFTWARE
Project managers use sofrware applications to help plan, schedule, monitor, and
report on a project. Most programs offer features such as PERT/CPM, Gann charts,
resource scheduling, project calendars, a nd cost tracking. As shown in Figure 3-2 1,
M icrosoft Pro ject is a full -featured program that holds the domi nant share of the
market. Ir is available as a software product for W indows and as an add-on on line
service as parr of i\llicrosoft's Office 365.
-- -·- - - -
,_
__
....
°"'......,
Project
Project management
.......
.__
M~l'nlfe<thelperou,etnanod
......, _ _ .....i---.--1n......,..i.--..o........,_help,.....
,_,....,,., ..... twnl s\ey pr I d~ C'liv..
FIGURE 3-2 1 Microsoft Proje~
'°"ref': ,.. '
C I
In addition to 1\i1icrosofr Project, there are a number of other project management
tools available. For example, GanttProiect is a free open-source Java-based project
management too l that is available on multiple platforms (Windows, Mac OS X, and
Linux). It can produce Ga ntt and PERT/CPM charts, calculate the critical path auto·
marically, and read/write M icrosofr Project files .
Canlter is a free cloud-based project management tool. It runs in a browser window, so there's no sofrware to install to use it. Apptivo and smartsheel are other
example~ of web-ba~ed project management tools offering simi lar capabilities but on
a paid subscription model.
Monday is a project management tool that is 11:ailored toward Mac u ers. As
shown in Figure 3-22, it is a highly visual cloud-based tool that supports agile development. Trello, shown in Figure 3-23, is aoorher project management tool that is tailored toward agile development.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 3
Managing Systems Projects
3.7 Project Management Software
90
A new way to manage your projects
Pion Orgon11e Trock In one VISUO~ colloboroltve space
..
,;
Sprint
0
Spmt2(TMWffli)
II
11> ...
Allignfl
p""' ...., ~...
""""'°Pon:..
"-••Part. IOM brnp
1
"'9
" ii ' '!M
Spr1m 1 (IA11 _ ,
s..1...
I ,,,... .......
I
---Ito-.
c1o,.
HOllWl>lge
OJllayo
Fdrurt
Ollllyt
Epoc
Ettlf'l'lll~
lkJ9
02doft
Hew
0
E111m1110n
Epic
St11u1
,....,.
0
01-,.
I g
-
u.,.
FIGURE 3-22 Monday is a project management tool that is tailored toward Mac users.
Sour«<
...,
............
•
_a
,_
Don'•--~
n
...
U t ............ ~CNdft!A
,,.,,...n.n orH'*9 1 filil "°"1 • Ofll.
Ill
• tt• fD
~
,_., o..g.
_____
~r
-
a
'*•••
,
•
"'
-
FIGURE 3. 23 Trello is a project management tool that is tailored toward agile development.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f •,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
91
3.7 Project M anagement Software
The websites for all of rhese cools have more information about their capabilmes,
including demos, trial versions (where applicable), and rraining material.
Lrrespective of which projecr management tool used, a seep-by-seep process is
followed co develop a WBS, work wirh cask patterns, and aoal)'ze cbe critical path.
Tbe main difference is thar the sofrware does most of cbe work automatically, which
enables much more effective managemenr.
The followmg secnons explain how ~licrosofr Project could be used to handle
the sample cask summary for a preliminary investigation shown in Figure 3-24. This
example illusrrares that project management is dynamic and challenging. One significant advamagc of intcgraced project 1nanagement software is that it allows the proiecc
manager to adjust schedules, estimates, and resource assignments rapidly in response
to real-world evenrs.
PIMH etucty the following t.ak aunnMry:
• First. we need to spend one day studying potential problems or opportunities.
• Then. we will define the project scope and constraints. That will take two days.
• Next, we will a11&lyze the organization ollarts That will take one day.
• After we analyze the charts. tour fact.finding tasl<s can start at once
' Observe operabons (two days)
> Conduct a user survey (three days)
> Conduct 11\terv- (two days)
> Review dOcumentatlOO (One day)
• When alt lour fact-finding tasks are fil'llShed, we win spend one day evaluating leasibilly
• Then we wlll spend one day presenllng the resuns and recommendallons to management.
FIGU RE 3-24 A sample ask summary for a preliminary investig;itiOfl.
WORK BREAKDOWN STRUCTURE: Creating a WBS usmg Microsoft Project is
much the same as creating it manually. The tasks, durations, and task pacterns mu~t
still be identified. This informauon might have to be developed, or a task summary
like the one in Figure 3-24 might be used. The goal is co document all casks, dependencies, dac~, and total projecr durarion. The first step is to create a Gann chart
showing the necessary information. As the information for each task is entered into
Microsoft Project, the duration and the predecessor tasks, if any, should also be
noted.
GANTT CHART: As casks arc entered, the progcam automatically performs the
c::ilculations, detect~ the task patterns, and creates a Gann chart. The charr consists
of horizontal bars, connected with arrows that indicate task dependencies. If a typical workweek is selected, casks wi ll not be scheduled on Saturdays and Sundays.
However, for a mission-critica l project, a 24/7 calendar might be created. Whatever
is specified, the program will handle che tasks accordingly. Microsoft Project offers
numerous choice~ of display senings, formats, and calculation methods.
NETWORK DIAGRAM: After the Gann chart is completed, rhe darn can he viewed
in the form of a tvlicrosoft Project network diagram, which is simil::ir to a PERT
chart. When rhe Network Diagram option is selected, the project tasks, dependencies,
and stare and finish dares for each task are shown. A network diagram displays the
same information as the Gantt chart, including cask dependencies, but use task boxes
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 3
Managing Systems Projects
3.7 Project Management Software
92
to include much more derail. Using Microsoft Projecr, each cask can be assigned to
one or more people, budgets can be assigned targets, progress reports produced, and
schedules and deadlines readjusted as necessary.
CALENDAR VIEW: Calendar view is a good way to manage da y-to-da)' activity. This
view !.hows the tasks, simila r to a PERT charr, as an overlay on the actual calendar.
Because the criucal path is highlighted in red, it is easy for a project manager to determine priorities at any poim in rime.
Suppose the project manager wants to view the preliminary investigation in
Figure 3-24 as a Gantt chart, a PERT chan, and a day-to-day calendar. All three views are
shown in Figure 3-25. Each view sbo\vs the tasks, tbe riming, the dependencies, and the
critical parh. Note rhat of the four tasks scheduled for September 25, onl)1 the user surve)'
is on rhe critical path, therefore that should be rbe project manager's primary concen1.
Gantt Chart View
.....
.........................,.......
.... ,o.e-,,,.,...............
·~~..........
•9\"
...........,.._.....
....,......
-·---...................
. ..
.,..,..... '
...·-... ''
....
• .,.-.-_....,...
I
i
~·
u ....
~-
~.-.........
-
·-
_ • .,....... ....................... t_.
... fl'lllWllll.......
. ....
---···· .
..............
-
PERT Chart View
..
-..._
--·
......... u
••
-·--•ft•
•• _
h_..,, ...
.. -....... ...,_
......."" . ....
• •.
.. .-.......
........ ·~-
~
~
-
.... .........-......·
~
'+
.... fl'Wl1
...
,._,., WV.•
., •
.... I...,.
C11lendarVlew
l1 ~_ _ _ _ _ _ _ 2t.
,----~-----'-'
FIGU RE 3-2S Note how each view displays tile project and highlights tile crttial patll If you were the
project manager on September 25, your primary concern should be conduct1ng tile user survey.
(....,..... J:gi ( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,...... .,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
__.~~ c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
93
3.8 Risk Management
J.8 RisK MANAGEMENT
Every IT project involves risks that systems analysts and project managers must
address. A risk is an event char could affect the project negati\·ely. Risk management
is the process of identifying, analrzing, anriciparing, and monitoring risks to minimize
their impact on the projecr.
Although project management experts differ \vith regard to the number of seeps or
phases, a basic list of risk management casks would include rhe following:
•
Develop a risk ma11ageme11t plan. A risk management plan includes a review
of the project's scope, stakeholders, budget, schedule, and any other internal
or external factors t hat might affect the project. The plan should define project
roles and responsibilities, risk management methods and procedures, categories
of risks, and contingency plans.
• fdenti(y tl1e risks. Ri\k identification lists each risk and as~esses the likelihood
that it could affect the project. The derails ·w ould depend on the specific projCl't, but most lists would include a mean~ of identification, and a brief description of the risk, what might cause it to occur, who would be responsible for
responding, and t he potential impact of the ris k.
• Analyze the risks. This typically is a rwo-step process: Qua litative risk analysis
and quantitative risk analysis. Qualitative risk analysis evaluates each risk by
estimating the probability that it will occur and the degree of impact. Project
managers can u~e a formula to weigh risk and impact values, or they can display the result~ in a two-axis grid. For example, a Microsoft Excel XY chart
can be used ro display rhc marrix, as shown in Figure 3-26. In rhe chart, norc
the various combinarions of risk and impact racings for the five sample values.
This tool can help a project manager focus on the most critical areas, where
risk probability and porenrial impact are high.
High impact
Low probability
High impact
•
High probability
Risk Matrix
10..->o~---~-------~~~~~~~
Medium impact
Medium probabt~ty
9
•
8
7
t;
"'
8
5
~
-"
.!!
Low Impact
High probability
4
a:
3
2
1
0 *-~~~~~~~~~~~~~..;..-~~~~--!
3
4
5
6
7
8
9
10
.--~'"-----. 2
Low Impact
Low probabiltty
4
4
t
•
Risk Probability
.:. ~ ------
~·
•
•
FIGURE 3-2 6 You can use a Microsoft Excel XY chart cype to display a nsk rmtr1x
that shows risk probability and potential impact.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 3
Managing Systems Projects
3.9 Managing for Success
94
The purpose of quantitative risk analysis is to understand rhe actual impact in
terms of dollars, rime, project scope, o r quality. Quantitative risk analysis can involve
a modeling process called what-if analysis, which allows a project manager ro var)'
one or more elemenr(s) in a model to measure the effect on other elements. This topic
is di5cu5scd in more detail in Chapter 12.
•
•
Create a risk response plan. A risk response plan is a proactive effort ro
anticipate a risk and describe an acrion plan to deal with 1t. An effective risk
response plan can reduce the overall impact by triggering rimely and appropriate acnon.
Monitor risks. This activity is ongoing throughout the risk management process. Ir is important to conduct a continuous tracking process that can identify
new risks, note changes in existing risks, a nd update any other areas of rhe risk
management pla11.
Forrunarely, there is a wide variety of risk ma nagement ~ofrware available to help
a project manager with these casks. Most packages allow a project manager to assign
specific dares as constra ints, a lign task dependencies, note external factors rh a t might
affect a task, track progress, and displa)' casks that a re behind schedule. Armed with
rhis information, the IT ream can quantify the project's risks, just as rhcy use financia l
analysis tools to quantify costs and benefits.
3.9 MANAGING FOR SUCCESS
Project management is a challenging task. Project managers musr he alert, rcchnically
competent, and highly resourceful. They also must be good communicators with
strong human resource skills. Project managers can be proud when they handle a succes-;ful project that helps rhe company achieve irs business objecrive5.
Unfortunately, projects can and do get derailed for a wide variety of reasons.
\'<'hen problems occur, the project manager's abiliry to handle the siruarion becomes
t he crincal factor. When a project manager first recognizes that a project 1s 111 trouble,
what options arc available? Alternatives can include t rimming the project requirements, adding to the project resources, delaying the project deadline, and improving
management controls and procedures. Sometimes, when a project experiences delays
or cosc overruns, the system still can be delivered o n time and within budget if several less critical requirements are trimmed. The system can be delivered to satisfy the
mosr necessary requ iremen ts, and additional features can be added later as a part of a
ma intenance or enhancement project.
If a project is in trouble because of a lack of resources or o rga nizational support,
management 1night be willing to give rhe project more commitment and higher priority. For example, ma nagement might agree to add mo re people to a project that is
behind schedule. Adding staff, however, will reduce the project's completio n time o nly
if the addiciona I people can be integrated effectively into the development team. If
tea m members lack experience with certain aspects of the req uired technology, temporary he lp might be o bta ined from IT consultants or part-time staff. Adding sraff
can mean t rai ning a nd o rienting the new people, however. In some situations, adding
more people to a project actually might increase the time necessary ro complete the
project because of a principle called Brooks' law. Frederick Brooks, Jr., then an IBM
engineer, observed that add ing manpower to a late software project only makes it
lacer. Brooks reached this conclusion when he saw that new workers on a project first
had to be educated and instructed by existing empl oyee~ whose own productiviry was
reduced according!)'.
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
3.9 Managing for Success
To be successful, an informarion sysrem muse satisfy business requiremenrs,
sray wichin budger, be complered on rime, and-mosr imporranr of all-be managed effectively. As stated earlier and derailed next, when a project develops
problems, the reasons typically involve business, budget, or schedule issues, as
explained in the followmg sections. In addition ro planning and managmg the
project, a project manager must be able to recognize these problems and deal with
them effectively.
You are a systems analyst at Just-In-Time Software. a company that specializes in short delivery
cycles for itS products.The current project is running ~hind schedule, and the project manager
wantS to bring a few extra programmers onboard co help with the work.
You are familiar with Brook's Law. How can you best explain co the project manager
that adding more people co che project at this late stage may make things worse1 You
don 't want co be seen as a negative team player. but you're convinced that If you don't
speak up. the project's schedule will slip even more.
3.9. I Business Issues
TI1e major objective of every system is to provide a solution co a business problem or
opportunity. If the system docs nor do this, then it is a failure-regardless of positive
reaction from users, acceptable budget performance, or timely delivery. When the
information system does nor meet business requirements, causes can include unidentified or unclear requirements, inadequarely defined scope, imprecise targers, shortcuts
or sloppy work during systems analysis, poor design choices, insufficienr resting or
inadequate tcstmg procedures, and lack of change control procedures. Systems also
fail because of changes in the organization's culrure, funding, or objectives. A system chat falls short of business needs also produces problems for users and reduces
employee morale and productivity.
As explained in Chapter 2, projecrs without clear scope definitions are risky
because they rend to expand gradually, wfrhout specific authorization, in a process
called project creep. However, even when a project is clearly described, ir must be
managed consrnnrly.
3.9.2 Budget Issues
Cost overruns rypically resu lt from one or more o f the following:
•
•
•
•
•
Unrcalisric estimates that are roo o ptimisric or based on incomplete
information
Failure w devel<>p an accurate forecast chat considers all costs over the life of
the project
Poor monitoring of progress and slow response to early warning signs of
problems
Schedule delays due ro focrors chat were nor foreseen
Human resource issues, including mrnover, inadequate training, and
motivation
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
95
Chapter 3
Managing Systems Projects
3.10 Summary
96
3.9.3 Sc hedule Issues
Problems with timetables and project milestones can indicate a failure co recognize
task dependencies, confusion between effort and progress, poor monitoring and
control methods, personality conAicrs among ream members, or cu mover of
project personnel. The failure of an IT project also can be caused by poor pro1ect
management techniques.
If the project manager fails co plan, staff, organi1_e, supervise, communicate, monvate, evaluate, direct, and control properly, then t he project is certain co foil. Even
when factors outside his or her control contribute to the fai lure, the project manager
is responsible for recogn izing the early warning signs a nd handling chem effectively.
"Better blow the whistle," says your friend and project teammate at work."The project
is out of control, and you know it!" " Maybe so," you respond, "But that's not my call- I'm
not the project manager." What you don't say is that the project manager feels like her
career is on the line. and she is reluctant to bring bad news to management at this time.
She honestly believes t hat the project can catch up and says that a bad report on a major
project could resu lt in bad publicity for the firm and frighten potential customers.
To be fair. the next management progress report is scheduled in three weeks. It is
possible that the team could catch up. but you doubt it. You wonder if there is an ethical
question here: Even though the report isn't due yet. should a significant problem be
reported to management as soon as possible I You are concerned about the issue, and you
decide to discuss it with Stephanie. What will you say to her1
3 IQ SUMMARY
Project management is the process of planning, scheduling, monitoring, and reporting on rhe development of an information system. Plan ning includes identifying all
project tasks and esrimaring the completion rime and coM of each. Project scheduling
involves rhe crearion of a specific timetable, u!.ualJy in che form of charts t har show
casks, cask dependencies, and critical tasks char might delay rhe project. Projecr monitoring requires guiding, supervising, and coordinating the project ream\ workload.
The project manager muse monito r the progress, eva luate the results, and cake corrective action when necessa ry to contro l the project and stay o n carget. Project reporting
includes regu la r progress reports ro management, users, a nd the project rea m itself.
Effective reporting requi res st rong communication skills a nd a sense of what others
wa nt and need ro know a bo ut the project. A successful project must be com pleted on
time, be within b udget, and deliver a quality pro duct that satisfies users and meets
requiremen cs.
A project t riangle shows three legs: project cost, scope, and time. A project manager musr find rhe besr balance amo ng these clemeDrs because a change in any leg of
rhc triangle will affccr rhe orher two legs. Project management techniques can be used
rhroughour rhe SDLC.
Planning, scheduling, monitoring, and reporting-all rake place within a larger
project development framework, \vh.ich includes three key steps: creating a WBS,
identifying task parrerns, and calcula ting the critical path. A WBS must clearly
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Phase I
Systems Planning
97
3.10 Summary
idenrify each task and include an estimated duration. A rask, or activity, is any work
that has a beginning and an end and requires the use of company resources such as
people, rime, or mone)•. Time and cost esrimares for rasks usually are made m personda)'s. A person-day represents the work rhac one person can accomphsh in one day.
Esnmaring the rime for project activities is more difficult with larger systems. Project
managers musr consider rhe project size and scope, IT resources, prior experience
with similar pro1eccs or systems, and applicable constraints. In addition to tasks, every
project has cvenrs, or mile!>tones. An event, or a milestone, is a recognizable reference
point rhat can be used ro monitor progress.
Task patterns establish the sequence of work in a project. Task patterns involve
dependent casks, mulriple successor tasks, and multiple predecessor tasks. In larger
projects, rhese patterns can be very complex.
A critical path is a series of casks that, if delayed, would affect the completion dare
of rhe overall project. If any task on the critical path falls behind schedule, the entire
project will be delayed. Tasks on the critical path cannot have slack time. To identify
the critical path, calculate the start and finish date for each cask, which will determine
the critical path for the project.
In project schedu ling, rhc project manager de\•elops a specific rime for each rask,
based on available resources and whether or not -cbe task is dependent on ocher predecessor tasks. The manager can use graphical rools such as Gantt charts and PERT
charts ro assist in rhe scheduling process.
A Gann chart is a horizontal bar c hart that represents the project schedule with
rime on the horizontal axis and tasks arranged vertically. ft shows individual tasks
and rask groups, which include several casks. In a Gantt chart, the Ieng-ch of the bar
indicarcs rhc durarion of the rasks. A Gann chart can display progress bur docs nor
show rask dependency derails or re ource assign ment unless the charr was created
with a project management program that suppon:s dependency linking and rhe entry
of other information.
A PERT/C P~I charr shows the project as a nerwork diagram with tasks connected
by arrows. Using a prescribed calculation method, the project manager uses a PERT
chart to determine the overall duration of the project and provide specific information for each task, including the rask IDs, their durarions, start and finish rimes, and
the order in which they must be performed. \Xlirh this information, the manager can
determine the critical path, which is the sequence of tasks that has no slack time and
must be performed on schedule in o rder to meet the overall project deadline.
Mose project managers use software applications such as Microsoft Project co
plan, schedule, and monitor projects. Project managers are responsible for risk management, which is rhe process of identifying, analyzing, a nticipating, and monitoring
risks 10 minimize their impact on the project.
In ihe end, project management involves the same skills as any o ther management.
The project manager must be perceptive, analytical, well organized, and a good communicator. If the project manager senses that the project is off-track, he or she muse
take immediate steps to diagnose and solve the proble1n. lf the project manager fai ls
to plan, staff, organize, supervise, communicate, motivate, evaluate, direct, and control properly, then the project is certain to fail. Even when factors outside his or her
control contribute to the failure, the project manager is responsible for recognizing
the early warning signs and handling them effectively.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 3
Managing Systems Projects
Key Terms
98
Ke y Te rms
actJ\11)- Any work rhar ha~ a beginning and an end and require> the use ol compan) rc<.oorce' including
people, tmte, :rnd/or mone). Example$ indu<le conducung a >erto of 1nten 1cw,, de-1gnmg a report,
\clet.:ung ,ofrware, waifing for the delivery of equipment, and 1ra1nmg u..er~. <iu 11/su l.t\L..
best-ca~ c<itimatc The mosr opcirnisric outcome.
bonom-up technique A method for analyung a large, complex protect as a serii-s of mdl\·idual tasks,
called project tasks.
Brool..s' la" hedenck Brooks, an IB~l engineer, observed that adding more rnanpO\\Cr 10 a !are soft·
\I ar~ proiect 01il) mak~ 11 later.
code re1 iew See structured walk-through.
concurrent 1a;I.. A rask that can be completed ar the same tune as (in p.1rnllel wnh) another task.
~riucal path A 'cric• of events and activities with no ;lack time. If any act1v11y along tht• critical path
foils hchind schedule, the entire project 'chedule i\ similarly delayed. 1\s the name implic,, a critica l
parh include., all activities rhar are vir:il t() rhe project M:hedule.
Critical !~uh Method (Cl'M) Sbows a project as a nerwork diagram. The ,tctivitics Jre shown as vectors,
.ind the events are displayed graphically as nodes. Although Cl'M developed sepJrarely from the Progr.1rn
fa .1luarion Re1iew Technique (PERT), che two methods are essentially idenucal. See a'5o l'l:R l /CPM .
dependent t.1sk A task is said robe depeodem when ir has robe completed ma seri.11sequence.
design re\lew See srrucrured walk-through.
durauon lne amounr of time 1r will rake ro complere a rask.
cwnc 1\ reference point thar marh a major occurrence. U~ to monitor pro11rc\\ and mana11c a projen.
Sec .ilso m1fc,tone.
fin,.,h day/d:ue The dov or d:irc when a cask i:. scheduled to be finbhed.
C~nn ,h;an A hormmtal bar chart chat illusrrate> a ,.:hcduf.,. Dc1•dopcd man) year' a110 b) Henry L
Gann as a proJouion 'ontrol c.,,hniquc. Still arc in common LI><: todJ).
nufc,tnnc \ reference point that mark. a major occurrence. U«:d to monitor pmgre" and manage a
projccr. See also event.
ncmnrk d1agr:im A PF.RT chan al~o is referred to as a network diagram.
open source Sofrware thac is supported b) a large group of users and developer•. The source code is
mJde free!) available.
pcrson-dav I he amoum of work that one person can comple1e in one d.1y.
l'l:.R f /Cl'M lbe l'rogr.im Ev•lua11011 Review Tecbmque (Pl:.RT) "a> developed by 1he U.S. Navy 10
man.tgc very complex projects, such as rhe construction of nuclear submarines. At appro,imarcly rhe
same 11me, the Cnrical Pach Method (CPM) was de, eloped by pnvare indusrr) to rnccr ~1m1lar project
management needs. The tmporranr disrincrions berween the two methods hal'e disappeared over rime,
and rot.lay 1he rechmque is cillled either PERl~ CPM, or l'ERT/Cl'M.
prc<lccc"or ta\k A <mglc prior task upon wl1 ich two or more concurrent 1.1sk\ depend.
probablc·<:a\c c\limarc The most likely outcome is called a probable-ca~c c\timatc.
Prol\ram [·.valuation Re\ i~ Technique (PERT} See l'ERT/CPM.
project coordin;11or The person who handles administrative responsihilitie< for the development team
and negoriate' wirh u~ers who might have conAicring requirement~ or wane changes that would
rc4uirc .11Jditional time or c..:pcnse.
pro1c't lc:ldcr The perwn chJrgcd with leading a project from a rechnical per~pc,rivc.
pro1c.:1 m.inJgcment The process of planning, schedtilm!(, mon11onng, controlltng, .1ntl reportutg upon
che dcl'elopmen1 of an information system.
pro1c.:r manager The pcrwn charged ,,;th maaagiag a projccc from an admm1stranve pcr<ipective.
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
...............
_ .... ~---11rt~
-,..~---~~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Phase I
Systems Planning
99
Key Terms
pro1cct monitonng Gu1dmg, supervising. and coordin:iriog chc project 1eam's worlJoad.
project planninl( ldcnufymg prOJC\:t IJ>b and estimating completion ume Jnd cosb.
projcc1 rcporunit Pro,1dmg regular progress reports 10 managemen1. users, .md the pro1ecr 1eam nsclf.
pro1cx1 "'hrdulin11 The vca11on of a ">pc<:ific umcrable ro faciliratc complcuon ot J pro1a:1. Al'o m'ol'c'
<electing and ;,1;iffing rhc pro1ccr ream and a'\~1gnmg specific tasks to team mcmh<:.-.
pro1cct 1nan11k The thr« ma1or component~ of a project: co<t, scope, and nmc. A projc~'t manager rric\
to find the optimal balance among the\C facrors.
qualuati'c mk anal}"' Fvaluaring ri\k by escimaring che probability rhar ir will occur and the dcgrc-e of
impact.
quantitauvc ri~k anal) m cvaluaung mk m rerms of rhe acmal impact m terms of dollars, tune, pro1ccr
scope, or qualiry.
ri~k An C\'ent th.tr could affccr the pro1ccr negatively.
ri~k identification
Lming each risk and assessing the likelihood thar it could affect a pro1ccr.
ri'\k manai;cmcnt The procc'' of idcnrifying, evaluati ng. cracking, and controll ing ri'h to minimize rhcir
impact.
ri,I.. management plan lnducJc, n rcvi<.·w of the prujt:t.'t's scope, sr:akeholtle,.,., hud11tt, •chet.lulc, and any
other internal or c'rcrnal factor' chat might affect the project. The plan <hould define projc~1 role\ and
rC"pomihi liric<, ri'k m,inagcmcnr mcrhod< and procedures, categoric< of ri<h, and contini;cncy plan<.
risl.. response plan A proaciive cffon to .inricipare a risk and describe an action plan rode.ii with ii. An
effecche rt>!. respon.)t p!Jn can reduce che o~erall llllpacr by criggenng a timely and appropri.ue acuon.
~I.tel. urnc !be amount of ume b) which an e\'enr can be !are without delaymg the pro1ecr. lbc difference bet~ttn btest compleuon ume (LC!) and earliest completion titne (l:.Cf).
start day/dare lhc dJ) or date when a rask 1s scheduled to begin.
\tructurcd "alk-through \ rc,·1ew of a project ream member's work h}' other member\ of the ream.
Generali)', 'l'rcm' analy•r• review the work of orher S)"St:ems analym, and programmer\ renew rhc
worl.. of other programmer-, a' a form of peer re,·iew. Should take place throughout chi: SOI.( and
ar1: called rcqu1n:mcnt r.-vicw•, dc\lgn review<, code rC\;ews, or tc:>tmg n:v1cw•, dcp1:nd1ng on the
pha\C in "h11:h thcr occur.
\UCCC\\nr ta'k F.ach nf the cnncurrcnr ra•k' of a prcdeccswr cask.
ca'k An} worl.. that ha<i a beginn ing and an end and requires the use of company resources 111clud111g
people, time, ,111d/or money. Examples include conducting a series of inter\'iews. designing .1 report,
~elect111g buff\\ are, waiting for the deJi,ery of equipment, and training users. See .:1/su a1..1 .. it>ta>k bu" A i:o111ponc111 of a PF.RT/CPM charr that contains imporranr scheduling and duration informa tion abour J tJ>k. Fnch ra>k in a pruic1..-i is represented by its own task box in the PF.RT/CPM 1..hart.
ta>k group A ta'k thnt rcprc~cnr~ ~C\'eral activ11ics.
task ID A number or code thn1 uniquely identifies a task.
task name A brief dcscrip11ve name for a task, which does not have to be unique in the pro1ecr. Fc>r
example, a task 11.1med Conduct l111erv1ews might appear in several phases of the proiecr.
tasl.. paucrn A log"al •~quence of ra~ks ma WBS. Can involve sequential tJsk>, muluple >U"e;;or tasks,
and muluple predecessor tasks.
tcmng rc•icw See '\tructured \\all..-through.
\\eight An important mulupher th,1r managers facror inro esnmares so the) c.in he an3lyzed.
\\Ork brcal..do" n uructurc (WBS) A pro1ect broken down imo a series of smaller task\. Su also Gantt
chan; PERT/CPM chan.
wo~t -ca'c C\t1111.1tc The most pcss1m1sric outcome.
~ JD» (".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_ ._.... ~~
...
. ..............
_ .... ~---11rt~
-,..~---~ ~
.... . _
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Chapter 3
Managing Systems Projects
Exercises
100
Exercises
Quest ions
I. Draw a pro1ect rriangle that shows rhe relationship among project cost, scope, and time.
2. \Vrite the S(.Tipt for a one-minute explanation of basic project management concepts.
3. Explain the differences bcrwecn a Gann charr and a PERT/CP~I chart.
4. \Vhat are the three main task parrerns t)'Pes? Provide an example of each.
5. Why is the critical path important?
6. What is a srrucrured walk-through?
7. What arc the rwo main ways project starus is reported to management?
8. What i~ a significanr advanrnge of project management sofrware?
9. List the basic tasks in a risk management plan.
1 O. Explain Brooks' law.
Discussion Topics
I . When using a project rriangle to illustrate conflicti-ng priorities, Microsoft suggests rhar if rhe problem
is in the fixed leg, work on rhe other rwo legs. For example, if rhe project must nor exceed rhe budger
and it is starting to run over, adjust rhe schedule, or the scope, or hoth. However, if the problem is nor
related ro rhe fixed leg, rhe adju~rmenr mighr have to be in the remaining leg. So, when faced wirh an
inflexible budget (fixed leg) and the schedule is slipping (problem leg), rhe project's ~cope (remaining
leg) mighr have robe adjusred. Why is explaining this siruarion ro management sometime~ a very difficulc cask for chc sysccms analyst?
2. lf you are managing a large project, would you prefer Gantt charts or PERT/CPM charts ro represent
project status? Explain why.
3. Consider a scenario where a cask is dependent on another task being started bur nor necessarily completed. for example, a prOJect may depend oa a cask being started and one-fourrh compleced before
the group could start 1heir porrion of the project. Do you think this situation occurs frequently in systems pro1ects? Wh>• or why not?
4. Some project management applications can be quire expensive. As a manager, how would you justify
the purchase of this sofrware?
5. Risk analysis is rypically a two-step process: qualitative risk analysis and quantitative risk analysis.
As a systems analyst, for which sores of project management decision!. would you use the results from
qualitative risk analysis? 1-rom the quantitative risk analysis?
Projects
1. Think of all the tasks chat you perform when you p urchase a car. Include any research, decisions,
or financial issues that re lare ro the purchase. Crea re a \X'BS that shows all the rnsks, their estimated
duration, and an)' predecessor rasks.
2. Figure 3-27 shows a \XfBS with l Ltasks. Note tbat each rask has an ID, a description, durarion, and
a reference to predecessor tasks, if any, which must be completed before the task can begin. Also note
that dependent casks can have one predecessor task or several. Construct a PERT/CPM chart from
rhese tasks. Reca ll that rhis is done as a rwo-step process: (l) display the casks and task patterns, and
(2) enter start and finish rime.
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~... .... .,... ~ • ........._ ......_.,.,.. o-... ..,._ .,,.,.. _..,. ~ ,...... ..., ................. .._... ..,.,...,.~"
........... ........ ..., .................... . . .... -.., .n..-. ....-i k-s c~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
Phase I
Systems Planning
I0I
Exercises
•
D escr ipt ion
D ur ation
( D ays)
Predecessor
Tasks
I
Develop Plan
2
Assign Tasks
4
3
..
Obtain Hardware
17
Programming
70
2
5
Install Hardware
10
3
6
Program Test
7
Write User Manual
B
9
Convert Files
System Test
10
User Training
II
User Test
30
25
20
25
20
25
..
5
5
6
7,8
9,10
FIGURE 3-27 Example of a work breakdown structure listing 11 tasks.
together with their descriptions. durations, and predecessor casks.
3. Many of roday's projects involve team members scanercd across different time zones and in different
phy~ical locations. Moreover, the projects may have adopted an agile mechodology, which reduces
cycle time dramarically. Wrire a brief report rhat summarizes some of the key differences a manager
would face managing chi~ rypc of projecr, as opposed to a traditional pro1ecc.
4. Go to the websites for project management rools (besides Microsoft Project), such as Apptivo (www
.apptit'O.com ), GanttPro1ecr (www.ganttprojed.biz), Ganner (wwmga11Ner.com), smarrshcet (u11uw
.s111arts/Jeel.comlprod11d-to11r/gm1N-charts), }vlonday (U11t•w.mo11day.com), and Trello (www.trello.com).
I:xplorc each program's fearures and describe what you like and don't like.
5. Perform an Internet research co learn more about project risk management and write a summary
of the resulrs. Be sure to search for cbe classic book titled Waltzing with Bears: Managing Risk 0 11
So(tw<1re Projects, by Tom Demarco and Timothy Lister.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
~ JIJ»C....... ~ Al RlilfD
~ ... _
l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.: ......,_ . . . ,_.,~-.lit .......... .._.,._.__..,~•\
. . . _ . .... ..., ~...,.._,_..,..., J\&."9 ... --.11 ......... ~ C'dptl"~~d.tt ...... -
............ -
..... -
..........
-.-.....w--...-.11
PHASE
Systems analysis is the second of five phases in the systems development life cycle. In the
previous phase, systems planning, a preliminary investigation was conducted to determine the
project's feasibility.The output of that phase, the preliminary investigation report. is used as input
to the systems analysis phase, where a system requirements document is created that captures
the needs of the all stakeholders.
A successful project manager must determine the requirements before starting the design
process. not the other way around. It may be tempting to "just do something" to give the
appearance of productivity, but a systems project that does not satisfy business requirements
serves no useful purpose.
Chapter 4 focuses on the requirements engineering process. This includes system requirements,
team-based techniques, gathering requirements through interviews and other methods,
gathering requirements in agile projects, representing requirements. validating and verifying
requirements, and requirements tools.
Chapter 5 focuses on data and process modeling techniques that analysts use to show how
the system transforms data into useful information. This includes logical versus physical models,
data flow diagrams and symbols, drawing data flow diagrams. drawing context diagrams, drawing
diagram 0 DFDs, drawing lower-level OF Os, data dictionaries, and process descriptions.
Chapter 6 focuses on object modeling techniques that analysts use to create a logical
model. This includes object-oriented analysis, objects, attributes, methods, messages, classes,
relationships among objects and classes, the Unified Modeling Language (UML), and tools.
Chapter 7 focuses on development strategies for the new system and plans for the transition
to the systems design phase.This includes traditional versus web-based systems development,
evolving trends, in-house software development options, outsourcing, offshoring. Software
as a Service (SaaS). selecting a development strategy, the software acquisition process, and
completion of systems analysis casks.
103
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ . ....._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... .., .,. ..,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Chapter 4
Requirements Engineering
•
• ••• • ••
•
•••• •••••••••••
•••••
• ••
•••••
•
······----····
·····---··-··
......
- ·····
---· --
Requirements
Engineering
Chapter 4 is the first of the four chapters m the
systems analysis phase. This chapter describes the
requirements engineering process: gathering facts
about a systems project. creating models that will be
used to design and develop the system, and verifying
and validating that the models are correct before
proceeding to the next phase of the SDLC.
The chapter includes three "Case In Point"
discussion questions to help contextualize the concepts
described in the text. The "Question of Ethics" raises
the issue of considering a request by a supervisor to
identify departments that reported the lowest ratings in
a survey that was supposed to be kept anonymous.
LEARNING OBJECTIVES
Whe11 you finish tl1is chapter, you should be able to:
CONTENTS
1. Explain system rcquiremenrs and rhc challenges
associated with the rcquircmcnrs engineering process
2. Compare and contrast funcnonal and
non-functional requirements
3. Apply team-based rcquircmcnrs engineering
techniques, including joinr application development
UAD), rapid appltcaaon development (RAD), and
agile method~
4. De1'elop a face-finding plan for gathering
requirements
5. Conduct an interview to gather sy3tem
requircmcntS
6. Use other requirement~ garhering rcchniqucs,
including document review, observation,
questionnaires and surveys, brainstorming,
sampling, and research
4. 1 System Requiremenrs
4 .2 Team-Based Techniques
Case in Poinr 4.1: 'orch Hills College
4.3 Gathering Requirements
4.4 Garnering Requirements Through lnrerviews
4.5 Gathering Requirements Using Other
Techniques
Case in Point 4.2: CyberStuff
4 .6 Gathering Requirements in Agile Projects
4 .7 Represenring Rcquircmcnrs
Ca3e in Point 4.3: Digital Pen Transcription
4 .8 Validating and Verifying Requirements
4 .9 Tools
A Question of Ethics
4. 10 Summary
Key Terms
Exercises
7. Explain how requircmcnrs arc gathered in agile
projects
8. Utilize different requircmenrs representation
techniques, including natural language,
diagram~, and mo<leb
9. Explain how ro validate and verify requiremenrs
10. E.x:plain bow roob can help wirh requirements
engineering acciv1ti~
f"........., ,.,.r...., t . . . . . 4•111..-.•...__. .......
• ........._ ......_.,.,.. o-...
~
~------..
.,...~
..,._.,,.,.._..,.~
,........,.., ........... ._... ..,.,...,.~"
... ~ ........................ -..,.n..-.....-ik-sc~ c....,a..-.,.,...,. ..... ID>_... ........ _
.. ~ ........................_ .... ._
Phase 2
Systems Analysis
105
4.1 System Requirements
4. I SYSTEM REQUIREMENTS
During the first part of the srstems analysis phase of the SDLC, systems analysts must
idenrify and describe all system requirements. A system requirement is a characteristic or
feature that must be included in an informarion system to satisfy business requirements
and be acceprable to users. System requirements serve as benchmarks to measure the
overall acceprabiliry of the finished system.
Because system requirements arc the focus of t he start of the systems analrs1s phase,
it's important to get rhcm correct, right at rhc start of the process. Any problems with
the requirements will have a ripple effect that could negacively affect subsequent phases
of the DLC. In facr, poor requirements engineering is a leading cause of failed projects.
Requirements engineering is composed of three main activities:
1. Gathering requirements: 1111derstanding the problem
2. Representing requirements: describing the problem
3. Validating and verifying requirements: agreeing upon the problem
Each of these activities is described in more decailt in this chapter. The output of
requirements engineeri ng are requirements docun1enrs that capture the essence of
what the system should do. These documents are the input to the next step in the
SDLC, data and process modeling, which is described in Chapter 5.
4.1.1 Types of Requirements
Requirements can be classified according to various characteristics. For example,
requirements may be primarily for the system user, in which case they are referred to
as requirementS definitions. Requirements may also be primarily for the engineering
team, in which case they arc referred to as requirements specifications.
System requirements can also be classified as functionaJ and non-functional. A
functional requirement is a statement of the services a system provides. Examples of
functional requirements include the folJowing:
•
The website shall report online volume srariscics every four hours and hourly
during peak periods.
•
The inventory system shall produce a daily report showing the part number,
description, quantiry on hand, quanriry alJocated, quantity avaiJable, and unit
cost of all sorted by pare number.
•
The contact management system sball generate a daily reminder list for all sales
representatives.
Each input form must include date, time, product code, customer number, and
quantity.
The system must provide logon securiry at the operating system level and at the
application level.
•
•
A non-functional requirement is a statement of operational system constraints.
Non-functional requirements are also known as quality attributes. Examples of functional requirements include the following:
•
Data entry screens must be uniform, except for background color, which can be
changed by the user.
•
The ~)·stem must support 25 users online simuJtaneously.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 4
Requirements Engineering
4.1 Syscem Requ irem encs
106
•
•
Response rime muse nor exceed four seconds.
The system must be operational 7 days a week, 365 days a year.
•
The sysrcm should work on Windows and Nlac platforms.
Non-funcrional requirements may be more critical rhan funcrional rcquiremcnrs;
if t he former are not satisfied, the system is useless. Conflicts berween different
non-functional requirements arc common in complex systems. For example, a user
may requcsr chac a sysrem be 100% secure but very usable--rwo requirements chat
arc hard co reconcile.
4. 1.2 Requirements Challenges
Requirements present numerous challenges to the systems analyst. Three of the most
imporrant arc imprecision, agreement, and creep.
IMPRECISION: Requirements arc often imprecise because rhcy are usuall y repre-
scnccd using natural language, such as the examples shown in Secrion 4.1.1. Natural
language is expressive, bur it is prone to misintcrprerarion. Ir is not uncommon for
vnrious i.rakeholde rs to completely dlisagrec as to the mea ning of a simple req uirement. It is for chis reason chat other techniques are used to represent requirements, as
described in Secrion 4. 7.
A req uirement may be a high-level abstract statement of a service or of a system
constra int, bur it can a lso be a derailed mathematical specifica tion. T his is because
requirement~ often berve rwo functions: as a basis for a bid for a contract, a nd as the
basis for rhe cotitract itself.
If rhe requirements are the basis for the contract bid, it muse be open to interpretation. Bur if the requirements are the basis for rhe contract itself, it must be defined in
detail. These rwo constraints are difficult to satisfy.
AGREEMENT: One of the main problems with requirements is getting everyone co
agree on the exact meaning of the requirements statements. Jn other words, we want
ro develop requirements in such a way that, upon completion of the system, borh t he
systems analyse and rhe client can agree on whether or nor a specific requirement has
been met.
In theory, requirements shou ld be both complete and consistent. A requirement is
complete if it includes descriptions of all faci lities needed by the system. In pr::ictice,
it's 11npossible to corn plerely descri be the requirements for a complex system.
A requ irement is consisrenr if there are no conflicts or contradictions in the
description of rhc system facilities. In practice, ensuring char there are no conflicts in
the system requiremencs when there may be thousands is quite cha llenging.
CREEP: There are many social and organizational factors that influence sysrem
requirements. For example, business changes inevitably lead to ch:mging requirements-usually more of them ;ts the project progresses. T his is particularl y true for
long-lived projects where the personnel involved change over rime. This phenomenon
is known as "feature creep."
Rapidly c hangi ng requirements can cause numerous problems for systems analysts
and other ream members. T his is particularly true for project!. that follow a traditional waterfall model of the SDLC. It is partly for th is reason rhar agile methods are
popular: They explicitly address changing requirements as part of rhe project's managemen t structure.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
Phase 2
Systems A nalysis
107
4.1 System Requirements
4.1 .3 Additional Considerations
In addition to the three challenges ourlined earlier, syscems analysts muse consider
three important supplementary factors: ( 1) scalability, which determines how a system will handle future gro\\'th and demands; (2) security, which 1s all-imporrnnc for
today's networked systems; and (3) che coral cost of ownership, which includes all
future operanonal and support coses.
SCALABILITY: Scalability refers co a system's ability to handle increased business
volume and transactions in the future. Because it will have a longer useful life, a scalable S)'Stem offers a bener rerum on the initial invesanent.
To evaluate scalability, information is needed about projected future volume for all
outputs, inputs, and processes. For example, for a web-based order processing system,
one needs to know the maximum projected number of concurrent users, the periods
of pc:ik onlinc activity, the number a nd types of data items required for each transaction, and the method of nccessing and updating customer files.
Even to print customer statements, the analyst needs to know the number of active
accounts and h:we a forecast for one, rwo, or five years because char informa tion affeccs
fucure hardwa re decisions. In addirion, wich realistic volume projeccions, reliable cosc
estimates for rcl:ued expenses, s uch as postage and online charges, can be provided.
Similnrly, to ensure thac a web-based hotel reservation system is sufficientl y scalable, the anal)'St would need ro project ncrivity levels for several years of operation. For
example, one might forec:ist the frequency of oaline queries :ibout room availability
and e~timate the time required for e:ich query nnd the average respon~e time. With that
information, server transaction volume and nerwork requirements could be estimated.
Transaction volume has :1 significant impact on operating costs. When volume exceeds
a system's limitations, mainrenance costs increase sharply. Volume can ch:inge dramatic:illy
if a comp:iny expands or enters a new line of business. For example, a new lntemet-b:ised
marketing effort might require an additional server and a 24-hour technical support.
Darn storage also is an important scalability issue. The analyst must determine
how much datn storage is required currently and predict future needs based on system activity and growth. Those requirements affect hardware, software, and network
bandwidth needed to maintain system performance. Data retention requirements
must also be considered to determine whether data can be deleted or archived on a
specific timetable.
SECURITY: Jn rhc past, security was considered an add-on to a system'& de ign.
This is particul:irly true for legacy sysrems that have been deployed for some time.
Nowadays, security is so important for networked systems that it has changed from a
non-functional requirement to a functional requirement. ln other words, security is :in
ei.sential consider:ition for a ll systems development.
incorporating security as a first-class requiretnent is particularly important in lig ht
of the seemingly endless news reports of 1nassive data breaches. These hacks tele:isc
personal information from o nline systems at a scale previously unseen. lf the systems
h:id been m:ide with security in mind from the beginning, they would be much harder
to infiltrate.
The ch:illenge with security as a system requirement is tha t it is often in conflict
with other user requirements. For example, a requirement that the system should be
accessible online using n web interface immediately makes securing the system much
more challenging. The systems analyst must attempt co reconcile and prioritize the
conflicting requirements during the requirements engineering process.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 4
Requirements Engineering
4.2 Team-Based Techniques
108
In addition to direct costs, systems developers must
identify and document indirect expenses that contribute to the total cost of ownership
(TCO ). TCO is especially important if the development team is as!.essing several alternative!.. Afcer considering the indirect costs, which are not always apparent, a syscem
thar seems inexpensive iniriaUy migbt actually rurn our ro be rhe cosrliesr choice. One
problem is that cost estimates rend to understate indirect col.ts such as user support
and downtime productivity
losses. Eve n if accurate figures are unavailable, syscems
analysts should try to identify
indirect costs and include them
TCO for Cloud Computing
in TCO estimates.
Because cost contro l is
so important, vendors ofren
claim that their products or
services will reduce T CO significantly. For example, one
of the most commo n reasons
to migrate n legacy system to
the clo ud is reduced TCO. As
shown in Figure 4- 1, cloud
computing offers rhe opportunity for lower operational
costs due to the our ourcing
of expenses such as ca pita I
investment in exchange for a
FIGURE 4-1 Total cost of ownership when migraung co the cloud can be significandy less
pay-as-rou-go pricing model.
than current computing platforms.
TOTAL COST OF OWNERSHIP:
29°10
57°10
v
4.2 TEAM-BASED TECHNIQUES
The IT department's goal is to deliver the best possible information system, at
the lowest possible cost, in the shortest possible time. To acbjeve the best results,
systems developers view users as partners in the development process. Greater user
involvement usually results i11 better communication, faster development times, and
more satisfied users.
The traditional model for systems development was an IT department that used
st ructured analysis and consulted users o nlr when their inpur o r approval was
needed. Although the TT staff still has a central role, and structured analrsis remains
a popular merhod of systems development, mosr IT ma nagers invire system users to
parricipare actively in various development tasks.
As described in Chapter 1, ream-based approaches have been around for some rime.
A popular example is joint application development UAD), wh ich is a user-oriented
technique for fact-finding and requirements engineering. Because it is not linked ro a
specific development methodology, systems developers use JAD whenever group input
::ind inreraccion are desired.
Another popular user-oriented method is rapid application development (RAD ).
RAD resembles a condensed version of the entire SDLC, with users involved every
seep of the way. While JAD typically focuses only on fact-finding and requirements
determination, RAD provides a fast-track approach to a full spectrum of systems
development tasks, including planning, design, construction, and implementation.
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
P hase 2
Systems A nalysis
109
4.2 Team-Based Techniques
Finally, as described in Chapter 1, agile merhods represent a recent trend that
srresscs intense interaction between systems developers and users. JAD, RAD, and
agile methods arc discussed in the following seccions.
4.2. 1 Joint Applicatio n Deve lopme nt
Jome application dc\.clopmcnc UAD) is a popular fact-finding technique that brings
users 111to the development process as active participanrs.
USER INVOLVEMENT: Users have a vital stake in an information system, and
they should participate fully in rhe development process. Many years ago, rhe IT
department usually had sole rcsponsibiliry for systems development and users had
a relatively passive role. During rhe development process, the IT staff would collect
information from users, define system requirements, and construct the new system. At
various stages of che process, che IT staff might ask users to review the design, offer
comments, and submit changes.
Today, users rypically have a much more active role in systems development. IT
professionals now recognize that successful systems must be user oricnrcd, and users
need to be involved, formally or informally, at every stage of systems development.
One popular strategy fo r user involvement is a JAD team approach, which
involves a cask force of users, managers, and IT µrofessiona ls who wo rk togcrhcr to
gather information, discuss business needs, and define the new system requirements.
JAD PARTICIPANTS AND ROLES: A JAD team usually meets over a period of days
or weeks in a special conference room or at an off-sire location. Either way, JAD
participanci. should be insulated from rhe distraction of day-co-day operations. The
objecti,·e is to analyze the existing system, obtain user input and expectations, and
document user requirements for the new system.
The JAD group usually has a project leader, who needs strong interpersonal
and organizational skills, and one or more members who document and record the
results and decisions. Figure 4-2 describes typical JAD participants and their roles.
IT staff members often serve as JAD project leaders, but that is not always the case.
JAD PARTICIPANT
ROLE
JAD protect leader
Develops an agenda. acu as a facilitator. and leads the JAD session
Top manageme nt
Provides enterprise-level authorization and support for the project
Managers
Provide department-level support for the project and understanding of
how the project must support business functions and requirements
Users
Provide operational-level input on current operations. desired changes,
input and output requirements. user interface issues, and how the project will support day-to-day tasks
Systems analysts and
other IT staff members
Provide technical assistance and resources for JAD team members on
issues such as security, backup. hardware. software. and network
capability
Recorder
Documents results of JAD sessions and works with systems analysts to
build system models and develop CASE tool documentation
FIGURE '4-2 Typial JAD partlcipancs and roles.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 4
Requirements Engineering
4.2 Team- Based Tec hniques
I I0
Syscems analysts on rhe JAD ream participate in discussions, ask questions, rake
note , and provide support to rhe team. If CASE tools are available, analysts can
develop models and enter document ation from the JAD session directly into the
CASF tool.
A typical JAD session agenda is s hown in Figure 4-3. The JAD process involves
intensive effort by all ream members. Because of the wide range of input and constant
interaction among the participants, many companies believe th:u a JAD group produces the best possible definition of tbe new system.
Project leader
• Introduce all JAD team members
• Discuss ground rules, goals. and objecuves for the JAD sessions
• Explain methods of documentation and use of CASE tools, if any
Top management (sometimes
called the project owner or
sponsor)
• Explain the reason for the project and express top management
authorization and support
Project leader
• Provide overview of the current system and proposed project
scope and constraints
• Present outline of specific topics and issues to be investigated
Open discussion session,
moderated by project leader
• Review the main business processes, tasks, user roles. input. and
output
• Identify specific areas of agreement or disagreement
• Break team into smaller groups to study specific issues and assign
group leaders
JAD team members working
• Discuss and document all system requiremenu
• Develop models and prototypes
in smaller group sessions,
supported by IT staff
--------
Group leaders
• Report on results and assigned tasks and toptcs
• Present issues that should be addressed by the overall
JAD team
Open discussion session,
moderated by pro1ect leader
• Review reporn from small group sessions
• Reach consensus on main issues
• Document all topics
Project leader
• Present overall recap of JAD session
• Prepare report that will be sent to JAD team members
FIGURE 4-3 Typical agenda for a )AD session.
)AD ADVANTAGES AND DISADVA.NTAGES: Compared with traditio nal
meth ods, J AO is more expensive and can be cumbersome if the grou p is too large
relative co the size of rhe project. M any companies find, however, that JAD a llows
key users to pa rticipate effectively in the requ irements engineeri ng process. When
users participate in rhe sysrems development process, they arc more likely ro feel a
sense of ownership in the results and support for the new sysrem. When properly
used, JAD can result in a more acc urate statement of system requirement , a better
understanding of common goals, a nd a stronger commirment to the s uccess of the
new system.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
I
Phase 2 Systems Analysis
I II
4.2 Team-Based Techniques
CASE IN POINT 4.1:
N ORTH H ILLS C OLLEGE
North Hills College has decided to implement a new registration system that will allow
students to register online as well as in person. As IT manager, you decide to set up a JAO
session to help define the requirements for the new system.The North Hills organizaoon
is fairly typical, with administrative staff that includes a registrar. a student support and
services team, a business office, an IT group, and a number of academic departments. Using
this information, you start work on a plan to carry out the JAD session. Who would you
invite to the session, and why! What would be your agenda for the session, and what would
take place at each stage of the session!
4.2.2 Rapid Application Development
Rapid application d evelo pment (RAD) is a team-lbased technique that speeds up
information systems development a nd produces a function ing information system.
Like J AD, RAD uses a group approach bur goes much further. \Xlhtle t he end product
of J AD is a requ irements model, the end product of RAD is the new informa tion sys·
rem. RAD is 3 complete merhodoloh')', with a four-phase life cycle that p:.uallcls rhe
cradicional SDLC pha!ies. Companies use RAD to reduce cost a nd development rime
and increa!ie the prohabiliry of success.
RAD rel ies heavi ly on prototyping and user involvement. The RAD process allows
u!ier!i to examine a working model as early as possible, deter mine if it meets their
neeru., and suggest necessar}' changes. Based on user input, the prototype is modified,
and the interactive process conrinues until the system is completely developed and
users are i.atisfied. The project team uses CASE tools to build the prototypes and create a concinuou!i stream of documentation.
RAD PHASES AND ACTIVITIES: The RAD model consists of four phases: require-
ments planning, user design, construction, and cucover, as shown in Figure 4-4.
the continuous inreract ion between the user design and construction phases.
1
ote
Require me nts planning. The requirements planning phase combines element~ of the
systems planning and l>ystems analysis phases of t he SDLC. Users, managers, and IT
staff members discuss and agree on business need s, project scope, constraints, and
sy~tem requirements. The requirements planning phase ends when the team agrees on
the key issues and obtains management authorization to continue.
User design. During the user design pha~e, users interact with systems analysts
and develop models and prototypes chat represent a ll system p rocesses, outputs, and
inputs. T he RAD group or subgroups typically use a combinatio n of J AD techniques
and CASF, roo ls co transla te user need s into wor kin g models. User design is a conti nuous, interactive p rocess that allows users to u ndersta nd, modify, a nd eventua ll y
approve a working model of the system tha t meecs cheic needs.
Constructio n. The constru ction phase focuses on program and application development tasks similar to the SDLC. In RAD, however, users continue co participate and
still can suggest changes or improvements as acrual screens or reports are developed.
Cutove r. The curovcr phase resembles the final tasks in the SDLC implementation
phase, including data conversion, resting, changeover to the new system, and user
training. Compared with traditional methods, the entire process is compressed. As a
result, the new S)'Stem is built, delivered, and placed in operation much sooner.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Chapter 4
Requirements Engineering
4.2 Team-Based Techniques
I 12
Requi rements Plannlng
Task s
• Users, managers, and IT
staff agree upon business
needs, project scope, and
systems requirements
• Obtain approval to
continue
User Design Tasks
• Interact with users
• Build models and
prototypes
• Conduct intensive
JAD-type sessions
Continuous interaclton
between the user design
and construction phases
Construction Tasks
• Program and
application
development
• Coding
• Unit, Integration,
and system testing
User
Design
Cutover
CutoverTasks
• Data conversion
• Full-scale testing
• System changeover
• User training
FIGURE 4·4 Tho fo11r ph11s~ of tile R.AD rno<!el ;i,~ ~quire111entt planning, user design, connruction, arid
cucover. Note the continuous lnceractlon between the user design and construction phases.
RAD OBJECTIVES: The main objective of all RAD approaches is co cue developmenr
rime and expense by involving users in every phase of sysrems development. Because
iris a conrinuous process, RAD allows rhe developmenr ream ro make necessary modificarions quickly, as the design evolves. In times of right corporare hudgers, iris especially imporranc co limit che cost of changes chat typically occur in a long, drawn-our
development schedule.
In addition to user involvement, a successful RAD team muse have IT resources,
skills, and management support. Because ic is a dynamic, user-driven process, RAD
is especially v::iluahle when a company needs an information :.yMem to support a
new business function. By obtaining user input from the beginning, RAD also helps a
development ream design a system that requ ires a highly interactive or complex user
interface.
R.A D ADVANTAGES AND DISADVANTAGES: RAD has advantages and
disadvantages compared with rraditiooal structured analysis methods. The primary
advantage is that systems can be developed more quickly with significanc cosr
savings. A disadvanrage is rbat RAD srresses rhe mechanics of the sysccms irsclf and
docs nor emphasize rhe company's suategic business needs. The risk is that a system
mighr work well in rhe shore term, but the corporare and long-term objectives for che
S)'Srcm might nor be mer. Anorber pocenrial disadvantage is char the accclcrared rime
cycle migh t allow less rime co develop quality, consistency, and design standards.
RAD can be an arrracrive alrernarive, however, if an organizarion understands rhe
possible risks.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
- Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
- ·~•-fllllie<'f •,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
Phase 2
Systems A nalysis
113
4.2 Team-Based Techniques
4.2.l Agile M ethods
Chapter I explained that agile methods attempt to develop a system incrementally by
buildmg a series of prototypes and constantly adjusting them to u er requiremenrs. A~
the agile process continues, developers revise, extend, and merge earlier versions into
the final producr. An agile approach emphasizes continuous feedback, and each incremental step is affected by what was learned in the prior steps.
As agile methods become more popular, a large con1munity of agile-related software and &ervices ha~ evolved. Many agile developers prefer not to use CASE toob at
all, and as ~hown in Figure 4-5 rely instead on whiteboard displays and arrangements
of movable sticky notes. This approach, they believe, reinforces the agile strategy:
si1nple, rapid, flexible, and user oriented.
--
i
••
--
-
-~
,. -
-
•
aI
I
•
•
-,... -
-
,,:::
• -1
•
I
FIGURE 4-5 Reinforcing the agile stntegy: simple, rapid.flexible. and user oriented.
S..., ~d..,. 'I
IO l<n
'Vt'f1
lfTI
Scrum is anod1er agile approach. The name cornes from the rugby term scr11111, where
team members lunge ar each other to achieve their objectives, as shown in Figure 4-6.
ll1e systems development version of Scrum involves the same intense interaction, though
it is more mental than physical. ln a Scrwn session, agile ream members play specific
roles, including colorful designations such as pigs or chickens. These roles arc based on
the old joke about the pig and chicken who discuss a restaurant where ham and eggs
would be served. I lowever, rhe pig declines, because that role would require a total
c01nmirmenr, while for rhe chicken, ir would only be a contribution.
Jn the agile world, rhe pigs include the product owner, the facilitator, and the
development team, while rhe chickens include users, ocher stakeholders, and managers. Scrum sessions have specific guidelines that emphasize time blocks, interaction,
and team-based activities thar result in deliverable software. An agile ream uses a
series of scrums to pause the action and allow the players to reset the game plan,
which remains in effect until the next scru m.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
--
........... ......
"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
__....
~~·~---- ···---~~ - .,.-"~
Chapter 4
Requirements Engineering
4.3 Gathering Requirements
I 14
FIGURE 4-6 In a rugby scrum. team members prepare to lunge at each other to achieve their objectives.
.... ~~
tlCf h~~
""'
Agile, or adaprive, methods are very flexible and cfficienr in dealing wirh cbange. The)' are popular because
rhey srress ream inreracrion and reflecr a set of community-based values. Also, frequenr deliverables consranrly validare rhe projecr and reduce risk.
I lowever, some porenrial problems exist. For example, ream members need a high
level of technical and interpersonal skills. Also, a lack of structure and documenrarion
can introduce risk factors, such as blurring of roles and responsibilities, and loss of
corporate knowledge. Finally, rhe overall projecr may be subject to significant change
in cope as user requirements continue to evolve during the projecr.
AGILE METHOD ADVANTAGES AND DISADVANTAGES:
4.3 GATHERING REQUIREMENTS
Gathering requirements is the fi rst step in the requirements engineering process. This
step is also known as requirements elicitation or fact- finding (collecting information).
Whether working solo or as a me1nber of a team, during requirements gathering, the
systems a nal yst will use various teclu1jques, including interviews, document review,
observation, surveys and questionnaires, sampling, a nd research.
Although software can help gather and analyze requirements, no program actuall y
gathers them a uto matically. First, the information needed must be identified. Typically, t his activity begins by asking a series of questions, such as the following:
•
•
(....,..... J:gi( . . . . .
\'<i'hat bu'>iness functions are su pported by the current system?
What strategic objectives and business requirements must be supported by the
new sysrem?
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
P hase 2
Systems A nalysis
llS
4.3 Gathering Requirements
•
•
\Xlhat arc the benefits and TCO of rhe proposed system?
\XThat transactions will the system process?
•
\Xlhar information do users and managers 111eed from the system?
•
Must the new sy~rem interface with legacy systems?
•
What procedures could be eliminated by business process reengineering?
•
What security issues exist?
•
•
What risks are acccprable?
What budget and rimerable constrainrs will affecr sysrems development?
To obtain answers to these questions, the analyst develops a face-finding plan,
which involves answers to five familiar questions: who, what, where, when, and how.
For each of those questions, one a lso must ask another very important question: why.
Some examples of rhese questions a re as follows:
1. \'(I/Jo? \'V'ho performs each of the procedures within the system? Why? Arc the
correct people performing rhe activity? Could other people perform rhe casks
more effectively ?
2. \'(/hat? What is being done? What procedures are being followed? Why is the
process necessary? Often, procedures are fo llowed for many years and no one
knows why. Question why a procedure is being followed ar a ll.
3. \'(/here? Where are operations being performed? \Vhy? Where could they be
performed? Could they be performed more efficientlr elsewhere?
4. \'(!hen? \'V'hen is a procedure performed? Why is it being performed ac chis
ame? ls this the best time?
5. I l ow? I low is a procedure performed? Why is it performed in that manner?
Could it be performed better, more efficiently, or less expensively in ~ome ocher
manner?
There 1s a difference between asking whar is being done and whar could or
should be done. The sysrems analyse first must understand the current siruation.
Onl)' then can rhe question of whar should be done be answered. Figure 4-7
liscs rhe basic questions and when rhey should be asked. Note thar the first two
columns relarc co rhe current system bur the third column focuses on rhe proposed
system.
PROPOSED SYSTEM
CURRENT SYSTEM
Who does It!
Why does this person do ltl
Who should do itl
What Is donel
Why Is it donel
What should be donel
Where is it donel
Why is it done there!
Where should It be done!
When Is It donel
Why Is It done then!
When should It be donel
How is it donel
Why Is It done this way!
How should It be donel
FIGURE 4-7 Sample quesaons during requirements elicitation as the focus shifts from the current system co
the proposed system.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 4 Requirements Engineering
4.4 Gathering Requirements Through Interviews
I 16
4.4 GATHERING REQUIREMENTS THROUGH INTERVIEWS
interviewing is an imporrant requirement gathering technique during the systems
analysis phase. An interview is a planned meeting during which the analyse obrains
information from another person. The skills needed to plan, conduct, document, and
evaluate interviews successfully must be understood.
4.4. 1 The Interview Process
After identifying che information needed, as described earlier in rhe chapter, the interviewing process commences, which consists of seven steps for each interview:
I. Determine the people to interview.
2. E.srablish objecti ves for the interview.
3. Develop interview questions.
4. Prepare for rhe interview.
5. Conduct the interview.
6. Documenr rhe interview.
7. Evaluate the interview.
STEP I: DETERMINE THE PEOPLE TO INTERVIEW: To ger an accurate picture, rhe
analyse mu~t select che rig ht people to interview and ask chem the right questions.
The preliminary investigation involved mainly middle manager or department heads.
Now, during the systems analysis phase, people from all levels of rhe organization
should be interviewed. In some situations, it might be prudent to interview stakeholders that are nor members of the organization, because their opinion is valuable.
Although interview candidates can be selected from the formal orgamzarion charts
reviewed earlier, one must also consider any informal structures that exist in the organization. Informal structures usual!)' are based on interpersonal relationships and can
develop from previous work assignments, physical proxjmity, unofficial procedures,
or personal relationships such as tbe informal gathering shown in Figure 4-8. In an
informal structure, some people have more influence or knowledge than appears on
FIGURE 4-8 When setting up interviews. an analyst should look
outside a formal organization chart to identify people who might
provide valuable information.
c
#.f"Sl-- .....ay LU"'
1
(....,..... J:gi( . . . . .
4
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
P hase 2
Systems A nalysis
I 17
4.4 Gathering Requirements Through Interviews
an organizarion charr. The analysr's knowledge of rhe company's formal and informal
srrucrures helps derermine rhe people ro inrervie'v during the systems analysis phase.
Should several people be interviewed at the same time? Group interviews can
ave time and provide an opporrunicy to observe interacrion among the participant<;.
Group interviews also can present problems. One person might dominate the convcration, even when questions are addressed specifically to others. Organization level
also can present a problem because the presence of senior managers in an interview
might prevent lower-level employees from expressing themselves candidly.
STEP 2: ESTABLISH OBJECTIVES FOR THE INTERVIEW: After deciding on the
people to interview, objectives for tbe session must be established. First, the general
areas to be discussed should be determined, and then the facts to be gathered should
be listed. Soliciting ideas, suggesrions, and opinions during thc interview is also a
good idea.
The objectives of an inrerview depend on the role of the person being interviewed.
Upper-level managers can provide the big picture to help understand the system as a
whole. Specific details about operarions and business processes are best learned from
people who actually work wirh the sysrem on a daily basis.
In the early stages of systems analysis, interviews usually are general. As the
fact-finding process continues, however, the interviews focus more on specific topics. Interview objectives a lso vary at different stages of the investigation. Interviews
should be as brief as possible (though as long as needed), since time is so valuable m
employees, e.~pecially managers. By sening specific objectives, a framework is created
that helps the analyst decide what quescions to ask a nd how ro phrase them.
STEP 3: DEVELOP INTERVIEW QUESTIONS: Creating a Standard list of interview
questions help to keep the session on track and avoid unnece~ar) tangents. Also,
if everal people who perform the same job are interviewed, a s tandard question list
permits a comparison of their answers. AJtbough there may be a list of specific questions, the mterv1ewer might decide to depart from ir because an answer to one quei.tion leads to another topic that warrants pursuing. Thar question or topic then should
be included m a re' 1 ed set of questions used ro conduct future interviews. If the
question proves to be extremely important, it may be needed ro return to a previous
interviewee to query him or her on the topic.
The interview should consist of several different kinds of questions: open-ended,
closed-ended, or questions wirh a range of responses. When phrasing questions, :ivoid
leading questions that suggest or favor a particular reply. for example, rather than
asking, "What advantages do you see in the proposed system?" ask instead, "Do you
see any advan tages in the proposed system?"
Open-ended questions. Open-ended ques tions encourage spontaneous and
unstructured responses. Such questions are useful to understand a larger process
or draw our rhe interviewee's opinions, attitudes, or suggestions. Here are some
examples of open-ended questions:
•
\Vhat arc users saying about the new system?
•
•
How is rhis cask performed?
Why do you perform the task that way?
•
How are the checks reconciled?
•
What added features would you like to have in the new billing system?
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 4 Requirements Engineering
4.4 Gathering Requirements Th rough Interviews
I 18
Also, an open-ended question can be used ro probe further by asking: ls rhcre anything else you can rell me abour rhis ropic?
Closed-ended questions. Clo~ed-ended q uestions limit or restrict the response.
C losed-ended questions are used wbea informarion chat i more specific is needed
or when facts must be verified. Examples of closed-ended questions include the
following:
•
How many personal compurers do you have in this department?
•
Do you review the repo rts before rhey are sent our?
•
How many hours of training does a clerk receive?
•
•
Is the calculacion procedure described in the manual?
How many cusromers ordered products from rhe website lasr month?
Range-of-response questions. Ra nge-of-res ponse questio ns are closed-ended questions chat ask the person ro evaluate something by providing limited answers ro
specific responses or on a numeric scale. This metho d makes it easier co tabulate the
answers a nd interpret che results. Ra nge-of-response questions might include the
fol lowing:
•
•
On a scale o f I co 10, with 1 the lowest and 10 the highest, how effective was
your training?
How would you rate rhe severity of rhe problem: low, medium, or high?
• Is rhe system shutdown something that occurs never, sometimes, often, usuall>•,
or always?
STEP 4: PREPARE FOR THE INTERVIEW: After setting the objccti\'eS and develop-
ing the quesrions, preparing for rhe incerview is next. Careful preparation is essenrial
because an interview is an important meeting and nor just a casual char. \Xfhen the
interview is scheduled, suggest a specific day and time and let the interviewee know
how long the meeting is expecced ro last. Ir is also a good idea to send an email o r
place a reminder call rhe day before the interview.
Remember rhat rhc interview is an inrerruprion of the other per~on 's routine,
so rhc interview should be limited re> no more than one hour. If business pressures
force a postponement of the meeting, schedule another appoinrment as soon as ic
is convenient. Remember co keep de partment managers informed of meetings with
cheir srnff members. Sending a message to each department manager listing planned
appointments is a good way co keep them informed. Figure 4·9 is an example of such
a message.
A list of topics should be se11c to an interviewee several days before rhe mcecing,
especially when detailed in£ormatioo is needed, so the person can prepare for the
interview and minimize the need for a follow-up meeting. Figure 4- J 0 shows a sample
message chat lists specif ic questions and confirms the date, time, location, purpose,
and anticipated duration of the interview.
If there are questions about documents, ask the interviewee to have samples avaiJable at the meeting. The ad vance memo should include a list of the documents co
discuss (if it is known what they are). Also, a general request for documents can be
made, as the a nalyst did in the email shown in Figure 4· 10.
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gi ( . . . . . I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,...... .,..~
__.~~ c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
P hase 2
Systems A nalysis
119
4.4 Gathering Requirements Through Interviews
•••
d
••
I)
-
°"""'-·
-
0
B
From: Soon Tiiiy - t• f ~.. . .
•••a. Miii I wetM ..._ • ""9l!t _ . . tie¥Wlll
I em~ M U..Mw,.....,. ,....a~..,_.. I ....o .......... fWe .-.out uw"""
~ ol,,......
~ tN 1'11.W IYlhl'ft. ,._.. iM. me io.w 6 O'lt ,.....,.. 9CNdlolle • OK:
..rr
'°
•ff _ _ .... , _
· - i - . . - 1 1 .. , .1·-
. _ ..........- : u ..
to,,,.. ..... .,.,, ottw.,.....
1 ... ,.. k1'0W, I MM
WI ,...., ••• tl•*'lll..,. r. ~w ~It netCS4f I Nft ta~..... tfllt ....leml
.,......., .,,.... ..... tM end ti the~ ... rt ...........
ct. ayllCm . . .~ dow"*" .. toon . . ~ ......ble
M¥t ·~
~. ...... · - ~ Tt\tnld,
copy"'
u.,....
FIGURE 4-9 Sample message to a department head about interviews .
•••
d
••
0
I)
8
Cc:
llcc
-
"°"""',....,...,..,
l oa.-., oa.o. 1.L rm~.,. .. ,.... t....o ~
x ,._...., , ..,., .. _.,...,.~...,.~~.-e~w. .,..~u.'" wcu.,...,.tN __
TM-....,..,_"'¥~""'°'.,.., \fl ....,.~•
..... ..,.
•s...,•• "*'.....,at ..
• Wt' tJ'W,.. ~ M"'f
~ 1octbotl&1
• 0. .,._...,. ~,..... .......... ~ ~ tit tN: . . . .,"""' ,,..,-?
• W"llC ..,,,,., ~ .... 0 . . . . . . , . ,...,.,.. .,. the,..... ~?
• Wt'9 . . ~· .ll'\ tht~411cltMAon~"
• HIDW....,. .. .,....
·~~ !ft ~,.,... wipiCll
If"""
h9W! "'" ~-..,.....,,..or-..... O\IC dOni '*" thl:
TM"b
,_yew~
GM"IWft
s...-em. P'MM No-.. UIOl9 ....._.._•I wn rnicw ""-"".._,.we nllefll
.......
Scott Tii ey
FIGURE 4-1 0 Sample message to confirm an interview.
Two schools of thought exist about the best location for an interview. Some
analysts believe that interviews should take place in the interviewee's office, whereas
other analysts feel that a neutral location such as a conference room is better.
Supporters of interviews in the interviewee's office believe that is the best locntion
bccnu~e it m:.ikel> the interviewee feel comfortable during the meeting. A second
argument in favor of che interviewee's office is that the office is where he or she has
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
--
........... ......
"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ..... ...... ... ~..
__....
~~·~---- ···---~~ - .,.-"~
Chapter 4
Requirements Engineering
4.4 Gathering Requirements Through Interviews
120
the easiesr access co supporting material that might be needed during the di cussion.
If a complete list of copies is provided in advance, however, che interviewee can bring
the necessary items co a conference room or other location.
Supporters of neutral locations srress the importance of keeping interruptions to a
minimum so both people can concentrate fully. In addition, an interview that is free of
interruptions takes less rime. If the meeting does take place in the interviewee's office,
tactfull y suggest that all calls be held until the conclusion of the interview.
STEPS: CONDUCT THE INTERVIEW: After detennining the people to interview,
setting che objectives, and preparing the questions, a specific plan for the meeting should be developed. When cond ucting an interview, begin with introductions,
describe the project, and explain tbe interview objectives.
During the interview, ask questions in the order in which they were prepared and
give the interviewee sufficient time to provide thoughtful answers. Some answers will
lead co additional questions, which should be asked in a logical order. Establishing a
good rapport with rhc interviewee is important, especia lly if this is the first meecing. If
the other person feels comfortable and at ease, they will probably provide more complete and candid a nswers. T he analyst's primary responsibility during a n interview is
co listen carefull y to the answers. Analyses sometimes hear only what they expect co
hear. Concentrate o n what is said and notice an)' non ve rbal communication that takes
place. This process i called engaged Hstening.
After asking a question, allow the person enough time to think about the question
and arrive ar an answer. Studies have shown rhar the maximum pause during a conversation i ~ usually rhree to five seconds. After that interval, one person will begin
talking. An analyst needs co be patient and practice his or her skills in many acrnal
interview !>iruarions to be successful.
When all the q uestions have been asked, summarize the main points covered in
the interview and explain t he next course of action. For example, mention that a
follow-up memo will be sent or that the interviewee should send certain requested
information after the meeting. When the interview has concluded, thank the person
and encourage him or her to reach out with any questions or additional comments.
Also, when the interview ends, it is a good idea to ask the interviewee whether he or
she can suggest any additional topics that should be discussed.
After an interview, sumuiarize the session and seek a confirmation from the other
person. By stating the interviewer's understanding of the discussion, the interviewee can
respond and provide corrections, if necessary. One approach is to rephrase the interviewee's answers. For example, the analyse could say, "If I understand you correctly,
you arc saying rhat ...."and then reiterate rhe information given by the inrcrviewcc.
STEP 6: DOCUMENT THE INTERVIEW: Although taking notes during an interview
has both advantages and disadvantages, it should be kept co a minimum. It 1s a good
idea to write down a few notes to remember key poin ts after the interview but avoid
writing down everything that is said. Too much writing distr::1crs the other person a nd
makes ir harder ro establish a good rapport.
After conducting the interview, record the informa tion quickly. Set aside rime right
after the meeting to record the facts and evaluate the information. For that reason,
try not to schedule back-to-back interviews. Studies have shown char 50o/o of a conversarion is forgotten within 30 min utes. Therefore, use the notes ro record the facrs
immediately so they will not be forgotten. Sun1marize the facts by preparing a narrative describing wbar cook place or by recording the answers received next to each
question on the prepared list.
Small, portable recorders are effective tools for interviews, but some people arc
uncomfortable when they are used. Before using a recorder, discusr. ics use with the
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
P hase 2
Systems A nalysis
121
4.5 Gathering Requirements Using Oth er Techniqu es
interviewee. Assure the interviewee rhar rhe recording will be erased after its contents
are transcribed into note form and t hat rhe inrerview can be stopped ar any time ar
the inrer\'iewee's request. If sensitive questions are asked, or the interviewee wants ro
answer a question without being recorded, explain that the recorder can be turned off
for a period of rime during che incerview.
Instead of u~ing a traditional recorder that calls anenrion to its presence, an incerviewer can use built-in audio (or even video) recording features on a notebook or
mobile device. Also, as pointed our in Section 4.9, an interviewer can use powerful
informarion management software, such as Microsoft OneNote, co record the meeting,
store rhe resulrs, and create a searchable file for easy access. lrrespecrive of che mechanism used co record che meeting, all participants should be aware that what they say is
being recorded.
Wherher or not rhe meeting is recorded, listen carefully to the interviewee's
responses so good follow-up questions can be asked. Otherwise, a second visir
might be needed to ask the questions missed the firsr rime. Also, remember that each
recorded interview takes twice the amount of ri1111e, because the analyst must listen to
or view the recorded meeting again after conducting the interview itself.
After the meeting, a memo should be sent to the interviewee, expressing appreciation for his or her time and cooperation. In the memo, note the dare, rime, location,
purpose of rhe interview, and rhe main points discussed, so the interviewee has a written summary and can offer additions or corrections.
STEP 7: EVALUATE THE INTERVIEW: In addition to recording the facts obrained
in an interview, rry co identify any possible biases. For example, an interviewee who
tries to protect hi~ or her own area or function might give incomplece answers or
refrain from volunteering information. Or, an interviewee with strong opinions about
the current or future system might distort the facts. Some interviewees mighc answer
quescions in an arrempr to be helpful even though they do nor have rhe necessary
experience to provide accurate information.
Some interviews are unsuccessful irrespective of the amount of preparacion. One
of the main reasons could be rhar the interviewer and the interviewee did not get
along well. Such a siruarion can be caused b)' several facrors. For example, a misunderstanding or personal1ry conflict could affect the interview negatively, or the interviewee might be afraid that the new sysrem will eliminare or change his or her job.
In other cases, the inter viewee might give onJy shon or incomplete responses to rhe
open-ended questions. If so, switching ro closed-ended questions, or questions with a
range of replies, may elicit more favorable responses. If that stilJ does nor help, find a
tactful way to conclude the meeting.
Continuing an unproductive interview is difficult. T he inrerviewce could be more
cooperarive later, or the analyse might find the information required elsewhere. If fai lure to obtain specific information will jeopardize rhe success of the project, the supervisor s hould be informed, who can help decide what action to take. The supervisor
might contact the interviewee's supervisor, ask another systems analyst to interview
the person, or find some other way to get the needed information.
4.5 GATHERING REQUIREMENTS USING OTHER TECHNIQUES
In addition ro interviewing, syMems analysts use other requirement gathering techniques, including document review, observation, questionnaires and surveys, sampling, and research. Such techniques are used before interviewing begins to obtain a
good overview and to help develop bener interview questions.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 4
Requirements Engineering
4.5 Gathering Requ irements Using Other Techniques
122
4.5. 1 Docume nt Review
Document review c:in help the analyse undersrand how the current system is supposed
to work. Remember that system documenrarion sometimes 1s our of d:itc. Forms
can change or be discontinued, and documented procedures often arc modified or
eliminated. It is prudenr to obtain copies of actual forms and operating documents
currently in use, and ro review blank copies of forms, as well as samples of actual
completed forms. Document samples can be obtained during interviews with the people who perform that procedure. If rhe system uses a software package, review the
documentation for that software.
4.5.2 Observation
The observation of current operating procedures is another fact-finding technique.
Seeing the system in action provides additional perspective and a better understanding of system procedures. Personal observation also allows the analyst ro verify statements made in interviews and deterounc whether procedures really operate as they
arc described. Through observacion, it might be discovered that neither the system
documentation nor rhe interview statements are accurate.
Personal observation also can pro vide important advantages as the development
process continues. For example, recommendations often arc better accepted when
they arc based on personal observation of actual operations. Observation also can
provide the know ledge needed to rest or install future changes and can help build
relationships with the users who will work wirh the new system.
Plan observations in advance by preparing a checklist of specific casks to observe
and qucscions co ask. Consider the following issues when preparing che lisc:
•
Ask sufficient questions co ensure a complete understanding of rhe present system operation. A primary goal is to idenrify the methods of handling sicuarions
that arc not covered by standard operating procedures. For example, what
happens in a payroll system if an employee loses a rime card? \Vhar is rhe procedure if an employee starts a shift 10 minutes late but then works 20 minutes
overtime? Often, rhe rules for exceptions such as these arc nor written or formalized; therefore, try ro document any procedures for handling exceptions.
• Observe all rhe steps in a transaccion a nd note the docu1nents, inputs, oucpurs,
and processes involved.
• Examine each form, record, and report. Determine the purpose each item of
information serves.
• Consider each user who works with the system and the following questions:
What informa tion does tbat person receive from other people? Wh:ir information does this person generate? How is the information communicated? How
often do interruptions occur? How much downtime occur)? I low much support does the user require, and who provides it?
• Talk ro the people who receive current reports to sec whether the reporrs arc
complete, timely, accurate, and in a useful form. Ask whether information can
be eliminated or improved and whether people would like to receive additional
information.
As people are observed at work, as s hown in Figure 4-11, consider a factor called
the Hawthorne Effect. The name comes from a well-known study performed in the
Hawthorne plane of rhe Western Electric Company in the 1920s. The purpose of the
study was co determine how various changes in the work environment would affect
(....,..... J:gi( . . . . .
I_,.. 4 111.,.. .................,.t11ru
- Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
- ·~• -fllllie<'f •,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~-- - t fta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-.. • ~-" .....- ""'*"....,.._...,.. ..
I'
I
P hase 2
Systems A nalysis
123
4.5 Gathering Requirements Using Oth er Techniqu es
employee productivity. The surprising result was that productivity improved during
observation whether the conditions were made better or worse. Researchers concluded that producriviry seemed to improve whenever the workers knew they were
being obsen·ed.
FIGURE 4-1 1 The Hawthorne swdy suggested !hat worker productivity improves during observaaon. Always
consider the Hawthorne Effect when observing the operation of an existing synem.
.....
Although some recent srudies have raised questions about the original findings, be
aware that observation can and does have an effect on normal operations. With this
in mind, always give advance notice ro the supervisor in that area. In some situations,
it might be helpful to explain the purpose of the visit to the people being observed.
4.5.3 Questionnaires and Surveys
In projects where it is desirable ro obrain input from a large number of people, a
questionnaire can be a valuable tool. A questionnaire, also called a survey, i~ a document containing a number of standard questions that can be sent to many individuals.
Questionnaires can he used ro obta in information about a wide range of topics,
including workloads, reports received, volumes of transactions handled, job duties,
difficulties, and opinions of how the job could be performed better or more efficienrly.
Figuie 4-12 shows a sample questionnaire that includes several different question and
response formats.
A typical questionnaire starts with a heading, which includes a tirle, a brief
statement of purpo e, the name and telephone number of the contact person, the
deadline date for completion, and how and where to return the form. The beading
usually is followed b)• general instructions that provide clear guidance on how
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
--
........... ......
"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ..... ...... ... ~..
__....
~~·~----···---~~ - .,.-" ~
Chapter 4
Requirements Engineering
4.5 Gathering Requ irements Using Other Techniques
124
..........
..._,......
.....
.
..
..............
.
__....... ---·--
,._
......_...._ __...
_..
........................
_....,._._.,,......
...-~
tt•W . . . . _ _ . . _ . ,.......... - . - - - - ·· . . .
--··-·-·.....
,,_
I_ . . . . . . . . . . . .,.., . . . . _ . . . . . . . . _ _
a.0.,. ............ - -.........l
--·
... ..
•••,.
··---
----- ......
---
. . . . . . . . . . ,.. . . _ _ _ .....,..l
..............................,
.. ..,,.. lUOOltT'IOMI
--
a. ......................... .,...,............, _ _ _ _ _ ,..
--
_....,,, __ .._IN.............
-
to answer rhe questions. Heading~ also arc used to
introduce each main section or portion of the survey
and include instructions when rhe type of question or
response changes. A long questionnaire might end with a
conclusion that thank~ the participants and reminds them
how to return the form.
What about the is ue of anonymity? Should people
be asked to sign the questionnaire, or is tr bener to allow
anonymous responses? The answer depend~ on two questions. First, does an analyst really need ro know who the
respondents arc in order to march or correlate informatio n? For example, it might be important to know what
percentage of users need a certain software feature, but
specific usernames might not be relevant. Second, docs
the questionnaire include any sensitive or controversial
topics? Many people do not want to be identified when
answering a question s uch as " H ow well has yo ur supervisor explained the system to you?" In such cases, a nonymous res ponses might provide better information.
Wben designing a questionnaire, the most important rule of all is to make sure that the questions collect
rhe right data in a form that can be used to further the
fact-finding effort. Herc arc some additional ideas to keep
in mind ·when designing the questionnaire:
• Keep the questioonaLre brief and uscr-fricndlr.
• Provide clear instructions chat will answer all anticiFIGURE '4-12 Online version of a sample questionnaire.
Does it follow the suggested guidelines!
pated questions.
• Arrange the questions in a logical order, going from
simple to more complex topics.
• Phrase questions to avoid misunderstandings; use simple terms and wording.
• Try not to lead the response or use questions that give clues to expected
answers.
• Limir the use of open-ended questions that are difficulr to tabulate.
• Limit the use of questions that can raise concern~ about job security or other
negative issues.
• Include a secrion at the end of the questionnaire for general comments.
• Test the questionnaire whenever possible on a small test group before fina lizing
ir and distributing ro a large grou p.
A questionnaire can be a traditional paper form, or it can be created in a fill-in form ,
and the data can be collected on the internet or a company intrnnct. Before publishing the form, protect ir so users can fill it in but cannot change the layou t or design.
O nline survey websites, such as SurveyMonkey and Google Forms, ca n also be used
to create and manage questionnaires .
4.5.4 lnterviewsVersus Questionnaires
\'<i'hcn seeking input from a large group, a questionnaire is a very useful cool. On the
other hand, if detailed information is required from only a few people, then each
(....,..... J:gl( . . . . . I_,.. 41 11.,.. ~- )U, ..,...,.......,..~
r..a...w...,..._...., ..
Woip-M ._..,.. - ·~• -fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---t fta111&....-.~~ij
.................,.t11ru ..
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-.. • ~-".....-""'*"....,.._...,.. ..
I'
I
Phase 2
Systems A nalysis
125
4.5 Gathering Requirements Using Oth er Techniqu es
person should probably be interviewed individual!)•. ls it bener co interview or use
a questionnaire? Each sicuacion is different; consider the rype of information, time
constraints, and expense factors.
The interview is more familiar and personal than a questionnaire. People who
are unwilling co put critical or conrro,·ersial comments in writing might talk more
freely in person. ~l oreover, during a face-co-face interview, the interviewer can react
immediately co anything che interviewee says. If surprising or confu~111g statements
arc made, the topic can be pursued with additional questions. In addition, during a
personal interview, the analyst can watch for clues co help determine if responses are
knowledgeable and unbiased. Participation in interviews also can affect user anirudes because people who arc asked for their opin ions often view the project more
favorably.
Interviewing, however, is a costly and rime-consuming process. IJ1 addition to the
meeting itself, both people must prepare, and the interviewer has to do follow-up
work. When a number of interviews are planned, the rotal cost can be quite subsrnntial. The personal interview usually is the most expensive fact-finding technique.
ln contrast, a question naire gives many people the opportunity to provide input
and suggestions. Questionnaire recipients can answer the questions at their convenience and do not ha vc to set aside a block of time for an interview. If the questionnaire allows anonymous responses, people might offer more candid responses than
they would in an interview.
Preparing a good questionnaire, however, like a good interview, requires skill and
time. If a question is misinterpreted, its meaning cannot be clarified as easi ly as in a
face-to-face interview. Furthermore, unless questionnaires arc designed well, recipients
mighr view rhem as inrrusive, rime-consuming, and impersonal. The analysr should
elect rhe rechnique char will work besr in a particular siniarion.
4.5.5 Brainstorming
Another popular method of obtaining input is called brainstorming, which refers to
a small group disCu$s1on of a specific problem, opporruniry, or issue. Thi'! technique
encourages new ideas, allows team parricipation, and enables participants to build
on each other's inputs and thoughts. Brainstorming can be structured or unstructured. In struccured brain\torming, each participant speaks when it is his or her turn
or passes. In un \ tructured brainstorming, anyone can speak ac any rime. At some
point, the resulrs are recorded and made pare of che fact-finding documenratton
process.
4.5.6 Sampling
When studying an information system, examples of actual documents should be collected using a process called sampling. The samples might include records, reports,
operational logs, data entry documents, complaint summaries, wo rk requests, and
various types of forms. Sampling techniques include systematic sampling, stratified
sampling, and random sampling.
Suppose there is a list of 200 cusromers who complained abour errors in their
statements, and a representative sample of 20 customers will be reviewed. A
systematic !>ample would select every cench customer for review. To ensure that the
sample is balanced geographically, however, a stratified sample could be used to select
five customers from each of the four postal codes. Anocher example of stratified
sampling is to select a certain percencage of rransaccions from each postal code, rather
than a fixed number. Finally, a random sample selects any 20 customers.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
--
........... ......
"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
__....
~~·~---- ···---~~-.,.-"~
Chapter 4
Requirements Engineering
4.5 Gathering Requirements Using Other Techniques
126
The main objective of a sample is co ensure that ir represents the overall popularion accurately. If inventory transactions are being analy7ed, for example, select
a sample of tran actions char is typical of actual inventory operations and docs not
include unusual or unrelated examples. For insrance, if a company performs special
processing on the last business day of rhe month, char day is not a good time to sample typical daily operations. To be useful, a sample must be large enough to provide a
fair reprcsenrarion of the overall data.
Sampling should also be considered when using interviews or questionnaires.
Rather than interviewing everyone or sending a quesrionna1re to the entire group, a
sample of participants can be used. Sound sampling techniques muse be used to reflect
the overall population and obtain a n accurate picture.
4.S.7 Research
Research is another important fact-finding technique. Research can include the Internet, IT magazines, and books to obtain background information, technical material,
and news about industry trends and developments. In addition, attending professional
meetings, seminars, and discussions with other IT professionals can be very helpful in
problem solving.
The Internet is rin extremely valuable resource. Using the Internet, the analyst can
access information from federal and state governments as well as from publishers,
universities, and libraries around the world. Online forums and newsgroups arc good
resources for exchanging information with other professionals, seeking answers co
questions, and monitoring discussions that are of mutual interest.
All major hardware and software vendors maintain websites with information abour product<> and services offered by the company. There arc also websites
mainrained by publishers and independent firms that provide links co hundreds of
hardware and software vendors. Examples of popular websites for IT professionals
include Ars Technica, CNET, Info World, TechCrunch, and the Wlal/ Street journal's
Technology pages (shown in Figure 4-13).
.
.
-~---
-
. ..
..
'VSJ lICll
--·
- -- "" ...................... .,_,. w.•• .......... _._
-a.
_,.
- ·---
_
.........
------......_...._
..... ~...._ .........<-. -
__ - "'
.....,._...,._
,._
__
........
.
_.,._ •·--·---.. --· ~
~-·
--~
.,,..._.
1- - 1
__
........
,_...._,.
.........
-.. _
_
.............
......... ....................... !-··!
...,._ ... .......... .. ,....._.,_,..
_
...
..
.....__........,_
..,
.............
,_._
.. ... --·· -·-· . .
r...J.....~c:.ar...
~
\
f\>llllcal Rtallly: Buy Ads
_......._..,._
._
......
~
on Fatfbook or lllik
Loi.Ins the ElecUoo
--
..........
.......
___
......
_.................
-...............
_...,...
__.....·-_--........ .... .......
-----·
~
..._._
...,_~
------·~
--·---
FIGURE 4 . 13 The WoH Sr:reetjoumo/'sTechnology website contains valuable infonnadon
for IT professionals.
~re-=
(....,..... J:gi( . . . . .
.. ~ ~•
n.l.
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~---tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
I
Phase 2
Systems Analysis
4.6 Gathering Requirements in Agile Projects
Research also can involve a visir ro a physical location, called a site \tsit, where the
objective is to observe a system in use at another location. For example, if a firm's
human resources information system is the subject of study, it might be beneficial co
see how another company's system works. Site visirs also are important when considering the purchase of a sofrware package. If the sofrware vendor suggests possible
sites to vi~it, be aware that such sires might constirute a biased sample. A single site
visit seldom provides crue picrures, so try co visit more than one installation.
Before a site visir, prepare just as for an interview. Contact rhe appropriate manager and explain rhe purpose of the visir. Decide what questions will be asked and
what processes will be observed. During the visir, observe how rhe S)'Stem works and
note any problems or limiracions. Also learn about the support provided by the vendor, the quality of the system documentation, and so on.
CASE IN POINT 4.2:
CYBERSTUFF
CyberSwff is a large company that sells computer hardware and software via telephone and
online. CyberSwff processes several thousand transactions per week on a three-shift operation
and employs SO full-time and 125 part-time employees. Lately. the billing department has experienced an Increase In the number of customer complaints about incorrect bills.You have been
tasked with finding out why this is happening.
During your preliminary Investigation, you discovered that some CyberStuff representatives did not follow established order entry procedures.You feel that with more Information. you might find a pattern and identify a solution for the problem, but you are not
sure how to proceed.
Is a que stionnaire the best approach, or would interviews be better? And whether you
use interviews, a questionnaire, or both techniques. should you select the par ticipants at
random, include an equal number of people from each shift. or use some other approach?
How do you proceed?
4.6 GATHERING REQUIREMENTS IN AGILE PROJECTS
Lf agile methodi. are used for requi rements gathering, a variation on interviews
that focuses on features, user ~tories, scenarios, a nd storyboards is used. A feature
(sometime~ called an epic) is a simple, bigh-level statement of a requirement. A
feature has a descriptive name, an estimate of its size in terms of derived requi remenrs
or user stories, and a priority. Featu res are typically provided by the stakeholders
through initial interviews with rhe systems analyst.
User stories represent more fine-grai ned requirements. Taken together, a set of user
stories forms a fearure. A user story also has a descriptive name, along with a i.imple sentence of the form "As a Iuser role], I want [action] so that [goal I." User roles,
actions, and goals arc terms that represent a category of stakeholder, a particular
effect, and an outcome, respectively. User stories also include an optional condition
of satisfaction, wh ich can be used as a guide to determine whether or not the requirement was satisfied by the produce. A user story is: 1neanr to be succinct and is often
drawn on a 3" x 5" index card (or the software equivalent).
A scenario is a real-world example of how users will interact with the system. A
scenario describes a parricular ser of seeps raken or events that wiU occur while the
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
127
Chapter 4
Requirements Engineering
4.7 Representing Requ irements
128
system is used for a specific function. Ir is used to refine rhe system requirements ro
better reflect actual usage of the sysrem.
A storyboard is a simple graphic organi7..er rhar helps systems analysts visuali7..C rhe
srarus of a project. A sror)•board can be as rudimentary as a wall with <;rick)' norcs.
There arc also many software roots that enhance storyboards while still maintaining
their essential feel.
Because agile methods are iterative in nature, requirements are gathered and successively refined. They begin as features, which are then spllC mro smaller user stories,
which in rurn are refined inro scenarios. Agile methods are particularly well suited ro
pro1ccrs where rhe requirements are expected to change frequently.
4. 7 REPRESENTING REQUIREMENTS
Once requirements have been gathered, they must be recorded. Keeping accurate
records of inrerviews, faces, ideas, and observations is essential to s uccessful systems
development. As information is garhered, the importance of a sing le item can be
overlooked or complex system derails can be forgotten. The abili ty ro manage infor1narion is rhe mark of a successful systems analyst and an important skill for all .IT
professionals. The basic rule is to write it down. Analysts shou ld document their work
according to the following principles:
•
Record information as soon as it is obtained.
•
Use the simple'lt recording method possible.
•
•
Record findings in such a way rhat someone else can understand them.
Organize documenrarion so related material is located easily.
There arc several techniques used to do this, ranging from an unordered collection of
sentences to a structured database of formal models. Whatever representation is chosen, proper!)' managing the requirements over rhe lifetime of a project is a key to irs
success.
4.7. I Natural Language
The vast majoriry of requirements are represented using unstructured natural language, that is, plain English. Examples of these requirements were shown in Section
4. ·1.1. This represcnrarion is easy to create but is prone co problems such as imprecision and a lack of shared understanding.
Requirements represented as unstrucrured natura l language can he ~tored in a simple file, in a database that may facilitate sea rch ing its contents, or in an Excel spreadsheet. The larrer choice is a popular one, because most systems analysts are familiar
with rhe root, a nd chey are likely to have access co it already.
An improvement upon unstructured natural language is structured natural language. This representation rags part o f the requirement, rather like an XML document. This facilitates automated processing of the requirement statements, but it's not
very user-friendly.
Requirements represented as structured natura l language can be stored on a simple
index card. The Volere shell from the Atlantic Systems Guild, shown in Figure 4- 14,
i~ a mature method of representing single requirements on a 3" x 5" card. There are
several tools that mimic these fearures, providing automation while maintaining the
simple representational format.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
I
Phase 2
Systems Analysis
129
4.7 Representing Requirements
There arc also formal techniques, based on mathematics,
that can be used to represent complex requirements.
Languages such as VDM and Z are used for this purpose.
They have the advantage of mathematical consistency, but a
major disadvantage of this technique is that many systems
analysts are unfamiliar with the language's consrrucrs,
which can affect the requirements' understandability.
lrrespecttvc of the natural language cechnique
chosen, md1v1dual requirement<; must be collected
into a requirements document. This document is the
official statement of what is requi red of rhe syscem by
the users. The Volere template is a good template for a
comprehensive requirements document. It is populated by
atomic requi rements from the Volcre shells.
CASE IN POINT 4.3:
Volere
FIGUR E 4- 14 TheVolere shell.
~ A tr•
\... 1 r
DIGITAL PEN TRANSCRll'l ION
You are the lead systems analyst on a large project.A big part of your responsibilities is to handle the system requirements. Extensive interviews have taken place, and you have written down
your notes using a digital pen system.This system recognizes letters and words while you write
on paper and srores them in digital format on your computer. In this way. the requirements are
written in unstructured nawral language but stored digitally, which means they can be searched
and processed. Do you think it would be worthwhile to edit the transcription and insert tigs to
delineate key terms in the requirements, so that a CASE tool could better analyze them/There's
a lot of effort required to do the manual tagging. but the rewards could be better requirements.
How would you perform the tradeoff analysis!
4.7.2 Diagrams
~lany people are more visual rhan texrual. For them, diagrams are an excellent choice
co repre!.en r system requirements. Diagrams help users, managers, and IT professionals understand the design of a system. Diagramming involves graphical methods and
nontechnical language that represent the system at various stages of development.
During requiremen ts engineering, the analyst can use various cools co describe business processes, requirements, and user interaction with the system.
Systems analysts use diagram1ning and fact-finding interactively-first they build
fact-finding resu lts into diagra ms, then they study the diagrams to determine whether
additiona l face-finding is needed. To help chem understa nd system requirements,
ana lysts use fu nctional decomposition diagrams, business process diagrams, a nd dara
flow diagrams. Any of these diagrams can be created wi th CASE cools or sta nd-alone
drawi ng tools if desired.
A fun ctional decomposition
diagram (I-OD) is a mp-down rep resentation of a. fu nction or process. Using an f DD,
an analyst can show business functions and break chem down inco lower-level func·
tions and processes. Crearing an FDD is sin1ilar co drawing an organization chart:
Scare at rhe top and work downward. Figure 4-15 shows an FOO of a library system
drawn with the Visible Analyst CASE cool. FDDs can be used at several stages of
FUNCTIONAL DECOMPOSITION DIAGRAMS:
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Chapter 4
Requirements Engineering
4.7 Representing Requi rem ents
130
systems development. During requi rements engineering, analysts use FD Os to model
business functions and show how they are organized into lower-level processes. These
processes translate into program modules during application development.
Finan: e &
Human
Resources
AccOUlbng
Operalons
Budge:ing
Add&
Remove Books
CheckolJ&
RetumBooks
Bock
Management
Personnel
AssigfT1'1ef11
Arctwe CheckolJ
l.Jst and Use' l.Jst
FIGURE 4- 15 This Visible Analyse FDD shows a library system with five top-level functJons. The Library
Operadons function includes cwo additional levels of processes and sub-processes.
BUSINESS PROCESS DIAGRAMS:
A~
described in Chapter I, a bu\iness proce~s
model (BPM) represents one o r more
,.
Create
Sh1.
p
p1ng
busi11ess processes, such as handling an
Pfoce11 Order - t Prepare 81111no H
E
Oata
airline reservation, filling a product order,
~
ti;
or updating a customer account. During
~
c
;;;
requirements engineering, analysts ofren
w
create diagrams that use a standard
!!
syntax called business process modeling
~
Assign
notation (BJ>MN). BPMN includes
si ' Obtain Crtidil I-+ " Validate Credit H
Customer
011•
S tatus
Number
various shapes and symbols to represent
3 'events, processes, :1 nd workflows.
When creating a business process diagram using a CASE tool such as Visible
Analyst, the diagram automatically
FIGURE <4- 16 Using the Visible Analyst CASE tool, an analyst can create a
busine.ss process diagram.The overall diagram Is called a pool. and the cwo
becomes part of the overall model. In
separate customer areas are c:alled swim lanes.
the example shown in Figure 4- 16, using
s.-... ,.,_ _ _ ,,.
""' ''"' - """"'...,,.
BPMN terminology, the overall diagram is
called a pool and che designated customer areas arc called swim lanes. Integrating BP~1
into the CASE development process leads to faster results, fewer errors, and reduced cost.
-..
-..
-..
i
!
a
..
~
~·
Q.
a
--
I
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
Phase 2
Systems A nalysis
131
4.7 Representing Requirements
DATA FLOW DIAGRAMS: \Xforking from an FDD, analysts can creace daca now
diagrams (DFOs) co show how che syscem scores, processes, and cransforms daca.
The DFD in Figure 4- 17 describes adding and removing books, which is a function
shown in the Librar)' Managemenc diagram in Figure 4-15. ore char the cwo boxes
in che DFD repre'lenc processes, each with various inpucs and outputs. Additional
le,·els of informacion and decail are depicted in o rher, related DFDs. Daca and process
modeling is deM:rihed in derail in Chapter 5 .
..
Boob
Bool<Tllo
,.
~
---2..!.. Ir'"':'
- A61'S"'
~
Add----
.
.
AWlOl's
Updaled AIA!"Ol'S
Boob
Doob
'
'.
.
••
Boolcs
"
FIGURE 4-1 7 This Visible Amlyst DFD shows how books are added and
removed 1n a library system.
'
4 .7 .3 M odels
Models provide a more formal representation of system requirements. They arc o ften
depicted as graphical in nature, so they share some of the cbaractcriscics of rhc techniques described in Secrion 4.7.2. But models have an additional feature: The underlying language has semantics, which means the diagram has a significance that can be
aucomatically analyzed by a CASE rool.
The Unified Modeling Language (UML) is perhaps rhe most widely used modeling technique for visual izing and documenting software sysrems design. UML uses
object-oriented design concepts, but it is independent of any specific programming
language and can be used ro describe business processes and requirements generally.
SysML is a dialecr of UML and has become the sitandard for Model-Based Sysrems
Engineering (M BSE) applications.
UJ\ll L provides various graphical cools, such as use case diagrams and sequence
diagrams. During requirements engineering, a systems analyse can utilize the
UJ\ll L co represcnc the informacion syscem from a user's viewpoinr. Use case dia!,'Tams, sequence diagrams, and other U~1L concepcs are discussed in mo re derail in
C haprer 6, along with other object-orienced analysis conceprs. A brief description of
each technique follows.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 4
Requirements Engineering
4.7 Representing Requireme nts
132
USE CASE DIAGRAMS: During requirements engi-
neering, S}'Stems analysts and users work together to
document requirements and model system functions.
A use case diagram visually represents the interaction
between users and the information system. In a use case
Submits
card O..ta
diagram, the user becomes an actor, with a specific role
that describes how he or she interacts with the sy5tem.
Systems analysts can draw use case diagrams freehand
or use CASE tools t hat integrate the use cases into the
Customer
overall systems design.
Figure 4-18 shows a simple use case diagram for
a sales system where the actor is a customer and
FIGURE 4-18 This Visible Analyst use case diagram
the use case involves a credit card validation that is
shows a sales system, where the actor Is a customer and
perforn1ed by the system . Because use cases depict
the use case is a credit card validation.
the system through the eyes of a user, common
I
" '" f "1\/ •4 'Y'i
I C ~ I •I Jll'I
business language can be used to describe the
transactio ns. For example, Figure 4-1 9 shows a table that documents the credit
card validation use case, and Fig ure 4-20 shows a student records system, with
severa l use cases a nd actors.
' ¥<' I
f
SEQUENCE DIAGRAM: A sequence diagram shows t he timing of interactions
between objects as t hey occur. A systems a nalyst might u~e a sequence diagram to
show all possible outcomes o r focus on a single scenario. Figure 4-2 1 shows a ~im­
ple sequence diaE,'Tam of a successful credit card validation. T he interaction proceeds
from top to bottom along a vertical rimeline, while the horizonral arrows represent
messages from one object co another.
Name of Use Case:
Credit card validation process
~~~~~~~~~-
Actor:
Customer
Description:
Describes the credit card validation process
Successful Completion:
I. Custo mer clicks the input selector and
enters credit card number and e)(piration date
2. System verifies card
3. System sends autho rization message
Alternative:
I. Customer clicks the input selector and
enters credit card number and e)(piration date
2. System rejects card
3. System sends rejection message
Precondition:
Customer has selected at least one item and
has proceeded to checko ut area
Postcondition:
Credit card information has been validated
Customer can continue with order
Assumptio ns:
None
FIGURE 4- 19 This table documents the credit card validaaon use case shown in Figure 4-18.
~- )U,
-Woip-M ._..,..
r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
..
(....,..... J:gi ( . . . . .
..,...,...... .,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~ c.....,..~
.........,..,. ..
._.,.,.,.......c:-..•~-".....-""'*"....,.._...,..
..
I'
I
P hase 2
Systems A nalysis
133
4.8 Validating and Verifying Requirements
Registration
System
Student
Advisor
Record
Grades
Registrar
lnstruttor
FIG URE 4-20 This Vislble Analyst use case diagram shows a student records system.
Sou~:
•r•
I
~ 1 ....1tk pC'f'Tn1
"' 1•om\l'~I~ !)~CoiporatlO'\-
V•lldate
Card.:Credll Card
Cu1toma11
Customer Credll
Card Cutlomen
I
I
Enter Card Number
I
I Verify Card Number
I
I
I
I
Authortlation
FIGURE 4· 21 ThisVlsibleAnalyst sequence diagram shows a
credit card vatldatlon process.
Soutt•:ti.
V..ll.
wl'1;:>
onl -iV ·bicS~~ ·
4.8 VALIDATING AND VERIFYING REQUIREMENTS
Requirements validation and verificarion (V&V) is concerned with demonstrating
that the requirements define the system that the customer really wants. Since require·
ments error costs arc high, V&V is very important; it is many times more expensive
to fix a system later in the SDLC rhan iris to fix it during requirements engineering.
Requirements V&V focuses on answering rwo important questions:
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ...............,..
__....
--
........... ......
o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
~~·~----···---~~-.,.-"~
Chapter 4
Requirements Engineering
134
4.9 Tools
•
•
Validation: Are rhe correct requirements stared?
Verification: Are the requirements stated correctly?
To answer these questions, the following requirements anributes should be
checked:
•
Validity: Does rbc system provide the functions that best support rhe customer's needs?
•
•
Consistency: Are rhere confliccing requirements?
Completeness: Are all funcrioos required by rhe customer included?
•
•
Realism: Can che requiremenrs be implemented given avmlahle budget and
technology?
Verifiability: Can the requirements be checked?
•
Comprehensibility: Is the requirement properly understood?
•
•
Traceability: Is the origin of rbe requirement clearly seated?
Adapt:ibiliry: Can the requirement be changed without a large impact on ocher
requirements?
To check rhese, the following techniques can be used:
•
Requirements reviews: Systen1atic manual analysis of the requirements.
•
Prototyping: Using an cxecucable model of the system to check the
req u iremcn rs.
• Test-case generation: Developing resrs for requirements co check testability.
•
Automated consistency anaJysis: Checking the consistency of a srrucrured or
formal requirements descripcions.
Consider requirements reviews. Regular reviews can be held while the requirements are initially being formulated. Ideally, the systems analyse and the customer
(a nd perhaps other key scakeholders) should be involved in the reviews. The reviews
can be forma l (with complete documentation) or informal. The key is that good communicauons berween analyses, customers, and others can resolve problems ar an early
stage, which is better for everyone.
4.9 TOOLS
All requirements engineering activities can be helped through rhc judicious use of
tools. For example, many softwa re programs a re available co help record and document information elicited during the requirements gathering process. This type of
productivity software includes automation, word processing, spreadsheet, database
management, presentation grap hics, and collaboration software programs. Although
Microsoft Office is the best-known set of productivity software programs, ocher vendors offer produces in each of these categories.
A pcr5onal information manager (PIM), such as Microsoft Outlook, includes a
personal calendar, a to-do list with priorities and the capabi lity co check off completed items, and powerful contact management features. Outlook can manage email
and appointments and supports collaboration and team projects.
Although a PL\il such as Microsoft Outlook can handle day-to-day activities,
tasks, and schedules, it is nor the best wa)' co capture and organize large amounrs of
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
Phase 2
Systems A nalysis
135
4.9 Tools
information. lnsrcad, analysts use information management sofrware such as Microsofr
OneNore, which is a powerful, flexible tool that can handle many differenr types of
input, including text, handwritten notes, images, audio and video recording, web link~,
and much more. One ore is included in several versions of the Office suire.
Figure 4-22 show~ anorher popular Pl~1 called Evernote. Ir is available for free
on mosr computing plarforms, including smanphones and on rhe web. There are also
premium versions available on a monchly subscriprion model. Evernote does a great
job of handling all sorts of mulcimedia concent, adding free-form nores, and providing
templates for organizing projects. It also syncs files across all devices.
4 Evemote
_;__...J
- · . , Ll
FIGURE 4-ll Evernole offers a free version of its popular infonnation managemenl software for mon
computing platforms. Including smartphones and on the web.
Sowcc
Using word processing sofrware such as rvlicrosoft Word, the analyst can create
repons, summaries, tables, and forms. In addicion ro standard document prepararion,
the program can help o rga nize a presentation wirb templates, bookmarks, annotations, revision control, and an index. Fill-in forms can also be creared ro conduct surveys and quesrionnaires, as described earlier in this chaprer.
Spreadsheet software, s uch as Microsoft Excel, can help track and manage
numeric dara or financial informarion. fn fact, Excel is one of the most popular ways
of representing requirements in an informal manmer. Graphs and charrs can also be
generarcd thar display rhe darn and show possible parrerns. The statistical functions
in a spreadsheer can be used to tabulate and analyze quesrionnaire data. A graphica l
formar often is used in qua liry conrrol analysis because it highlights problems and
their po s ible causes, and iris effective when presenting results to management. A
common tool for showing rhe disrribution of questionnaire or sampl ing results is a
vertical bar cha re called a histogram. Most spreadsheet programs can create histograms and other charts chac can display the daca collected. Figure 4-23 displays a typical histogram char might have resulted from rhe questionnaire shown in figure 4- 12.
Database management software allows the analyst co document and organite
fact-finding results such as events, observations, and daca samples. A database prograrn such as Microsoft Access can be used to manage the details of a complex project, create queries to retrieve specific informarion, and generate custom reports.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 4
Requirements Engineering
4.9 Tools
136
A
c
B
(j
E
D
1
Question 2:
2
What percenblge of your time do you spend processing niqulsltlon•?
3
4
s
6
1
8
9
C•l!QO'Y
< 20%
20-3t%
.o.tit%
60-7t%
80% or mora
Number
11
21
36
2A
!I
10
le
Question 2 results
40 35
30 + - - - - - --1> Jl - - - - ---1
25
'l l---:::::----1
20
+-------a. . ~-'
11
12
13
15 .__ _-f.; :1--1 ,,1 --1 .1 - - ---1
10 -'--'....,._ _,, ..._ ... . . _ ...
14
1!>
16
11
0 ~-.._.-............- .....................- ..
5 .....
<20%
2039%
;
--n-~
·
4059%
60- 80% or
79% more
18
19 4
,.
•
•1 SheetJ
St (11.-u
ID •~-======::=======================~·
____
. _ __,'
FIGURE 4·ll This histogram displays the results fro m Question 2 In the questionnaire shown
In Figure '4-12.
Presenrarion graphics software, such as tvl icrosoft PowerPoint, is :i powerful tool
for organ i.ling and developing formal presentations. Presentation graph ics programs
enable the creation of org:inizarion charts that can be ui.ed in a preliminary inve~ciga­
tion and later during requirements engineering. T hese high-quality charts also can be
included in written reports and management presentations.
Collaborarion sofrware is the latest weapon in the struggle co boost productivity.
People work m reams and use web-based software such as Google Docs and Microsoft
Office 365 co access data and share files. Google and others are betting char cloud com·
puring will create a vinual workplace, where people will be able co interact in real time,
with all the benefits of a traditional face-to-face workplace bur none of che limirarions.
When it comes co creating diagrams char
represent requirements, Microsoft Visio is a
...
.._
popular graphic modeling cool char can produce a wide range of charts and diagrams .
•
Visio includes a library of templates, stencils,
and shapes. An analyst can use Visio co create
I "
many types of visual models, including business
processes, flowcharts, network diagrams, orga~
nization charts, and ma ny more. For example,
....
in Figure 4-24, the :inalyst used drag-and-d rop
Ii..
shapes to represen r a business process .
For more forma l models of rcqui rcmcnrs,
'1l
special-purpose tools such as IBM Rational
e
DOORS are used. These cools faci litate the use
fJ
of UML (and SysM L) co model sysrcm require:l·
ments in a way that enables desirable character0
istics, such as traceability, where rhe origin of a
requirement i~ connected back co the requirement itself, which in turn is linked forward co
design artifacts, code fragment~, and even rest
cases in the SDLC. Figure 4-25 illustrates some
FIGURE 4-24 Th1sV1sio drawinc uses drag-and·drop shapes
of the capabilities of DOORS Next Generation.
to re present a business process.
., -
- - - --
'..•
•••
- •I•1
c: •.]l
..
-
..
(....,..... J:gi( . . . . .
I_,.. 4 111.,.. .................,.t11ru
- Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
- ·~• -fllllie<'f •,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~-- - t fta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-.. • ~-" .....- ""'*"....,.._...,.. ..
I'
I
I
Phase 2
Systems Analysis
4.10 Summary
FIGURE 4-25 IBM DOORS Is a to0I for capturing. analyzing, an d tr.icing system requirements.
ISM C. P r&
Your supervisor manages the corporate office where you work as a systems analyst. Several weeks ago, after hearing rumors of employee dissatisfaction, he asked you to create a
survey for all IT employees.After the responses were returned and tabulated. he was disappointed to team that many employees assigned low ratings to morale and management
policies.
This morning he called you into his office and asked whether you could identify the
departments that submitted the lowest ratings. No names were used on the individual
survey forms. However, with a little analysis, you probably could identify the departments
because several questions were department related_
Now you are not sure how to respond.The expectation was that the survey would be
anonymous. Even though no individuals would be identified, would it be ethical to reveal
which departments sent in the low ratings/ Would your supervisor's motives for wanting
this information matter1
4.1 0 SUMMARY
The systems analysis phase includes three activities: requirements engineering,
data and process modeling, and consideration of development scrategies. The main
objecu,·e is co understand rhe proposed project, ensure char ir will support business
requirements, and build a solid foundation for the systems design phase. Requirements
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
13 7
Chapter 4
Requirements Engineering
4.10 Summary
138
engineering irself is composed of three main parts: ( 1) garhering rcquiremenrs,
(2) represenring requiremencs, and (3) validating and verifying requiremenrs.
During requi remcnrs engineering, che business-relared requircmenrs for rhe new
information sysrcm a re idenrified. Scalabiliry is considered ro ensure rhar rhe sysrem
can supporr fururc growth and expansion. Securiry is an essenrial requiremenr of all
modern connccred sysrcms. The TCO is also esti mated to idenrify all coses, including
ind1 recr cos rs.
Popular team-based approaches include JAD, RAD, and agile methods. J AD is
a popular, ream-based approach co fact-finding and requ1remenrs engineering. JAD
involves an interactive group of users, managers, and IT professionals who participare
in requiremenrs engineering and develop a greater commirmenc co the project and to
their common goals.
RAD is a team-based technique that speeds up informar ion sysrems dcvelopmenc
and produces a functioning information sysrem. RAD is a complete methodology,
with a four-phase life cycle tha t parallels the cradirional SDLC phases.
Agile mechods a ttempc co develop a system incremenrnlly by building a series
of prototypes and constantly adjusting them to user requirements. Tools are o ften
:ivo ided and repbced with simpler ailds, such as whiteboards and sticky notes to faci litate communication.
The requirements gathering process includes interviewing, document review, observation, questionnaires, sampling, and research. Successful interviewing requires good
planning a nd stro ng interpersonal and communication skills. The sysrems ana lyst
musr decide on rhc people to intervie w; ser interview objectives; and prepare for, conduct, and :inalyzc incerviews. The analyst a lso might find ic helpful ro use one or more
software rools during facr-finding.
Systems analysts use va rious tools and techniques ro represent system requirements. N:irural language, srrucrured or unstrucrured, is still the default. Requirements
can be stored as simple text in a plain file or in an Excel spreadshcer.11ley can :ilso be
srored online for automated search and analysis.
Diagrams are another way of represenring requirements. They are suic:ible for analysrs who arc more visually oriented. They can a lso capture complementary aspects of
t he system reqmrements. Sample diagram rypes include FDDs, busine s process diagram!>, and DfDs.
Nlodels provide a more formal represenration of system requirements. The UML
is a widely used method of visualizing a nd documenting i.ofrware de!>ign through the
eyes of the bu~iness user. UML cools include use case diagrams and sequence diagmms ro represent actors, their roles, and the sequence of trans:iccion!. that occurs.
Systems :inalysts should carefully record and d ocumenr factua l information as it
is collected, and various software tools can help a n analyst visualize and describe an
informorion system .
Requirements V&V is concerned wirh demonstraring that the requirements define
the system that the customer really wants. Validarion :isks if the correct requircmenrs
:ire srated, while verification asks if the requiren1cnts arc stated correctl y.
All requirements engineering activities can be helped through rhc judicious use
of tools. They provide automated support for req uirements atrriburcs such as rraceabiliry. For very large systems with thousands of requirements to manage, CASE tool
aS!.isrn nee is necessary.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
I
Phase 2
Systems Analysis
139
Key Terms
Key Terms
aaor An external enm> wirh a ~pt.'Cific role. ln a use case model, a<.<ors are u>ed !O model mierac.:tion
w11h 1hc >)\lem.
agile method• ~)>leim deH~lopmem methods !ha1 anempt to de,elop a system incrememally h) buildmg a series of protOt) pes and constantly adiusang them rouser reqwremeots. Also calltd adapuvt
method>.
brain~tomung A fact-finding technique for gaining information rhrough the use of a small group d1scu~­
sion of a specific problem, opporrunir), or issue.
bu\ine<>\ pr<~.,., model (BPMJ A b'l"aphical representation of one or more husine>> prnce~e>.
bu.,inc\\ prcx:c\\ modeling notation ( BP~) A standard set: of >hape> and 'ymbol> used to rtpre~cnc
evcnL,, proc.e"~• and workOow> in compucer-ha,\ed modding cool>.
clo;cd-endcd qucsuoos Queries thm Imm or restrict che range of responses. Used 10 the 1men 1ew process when sp«1fic mform.irion or facr verificanon ts desired.
cons1rue1ion phase A ph.1se rhnt focuses on progr,un and applkanon development tasks s1mil.1r to rhe
SDLC.
cuun·cr pha'c A pha\C chat resemble' rhc final ca~ks in che 501 C implementation pha,c, including dam
converoion, te,ring, chnnflcovcr m rhe new •ysrem, and tL~er rraining.
data Oow diagram (DFD) Diaflram rh:u ,how~ how che syscem scores, proces,e•,, and tran,form' data
into u,cful information.
document re•icw A review of b.iselme docurnemauon. A useful fact-finding techuique tllJt helps ,rn .111.1lyst underst.ind how the current system rs supposed co work.
eng.igcd lmcmng lne ab1lary ro reall} concenrrare on whar someone as saying and .tvo1d the temptauon
to he.ir "h.1t is e'l.pteted. Alw includes noricmg nonverbal communicanon.
epic In an awlc rro1ccr, a •imple, h1gh-lcvel •caccmcnt of a requirement. Sec feature.
fact-finding The procc•s of pthcring rcquircmenr•. Sec requirement\ elicitation.
feature lo an agile pro1cc1, a sample, high-level staremem of a requirement. See epic.
fill ·in form A template used 10 collect data on the lmemet or a compan) intranet
functional dccornpo\ltion diagram (FOO) A top-down representation of husine'' function\ and pro·
ce..>;e<.. '"'"called a 'truccure chart.
functional requirement A 'taiement of rhe -;en ice, a ..ysrem providei..
H;m 1home Ufcc1 A phenomenon where emptor~ who know chey arc bemg obsef\ ed .ire more
producttvc.
histogram A ~ommon tool for showing rhe d1str1burion of quesrionna1re or sampling results. It take• 1he
form of a vcmcal bar charr.
informal \lructurc An organi73rion based on interpersonal relationships, w hich can develop from prcvi
ou~ work n~~ignmcnr~, physica l rruximiry, unofficial procedures, or per~ona l rclation~hip>.
intcr"icw J\ planned meeting during which i11formario11 is obrnined from onorhcr pcr,011.
join1 applica1io11 dcvclopmcni UAD) A systems development tecb.aique !h.ir uses a rask force of users,
manager>. and IT profc>>tonal~ who work rogether to gather information, dii;cu~> bu;in~> n~cd>, and
define the new S)'Stcm requirements.
lcadtng qucsuons Queries th.11 suggcsr or fovor a particular reply.
non-fun<11onal requirement\ A sratemt'nt of operational sysrcm con~tramt~.
ob~cnauon A facr-fmd1n~ technique where an analrsr sees a system in dctton. Obsen·auon allow' th<'
veraficanon of statements made in interviews.
oix:n·cnded quc\lion~ Quenc> that allow for a range of answers. The)' encourage spontaneous and
umtru~1ured respon!>e> and are u..eful in under..canding a larger proces>.
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
...............
_ .... ~---11rt~
-,..~---~~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Chapter 4
Requirements Engineering
Key Terms
140
pcl"Jonal information manager (PIM ) A cool chac helps manage rnsks and schedules. Many handheld
devices also indude tlus luncuon.
pool Tiie merall d1a11ram 1n BPMN.
produ,,,, II) .,.,r''""" Applic:mons wc:h as word proce\~inµ, .,pread_~heec, dat.iba..., manaitemtnt, and
preo,cnranon 11raphic., program'>.
quahf) annbur~ Su non-functional requiremems.
quescionna1rc A document conrainmg a number of srandard questions that can be scnr co many individuals. Also called a survey.
random ,ample A ~elecrion rnken in a random, unplanned manner. For example, a random \ample mighc
be n >ample char 'ele•"ts nny 20 cusromers.
rn1111.:-ur-re,pon'c quc\UOn> Closed-ended quescions that a>k the p<!r,un to evaluate >omctliing hy pm' id11111 limited an\wtr> to specific re,ponses or 011 a numeric >ca lc.
rapid .1pphca11on de,·clopment (RAD) A ream-based technique that speeds up mformA non sysrems developmcn1 .ind produces a funcrioniug information system. RAD is simil.1r in concept co JAL) buc goes
furrher by including all phases of che SDLC.
requirement~ definition~ A description of che sysrem requirements from the user's poinc of view.
rcquircmcnl\ elicitation The process of gathering requirement~. Sec f.tcJ-findinjl.
requirement\ engineering Used in rhe ~)'l>-Yem< planning pha-;e of rhe SDLC It involve; fact findini: m
de.,.ribl: the ~urrenr sy,rcm and identify rhe requirement> tor the new \)'.tcm.
rcquircmeng plnnning pb:ise A phase ch:u combines elements of the systems plJnrung Jnd systems Jn:1l)S1s phas~ or rhe SDLC.
rcqULremcnts •pcc1fica11ons A descnpnon of che system reqwremenrs from the Jnalyst or engineering
ceam's point of \1cw.
rc,c;irch ,\n imporranr fact-finding technique thar includes rhe review of journal~, periodicals, and
hook• m ohr:un h:ickgmund information, rechnical marenal, and new• about mdu-rf)' trends and
de• elopmenr~.
'an1plrnq A pr<><.-e" where an an:ilr<t colleas e'<ample, or a•-rual document,, wh1~h ~oul<l mdude
rc~urd,, report;, or variou~ fum1~.
scalab1l11~ A characrerisnc of a system, 101plying chat the S)'Slem can be expanded, modified, or down-
sized cas1l) to mecr the rapidly changing needs of a business enrerpnse.
<ccnario< In an agile project, a real-world example of how users w1ll 10tcr.1ct wnh the system.
~rum ;\ popubr rechniquc for agile projecr managemcnr. Derived from a rugby rerm. In Scrum, rc~m
memhe~ play specific roles nnd interact in intense •es•ions.
\Cqucncc dia11rnm /\ UML diagram th3t 'hnws the riming of transaction~ between ohjccn, a' rhey occur
durin!I ~y~tcm execution.
~itc vis11 A mp 10 a physical location to observe a system Ln use at :1nocber location.
~1ra11ficJ ~ample A set memc 1s collected across fwJCtional ure:i>. l-ur example ••1 ct'rr.1111 pcrccnrjge of
trnn~acrion< from every work shift, or five cusromers from cuch of four zip code~. could be a 'tr<uified
'ample.
'toryboard In an agile project, a simple graphic organi1er rhar helps system< ;in.ily~ts vi~ua l iu rhe •mtu'
of a project.
\tru~turcd br.iin\lorming A group discussion where each parricipant speab "hen it i> his or her tum or
pas~'·
~unc)
A dcxument conra1n10g a number of standard questioll!i rhat t:J.11 b.: .ent to mJny 111J1v1<lual>.
Also called a que~11onMirc.
~ JD» (".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_ ._.... ~~
...
. ..............
_ .... ~---11rt~
-,..~---~ ~
.... . _
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
I'
I
I
Phase 2
Systems Analysis
I41
Key Terms
swim lane> In .i bu•ine'; pr<><.e<>\ diagram, che overall diagram is called a pool and the des1gna1ed C:U>
tomer area> are c:alled >w1m !:inn.
S)s.\11 A dialect of U/\iL 2, used for representing requiremerus (and other thing;). pmn.inl) m .\IBSL
applications.
system rcqu1Ccment A charac1ens1ic or fe;irure that musr be included in an mformauon S) stem to sans!)
bu~ine~\ requirements and he accc-prable ro users.
'Y\lcma11c \ample A \ample char occur~ ac a predeccrmincd pcriodiciry. For example, every tenth cu<comcr record mighr he sclccred a~ a sy~emaric sample for review.
wtal co-r of o"ncnh1p (TCO) A numhcr used in assessing cosrs, which include' ongoini; 'upporc and
mamcenance co\t' ,1, well 3> acquisinon cosr•.
uaceabi!Jty ·1be Jbtht)' co follow a reqtmemellt backward to JtS ongms and forw.1rd through the SDLC
to link design documcnrs, code fragments, .rnd 1esr artifacrs.
Unified Modeling l anguagc (UM I ) A widely used method of visualizing and documenunp. softw,1rc systems design. UML uses objccc-oricntcd design concepts. bur iris iudcpcndcnr of any specific programming language and c.in be used 10 describe business processes and requiremcms generally.
un\lructurcd brain,turmini: A i:mup di~ussion where any parricipanr can speak at any time.
u_\e ca\c diagram A vi,ual repre~enrntion chac represenrs the inreracrion between u'er~ and the informa-
ti<>n 'Ystem in lJM L.
user d~ign ph.ise In tht> phase, users inter.1c1 with systems 3Jl:tlyscs and develop models and protott~
thdt represent all S)srtm processes, ourpurs, and inputs.
user stories In Jn agile pro1ecr, a ser of more refined requtremenrs derived from features.
~ JD» (".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_ ._.... ~~
...
. ..............
_ .... ~---11rt~
-,..~---~ ~
.... . _
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Chapter 4
Requirements Engineering
Exercises
142
Exercises
Questions
I. \'(lhar is a srstem requiremenr and what are the three challenges it presents co the
S) stems analyst?
2. Is the requirement "The system shall respond within 2 seconds" a functional or
non-functional requirement?
3. What is scrum?
4. \'(lhar five questions typically are used in fact-finding?
5. Provide rhree examples each of closed-ended, open-ended, and range-of-response
questions.
6. Explain how the observation fact-finding technique works, including the
I la wthorne Effect.
7. Wh:it is rhe rel:irionship berween user stories and fcarures in :igi le projecrs?
8. What is an FDD and why would you use o ne?
9. What is the d ifference between validation and verificat ion of sysrem
requirement~?
10. Why is rraceabiliry important in tool support for requirements engineering?
Discussion Topics
I. JAD requires strong interpersonal and communicacion skills on the part of the
sysrems analyst. Are those skills different from che ones that an analy~r needs
when conducting one-to-one inten•iews? Explain your answer.
2. Agile methods use rapid development cycles to iteratively produce running versions of the system. How would these shorrer cycles affect the abiliry of the analyst ro manage sysrem requirements?
3. A group meeting sometimes is suggesred as a useful compromise bcrwccn mrerviews and questionnaires. In a group meeting, a systems analysr meets with a
number of users at one time. Discuss the advantages and disadvantages of group
mccrin~.
4. Research the Internet, magazines, or textbooks co find examples of visual aids,
including a bar chart, pie chan, line chart, table, diagram, and bulleted lisr. How
effective was each example? Find at least one example char you could improve.
Explain your choice.
5. Traceability is an important requirements atcribute. lt'!> one of the things that
should be checked when performing V&V of the syMem requi rements. Describe
how you would manually check traceability for an existing system and list a few
features of a CASE tool rhat you think wou ld help you with the task.
Projects
I. Use the requiremcncs gathering techniques of document review, observ:ition,
brainstorming, sampling, and research co capture the requirements of a typical
elevator control system. Use narura l language and the UML to represent the siruauon where people on different floors push the ''Up" button at the same time.
2. Prepare a presentation summarizing JAD and RAD. Explain how t hey differ
from traditional facr-finding merhods. What arc the m:iin advantages of teambased methods?
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
I'
I
I
Phase 2
Systems Analysis
Exercises
3. Design a questionnaire ro learn what srudenrs think of the registration process at
your school. Apply the guidelines you learned in this chapter.
4. Create an FDD similar to the one in Figure 4-15 but showing your school mstead
of the librar) example.
5. A desirable characteristic of a requirement is that it be borh consisrenr and complete. Examine several requirements engineering CASE tools and document how
(if ar all ) they support automated consistency analysis for validatmg :rnd verifying requirement<;.
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~....... .,...~ • ........._ . ....._.,.,.. o-... ..,._.,,.,.. _ ..,.~ ,........., ................. .._... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
143
Chapter S
Data and Process Modeling
Data and Process
Modeling
Chapter S is the second of four chapters in the systems analysis phase of the SDLC. This chapter discusses
data and process modeling techniques that analysts use
to show how the system transforms data into useful
information. Data and process modeling involves three
main items: data flow diagrams, a data dictionary, and
process descriptions.The deliverable, or end produce,
of data and process modeling Is a logical model that will
support business operations and meet user needs.
The chapter includes three "Case in Point" discussion questions to help contextualize the concepts
described in the text. The "Question of Ethics" raises
the issue of how to respond to subtle but insistent
requests by an IT manager In a systems analyst's new
organization for proprietary information related to
the business processes used by the analyst's previous
employer. which is a competitor of the analyst's current
company.
LEARNING OB ECTIVES
CONTENTS
5. 1 Logical Versus Physical Models
5.2 Data Flow Diagrams
5.3 Data Flow Diagram Symbols
5.4 Drawing Dara Flow Diagrams
5.5 Drawing a Context Diagram
5 .6 Drawing a Diagram 0 01-D
5 .7 Drawing Lower-Level DFDs
Case in Poinr 5.1: Big Ten Univcrsiry
5 .8 Data Dictionary
5 .9 Process Description Tools in Modular Design
Case in Point 5 .2: Rock olid Outfitrers (Parr 1)
Case in Point 5 .3: Rock Solid Outfitters (Part 2)
A Question of Ethics
5 . 10 Summary
Key Terms
Exercises
W/Jen you finish tbis chapter, you sl101tld be able
to:
l. Describe rhe relarionship bcrween logical and
physical models
2. Explain data flow diagrams
3. Draw rhe four basic dara flow diagram symbols
4. Explain the si.~ guidelines used when drawing
data flow d1agr:ims
5. Draw context diagrams
6. Draw diagram 0 data flow diagrams
7. Draw lower-level darn flow diagrams
8. Explain how to level and balance data flow
diagrams
9. Create a darn dictionary
IO. Apply process description tools in modular
design
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ . ....._.,.,.. o-... ..,._.,,.,.. _ ..,.~ ,........., ................. .._... .., .,. ..,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Phase 2
Systems Analysis
145
5.2 Data Flow Diagrams
5.1
LOGICAL VERSUS PHYSICAL MODELS
During rhe requiremenrs engineering process described in Chaprer 4, face-finding
techniques were used ro invesrigare rhe currenr sysrem and idenrify user requirements.
Chaprcrs 5 and 6 explain how char information is used ro develop a logical model of
rhe proposed system and documenr the sysrem requirements. A logical model shows
what rhe sysrem musr do, regardless of how ir will be implemented physically. L1rer,
in rhe S)'Srems design phase, a physical model is built that describes how rhe system
will be consrrucred.
While srrucrured analysis cools are used ro develop a logical model for a new
informarion sysrem, such cools also can be used to develop physical model of an
information system. A physical model shows how rhe system's requirements are
implemented. During rhe systems design phase, a physical model of rhe new information system •~created chat follows from the logical model and involves operational
tasks and techniques.
To undersrnnd rhe relationship between logical and physical models, think back
to rhe beginning of the systems analysis phase. To understand how the current tasks
were carried our in the existing system, the physical operations of the existing system
were studied before the logical model. Many systems analysts create a physical model
of rhe currem S)1srem and then develop a logical model of the currenr system before
tackling a logical model of the new system. Performing that extra step a llows them to
understand rhe current system better.
Many analysts follow a four-model approach, which means that they develop a
physical model of the current system, a logical model of the current system, a logical
model of the new system, and a physical model of the new system. The major benefit
of the four-model approach is rhat it provides a clear picrure of current system
functions before any modifications or improvements are made. Thar is important
because misrakes made early in syscems de\•elopment will affect later SDLC phases
and can result in unhappy users and additional cosrs. Taking additional steps to
avoid these potentially costly mistakes can prO\'e to be weU worth the effort. Another
advantage is thar the requirements of a new information system often are quite
similar to those of rhe current information system. especially where the proposal is
based on new computer technology rather than a large number of new requirements.
Adapting the current system logical model to the new system logical model in these
cases is a straightforward process.
The only disadvantage of the four-model approach is the added rime and
cost needed to develop a logical and physical model of rhe current sysrem. Most
projects have very right schedules that might nor allow rime ro create the current
system models. Additionally, users and managers want ro see progress on rhe new
system-they are much less concerned about documenting the current sy:.tem.
The ~ystems ana lyst must stress the importance of careful documencation and
resist the pressure to hurry the development process at the risk of creating serious
problem:. later.
5.2 DATA f LOW DIAGRAMS
Systems analysts use many graphical techniques ro describe an information system.
One popular method is to draw a set of dara flow diagrams. A data flO\\ diagram
(DFD) uses various symbols to show how the system transforms input data into useful informatton. Other graphical tools include object models, which are explamed in
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter S
Data and Process Modeling
5.3 Data Flo w Diagram Symbols
146
Chaprer 6 (Object Modeli ng), and enriry-relationship diagrams, which arc described
in Chapter 9 (Dara Design).
During the sysrems analysis phase of che SDLC, the systems anal)'St creates a
visual model of the information system using a set of O FDs. In his seminal book The
Visual Display of Quantitative 111(ormatio11, aurhor and renowned academic Edward
Tufte provides guidance on crearing effecrive diagrams to concisely convey complex 111formation. A DFD is an example of this rype of visual e'<planation of system
behavior.
A DFD shows how data moves th rough an inforrnanon system but does not show
program logic o r processing steps. A ser of DFDs provides a logical model that shows
what the system does, nor how ir does it. T hac discinction is important because focusing on implementation issues at this point would restrict the search for the most effective system design.
5.3 DATA FLOW DIAGRAM SYMBOLS
DFDs use fou r basic symbols tha t represent processes, da ta flows, data stores, a nd
entities. Several different versions o f DFD symbols exist, but they a ll serve t he same
pu rpose. DFD examples in this rexr use the Gane and Sarson symbol set. Another
popu lar symbol set is the Yourdon sym bol set. Figure 5- 1 shows examples of both
version'>. In this text, symbols are referenced using all capital letters for the symbol
name.
Gane and Sarson Symbols
Symbol Name
Yourdon Symbols
APPLY
PAYMENT
Process
APPLY
PAYMENT
II
BANK DEPOSIT
Data Flow
BANK DEPOSIT
STUDENTS
Data Store
STUDENTS
CUSTOMER
External Entity
CUSTOMER
FIGURE S- 1 Data flow diagram symbols, symbol names, and examples of the Gane and
Sarson and Yourdon symbol sets.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
Phase 2
Systems A nalysis
147
S.3 Data Flow Diagram Symbols
5.3.1 Process Symbols
A process receive input data and produces ourpur rhar has a different content, form,
or both. For instance, the process for calculating pay uses rwo inpurs (pay rate and
hours worked) to produce one output (total pay). Processes can be very simple or
quire complex. In a typical company, processes might include calculating sale trends,
filing online insurance claims, ordering inventory from a supplier's y tern, or verifying email addresses for web customers. Processes contain the business logic, also
called busine s rules, that transforms the data and produces the required resulrs.
The symbol for a process 1s a rectangle with rounded comers. The name of the
process appears inside the rectangle. The process name identifies a specific function
and consists of a verb (and an adjective, if necessary) followed by a singular noun.
Examples of process names arc APPLY REl\lT PAYMENT, CALCULATE COMMISSION, ASSIGN Fl Al GRADE, VERIFY ORDER, and FILL ORDER.
Processing derails arc nor sho,vn in a DFD. For example, there might be a process
named DEPOSIT PAYMENT. The process symbol does nor reveal the business logic
for the DEPOSIT PAYMENT process. To document the logic, a process description is
created, which is explained later in this cbapteL
In DFDs, a process symbol can be referred to as a black box, because the inputs, outputs, and general functions of the process are knov.m, but the underlying details and logic
of the process arc hidden. By showing processes as black boxes, an analyst can create
DFDs that show how the system functions bur avoid unnecessary detail and clutter. When
the analyst wishes ro show additional levels of detail, he or she can zoom in on a process
symbol and creacc a more in-depth DFD that shows the process's inrernal workingswhich mighr reveal even more processes, dara flows, and data stores. In this manner, the
information )'Stem can be modeled as a series of increasingly detailed picrures.
The network rourer shown in Figure 5-2 is an example of a black box. An
observer can see cables rhar carry data inro and ouc of the router, but rhe rourer's
internal operations are nor revealed-on!)' che results are apparent.
FIGURE 5·2 A router acts like a block box for network data. Cables
carry data In and out, but internal operations are hidden inside the case.
""'
..
I'
5.3.2 Data Flow Symbols
A data flow is a path for data to move from one part of rhe information system to
another. A dara flow in a DFD rcpresenrs one or more data irems. For example, a daca
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter S
Data and Process Modeling
5.3 Data Flow Diagram Symbols
148
flow could consist of a single dara item (such as a student ID number), or it could
include a set of data (such as a class roster with student ID numbers, names, and
registration dates for a specific class). Although che DFD does not show the detailed
contents of a data flow, that information is included in the darn dictionary, which is
de'ICribcd later in this chapter.
The symbol for a data flow is a line with a single or double arrowhead. The data
flow name appears above, below, or alongside the line. A data flow name consists
of a singular noun and an adjective, if needed. Examples of dara flow names are
DEPOSIT, INVOICE PAYMENT, STUDENT GRADE, ORDER, and COMMISSION. Exceptions co the singular name rule are data flow names, such as GRADING
PARAMETERS, where a singular name could mislead the analyst into thinking a single parameter or single icem of daca exists.
Figure 5-3 shows correct examples of data flow and process symbol
connections. Because a process changes rbe data's content or form, ar least one
data flow must enter and one data flow must exit each process symbol, as they
do in the CREATE rNVO ICE process. A process symbol can have more than one
outgoing data flow, as shown 111 t be GRADE STUDENT WORK process, or more
than one incomi ng data flow, as shown in the CALCULATE GROSS PAY process.
A process also can connect to any o t he r symbol, including another process
symbo l, as shown by the connection benveen VERIFY ORDER and ASSEMBLE
ORDER in Figure 5-3. A data flow, therefore, must have a process symbol on at
least one end.
SERVICES PERFORMED
CREATE
INVOCE
INVOICE
GRADED WORK
SUBMITIED WORK
l-
o
w
a:
a:
0
GRADE
STUDENT
WORK
STUDENT GRADE
HOURS WORKED
0
PAY RATE
ORDER
VERIFY
ORDER
CALCULATE
GROSS
PAY
ACCEPTED
ORDER
GROSS PAY
ASSEMBLE
ORDER
INVENTORY
CHANGE
FIGURE S-3 Examples of correct combinations or data flow and process symbols.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
P hase 2
Systems A nalysis
149
S.3 Data Flow Diagram Symbols
Figure 5-4 shows three data Aow and process combinations that must be avoided:
•
Spontaneous generatio n. The APPLY INSURANCE PREMIUM process, for
instance, produces output but has no input data flow. Because it has no input,
the proce s is called a spontaneous generation process.
•
Black hole. CALCULATE GROSS PAY IS called a black hole process, which is a
proce&s that has input bur produces no output.
Gray hole. A gray hole is a process that has ar least one input and one ourpur,
but the input obviously is insufficient to generate rhe output shown. For example, a date of birth input is nor sufficient ro produce a final grade output in the
CALCULATE GRADE process.
•
Spontaneous generation, black holes, a nd gray holes are impossible logically in a
DFD because a process must act on input, shown by an incoming data flow, and produce output, represented by an outgoing data flow.
S.3.3 Data Store Symbols
A data ~tore is used in a DFD to represent
APPLY
dara that the system stores because one or
POLICY NUMBER
INSURANCE PAYMENT AMOUNT
more processes need to use the dara ar a
PREMIUM
later time. For instance, instructors need to
store student scores on rests and assignments
during the semester, so they can assign final
grades at the end of the term. Similarly, a
(.)
company stores employee salary and deducUJ
a:
HOURS WORKED
PAY RATE
tion data during the year in order ro print
CALCULATE
a:
GROSS PAY
\Y/-2 forms with total earnings and deduc0
0
tions ar the end of rhe year. A DFD does nor
z
show the derailed contents of a data store-the specific structure and data elements are
defined in rhe dara dictionary, which is discus&ed later in this chapter.
DATE OF BIRTH
FINAL GRADE
CALCULATE
The phy ical characteristics of a daca &tore
GRADE
are unimportant because the logical model
is the only concern at this point. Also, the
length of time that the data i~ ~tored i& unimportant-it can be a matter of seconds while
IFIGURE 5-'4 Examples of Incorrect combinations of data flow and
process symbols. APPLY INSURANCE PREMIUM has no input and is
a transaction is processed or a period of
called a spontaneous generation process. CALCULATE GROSS PAY has
months while data is accumulated for yearno outputs and is called a black hole process. CALCULATE GRADE has
end processing. What is important is that a
:an input that is obviously unable to produce the output. This process is
process needs access to the data at some later
called a gray hole.
time.
In a DFD, rhc Gane and Sarson symbol for a data store is a flat rectangle that is
open on the r ig ht side and closed on the left side. The name of the data store appears
between the lines and idenrifies the data it contains. A data store name is a plural
name consisting of a noun and adjectives, if needed. Examples of data store names
arc STUDENTS, ACCOUNTS RECEIVABLE, PRODUCTS, DAILY PAYMENTS,
PURCI IASE ORDERS, OUTSTANDING CHECKS, INSURANCE POLICIES, and
EMPLOYEES. Exceptions to the plural name rule are coUective nouns that represent
multiple occurrences of objects. For example, GRADEBOOK represents a group of
students and their scores.
....
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter S
Data and Process Modeling
5.3 Data Flo w Diagram Symbols
I SO
A data store must be connected to a process with a data flow. Figure 5-5 illust rates
typical examples of data stores. Since data scores represent data storage for use by
another process in the furure, in each case, che data store has ac least one incoming
and one outgoing data flow and is connected to a process symbol wich a data flow.
CREATE
INVOICE
POST
PAYMENT
CUSTOMER
PAYMENT
1-
u
w
INVOICE
DAILY
PAYMENTS
a:
a:
ADMIT
PATIENT
ADMISSION
FORM
ACCOUNTS
RECEIVABLE
PATIENTS
·1
0
u
DAI LY
PAYMENT
PAYMENT
DETAIL
INVOICE
DETAIL
PREPARE
DEPOSIT
SYMPTOM
DIAGNOSE
PATIENT
POST
PAYMENT
TREATMENT
TREAT
PATIENT
FIGU RE 5-S Examples of correct use of dat:a ttore symbols in a dat:a flow diairam.
Violations of the rule that a data store must have at least one mcoming and one
outgoing data flow are shown in Figure 5-6. In che first example, rwo dara stores are
connected mcorrectly because no process 1s between them. Also, COURSES has no
incoming data flow and STUDENTS has no outgoing data flow. In the second and
rhird examples, rhe da ta stores lack either an outgoing or incoming data flow.
1-
u
COURSES
w
a:
a:
0
POST
PAYMENT
I
CLASS
LIST
u
z
BOOK
FLIGHT
CUSTOMER
PAYMENT
STUDENTS
I
DAILY
PAYMENTS
FLIGHT
REOU EST
PASSENGERS
I
I
FIGU RE S-6 Examples of incorrect use of data store symbols in a data flow diagram.Two data
stores cannot be connected by a data flow without an intervening process. and each data store
should have an ouigoing and incoming data flow.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
Phase 2
Systems A nalysis
151
S.3 Data Flow Diagram Symbols
There is an exception to the requirement that a data store must have at least one
incoming and one outgoing data Aow. In some siruarions, a data store has no input
data Aow because it contains fixed reference data that is nor updated b)• the system.
For example, consider a data store called TAX TABLE, which contains withholding
ta-.: data that a company downloads from the Internal Re\•enue Service. When the company runs its payroll, the CALCULATE \XflTH HOLDI G process accesses data from
this data store. On a DFD, this would be represented as a one-way outgomg data Aow
from rhe TAX TABLE data score into the CALCULAT E WITHHOLD Ii G process.
5.3.4 Entity Symbols
T he symbol for an entity
is a rectangle, which may
be shaded to make ir look
three-dimensional. T he name
of the entity appears inside the
symbol.
A DFD shows only cxrernal
entities th:H provide data to rhe
sysrcm or receive output from
the system. A DrD shows the
boundaries of the system and
how the system interfaces with
the outside world. For example,
a cusromer enriry submits an
order to an order processing
system. Other examples of
entiti~ include a patient who
supplie~ data to a medical
record~ sy~tem, a homeowner
who receives a bill from a ciry
property tax S)•Mem, or an
accouncs payable system that
receives data from the compan)•'s
purchasing system.
DFD entities also are called
terminator) because they are
data origins or final dcsrin:irions.
Systems analysts call an enriry
that supplies data to rhe system
a source and an enriry that
receives data from the system
a sink. An enriry na me is the
singular form of a dcparm1ent,
an outside organiz;:irion, other
information system, or a person.
An external entity can be a
source or a sink or both, bur
each entiry must be connected
ro a process by :i d:ita Aow.
Figure 5-7 and Figure 5-8 show
correct and incorrect e-.::imples
of this rule, re pecrively.
.........""_.. ... .-.................
BANK
CUSTOMER
PAYMENT
INVOICE
ORDER
l-
o
w
a:
a:
VERIFY
ORDER
PREPARE
DEPOSIT
APPLY
PAYMENT
0
0
TIME
CARO
VERIFY
TIME
CARD
EMPLOYEE
PAYCHECK
CREATE
PAYCHEC1<
FIGURE 5-7 Examples of correct uses of e>nemal entitles on a cnu flow diagr.tm.
PAYROLL
DEPARTMENT
CUSTOMER
BANK
I-
0
w
PAYCHEC K
a:
a:
BANK
DEPOSIT
PAYMENT
0
0
z
ACCOUNTS
RECEIVABLE
DAILY
PAYMENTS
I
EMPLOYEE
FIGURE 5-8 Examples of incorrect uses of external ent1t1es on a cnu flow doagr.tm. An
external entity must be connected by a cnca flow to a process and not directly to a data store
or co another external entity.
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
BANK
DEPOSIT
CUSTOMER
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter S
Data and Process Modeling
5.4 Drawing Dae.a Flow Diagrams
152
S.3.S Using DFD Symbols
\'<'ith a n undersranding of the proper use of DFD symbols, the next step is co construct diagrams chat use these symbols. Figure 5-9 shows a summary of the rules for
using DFD symbols.
Correct and Incorrect Examples of Data Rows
LJ
LJ
LJ
-
LJ
D
D
D
II
D
II
Process to Process
./
Process to External Entity
./
Process to Data Store
./
'·
External Entity to External Enllty
II
External Entity to Data Store
II
Data Store to Data Store
'-
x
x
x
FIGURE S-9 Examples of correct and incorrect uses of data flows.
5.4 DRAWING DATA fLOW DIAGRAMS
During requiremen ts engineering, interviews, questionnaires, and ocher techniques
were used to gather facts about the system, and it was explained how the various
people, departments, data, and processes fit together to support business operations.
Now a grnphical model of the information system is created based on the fact-finding
results.
To learn how to draw DFDs, examples of two information systems will be used.
The first example is a grading system rhat instructors use co assign final grades based
on the scores that students receive during the term. The second example is an order
system that a company uses to enter orders and apply payments against a customer's
balance.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. - ·~•-fllllie<'f •,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
Phase 2
Systems A nalysis
153
S.4 Drawing Data Flow Diagrams
When drawing a context diagram and other DFDs, these guidelines should be
followed:
•
Draw the context diagram so it firs on one page.
•
Use the name of the infonnarion system as the process name in the context diagram. For example, the process name in Figure 5-10 1s GRAD! G YSTEM.
, ore that rhe process name is the same as t he system name. This is because
the conte>.t diagram shows rhe entire information system as if it were a single
proce!.s. For processes in lower-level DFDs, use a verb followed by a de criptl\e
noun, such as ESTABLISH GRADEBOOK, ASSIG FINAL GRADE, or PRODUCE GRADE REPORT.
•
Use unique names within each ser of symbols. For instance, the diagram in
Figure 5-10 shows on ly one enrity named STUDENT and only one data flow
named FINAL GRADE. Whenever the entity STUDENT appears on any other
DFD in the grading S)'Stem, ir indicares that it is the same entity. Whenever the
FINAL GRADE data Aow appea rs, it indicates that ir is rhc same dara flow.
The naming convention also applies to data stores.
•
Do not cross lines. One way to achieve that goal is to rest rict t he number of
symbols in any DFD. On lower-level diagrams with multiple processes, there
should not be more than nine process symbols. Including more than nine symbols usually is a signa l that rhe diagram is too complex and that the ana lysis
should be reconsidered. Another way to avoid crossing lines is to duplicate an
entity or a data store. When duplicating a symbol on a diagram, make sure
to document rhc duplicarion to avoid possible confusion. A special notation,
such as an asterisk, nexr to rhe symbol name and inside rhe duplicated symbols
signifies that they are duplicared on the diagram.
FINAL
GRADE
SUBMITTED
WORK
STUDENT
RECORDS
SYSTEM
STUDENT
o...
CLASS
ROSTER
process o
represents lhe
entire gred1ng sys1em
GRADING
PARAMETERS
......
GRADED
~ WORK
GRADING
SYSTEM
'
.
'
unique reference
number for
each process
GRADE REPORT
INSTRUCTOR
FIGURE 5- 10 Context diagram DFD for a grading system.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter S
Data and Process Modeling
5.5 Drawing a Context Diagram
I 54
•
Provide a unique name and reference nlLmber for each process. Because it is the
highesr-levcl DFD, the contexr diagram concains process 0, which repre encs
the entire infonnacion sysrem, bur does not show the incernal workings. To
de~cribe the next level of detail ins ide process 0, create a DFD named diagram 0,
which will reveal additional processes thar must be named and numbered. As
lower-level DFDs are created, assign unique names and reference numbers to
all processes, until che logical model is completed.
•
Obtain as much user input and feedback as possible. TI1e main objective is to ensure
that the model is accurate, is easy co understand, and meets the needs of its users.
5.5 DRAWING A CONTEXT DIAGRAM
The first srep in constructing a set of DFDs is co draw a context diagram. A context
diagram is a rop-level view of an information system that shows the sysrem's boundaries
and scope. To draw a context diagram, stare by placing a single process symbol in rhe
center of the page. Tbe symbol repres·ents the entire information system, and ir is identified as process 0 (the numeral zero, and nor tbe letter 0). Then place the S)•Stcm entiries
around the perimeter of the page and use data flows to connect the enriries to the central process. Data stores are not shown in the concext diagram because they arc contained within the system and remain hidden until more detailed diagrams are created.
To determine which entities and data flows to place in the context diagram, begin
by reviewing the system requirements to identify a U external data sources and desti·
nations. During that process, identify the entities, the name and content of rhe data
flows, and the direcrion of the data flows. If that is done carefully, and rhe job of
fact-finding was done well in the previous stage, drawing the context diagram should
be relatively easy. !'\ow review the following context diagram examples.
EXAMPLE: CONTEXT DIAGRAM FORA GRADING SYSTEM: The context diagram
for a grading ~ystem is shown in Figure 5- 10. The GRADING SY TEM process is at
the center of the diagram. The three entities (STUDE 'T RECORDS SYSTE~1, STUDE :T, and INSTRUCTOR) are placed around the central process. lnreracrion among
rhe cencral process and the entities involves six different data flows. The TUDENT
RECORDS SYSTEM entity supplies dara through rhe CLASS ROSTER daca flow
and receives darn chrough che flNAL GRADE daca flow. The STUDENT enciry supplies dara through the SUBMITTED WORK data flow and receives data through the
GRADED \VORK data flow. Finally, che INSTRUCTOR entiry supplies data through
rhe GRADING PARAMETERS data flow and receives daca through the GRADE
REPORT data flow.
EXAMPLE: CONTEXT DIAGRAM FORAN ORDER SYSTEM: The context diagram
for an order system is shown in Figure 5-11. Note chat the ORDER SYSTEM process
is at the center of the diagram and five entities surround the process. Three of the
entities, SALES REP, BANK, and ACCOUNTING , have single incoming data flows
for COMMISSION, BANK DEPOSIT, and CASH RECEIPTS ENTRY, respectively.
The WARE! IOUSE entity has one incoming data flow-PICKING LIST-char is,
a report chat shows the items ordered and their quantity, location, and sequence to
pick from the warehouse. T he WAREHOUSE entity has one outgoing data flow:
COtvl PLETED ORDER. Finally, the CUSTOMER entity has two outgoing data flows,
O RD ER and PAYMENT, and rwo incoming data flows, ORDER REJECT OTICE
and INVOICE.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
Phase 2
Systems A nalysis
155
S.6 Drawing a Diagram 0 DFD
ORDER
CUSTOMER
ORDER
PICKING
UST
WAREHOUSE
REJECT
NOTICE
INVOICE
PAYMENT
COMMISSION
SALES
REP
0
ORDER
SYSTEM
COMPLETED
ORDER
CASH
RECEIPTS
ENTRY
BANK
DEPOSIT
BANK
ACCOUNTING
FIGURE S· 11 C.:.nte>n diagram DFD for an order system.
The context diagram for the order system appears more complex than the grading
sy~cem becau1.e tt has two more entities and three more data flows. What makes one
~y~tcm more complex than another is the number of components, the number of levels,
and the degree of interaction among irs processes, entities, data stores, and data flows.
5.6 DRAWING A DIAGRAM 0 DFD
In the previous step, it was explained how a context diagram provides the most
general view of an information S)'Stem and contains a single process symbol, which is
like a black box. To show rhe derail inside the black box, a DFD diagram 0 is created.
Diagram 0 (the numeral zero, and not che letter 0 ) provides an overview of all the
components tha t interact to form the overall system. lt zooms in on the system and
shows major internal processes, dara flows, and data scores. Diagram 0 also repeats
the entities and data flows rhar appear in the context diagram. When the context diagram is expanded into DFD diagram 0, all the connections that flow into and out of
process 0 must he retained.
Figure 5- I 2 shows a
context diagram ar rhe top and diagram 0 beneath it. Note that diagram 0 is an
expansion of process 0. Also note chat the three same entities (STUDENT RECORDS
SYSTEt.1, STUDENT, and I STRUCTOR) and che same six data flows (FINAL
GRADE, CLASS ROSTER, SUBMITTED WORK, GRADED ~'ORK, GRADING
PARAMETERS, and GRADE REPO RT) appear in both diagram!>. In addition,
diagram 0 expands process 0 to reveal four internal processes, one data store, and
fi,·e additional data flows.
EXAMPLE: DIAGRAM 0 DFD FOR A GRADING SYSTEM:
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter S
Data and Process Modeling
5.6 Drawing a Diagram 0 DFD
156
Conlexl Diagram for Grading System
FINAL
G RADE
STUDENT
RECORDS
SYSTEM
SUBMITTED
WORK
STUDENT
0
GRADED
WORK
CLASS
ROSTER
GRADING
SYSTEM
•
GRADING
PARAMETERS
GRADE
REPORT
INSTRUCTOR
Diagram 0 for Grading Syslem
3
2
STUDENT
RECORDS
SYSTEM
STUDENT
GRADE
ASSIGN
FINAL
GRADE
FINAL
GRADE
CLASS
ROSTER
GRADING
DETAIL
GRADE
STUDENT
WORK
SUBMITTED
WORK
GRAOED
WORK
1
ESTABLISH
GRADEBOOK
CLASS
GRADEBOOK
01
GRADEBOOK
STUDENT
I
CLASS
DETAIL
GRADING
PARAMETERS
4
INSTRUCTOR
GRADE
REPORT
PRODUCE
GRADE
REPORT
F IGURE 5- 12 Context diagram and d~gram 0 for the grading system.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f •,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
Phase 2
Systems A nalysis
157
S.6 Drawing a Diagram 0 DFD
Note that each process in diagram 0 has a reference number: ESTABLISH
GRADEBOOK is I, ASSIGN FlNAL GRADE is 2, GRADE STUDENT \X!ORK is
3, and PRODUCF GRADF REPORT is 4. These reference numbers are important
because the)' identify a cries of DFDs. If more detail were needed for ESTABLISH
GRADEBOOK, for example, a diagram 1 would be drawn, because ESTABLISH
GRADEBOOK is process 1.
The process numbers do nor suggest char the processes are accomplished in a
sequennal order. Each process always is considered ro be available, active, and awaiting data co be processed. If processes musr be performed in a specific sequence, the
information should be documented in the process descriptions (discussed later in this
chapter), nor in the DFD.
The FINAL GRADE data flow output from the ASSIG FINAL GRADE process
is a diverging data Aow that becomes an input to the STUDENT RECORDS SYSTEM entity and co the GRADEBOOK data store. A diverging data Aow is a data Aow
iu which the same data travels to rwo or more diHereot locations. l11 that situation, a
diverging data Aow is the best way ro show the flow rather than showing rwo identical data flows, which could be misleading.
If the same data flows in borb directions, a double-headed arrow can be used to
connect the symbols. To identify specific data flows into and out of a symbol, however, separate data Aow symbols with single arrowheads should be used. For example,
in Figure 5-12, the separate data flows (SUBMIITED WORK and GRADED WORK)
go into and out of rhe GRADE STUDENT WORK process.
Because diagram 0 is an exploded version of process 0, it shows considerably more
derail than the context diagram. Diagram 0 can also be referred ro as a partitioned
or decomposed view of process 0. When a DFD is exploded, t he higher-level diagram
is called the parent diagram and the lower-level diagram is referred to as the child
diagram. The grading system is simple enough that no additional DFDs arc needed
to model che syscem. At chat point, che four processes, the one data score, and the I 0
data Aow can be documented in the data dictionary.
\Xlhen a sec of Of'Ds is created for a system, the processing logic is broken down mto
smaller units, called functional primitives, which programmers will use co de\'elop code.
A functional prinuci"e is a process that consists of a single function rhat 1s not exploded
further. for e'<ample, each of the four processes shown in the lower portion of Figure
5-12 is :i functional prnninve. The logic for a functional primitive is documented by
wriong a proce!.s description in the data dictionary. Later, when the logical design is
implemented as a physical system, programmers wiJJ transform e:ich function:il primitive into program code and modules that carry our the required steps. Deciding whether
to explode a process further or determine that it is a functional primitive is a marcer of
experience, judgment, and inceraction with programmers who musL translaLe the logical
design imo code.
EXAMPLE: DIAGRAM 0 DFD FORAN ORDER SYSTEM: Figure 5-13 is the diagram
0 for an order system. Process 0 o n the order system's context diagram is exploded to
reveal three processes (FILL ORDER, CREATE INVOICE, and APPLY PAYMENT},
one data store (ACCOUNTS RECEIVABLE), two additional data flows (INVOICE
DETAIL and PAYMENT DETAIL), a nd one diverging data Aow (lNVOICE).
The following walk-through explains the DFD shown in Figure 5- 13:
L A CUSTOMER submits an ORDER. Depending on the processing logic, che
FILL ORDER process either sends an ORDER REJECT NOTlCE back to rhc
customer or sends a PICKING LIST to the WAREHOUSE.
.........""_.. ....-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,. .., ~..,._.. .............. ~..
~~·~ --- - ·· · ---~~-.,.- " ~
Chapter S
Data and Process Modeling
5.7 Drawing Lower-Level DFDs
158
2. A COMPLFTED ORDER from rhe \'V'AREHOUSE is inpur ro rhc CREATE
INVOICE process, which ourpurs an INVOICE ro borh rhe CUSTOMER
process and rhe ACCOUNTS RECEIVABLE dara store.
3. A CUST01'1ER makes a PAY1vl8'.T that is processed by APPLY PAYMENT.
APPLY PAYMENT requires INVOICE DETAIL input from rhe ACCOUNTS
RECEIVABLE dara store along with the PAY1'1ENT. APPLY PAYMENT also
ourpurs PAY1'1ENT DETAIL back to the ACCOill'.iS RECEIVABLE dara
store and ourpurs COMMlSSION ro the SALES DEPT, BANK DEPOSIT ro the
BANK, and CASH RECEIPTS ENTRY ro ACCOUNTING.
1
ORDER
PICKING
UST
FILL
ORDER
ORDER
REJECT
NOTICE
CUSTOMER
WAREHOUSE
2
CREATE
INVOICE
INVOICE
DI
ACCOUNTS
RECEIVABLE
INVOICE
DETAIL
PAYMENT
COMPLETED
ORDER
PAYMENT
DETAIL
3
APPLY
PAYMENT
COMM ,SSION
BANK
DEPOSIT
SALES
DEPT
BANK
CASH
RECEIPTS
ENTRY
ACCOUNTING
FI GUR E S- 13 Diagram 0 DfD for the order system.
The walk-through of diagram 0 iUustrates the basic requirements of the order
system. Examine the detailed description of each separate process to learn more.
S. 7 DRAWING LowER-LEVEL DFDs
This set of lower-level DFDs is based on the order system. To creace lower-level diagrams,
leveling and balancing techniques must be used. Leveling is rhe process of drawing a
series of increasingly detailed diagrams, until all functional primicives are identified.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
Phase 2
Systems A nalysis
159
S.7 Drawing Lower-Leve l DFDs
Balancing mainrains consistency among a set of DFDs by ensuring that input and output
dam flows align properly. Leveling and balancing are described in more derail in the following sections.
Leveling uses a series of increasingly derailed
DFDs to de&cnbe an information S)'stem. For example, a system might consist of
doi.ens, or even hundreds, of separate processes. Using leveling, an analyst scares
with an overall view, which is a context diagram with a single process symbol.
Next, the analyst creates diagram 0, which sho,vs more detail. The analyst contmues to create lower-level DFDs until all processes are identified as functional
primitives, which represent single processing functions. More complex systems
have more processes, and analysts must wor k through many levels to identify the functional primitives. Leveling also is called exploding , partitioning, or
decomposing.
Figures 5-13 and 5-1 4 provide an example of leveling. Figure 5-13 shows diagram
0 for an order system, with the FILL O RDER process labeled as process 1. Now
consider Figure 5 - 14, which p rovides an exploded view of the RLL O RDER process.
Note rhat FILL ORDER (process l ) actually cons ists of t hree processes: VERIFY
O RD ER (process 1. 1), PREPA RE REJECT NOTICE (process L.2), and ASSEMBLE
ORDER (process 1.3).
EX AMPLE: LE VELING EXAMPLES:
CUSTOMER
ORDER
REJECT
NOTICE
ORDER
1.1
I2
VERIFY
ORDER
PREPARE
REJECT
NOTICE
REJECTED
ORDER
PRODUCT
DETAIL
CREDIT
STATUS
ACCEPTED
ORDER
CREDIT
HISTORY
I
D2 CUSTOMERS
I
1.3
D3 PRODUCTS
PICKING
DETAIL
ASSEMBLE
ORDER
PICKING
LIST
WAREHOUSE
INVENTORY
CHANGE
FIGURE S- 14 Diigram I OFD shows details of the FILL ORDER process in the order system.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter S
Data and Process Modeling
5.7 Drawing Lower-Level DFDs
160
As Figure 5-14 shows, all processes are numbered using a decimal notation
consisting of the parent's reference number, a decimal point, and a sequence number
within the new diagram. In Figure 5-14, the parent process of diagram I 1 process I, so
the proces cs in diagram 1 have reference numbers of 1.1, 1.2, and I. 3. If process 1.3,
ASSE~I BLE ORDER, is decomposed further, then it would appear in diagram 1.3 and
the processe!> in diagram 1.3 would be numbered as 1.3.1, 1.3.2, I. 3.3, and so on.
This numbering technique makes it easy to integrate and idenrify all DFDs.
\'Qhen Figure 5- 13 and Figure 5-14 are compared, it is apparent that Figure 5-14
(the exploded FILL ORDER process) shows two data stores (CUSTOMER and
PRODUCTS) that do nor appear on Figure 5-13, which is rhe parent DFD. Why not?
Tiie answer is based on a simple rule: When drawing DFDs, a data store is shown
on ly when rwo or more processes use that data store. The CUSTOMER and PRODUCTS data stores were internal to rbe FILL ORDER process, so the analyst did not
show chem on diagram 0, which is the parent. When the FILL ORDER process is
exploded into a diagram 1 DFD, however, three processes ( l. J, 1.2, and 1.3) interacting with the two data stores are now shown.
Now compare Figure 5-14 and Figure 5-15. Note that Figure 5-15 shows the same
data flows as Figure 5-14 but does not sbow tbe CUSTOMER a nd WAREH OUSE
entities. Analysts often use this technique to simplify a DFD and reduce unnecessary
cluner. Because the missing symbols appear on the parent DFD, that diagram can be
used to identify rhc source or destination of rhe data flows.
•
ORDER
REJECT
NOTICE
ORDER
1 1
1.2
VERIFY
ORDER
PREPARE
REJECT
NOTICE
PRODUCT
DETAIL
REJECTED
ORDER
CREDIT
STATUS
ACCEPTED
ORDER
CREDIT
HISTORY
I
D2 CUSTOMERS
I
1.3
D3 PRODUCTS
PICKING
DETAIL
ASSEMBLE
ORDER
PICKING
UST
INVENTORY
CHANGE
FIGURE 5- 15 This diagram does not show the symbols that connect to data flows entering or leaving
FILL ORDER on the context diagram.
Balancing ensures that the input and output data flows
of the parent DFD are maintained on the chjld DFD. For example, Figure 5- 16 shows
two 0 1- D : The order S)•stem diagram 0 is shown at the cop of che figure, and the
exploded diagram 3 DFD is shown ac the bottom.
BALANCING EXAMPLES:
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
P hase 2
Systems A nalysis
161
S.7 Drawing Lower-Level DFDs
The rwo DFDs arc balanced because the child diagram at the bottom has the
same input and output Aows as rhe parent process 3 shown ar the top. To verify rhe
,
Order System Diagram O DFD
P<CKING
UST
ORlJEA
flil
ORDER
ORDER
REJECT
I
NOTICE
CUSTOMER
WAREHOUSE
2
COMPLETED
CREATE
INVOCE
INVOICE
II
D1 ACCOUNTS
- - -""
ll"YMENT
RECEIVABLE
DETAIL
INVOICEf
.
DETAIL .
--
PAYMENT
•
3
I
I
I
APF'\.Y
PAYMENT
' - -i!!AN!!' '
COMMISSION
CASH
RECEIPTS
ENTRY
DEPOSIT
SAlES
DEPT
!IANJ(
,-- t -
I
I
I
I
I
I
I
I
I
I
I
-
ACCOUl"1"NO
1NllOICE
Order System Diagram 3 DFD
CVSTOMER
I
ORDER
PAYMENT I
- - - - - - - ,,
I "'I
31
'
I
POST
I
PAYUENT
I
I
1
DEll'&.
\
ID' ACCOU'<TS
RECEIVAlll.E
I
I
I
PAYMENT
OET.tJL
- - - - - .. - - - ...
CUSTOt.IER
PAYMENT
OOMMISS ION
EARNED
tw1.Y
AAl'MENTS
DAILY
ACCOUNT1NG
PAYMENT
PAYMENT
32
H
33
I
I
PREPAA£
DEPOSIT
ACCOUNTING
PAYMENT
ENTRY
.. - 1BANK - ---- DEPOSIT
~
<.'Xst-1'"
PAY
COMMISSION
-- - - -
RECEIPTS ENTRY
ACCOIJNf,NG
BAM<
I
I
I
I
I
I
-
i ~:ss~ON
SALES
REP
FIGURE S- 16 The order system diagram 0 is shown at the top of the figure. and the exploded diagram 3 DFD
(for the APPLY PAYMENT process) is shown at the boaom.The two DFDs are balanced because the child diagram
at the bottom has the same Input and output flows as the p;arent process 3 shown at top.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter S
Data and Process Modeling
5.7 Drawing Low er-Level DFDs
162
balancing, note that the parent process 3, APPLY PAYMENT, has one incoming dara
flow from an external enriry and three outgoing data flows to external entities. Fxamine the child DFD, which is diagram 3. Ignore the internal data flows and count the
data flows co and from external entities. From the diagram, it is evident chat the three
processes maintain the same one incoming and three outgoing data flows as the parent process.
Another example of balancing is shown in Figures 5-17 and 5-18. l11e DFDs in
the e figures we re created using the Visible Analyst CASE tool.
Figure 5-17 shows a sample concext diagram. The process 0 symbol has cwo input
flows and two output flows. Note char process 0 can be considered as a black box
... . uo.c ..,. .... ,," ' T
•
EXTERNAL
ENTITY A
I•
INPUT DATA
FLOW1
I
1-.
-----.
OUTPUT DATA
FLOW 1
EXTERNAL
ENTITY C
1
I
I
I PROCESSO I OUTPUT DATA
INPUT DATA
FLOW2
.I
I
•
FLOW2
•
EXTERNAL
EXTERNAL
ENTITY B
ENTITY D
FIGURE 5- 17 Examples of a parent DFD diagram. showing process 0 as a black box.
t; .iJ ¥ lol
A I A -. :& J• I •
\ !:J-Q 'l.-"l"\ '- "T .l
•- wJ "~I -' •
•
I
------- ---------,
3
1
I INPUT DATA
EXTERNAL
ENTITY A
•
-
FLOW I
UT OATA I
I
FLOW I
PROCESS 1
PROCESS3
'
I
I
I
I
.
I
I
EXTERNAL
ENTITY 8
I
I
I
I
I
EXTERNAL
ENTITYC
INTERNAL
DATA
FLOW1
INTERNAL
DATA
FLOW2
los
1041 DATA STORE 1
INTERNAL
DATA
FLOW3
INPUT DATA
FLOW 2
I
I
I
I
DATA STORE 2
I
I
INTERNAL
DATA
FLOW4
I
2
OUTPUT DATA
FLOW 2
I
I
I
•
PROCESS2
I
' ----------~-----
EXTERNAL
ENTITY 0
I
I
FIGURE 5- 18 In the next level of detail. the process 0 black box reveals three processes, tw0 <ba scores, and
four internal data ffows---gll of which are shown inside the dashed line.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gl( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
I
Phase 2
Systems Analysis
163
S.7 D raw ing Lo wer-Leve l DFDs
with no inrernal derail shown. In Figure 5-18, process 0 (che parent DFO) is exploded
inro rhe nexr level of detail. Now rhree processes, rwo dara scores, and four inrernal
dara Aows are visible. Note that the derails of process 0 are shown inside a dashed
line, 1ust as if the inside of the process was visible.
The DFDs in Figures 5- 17 and 5-18 are balanced because rhe four data flows into
and out of process 0 are maintained on the child DFD. The DFDs also are leveled
because each internal process 1s numbered co show that it is a child of the parent
process.
CASE IN POINT 5.1:
B1G TEN U N1VERs1n'
You are the IT director at Big Ten University.As part of a training program, you decide to draw
a DFD that includes some obvious mistakes to see whether your newly hired junior analysts
can find them.You came up with the diagram 0 DFD shown in Figure 5-19. Based on the rules
explained in this chapter, how many problems should the analysts find?
3
2
1
ASSIGN
AO\llSOR
STUDENT ID
N UMBER
TENTATIVE
SCHEDULE
MEET
WITH
AOlllSOR
CHECK
OPEN
CLASSES
FINAL
CLASS
SCHEDULE
INSTRUCTOR
CLASS
ROSTER
05 CLASS ROSTER
STUDENTS
ATTENDING
D6 SEATING C HART
SCH EDULE
OF OFFICE
HOURS
4
STUDENT
STUDENT ID
NUMBER
CALCULATE
GRADE
FINAL
GRADE
04 GRADES
FIGURE 5- 19 What are the mistakes in this diagram 0 DFD!
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
Chapter S
Data and Process Modeling
5.8 Data Dictionary
164
5.8 DATA DICTIONARY
A set of DFDs produces a logical model of the system, but the details within those
DFDs are documented separarely in a data dictionary, which is the second component
of stn1crurcd analysis.
A data dictionary, or data repository, is a ccnrral storehouse of information about
the system's data. An analyst uses rhe data dictionary to collect, document, and
organi1c specific facts about the system, including the contents of data flows, data
stores, entities, and processes. The data d ictionary also defines and describes all data
elements and meaningful combinarions of dara elements. A data clcmcnr, also called
a data item or field, is che smallest piece of dara that has meaning within an information system. Examples of data elements are student grade, salary, Social ccurity number, account balance, and company name. Dara e lements are combined into records,
also called daLa structures. A record is a meaningful combination of related data elements t hat is included in a data flow or ret:iined in a data score. For example, an auto
parts store inventory record might irnclude part number, description, su pplier code,
minimum and maximum stock levels, cost, a nd list price.
Significant relationships exist among the items in a data diction~iry. For example,
darn stores a nd data flows are based on data structures, which in rurn are composed
of data c lements. Data flows are connected to data s tores, entiLies, and processes.
Accurately documenting these relationships is essential so the data dictionary is consistent with the DFDs. The more complex the system, the more d ifficult it is co maintain fu ll and accurate documentation. Fortunately, modern CASE tools simplify the
task by flowing documentation automatically from the modeling diagrams into the
central repository, along with information entered by the user.
A CASE reposi tory ensures data consistency, which is especially imporranc where
multiple srsrems require the same data. In a large company, for example, the sales,
accounting, and shipping systems all might use a data element called CUSTOMER
NU.tvl BER. Once the CUSTOMER NUMBER element has been defined in the repository, other processes can access it, data flows, and data stores. The result is that all
sysrems across the enterprise can share data that is up to date and consistent.
5.8. 1 Documenting the Data Elements
Every dara element in the dara dictionary muse be documented. Some analysts like to
record their notes in o nline o r manual forms. Ochers prefer ro enter rhe information
directly inro a CASE rool. Irrespective of the specific CASE tool used, rhc objecrive is
the same: ro provide clear, comprehensive information about the data and processes
rhat make up the system.
Figure 5-20 shows a sample screen that illustrates how a data element representing
o SOCIAL SECURITY NU.tvl BER might be recorded in the Visible Analyst dara dictionary. Regardless of the terminology or method, the follow ing attrib utes usually arc
recorded and described in the data dictionary:
•
•
(....,..... J:gi( . . . . .
Data element name or label. The data element's standard name, which should
be meaningful to users.
Alias. Any name(s) other than the standard darn element name; this Jlternate
name is called an alias. For example, if there is a dat:i element named
CURR ENT BALANCE, various users might refer to it by alternate names such
as OUTSTANDING BALANCE, CUSTOMER BALANCE, RECEIVABLE
BALANCE, or AMOUNT OWED.
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
P hase 2
Systems A nalysis
165
S.8 Data Dictionary
• Type and length. Type refers ro
whether chc data element conrains
numeric, alphabetic, or character values. Length 1s the maximum number
of character~ for an alphabetic or a
character data element or the maximum number of digits and number
of decimal posirions for a numeric
data element. In addition to text and
numeric data, sounds and images
also can be stored in digital form.
In some systems, these binary data
objects are m:inaged and processed
just as traditional data clements are.
for example, an employee record
might include u digitized photo
image of the person.
•
i.w
Enbybpc
~
A!Us:
Default 11al11c. The default value is the
value for the data clemenr if a value
-
I of4
1-s.a..cySSH
\/oJues &
:::===:::___
n
~
O.twlt.-
Notes;
otherwise is not entered for it. For
example, all new cu~tomers might
have a default value of $500 for the
CREDIT LIMIT data element.
ISOCIAi. sicUltl'TY NUMlllJt
TJ!I<
lengsh:
!IN
Acc.--
None
5oufCC
Sttun1y
Appl1c1tton rorm
Pl)"Oll dq>tnmonl
R"'f>O"sib~ \Ml".
PoyniH d~l
Mf-"'9'1--
long Nome:
• Acceptable t•al11es. Spccificarion of
ArtOO!bi't objt<t llbfl an bt uP to 128 ctilrxt11s ID!lo. Jlld tllt Int c:IQ/xtt1 l'l\&St bt
the data element's domain, which is
• mtter.
the set of values permitted for rhe
data element. These values either can FIGURE S-20 A VlsibleA!Qlyst screen describes the data element named
be specifically listed or referenced
SOCIAL SECURITY NUMBER.
in a table or can be selected from a
-~.... - ,,.l
specified range of values. Also indicare if a value for the data element 1s optional.
Some data clements have additional validity rules. For example, an emplo)'cc's
salary musr he within the range defined for rhe employee's job classification.
• Source. The specification for the origination point for the data element's values.
The source could be a specific form, a depam11ent or an outside organization,
another information system, or rhe result of a calculation.
• Security. Identification for the individual or department that has access or
•
•
update privileges for each data clement. For example, only a credit manager
has the aurhority to change a credit limit, while sales reps are au thorized co
access dara in a read-only mode.
Responsible 11ser(s). Identification of the user(s} responsible for entering and
cha nging values for the data c lement.
Description and comments. This part of the documentation permits che entry
of addirional norcs.
S.8.2 Docume nting the Data Flows
In addirion to documenring each dara elcmenr, all data flows in the data dicrionary
must be documented. Alrhough terms can vary, the typical attribures arc as follows:
• Data flow 11ame or label. The data flow name as it appears on che DFDs.
• Description. Describes the data flow and irs purpose.
.........""_.. ....-.................
_..__ ...................
("..,_..., llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter S
Data and Process Modeling
166
5.8 Data Dictionary
•
•
•
•
•
Alternate name(s). Aliases for che DFD dara flow name(s).
Origin. The DFD beginning, or source, for che dara flow; the origin can be a
process, a dara score, or an entiry.
Destmation. The DFD ending poinc(s) for the dara flow; che destinarion can be
a process, a dara store, or an entiry.
Record. Each daca flow represents a group of related dara elements called a
record or data srrucrure. Ln mosc data dictionarie~. records are defined separately from the data flows and data scores. When records are defined, more
than one data flow or data store can use the same record, if necessary.
Volume and frequency. Describes the expected number of occurrences for che
data flow per unic of time. For example, if a company has 300 employees, a
T IME. CARD dara flow would involve 300 transactions and records each week
as employees submit their work hour darn.
5.8.3 Documenting the Data Stores
every DrD data srore in rhe data dicrionary must be documented. Figure 5-2 1 shows
che definition of a data score named l N STOCK. Typical characteristics of a darn store
a re as follows:
•
Data store name or label. The dara store name as it appears on the DFDs.
•
•
Description. Describes the data srore and its purpose.
Alternate name(s). Aliases for che DFD daca store name.
•
•
Attrib11tes. Standard DFD names that enter or leave che data score.
Volume and freq11e11cy. Describes the cscimaced number of records in the dara
store and how frequently they are updated.
I. This data Store has
an altemauve name.
or alias.
2. For consistency. data
flow names are stan·
dardlzed throughout
the data dictionary.
3. It Is important to
document these
enimates because
they will affect
design decisions In
subsequent SDLC
phases.
l
....
J
....
-..........
,........
......
FIGURE 5-21 A Visible Analyst screen that documents a data store
named IN STOCK.
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
P hase 2
Systems A nalysis
167
S.8 Data Dictionary
5.8.4 Documenting the Processes
Every proces<; mu t be documenred, as shown in Figure 5-22. The documentation includes
a description of the process's charaaeristics and, for functional primitive , a process
description, which is a model that documenrs the processing seeps and busme<;s logic.
The following are typical characteriscics of a process:
• Process name or label. The process name as it appears on the DFDs.
• DescrtfJ/1011. A brief <;tacement of the process's purpose.
• Process 1111mber. A reference number that identifies the process and indicates
relationships among various levels in the system.
•
Process description. This section includes the input and output data flows. For
functional primicives, the process description also documents the processing seeps
and bu~iness logic. The next section explains how co write process descriptions.
I . The process num·
ber identifies mis
process.Any subprocesses are numbered I. I, 1.2, 1.3,
and so on.
2. These data flows
will be described
spcclflcally elsewhere in the data
...,..r,,._ _ _ _ ___,
"""' L'""'""""
°'8qlpl!Oft [ ftc.(tf'l tit •¥rt~.....,_ NMd tifl l · - W .......IN<t h•IWiWltf
1 '1--1+- ·• ·
"9cMc
~
rr,,. .,._, .._. ~.. Cltttlll UAl\l!o MfJO! "1 OflM
0...-4.lf.t.._ UCllD<mll:~ M.CllflOOlllllll
diccionary.
-[
--
,___, -..
....
--Qp
t-
...
·-·
A ""8111tor'f~-- oP'I . . te ' - l.a C!Wlet". . . . . . . . W'9 h
~.,.. M
FIGURE S-22 A Visible Analyst screen that descnbes a process named
VERIFY ORDER.
5.8.5 Documenting the Entities
By documenting all entities, the data dictionary can describe all external encities char
interact with rhe system. Typical characteristics of an entity include the following:
•
•
•
•
•
Entity 11a111e. The enricy name as it appears on the DFDs.
Description. Describe the entity and its purpose.
Alternate na111e(s). Any aliases for the entity name.
Input data flows. The standard DFD names for the input data flows co the entity.
Output data (10111s. The standard DFD names for the data flows leaving the entity.
5.8.6 Documenting the Records
A record is a daca srrucrure chac contains a set of related data elements that are stored
and processed together. Data flows and data stores consist of records that must
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~----···---~~-.,.-"~
Chapter S
Data and Process Modeling
5.8 Data Dictionary
168
be documented in the data dictionary. Characteristics of each record mu~t also be
defin ed, as shown in Figure 5-23.
Typical characteristics of a record include the following:
•
Record or data structure name. The record name as it appears in the related
data flow and daca store entries in che data d ictionary.
•
•
De(i11itio11 or description. A brief definition of the record.
Alternate name(s). Any aliases for che record name.
•
Attributes. A list of all the daca elements, or fields, included in rhe record. The
dara elemenc names must march exactly those entered in the dara dicrionary.
o.....- 1.oc...... ......
EIU'.Dlt STAM
laMI
""'Y lYPI'
Oac.vP'IOftl
'"' J
I
.
Alflf\:
.......
,,,,
ill CUSTOMllt MJMll!l
!JI CUSlOMlll STATUS
Ch•
Attrlbults:
lftJ
l
C:witomtr (fedC d.tt•
......
....glh .....
Ch"
I. This data structure
is named CREDIT
STATUS.
2. The CREDIT
STATUS data
structure consists
ofcwo data
elements:
CUSTOMER
NUMBER and
CUSTOMER
STATUS CODE.
y
......
FIGURE S·ll A Visible Analyst screen that documents a record. or data
structure. named CREDIT STATUS.
5.8.7 Data Dictionary Re ports
The data dictionary serves as a central storehouse of documcnration for an informa·
rion sysrem. A data dictionary is created when rhe system is d eveloped and is updated
constantly as rhc system is implemen ted, operated, and maintained. In addition co
describing eac h daca clement, dara flow, dara store, record, emity, and process, the
darn dictionary documenrs the relationships among these components.
Many valuable reporrs can be obtained from a data dictionary, including the following:
•
An alphaberizcd list of all data elements by name
•
A report describing each daca element and indicaring the user or dcparrmenc
chat is responsible for daca entry, updaring, or delerion
A report of all data flows and daca stores char use a particular dara clcmenc
•
•
Detailed reports s howing all characteristics of data elements, records, dara
flows , processes, or any ocher selected item stored in the d ara dictio nary
~- )U,
-Woip-M ._..,..
r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
..
(....,..... J:gi( . . . . .
..,...,.......,..~
- ·~•-fllllie<'f •,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
__.~~c.....,..~
.........,..,. ..
._.,.,.,.......c:-..•~-".....-""'*"....,.._...,..
..
I'
I
P hase 2
Systems A nalysis
169
S.9 Process Description Tools in Modular Design
5. 9 PROCESS DESCRIPTION TOOLS IN MODULAR DESIGN
A process d e~cription documents the derails of a functional primitive and represents
a specific set of processing steps and business logic. When a functional primitive is
analyzed, the processing steps arc broken down into smaller unirs in a process called
modular design. Using a set of process description tools, a model is created chat is
accurate, complete, and concise. Typical process description tools include scrucrured
English, decision rabies, and decision crees.
5.9. 1 Process Descriptions in Object-Oriented Development
This chapter deals with srrucrured analysis, but the process descriptions can also he used
in object-oriented (0 -0) development, which is described in Chapter 6. As explained in
Chapter I, 0 -0 analysis combines data and the processes that acr on the data into things
called objects, and similar objects can be grouped together into dasse~, and 0 -0 processc~
are called methods. Although 0-0 programmers use different rermi11ology, they create the
same ki11d of modul::ir coding structures, except
that the processes, or methods, are stored inside
the objecrs, rather than as separate components.
VERIFY
PRODUCT
CODE
5.9.2 Modula r Design
Modular design is based on combinations
of three logical structures, sometimes called
control structures, which serve as building
blocks for the process. E.ach logical strucrure
must have a single entry and exit point. The
three structures are called sequence, selection,
and iteration. A rectangle represents a step
or process, a diamond shape represents a
condition or decision, and the logic follows the
Imes in the direction indicated by the arrows.
-
VERIFY
PRICE
FIGURE 5-2<4 Sequence structure.
YES
CALCULATE
OVERTIME
PAY
l. Sequence. The complerion of steps in
sequential order, one after another, as
shown in Figure 5-24. One or more of the
steps might represent a subprocess that
contains addirional logical strucrurcs.
2. Selection. The complerion of one of
two or more process steps based on
the resu lts of a res t or condirion. In
the example shown in Figure 5-25, the
sysrem rests the input, and if the hours
are greater than 40, ir performs the
CALCULATE OVERT IME PAY process.
NO
FIGURE S-25 Selection structure.
NO
3. Ite ration. The completion of a process
step thar is repeated until a specific condition changes, as shown in Figure 5-26.
An example of iteration is a process that
conrinues to print paychecks until it
reaches the end of the pa)•roll file. Iteration also is called looping.
.........""_.. ... .-.................
_..__ ...................
PRINT
PAYCHECK
YES
FIGURE 5-26 lte~tion structUre.
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
VERIFY
STOCK
LEVEL
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter S
Data and Process Modeling
5 .9 Process Description Too ls in Modular Design
170
Sequence, selection, and iteration structures can be combined in various ways to
de cri bc proces ing logic.
5.9.3 Structured English
Structured English is a subset of standard English that describes logical processes
clearly and accurately. \Xlhen using st rucrured English, be mindful of the following
gu1delt11es:
• Use only the three building
blocks of equence, selection, and
iteration.
....
&oorltP< --==-----~
~
f
•••'f"C<•~.,.... NW!lf9fll1 -dl1 ~Y1.,..,_,~, ~
I
• Use indentation for readability.
• Use a Ii mired vocabulary, including standard terms used in the dara
dictionary a nd specific words that
de cribe the processing rules.
........
"-'cOn«sll_.
111pt.1f Ml ..._.
~ ...._. fllfwll
01U1U. C'-'0!1 STAlUl, H<OJC1 OOAl
llUCTlD°'°"MXlPTmOltCtl
,_. . M Ch OftOIJt
W CUSltWO!Sl~MCOOl •" """''~004'1. • OtC
[I,.
o....- AC<CPTlOO«DU
+---1---1 Structured English
An example of srrucrured
English appears in Figure 5-27,
which shows the VERIFY ORDER
process that was illustrated earlier.
Note that the strucrured English
version documents the actual logic
char will be coded into the system. Srruccured English can help
process descriptions accurate and
understandable to users and system
developers.
FIGURE 5 . 27 The VERIFY ORDER process description includes logical rules and
Structured English might look
a structured English verst0n of the policy. Note the alignment and indentation of
familiar to programming srudenrs
the logic statements.
because it resembles p'eudocode,
which is used in program design.
Although the techniques are similar,
the primary purpose of structured Eaglisb is ro de~cribe the underlying business logic,
while programmers, who are concerned with coding, mainly use pseudocode as a
~horth::md notation for the actual code.
Following structured English ruJes ensures that process descriptions are underMandahle to users who must confirm that the process is correct, as well as to other
analysts a nd programmers wbo must design the information sy~rem from the
descriptio ns.
OV!pue '1•CttDOfl0.-l
statements
-
~--
°""' . . .
S.9.4 Decision Tables
A decision ta ble is a logical structure that shows every combination of conditions and
outcomes. Analysts often use dccisio11 tables to describe a process a nd ensure that
they have considered all possible situations. Decision rabies can be created using tools
such as M icrosofr PowerPoint, Word , or Excel.
If a process has a single condition, there only are
rwo possibilirie-;-yes or no. Either the condition is present or it is not, so there are only
two rules. For example, to trigger an overtime calculation, the process condition mighr
be: Are the hours greater than 40? If so, the calculation is made. Otherwise, it is not.
TABLES WITH ONE CONDITION:
~- )U,
- Woip-M ._..,..
r..a...w...,..._...., ..I_,.. 4 111.,.. .................,.t11ru
..
(....,..... J:gi( . . . . .
.., ...,...... .,..~
- ·~• -fllllie<'f• ,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~-- - t fta111&. ...-.~ ~ij
__. ~ ~c.....,..~
.........,..,. ..
._.,.,.,.......c:-.. • ~-" .....- ""'*"....,.._...,..
..
I'
I
Phase 2
Systems Analysis
I71
S.9 Process Description Tools in Modular Design
TABLES WITH TWO CONDITIONS: Suppose there is a need to create a decision rable
based on rhe VERIFY ORDER business process shown in Figure 5-28. When documcnring a process, it is importanr ro ensure char every possibility is listed. In chis example, rhc
process description contain~ two conditions: product srock sratus and cuscomer credit
srarus. If both conditions arc mer, rhc order is accepted. Otherwise che order 1s rejecred.
VERIFY ORDER Business Process with Two Conditions
• All order will be accepted only if the product is in stock and the customer's credit status 1s OK.
• All other orders will be rejected.
FIGURE 5-28 The VERIFY ORDER business process has two conditions. For an order to bi! accepted. the
product must be In stock and the customer must have an acceptable credit status.
After all the conditions and outcomes have been identified, rhe nexr step i~ to create a
decision tnhle simil:ir co the one shown in Figure 5-29. Nore that each condition has rwo
possible v:ilues, so the number of rules doub les each time another condition is added.
For example, one condition creates two rules, two ,conditions create four rules, three
conditions create eight ru les, and so on. In rhe two-condition example in Figure 5-29,
four pos~ibilities exist, bur Ruic I is the only combination that will accept :in order.
TABLES WITH THREE CONDITIONS: Suppose the company now decides rhar rhc
credit manager can waive the customer credit requirement, as shown in Figure 5-30.
Th:.ir creates a third condition, so there will be eight possible rules. The new decision
cable might resemble rhc one shown in Figure 5-31.
1. Place the
l"i'----VERIFY ORDER Process
nameofthe ~
I
2
l
4
process ma
heading at
y
y
N
N
~ Credit status is OK
the top left.
y
y
\!,/---.
Product
1
s
in
stock
N
N
_.
2. Enter the
conditions
x
Accept order
under the
Reject order
x
x
heading. with
one condiFIGURE 5-2 9 Example or a simple decision table showing the processing logic or the VERIFY ORDER
tion per line.
process. To create the table. follow the four steps shown.
to represent
the customer
status and availability
or products.
3. Enter all potential
VERIFY ORDER Business Process with Three Conditions
combinations ofY/N
for the conditions.
• An order will be accepted only if the product is in stock and the customer's credit status is OK.
Each column rep• The credit manager can waive the credit status requirement.
resents a numbered
possibility called a
• All other orders will be rejected.
}--W
__
x
--@
rule.
4. Place an X on the
FI GURE 5 -30 A third condition has been added to the VERIFY ORDER business process. For an order to be
actJon entries area for accepted, the product must be in stock and the customer must have an accepable credit status. However. the
each rule to indicate
whether to accept or
reiect the order.
credit manager now has the authority to waive the credit saws requirements.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter S
Data and Process Modeling
5.9 Process Description Too ls in Modular Design
172
First, the Y-N patterns must be filled in, as shown in Figure 5-3 1. The best way
to assure that a ll combinations appear is rouse parterns like these. The first condition uses a pattern of Y-Y-Y-Y followed by -N-N-N, the second condition uses
a repeating Y-Y-1 -N pattern, and rhe pattern in the third condition is a series of
Y-N~.
VERIFY ORDER Process with Credit Waiver (initial ve rsion)
I
2
3
4
5
6
7
8
Credit saws is OK
Product is In stoek
Waiver from credit manager
y
y
y
y
y
y
y
N
N
N
y
y
y
y
N
N
N
N
N
N
y
N
N
N
Accept order
Re1ect order
x
x
x
x
x
x
x
x
FIGURE 5-l 1 This decision 1:1ble is based on the VERIFY ORDER conditions shown in Figure S-30. With
three conditions. there are eight possible combinations or rules.
The nexr seep is very important, regardless of the number of condirions. Each
numbered column, or ru le, represents a different set of conditions. The logic muse be
carefully analyzed and che outcome f or each r ule shown. Before going further, srudy
the cable in Figure 5-31 co be sure the logical outcome for each of the eight rules is
understood.
\Vhen all the ourcomes have beeo determined, the next step is ro simplify rhe rable.
ln a multi-condition cable, some rules might be duplicates, redundant, or unrealistic.
To simplify the table, follow rhese steps:
I. Stud> each combination of conditions and outcomes. \Xlhen there are rules with
three conditions, only one or two of chem may control the outcome, and the
ocher conditions simply do not matter.
2. If there are conditions that do not affect the outcome, mark them with dashes
(-) as shown in the first table in Figure 5-32.
3. Now combine and renumber the rules, as shown in the second table in
Figure 5-32.
Afrer following these steps, Rules 1 and 2 can be combined, because credit status
is OK in both ru les, so the waiver would not matter. Rules 3, 4, 7, and 8 also can be
combined because chc product is not in stock, so other conditions do noc matter. The
resulr is rhar instead of eight possibilities, only four logical rules concrol rhe Verify
Order process.
In addition co mu ltiple conditions, decision rabies can have
more t han rwo possible outcomes. For example, the sales promotion policy shown in
Figure 5-33 includes three conditions: Was the customer a preferred customer, did the
customer order $1,000 or mo re, a nd did the customer use our company charge card?
Based on these conditions, four possible actions can occur, as shown in the decision
table in Figure 5-34.
MULTIPLE OUTCOMES:
~- )U,
-Woip-M ._..,..
r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
..
(....,..... J:gi( . . . . .
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ ij
__.~~c.....,..~
.........,..,. ..
._.,.,.,.......c:-..•~-".....-""'*"....,.._...,..
..
I'
I
P hase 2
Systems A nalysis
173
S.9 Process D escription Tools in Mo d ular De sign
VERIFY ORDER Process with Credit Waiver (with rules marked for
combination)
Credit status 1s OK
Produet 1s in stock
Waiver from credit manager
I
2
3
y
y
y
y
Jt
Accept order
Re1ect order
.C
N
x
N
x
5
N
y
y
x
6
7
8
N
y
N
N
N
x
x
x
I . Because the
product is not in
stock. the other
conditions do not
matter.
2. Because the
other conditions
are met.the
waiver does not
matter.
VERIFY ORDER Process with C redit Waiver (after rule combination and
simplification)
3
.C
(PREVIO US S)
(PREVIOUS 6)
(COMSINES
PREVIOUS J, 4, 7,1)
N
y
N
N
x
x
I
2
(COMBI NES
PREVIOUS 1, l)
C redit staws Is O K
Produet is in stock
Waiver from credit manager
y
y
N
y
y
Accept order
Reject o rder
x
x
FIGURE S-3 2 In the first decision table.dashes have been added to indicate that a condition is not relevant. In
the second version of the decision table. rules have been combined following the steps shown below. Note that in
the final version. only four rules remain.These rules document the logic and will be transformed into program code
when the system is developed.
SALES PROMOTION POLICY - Holida y Season
• Preferred customers who order $1 .000 or more are entided t o a 5% discount and an
additional 5% discount rf they use our charge card.
• Preferred customers who do not order S1,000 or more will receive a $25 bonus coupon.
• All other customers w ill receive a $5 bonus coupon.
FIGURE S-33 A sales promotion policy with three conditions. Note that the first statement contains tw0
separate conditions: one for the 5% discount and another for the additional discount.
Sales Promotion Po licy (initial version)
Preferred customer
O rdered S 1,000 or more
Used our charge card
y
y
y
y
y
5% d iscount
Additional 5% discount
$25 bonus coupon
$5 bonus coupon
x
x
x
N
y
N
y
y
N
N
x
x
N
y
y
N
y
N
N
N
y
N
N
N
x
x
x
x
FIGURE S-34 This decision table 1s based on the sales promot ion policy in figure S-33.This 1s the 1n1t1al
version of the table before simplification.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ..............
__....
--
........... ......
. ,.. o-....._ ...... _ ... ,..,...,...,~..,._.. ........... ... ~..
~~·~---- ···---~~-.,.-"~
Chapter S
Data and Process Modeling
5 .9 Pr o c ess Descri ption Tools in Modul ar Design
174
As explained in rhe preceding section, most rabies can be simplified, and this one is no
exception. After studying rhe condirions and outcomes, the following becomes apparent:
•
•
In Ruic I, all three condirions are mer, so both 5% discounts apply.
In Ruic 2, a preferred customer orders $ 1,000 or more bur does not use our
charge card, so only one 5% discount applies.
• Rules 3 and 4 can be combined into a single rule. \Vhy? If preferred customers
do nor order $ 1,000 or more, it does not matter whether they use our charge
card-either way, they earn onJy a S25 bonus coupon. Therefore, Rules 3 and 4
really arc a single rule.
• Rules 5, 6, 7, and 8 also can be combined into a ~ingle rulc-hecause if rhe person is not a preferred customer, he or she can only receive a $5 hon us coupon,
and the other conditions simply do not matter. A da~h is inserted if a condition
is irrelevant, as shown in figUie 5-35.
If das hes are added for rules that are not relevant, the table should resemble the
one shown in Figu re 5-35. When the results are combined and simplified, only four
ru les rema in: Rule 1, Rule 2, Rule 3 (a combination of initial Rules 3 and 4), and
Ruic 4 (a combination of initial Ru les 5, 6, 7, and 8).
Sales Promotion Policy (final version)
I
2
3
4
5
6
7
8
Preferred customer
y
y
y
y
N
N
N
N
Ordered $1 ,000 or more
y
y
N
N
Used our charge card
y
N
5% disco unt
x
x
x
x
x
x
x
x
x
Additional 5% discount
$25 bonus coupon
$5 bonus coupon
FIGURE 5-lS In chis version of me decision table. dashes have been added to indicate chat a condition is not
relevant.As chis point. le appears mac several rules can be combined.
Decision tables ofren are rhe best way ro describe a complex set of conditions.
Many analysts use decision rabies because they are easy ro construct and unde rstand,
and programmers fi nd it easy to work from a decision table when developing code.
CASE IN POINT 5.2:
llocKSouD O u rn ITt:Rs (PART 1)
The marketing director at Rock Solid Outfitters, a medium-sized supplier of outdoor climbing and
camping gear; has asked the IT manager to develop a special web-based promotion. Rock Solid will
provide free shipping for any customer who either completes an online survey form or signs up
for the Rock Solid online newsletter.Additionally. if a customer completes the survey and signs up
for the newsletter, Rock Solid will provide a $ 10 merchandise credit for orders of $ I00 or more.
The IT manager has asked you co develop a decision table that will reflect the promotional rules
that a programmer will use.She wantS you ro show all possibilities, and then to simplify the results
to eliminate any combinations that would be unrealistic or redundant. How will you proceed!
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
I'
I
I
Phase 2
Systems Analysis
175
S.9 Process Descr iption Tools in Modular De sign
5.9.5 Decision Trees
A decision tree is a graphical represencarion of che conditions, actions, and rules
found in a decision table. Decision crees show the logic structure in a hori1ontal form
chat re embles a tree with the roots at the left and the branches to che right. Like
flowcharts, decision trees are useful ways to present the system to management. Decision trees and deci~ion tables provide the same results but in different forms. In many
s1ruanons, :i graphic 1s the most effective means of communication.
Figure 5-36 is based on the sales promotion policy shown in Figure 5-33. A decision tree is read from lefr to right, with the conditions along the various branches and
the actions at the for right. Because the example has two conditions with four resulting sets of actions, the example has four terminating branches at the righ t side of che
tree.
y
y
Ordered
$1 ,000 o r
more?
Preferred
customer?
Used our
charge card?
,---------<
Y
---
5% discount and
an additional 5%
discount
- - - 5% dlacount
N
' - - - - - - - - - - - - $25 bonus coupon
N
N'--------------------~ S5bonuscoupon
FIGURE 5-36 This decision tree example is based on the same Sales Promotion Policy shown 1n the decision
ables in Figures S-34 and S-35. Uke a decision table. a decision tree shows all combinations of conditions and
outcomes.The main difference is the graphical format. which some viewers may find easier to interpret.
\Xlhether co use a decision table or a decision tree often is a matter of personal
preference. A decision cable might be a better way ro handle complex combination~
of conditions. On the other hand, a decision tree is an effective way to describe a relatively simple process.
CASE IN PO INT 5.3:
RocK Souo 0ITTFITIFRS (PART 2)
The IT manager at Rock Solid Outfitters thinks you did a good job on the decision table task
she assigned to you. Now she wants you to use the same data to develop a decision tree that
will show all the possibilities for the web-based promotion described in Part I of the case. She
also wants you to discuss the pros and cons of decision tables versus decision trees. How shall
you proceed this time!
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Chapter S
Data and Process Modeling
5.10 Summary
176
This is your first week in your new job at Safety Zone , a leading producer of IT modeling
software.Your prio r experience with a. smaller competitor gave you an edge in landing the
job, and you are excited about jo ining a larger company in the same field.
So far, all is going well, and you are getting used to the new routine. However. you are
concerned abo ut o ne issue. In your initial meeting with the IT manager. she seemed very
interested in the details of your prior position, and some of her questions made you a little
uncomfortable. She did not actually ask you to reveal any proprietary information, but she
made it clear that Safety Zone likes to know as much as possible abo ut its competitors.
Thinking about it some more, you try to draw a line between information that is OK to
discuss and topics such as software specifics or strategy that should be co nsidered private.
This is the first time you have ever been in a situation like this. How will you handle !ti
S. I 0 SUMMARY
Structured analysis tools can be used to develop a logical model during one systems
analysis phase and a physical model during the systems design phase. Many analyses
use a four-model approach, which involves a physical model of the current system, a
logical model of the current system, a logical model of the new system, and a physical
model of the new system.
During data and process modeling, a systems analyst develops graphical models
to show how the system transforms data into useful information. The end product of
data and process modeling is a logical model that wilJ support business operations
and meet user needs. Dara and process modeling involves three main tools: DFDs, a
data dictionary, and process descriptions.
DFDs graphically show the movement and rransformarion of data in the information sy rem. DFDs use four symbols: The process symbol transform data, the data
flow symbol shows data movement, che data store symbol shows dara ar resr, and the
external entity S)'mbol represents someone or something connected ro the information
system. Various rules and techniques are used to name, number, arrange, and annotate
the ~et of DFDs to make them consistent and understandable.
A set of DFDs is like a pyramid \Vith the context diagram at the top. The context
diagram represents the information system's scope and its external connections bur not
its inremal workings. Diagram 0 displays the information syscem's major processes,
darn stores, and dam flows and is the exploded version of the context diagram's process symbol, which represents the entire information system. Lower-level DFDs show
additiona l detail of t he information s,ystem through t he leveling technique of numbering :1nd partitioning. Leveling continues until the functional primitive processes arc
reached, which are nor decomposed further and are documented with process descriptions. All diagrams must be balanced to ensure their consistency and accuracy.
l11c data dictionary is the central documentation tool for structured analysis. All data
elements, data flows, data stores, processes, entities, and records are docwnentcd in the data
dictionary. Consolidating documentation in one location allows the analyst to verify the information sysrcm's accuracy and consistency more easily and generate a variety of useful reporcs.
Each functional primitive process is documented using structured English, decision
tables, and decision trees. Structured English uses a subset of standard English that
defines each process with combinacions of the basic building blocks of sequence, sclecnon, and iteration. Using decision tables or decision trees can also document the logic.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
I'
I
I
Phase 2
Systems Analysis
177
Key Terms
Key Terms
alias A term used m various Jara d1cttonaries 10 indicate an altemare name, or J name other than rhe
;,randard Jar.1 dcmem name, rhar 1s used co de.cribe the same data element.
balanunit A pr<><.c:-.\ u>ed to mam1.1m .:on~1scency among an enrire seri~ of dfagram•., mdudin11 mpu1
and output data Omn, Jara definmon, and pr0<.-e-;s dc::>cripuon~.
blad. ho' t\ metaphor for a proce>\ or an acrion that produces rc~ult~ an a non-rran\parcnt or nonoh-crvahle manner. In OFO~. a proce<.~ appears as a black box where che inpul', output\, and general
function of the prcx:C\~ arc known, bur rhe underlying demi ls are not ~hown.
black hole A process rhar has no output.
business logK Rules 10 derermme how a system handles data and produces useful informauon, rcflecnng
the operanonal rcqu1remenrs of rhe bustness. E..xamples include adding the proper amo•tnt of sales tJll.
to invoices, calcul.111ng customer balances and fmance charges, and deternunmg wherher a customer
is eligible for ,1 volum~-bascd discount. Also called business rules.
bu"n''" rule, Sec hminc\\ lo111c.
child diagrnm The lower-level diagram in an exploded DFD.
context diagram A rop-lcvcl view of an informarion system that shows the bound<lrics ond ~cope.
conrrol ~trucrurc ~crvc as bui lding blocks for a process. Conrrol structures have one entry ond cxir
point. '1 be) may be completed m sequential order, as the resulr of a rest or condmon, or repe.ncd until
J >pec1fic condmon ch.111ges. Also c.alled logic.ii structure.
data Jiu1onal') A ~c:nrral \torc:hou'c: of information about a >Y>tc:m'> data.
dara cli:mcnr 1\ ''"Jllc <:haracttri~c11: or fau ahout an cntil)-. A data clcrnc:m, fidd, or arrributt" the
'malle>t pic.:t of data that ha• meaning within an information sy,tcm. For example, a 'KK:1al Security
number or companr name could be example~ of a daca element. Alo;o called data item.
data Oo" A path for data to mo•e from ooe part of the informarion S) stem to a nor her.
data Oo" diagram !DfD) Diagram rhar shows how the S)"Stem scores, processes, and rraosforms dara
11110 useful informauon.
cilia item Sci! datJ dc:mc:nt.
Jar.a rc:po\llOI') t\ wmhol u>ed 111 DFO, to reprl!l>cllt a siruarion in which a s)stem mu\t rc:1a111 data
becau;,e cme or more prcK:~'-<"\ nc:c:d 10 use rhat stored data at a later time. u,c:d inrerchan11~hly wnh
the term dat.1 'tore.
data nore Su data rcposllOI) .
dara 'itructurc A m~anmgful comhmar1on of related data element<> rhar are included 111 a data flow or
retained ma data siorc. A frame\\ Ork for organizing and storing data.
dcci\ion table A ta hie char shows a logical structure, with all possible comhmatiom of condi11011\ and
re~u h ing acnon\.
dcl:i,ion rrcc A graphical rcprc;,c111,11ion of rhc cond itions, actions, and rule> found in ;1 dcci,ion 1:1blc.
decompo~in11 Anorher w:1y of conveying a process or >ysrem char has been broken down from .1 genera l,
top-level view 10 more dct.1i l. 1 he rerms exploded and part1tio11ed also can be used.
dia11mm 0 A diagr.1111 dcpic1111g rhc fir~r level of derail below the mirial conrext diagram. Diagram 0
(lcroJ 7.ooms rn on rhe context diagram and shows rna1or processes. darn flows, and d(l(a \tores, as
well as repeating che external enricies and data flows thac appear in the context diJgram.
di•crgmg dara flow A darn flow in which che same dam rra\"els co rwo or more different locarions.
domain The set ot value<; pcrmmcd for a d:na elemenc.
enut• A person, a pla1.:e, J rhmg, or an evem for which dara is collecred and m.110t;11ned. !'or example. an
ouhne >JI~ >»tcm mJ) mdude enm1~ n:tmed CUST0~1ER. ORDER, PRODUCT. .ind SUPPLIER.
explodtnit A J1agr;im 1s s.~td to be exploded 1i 11 "drills down" ro a more derailed or expanded view
~ JD» (".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_ ._.... ~~
...
. ..............
_ .... ~---11rt~
-,..~---~ ~
.... . _
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Chapter 5
Data and Process Modeling
Key Terms
178
field A ~mgle char.1crens11c or fact abour an enriry. A field, or anribuce, 1s 1hc ~m.iUest pie.:c of d.11a th:u
h.i; mumng wuhm an rnformation system. For example. a Social S«ut1t} numlx:r or company name
could!)( e~amples of a field. The rerms data eleme11t, data item, .ind field are used m1crchangeably.
four-moJd approach A ph)">ical model of the currenr system, a logu:al moJd of thc L-UITtnt \)\!em, a
loi;1cal model of rhe new S)-.rem, and a physical model of rhe new >y>tcm are all developed.
funuional pnm1tl\e A >mgle function char 1s nor exploded furrher. The logi~ for fun~t1onal prumrive' is
J0<;umcntcJ m a J~ta dictionary proct'.Ss description.
Gane and Sarson A popular symbol sec used in DFDs. Processes, data flows, dat.l scores, and exrernal
enrmcs all have a unique symbol.
gr:iy hole A process with an lllput obviously insufficient to geuerare the shown output.
i1cr.11ioo The complenon of a process step chat is repeated unttl a spectfic condiuon changes.
lcvdin11 The prt>ec" of drawinµ a scrie- of increasingly detailed diai:ram~ to rcai:h 1hc dc,ircJ IL-vd of detail.
logical model Shows what a S)n;rcm mu>r do, regardle's of how it will be implemented phy,ically.
logica l s1ruccure See cooirol scruccure.
looping Refers ro a process step that is repeated until a specific condition ch.1nges. !·or example. a
process that continues ro prmr paychecks unul 11 reaches the end of the payroll file 1s loopin11. Also
known .is rcpem1on.
modular design A design that can be broken do\\n inro logical blocks. Also known as partitioning or
1op·dow11 design.
p.arcnt Jiai.:ram The hi11hcr or more !Op-kvd dia11ram in an exploded DFD.
panitionini: The brcakini: down of overall objective• into •uh..y•rcm' and mudulc•.
ph) ~ical model A model chat describes how a system will be consrructed.
proccS> Procedure or ta.k that users, managers, md JT scaff members perfom1. Aho, the logic.11 rules of
.i S)Stcm chat are .ipplted ro rrmsform data mto mea.rungful utform.iuon. ln l)l l)s, a process receives
tnput d.11a and produces ourput that bas a ctiHerenr content. form, or both.
proccs~ 0 In a DfD, process 0 (zero) represenrs the entire infom1.ition sy:;rcm but does nm sho" the
internal workings.
pnK~" d~~-rtption A dcxumenrarion of a functional prnn1rivc':; detail;, whkh repre\Cnh a '>pc:~1fic.: sec of
prt><:c:<>,mg >rep\ and bu.,mcss logic.
p'cudocodc A rechnique for rcpreseming program logic.
record A set of related fields that describes one instance, or member of an entif), such a~ one customer,
one order, or one product. A record mighr ha'e one or do£ens of field~. depending on \\h3c mformanon is needed. Also called a tuple.
~eleccion A control strucrure 111 modular design, it is rhe complenon of two or more proce~~ steps based
on rhc re~ults of :i test or condicion.
,cqucncc The completion of sreps in sequential order, one 3.fter :lllother.
\inl.. An cx tcrn,d entity chat receives daca from an informarion syMcm.
\nurcc An external cnriry rhat supplies data roan information system.
~pontancou~ generation
An unexplained generation of data or information. With re~pccr ro DrDs,
proccs;es c:mnor spomaaeouslr generace data flows-they must have an inpur m have an oucput.
)trui;1ured [nglt>h A subser of standard English char describe> logical proccsse; dearly and JCCur3rel).
tcrmmalUr A D~D >ymbol that mdtcares a dara ongrn or final dc;rmarion. Al>o called an C'(tcrnal emit).
•altdtr) rule~ Chech thar are applied ro dara elemems when data is entered to ensure thar rhc value
entered is valid. For e..;ample, a validiry rule mighr require thar an employee·~ ~ala') numl>cr l>c wirnin
rhe cmplo)cr's predefined range for rhar position.
)ourdon A type of srmbol ser rhar 1s used in DFDs. Proccsse>, data flows, data stores, .ind exrcmal
cnriucs each have a unique symbol in rhe Yourdon srmbol set.
~ JD» (".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_ ._.... ~~
...
. .............
_ .... ~---11rt~
-,..~---~ ~
.... . _
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
I'
I
I
Phase 2
Systems Analysis
Exercises
179
Exercises
Questions
I. \Xlhar is rhe relationship bcrwccn logical and physical models ?
1. What is the function of a DFD in the SDLC?
3. Draw examples of rhe four basic DFD symbols.
4. \Xlhar are the six guidelines to follow when drawing DFDs?
5. What is rhe difference bcrween a conte"''t diagram and diagram O?
6. \Xlh1ch symbol is not used in a coarext dfagram?
7. I low would you level a DFD?
8. How would you balance a DFD?
9. What is a dat:i clement?
I 0. What is rhe purpose of a decision rab le?
Discussion Topics
I. How would you convince management char following a four-model approach is wise?
1. \'V'hen might it be :ippropriare co violate the "no crossed lines" guideline in DFDs?
3. \'<'hat is the relationship berween system requirements and context diagrams?
4. How might CASE cools be used to document rhe design of a data dicrion:iry?
5. Some systems analysts find it berrer to start with a decision table, and then construct a decision tree.
Others believe it is easier to do ir in the reverse order. Which do you prefer? Why?
Projects
1. The data flow symbols shown in Figure 5-1 were designed by Ed Yourdon, who was a well-known IT
author, lecrurer, and consulcant. t.1an)' IT professionals consider him to be among the most influenrial
men and women in rhe software field. Learn more about ~1r. Yourdon by visiting online resources and
write a brief re\•iew of his work.
2. Explore rhree CASE tools that provide the ability to dra\\ the four basic DFD symbols and describe
what you liked and disliked about each tool.
3. Draw :i context diagram and a diagram 0 D FD char represents the information system at a rypical
library.
4. Create a decision rable with three conditions. You can make one up or use a scenario from everyday
life. Eirher way, be sure co show all possible ourcomes.
5. Explore the use of Structured English to describe processes in fields other rhan systems analysis.
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~... . ... .,...~ • ........._ . ....._.,.,.. o-... ..,._.,,.,.. _ ..,.~ ,........., ................. .._... .., .,. ..,.~"
................... ..., ...................... .... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
Chapter 6
Object Modeling
Object Modeling
Chapter 6 is the third of the four chapters in the
systems analysis phase of the SDLC. This chapter
discusses object modeling techniques that analysts use to
create a logical model. In addition to structured analysis,
object-oriented analysis is another way to represent and
design an information system.
The chapter includes three "Case in Point"
discussion questions to help contextuali1e the concepts
described in the text. A "Question of Ethics" considers
the situation where an employee wants to skip a course
and just sit the exam and requests a copy of the training
materials from someone else who took the course.
LEARNING OBJECTIVES
CONTENTS
When you fi11is/J this chapter, yo11 should be
able to:
6. 1 Objecr·Orienrcd Analysis
1. Demonstrate how objccr-orientcd analysis can
be used to describe an informarion system
2. Explain whar an objecr represenrs in an informa·
tion sysrcm
3. Explain obiect artribures
4. Explain objecc mcrho<ls
5. Explain objccr messages
6. Explain classes
7. Explain relarion~hips among objccrs and classes
8. Draw an objecr relarionship diagram
9. Demonscrace use of the UML ro describe
objecr-oriented l.ystems, including use cases,
use case diagrams, class di:igrams, sequence
diagrams, scare transirion diagrams, activiry dia·
grams, and business process models
Case in Point 6.1: TravelBiz
6 .2 Objects
6.3 Attributes
6.4 ~lethods
6.5 ~lessages
6.6 Classes
6.7 Relationships Among Objecr~ and Classes
6 .8 The Unified Modeling Language (UML)
Case in Poinr 6.2: Hilltop Motors
Case in Poinr 6.3: Train rhe Trninerb, Inc.
6 .9 Tools
A Question of Ethics
6. 10 Summary
Key Terms
Exercises
lO. Explain how roob can bupporr object modeling
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
I'
I
I
Phase 2
Systems Analysis
181
6.2 Objects
6.1
OBJECT-ORIENTED ANALYSIS
As seated in Chapter I, rhe mosr popular systems development options are structured
analysis, object-oriented (0-0) anal)·sis, and agile methods. The table in Figure 1-17
shows rhe three alrernati,·es and describes some pros and cons for each approach. As
tbe rable indicares, 0-0 methodology is popular because it inregrares easily wirh 0-0
programming languages such as C++, Ja,·a, and Python. Programmers also ltke 0-0
code because it is modular, reusable, and easy to m aintain.
Object-oriented (0 -0 ) analy~is describes an information system by idenrifying
things called objects. An object represents a real person, place, event, or rransacrion.
For example, when a patient makes an appointment to sec a doctor, the patient is an
object, the doctor is an object, and the appoinanent itself is an object.
0-0 analysis is a popular approach that sees a system from the viewpoint of the objects
themselves as they function and interact. The end product of 0-0 analysis is an object
model, which represents the information system in rerms of objects and 0 -0 concepts.
Chapter 4 stated that the Unified Modeling Language (UML) is a widely used
method of vi~ua l izi n g and documenti ng an information system. ln this chapter, the
UML is used to develop object models. The first s tep is ro unde rstand basic 0 -0
terms, incl uding objects, attributes, methods, mes.sages, and classe~ . Th is chapter
shows how systems ana lysts use those te rms ro describe an information system.
CASE IN PO INT 6.1:
T RAVELBIZ
TravelBiz is a nationwide travel agency that speciali1.es in business traVel. It has decided to
expand into the vacation travel market by launching a new business division calledTravelFun. The
IT director assigned tw0 systems analysts to create a flexible and an efficient information system
for the new division. One analyst wants to use traditional analysis and modeling techniques for
the project, while the other analyst wants to use an 0-0 methodology. Which approach would
you suggest and why?
6.2 OBJECTS
An object represenrs a person, a place, an event, or a transaction that is significanr ro
the information ~ysrem. In Chapter 5, DFDs were created that treated data and processes separately. An object, however, includes data and the processes that affect that
data. For example, a c ustomer object has a name, an address, an account number, and
a current balance. Customer objects also can perform specific tasks, such as placing
an order, paying a bill, and changing their address.
Consider a simplistic example of how the UML might describe a famjJy wirh parents and children. UM L represenrs an o bject as a rectangle with the object name at
tbe cop, fo llowed by rhc object's attri butes and m ethods.
Figure 6- 1 shows a PARENT object ~vi th certain attributes such as name, age, sex,
and hair color. If there arc nvo parents, then there arc rwo instances of the PA RENT
object. T he PA RENT object can perform methods, such as reading a bedtime story,
driving the carpool van, or preparing a school lunch. When a PARE rT object receives
a message, it performs an acrion, or method.
For example, the message GOOD NIGHT from a child nught cell rhc PARENT
object to read a bedtime srory, while the message DRrYE from another parent signals
chat iris rhe PARF.NT object's turn co drive in the carpool.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Chapter 6
Object Modeling
6.2 Objects
182
PARENT Object
Attributes
Cllaracter.stlCS
that describe tile
PARENT object
Name
Age
Sex
Hair color
•a
Mary Smith
Age25
Female
Red
Ahmec:IAll
Age34
Male
Brown
...........
Task.s tllat the
PARENT objoct
can perform
Instances of
the PARENT Object
"ill
a1111112m ui.-.
AnthonyGrMna
Age 42
Mate
Brown
FIGURE 6 - 1 The PA RENT object has four attributes and two methods. Mary Smith, Ahmed All, and
Anthony Greene are Instances or the PAREN T •object.
Continuing with the fami ly example, che CHJLD object in Figure 6-2 posse ses che
same artrilrntes as the PARENT object and an additional arrribute thac shows the number of siblings. A CHllD object performs certain methods, such as picking up roys, eat·
ing dinner, playing, cooperating, and getting ready for bed. To signal the CHILD object
to perform those casks, a parent can send certain messages that rhe CHILD objecr will
undcrsrand. For example, rhe DINNER'S READY message cells a CHILD obiect to
come to the rable, while rhe SHARE \XfJTH YOUR BROTHER/SISTER message tells a
Cl ll LD object co cooperate wich other CHILD objects.
CHILD Object
CfSD
James Smltll
Age3
Attributes
Characteristics
Name
Age
Sex
Hair color
Number of slbllngs
that describe the
CHILD Object
Instances of
the CHILD Object
Male
Red
Amelia All
Age 1
Female
Brown
•...
-··
,..,
.........
tl?h•lfr
Tasks that the
CHILD objecl can
perform
MlatyGreene
Age t2
Female
Blonde
,
D
Ji
I
FIGURE 6 -2 The CHILD object has rive attributes and five methods. James Smith. Amelia A li. and
Mosty Greene are Instances or the CHILD object.
~- )U,
-Woip-M ._..,..
r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
..
(....,..... J:gi( . . . . .
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
.........,..,. ..
._.,.,.,.......c:-..•~-".....-""'*"....,.._...,..
..
I'
I
P hase 2
Systems A nalysis
183
6.5 Messages
6.3 ATTRIBUTES
An object has certain attributes, which are characteristics that describe the object. If
objects are similar to nouns, attributes are similar co adjectives that describe the characteristics of an object. For example, a car has attributes such as make, model, and
color. Some ob1ects might have a few attributes; ochers might have doz.ens.
Systems analysts define an object's attributes during the systems design proce~s. ln
an 0-0 system, ob1ecrs can inherit, or acquire, cercain attribuces from other objects.
Objects can have a specific attribute called a state. The state of an object i an
adjective that describes rhe object's current status. For example, depending on the
stare, a student can he a future srudenc, a current srudenr, or a past student. Similarly,
a bank account can be acrive, inactive, closed, or frozen.
6.4 METHODS
An object also has methods, which are rasks or functions that the object performs
when it receives a message, or command, to do so. For example, a car performs a
method called OPERATE WIPERS when it is sent a
message with the wiper conrrol, and it can APPLY
Method:
Steps:
BRAKES when it is sent a message by pressing the
MORE FRIES
t Heat oll
brake pedal. A method defines specific tasks that
2. All fry basket with frozen
:in object can perform. Ju~r ::is objects are similar co
potato strips
nouns ::ind ::irrribuces are similar to adjecrives, meThods
3. Lowe< basket Into hot oil
resemble verbs rhar describe what and how an object
does something.
4. Check for readiness
Consider a server who prepares fries in a fasc5. When ready, raise basket
and let drain
food re!.taurant. A systems analyst might describe the
operation as a method called r.10RE FRIES, as shown
6. Pour fries Into warming
lfllY
in Figure 6-3. The t.10 RE FRIES method includes the
steps required to heat the oil, fill the fry basket with
7. Add salt
frozen potato strips, lower it into the hot oil, check for
readines!>, remove che basket when ready and drain the
FIGURE 6-l The MORE FRIES method requires the
server to perform scvcn specific steps.
oil, pour the fries into a warming tray, and add salt.
6.5 MESSAGES
A message is ~1 command that tells an
object co perform a certain method. For
example, the message PfCK UP TOYS
directs rhe CHILD class to perform
all the necessary steps to pick up the
toys. The Cl llLD class understands the
message and executes the method.
The same message to rwo different
objects can produce different results.
The concept that a message gives
different meanings to different objects
is called pol>morphism. For example, in
Figure 6-4, the message GOOD NIGHT
signals the PARENT object to read a
.........""_.. ... .-.................
Message: GOOD NIGHT
PARENT
DOG
CHILD
Causes Ille
PARENT oo,ect lo
read a bedlime SlQ(y
Causes the DOG
obJOCI to go ro sleep
Causes lhe CHILD
object ID gel ready
for bed
FIGURE 6-4 In an example or polymorphism. the message GOOD NIGHT
produces different results. depending on wtuch ob1en receives 1L
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 6
Object Modeling
6.6 Classes
184
bcdrime story, but the same message to rhe CHILD object signals it to get ready for bed.
If the family also had a DOG object, the same message would tell the dog to leep.
An object can be viewed as a black box, because a message to the object triggers
changes within the object without specifying how the changes must be carried our.
A gas pump is an example of a black box. \Vhen the economy grade 1s selected at a
pump, it is not neces ary to think about how the pump determines the correct price
and selects the righ t fuel, as long as ir does so properly.
The black box concept is an example of encapsulation, which means that all
daca and methods are self-contained. A black box docs not want or need outside
interference. By limiting access to internal processes, an ob1ccr prevents its internal
code from being altered by another object or process. Encapsularion allows objects
to be used as modular components anywhere in the system, because objects send and
receive messages but do not alter the internal methods of other objects.
0-0 designs typically arc implemented with 0-0 programming languages. A major
advantage of 0-0 designs is that systems analysts can save time and avoid errors by
using modular objects, and programmers can translate the designs into code, working with reusable program modules t ha t have been tested and verified. For example,
in Figure 6-5, an INSTRUCTOR object sends an ENTER GRADE message roan
instance of the STUDENT RECORD
Message:
class. Note that the INSTRUCTOR
ENTER GRADE
object and STUDENT RECORD class
STUDENT
could be reused, with minor modifiINSTRUCTOR
RECORD
cations, in ocher school information
systems where many of the attributes
FIGURE 6-5 In a school Information system. an INSTRUCTOR object sends an
and mcrhocls would be similar.
ENTER GRADE message to an instance ol the STUDENT RECORD class.
6.6 C LASSES
An objecr belongs to a group or category called a class. For example, Ford Fiestas
belong ro a class called CAR. An instance is a specific member of a class. A Toyota
Camry, for example, is an instance of the CAR class. Ar an auto dealership, many
insranccs of rhc CAR class may be observed: rhe TRUCK class, the ~11NIVAN class,
and the SPO RT lITlLITY VEHICLE class, among others.
All objccrs within a class share common attributes and methods, so a class is like
a blueprint or template for all tbe objects within tbe class. Objects within a class can
be grouped into subclasses, which arc more specific categories within a class. For
example, TRUCK objects represent a subclass within rhe VEHICLE class, along wirh
other subclasses called CA R, M INTVAN, and SCHOOL BUS, as shown in Figure 6-6.
Nore that a ll four subclasses share common traits of the VEHICLE class, such as
make, model, year, weight, and color. Each subclass also ca n possess traits that are
uncommon, such as a load lim it for the TRUCK or an emergency exit location for the
SCHOOL BUS.
A class can belong to a more general category called a supcrcla~s . For example, a
NOVEL class belongs co a s uperclass called BOOK, because all novels are books in
this example. T he NOVEL class can have subclasses called HARDCOVER, PAPERBACK, and DIGITAL.
Similarly, consider a fitness cenrer illusrrared in Figure 6-7 char might have
students, inst ructors, class schedules, and a regisrration process. As shown in
Figure 6-8, the EMPLOYEE class belongs to the PERSON superclass, because every
emplO)'Ce is a person, and the rNSTRUCTOR class is a subclass of EMPLOYEE.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
P hase 2
Systems A nalysis
185
6.6 Classes
Subclass
Class
Vlllat E
Attributes
Common
allnbulH
Common
methOds
Attributes
Make
Model
Yur
Weight
Color
lmlYAN
....-.
Attributes
Attributes
Uncommon
ottnbutes
Load limit
FIGURE 6-7 A typical flmess center might
have students. Instructors. class schedules, and a
registration process.
SI<> I 1!1,.,'Shttlr1 1
'""
SCHOOL BUS
Attributes
Uncommon
Emergeoncy e•il location
allttbutes
FIGURE 6-4 The VEHICLE dass includes common attributes and methods.
CAR. TRUCK. MINIVAN. and SCHOOL BUS are instances of the VEHICLE class.
Superclass
PERIOH
Supeictass
name
Class
Attributes
Name
Common --:r Date of birth
attnbu1os
........
•11 ..
r:Com:::::mo=n'---,:A.111
methods
Class
name
Attributes
Subclass
Social Security number
Uncommon
attributes
...
Telephone number
Hire date
Title
Pay rate
Uncommon
methods
...
llJltiodl
Subelass
name
WllRUCIOR
Uncommon
attrlbutos
Attributes
lnatructor type
Avatlabillty
Giit....
7
0
0
•
Uncommon
methods
FIGURE 6-8 At the fitness center, the PERSON subclass includes common attributes and methods.
EMPLOYEE is a dass within the PERSON superclass. INSTRUCTOR is a subclass within the EMPLOYEE class.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~----···---~~-.,.-"~
Chapter 6
Object Modeling
6.7 Re lationships Among Objects and Classes
186
6. 7 RELATIONSHIPS AMONG OBJECTS AND CLASSES
Relationships enable objects to communicate and interact as they perform business
functions and t ransactions required by the system. Relationships describe what
objects need to know about each other, how objects respond to changes in other
objects, and the effects of membership in classes, superclasses, and subclasses. Some
relationships arc stronger than others (jusr as a relations hip berween family members
is stronger than one between casual acquaintances). The strongest relationship is
called inheritance. Inheritance enables an object, called a child, to derive one or more
of its attributes from another object, called a parent. In t he example in Figure 6,9,
the INSTRUCTOR object (child) inherits many t raits from rhe FMPLOYEE object
(parent), including SOCIAL SECURITY NUMBER, TELEPHO E NUMBER, and
HIRE DATE. T he INSTRUCTOR object also can posses~ additional attribures, such
as TYPE Of I STRUCTO R. Because a ll employees sh:ue cercnin attributes, rhose
attributes are assumed through inheritance and do not need to be repeated in the
INSTRUCTOR object.
Inheritance
Child Inherits
Parent
•llWCIOR
Attributes
Attributes
So<:lal Security number
Telephone number
Hire date
Type ol lnslNCtor
So<:lal Security number
~:.,.._--h Telephone number
Title
Pay rate
Hlredate _ J
Tiiie
Pay rate
....•••llOlllt
1lt
LS
CIAO 7 'ct 111'
FIGURE 6,9 An inheritance relationship exists between the INSTRUCTOR
and EMPLOYEE objecLS. The INSTRUCTOR (child) object Inherits characteristics
lrom che EMPLOYEE (parent) class. and can have additional attributes of Its own.
After objects, classes, and relationships have been identified, an object relation,
ship diagram can be prepared to provide an overview of the sy~tem. Thac model
is used as a guide to continue co develop additional diagrams and documenracion.
Figure 6, J 0 s hows an object relationship diagram for a fitne~s cencer. Note rhac che
model shows che objects and how they interact to perform business functions and
transactions.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
- Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
- ·~•-fllllie<'f •,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
P hase 2
Systems A nalysis
187
6.8 The Unified Modeling language (U ML)
EMPLOYEE
Isa
MANAGER
OFRCESTAFF
INSTRUCTOR
Indicates
RTNESS-CLASS
avallabillty
FITNESS-CLASS
SCHEDULE
Takes
roster
ST\JDENT
FIG URE 6 - 10 An object relationship diagram for a fitness center.
6.8 THE UNIFIED MODELING LANGUAGE (UML)
just as strucrnred analysis uses DFDs to model data and processes, systems analysts
use UM L co describe 0-0 ~yscems. Chapter 4 explained that UM L ts a popular
technique for documenting and modeling a system. UML uses a set of symbols to
represent graphically the various components and relationships within a system.
Although che UML can be used for business process modeling and requirements
modeling, it is mainly used to support 0-0 system analysis and to develop object
models.
6.8. 1 Use C ase Modeling
A use case represents the seeps in a specific business function or process. An external
entity, called an actor, initiates a use case by requesting the system to perform a
function or process. For example, in a medical office system, a PATIENT (actor) can
MAKE APPOINTMENT (use case), as shown in Figure 6-11.
Note that the UML symbol for a use case is an oval with a label that describes the
action or event. The actor is shown as a stick figure, with a
label that identifies the actor's role. The JiJJe from the actor
to the use case is called an association, because it links a
particular actor to a use case.
Use cases also can interact with other use cases. When
the outcome of one use case is incorporated by another use
case, we say that the second case ttses the first case. UM L
indicates the relationship with an arrow char points at rhe
MAKE APPOINTMENT
use case being used. Figure 6- 12 shows an example where a
(Use Case)
PATIENT
student adds a fitness class and PRODUCE FITNESS-CLASS
(Actor)
ROSTER uses the results of ADD FITNESS-CLASS to
FIG URE 6 - 11 In a medical office s11tem. a
generate a new fitnes.'>·clas.'> roster. Similarly, if an instructor
PATIENT (actor) can MAKE APPOINTMENT (use
changes hts or her availability, UPDATE TNSTRUCTOR
case). The UHL symbol for a use case is an oval.The
actor
is shown as a stick figure.
h FORMATIO 11ses the CHA GE AVAILABILITY
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 6
Object Modeling
6.8 The Unified Modeling Language (UML)
188
use case to update the
instructor's in formation.
To creare use cases, start
b)' reviewing rhe information that gathered during
the requirements modeling
<<U5eS>>
Produce Frtnes~lass
phase. The obrective is to
Add Rtness-Class
Student
Roster
identify the actors and the
functions or transactions
they initiate. For each use
case, develop a u~e case
description in the form of
a table. A use case description documents the name
<<USeS>>
of the use case, the actor, a
Change Avallablllty
Update lnslructor
description of the use case,
Instructor
ln1ormatlon
a step-by-step list of the
ra~ks and actions requi red
FIGURE 6- 12 When a student adds a class, PRODUCE FITNESS-CLASS ROSTER uses the
results of ADD FITNESS-CLASS to generate a new roster. When an instructor changes his or
for successfu l completion,
her availability, UPDATE INSTRUCTOR INFORMATION uses the CHANGE AVAILABILITY use
a description of alternative
case co update the Instructor's Information.
courses of action, preconditions, posrcondirions, and
assumptions. Figure 6-13 shows an example of the ADD NEW STUDENT use case
for the fitness center.
ADD NEW STUDENT Use Case
Name:
Add New Student
Actor:
Student/Manager
Add New Student
Description:
Describes the process used to add a student to a fitness-class
Successful
completion:
1. Manager checks FITNESS-CLASS SCHEDULE ob1ect for availabihty
2. Manager notifies student
3. Fitness-class is open and student pays fee
4. Manager registers student
Alternative:
1. Manager checks FITNESS-CLASS SCHEDULE object for availability
2. Fitness-class Is full
3. Manager notifies student
Precondition:
Student requests litn ess-class
Postcondition:
Student is enrolled in fitness-class and fees have been paid
Assumptions:
None
FIGURE 6- 13 The ADD NEW STUDENT use case description documents the process used to add a current
student into an existing dass at the fimess center.
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
I
Phase 2
Systems Analysis
6.8 The Unified Modeling Language (UML)
\'V'hen use cases arc idcnrified, al l rhe relaced cransacrions should be grouped inro a
single use case. For example, when a horcl customer reserves a room, rhe rescrvarion
S)'Srem blocks a room, updares rhe occupancy forecasr, and sends rhe cusromer a
confirmarion. Those cvcnrs are all part of a single use case called RE ERVE R00~'1,
and the specific acrions are ~tep-by-srep casks within the use case.
6.8 .2 Use Case Diagrams
A u~e ca~e diagram is a visual summary of several related use case!. w1chm a sy~tem or
subs) stem. Consider a C) pica I au co service deparr:menc, as shown in Figure 6- 14. The
service department involves customers, service writers who prepare work orders and
invoices, and mechanics who perform che work. Figure 6-15 shows a possible use case
diagram for the auro service department.
FIGURE 6- 1'4 A cyplal auto service department might involve custome". service
write" who prepare work orde" and invoices. and mechanics who perform the wo/1(.
.
"
\'<'hen a use case diagram is crearcd, the first step is co ide11cify the sysrcm
boundary, which is represented by a recrangle. T he system boundary shows whar is
included in rhe system (inside che recrangle) and whar is nor included in rhe system
(outside the rectangle). After the system boundary is identified, use cases are placed
on the diagram, the actors arc added, and the relationships shown.
CASE IN PO INT 6.2:
H1u.;roP MoroRs
You were hired by Hilltop Motors as a consultant to help the company plan a new information
system. Hilltop is an old-line dealership, and the prior owner was slow to change. A new management team has taken over. and they are eager to develop a first-class system. Right now, you
are reviewing the service department. which is going through a major expansion. You decide to
create a model of the service department in the form of a use case diagram. The main actors
in the service operation are customers. service writers who prepare work orders and invoices,
and mechanics who perform the work. You are meeting with the management team tomorrow
morning. How would you create a draft of the diagram to present to them?
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
189
Chapter 6
Object Modeling
6.8 The Unified Modeling Language (UML)
190
Use Case Diagram: Auto Service Department
Requests
Writes
service
Update
Customer
Service
Writer
Update
Work
Schedule
Performs
work
Mechanic
Prepare
Invoice
FIGURE 6- 1S A use case diagram t o handle work at an auto service department.
6.8.3 Class Diagrams
A cl:u~ diagram shows the object classes and relationships involved in a use case. Like
a DFD, a class diagram is a logical model, which evolves into a physical model and
finally becomes a functioning information system. In ~rructurcd analysis, enritics, data
stores, and processes are transformed into data structures and program code. Similarly,
class diagrams evolve into code modules, daca objects, and other system components.
In a class diagram, each class appears as a recrangle, with the class name at the
top, followed by the class's attributes and method~. Lines &how relationships berween
classes and have labels identifying the action that relates the two classes. To create
a class diagram, review the use case and identify the classe~ that panicipate in the
underlying business process.
The class diagram also includes a concept called cardinal ity, which describes how
instances of one class relate to instarnces of another class. For example, an employee
might h:ive e:irned no vocation days or one vacation day or many vacation doys.
Similarly, an employee migh t have no spouse o r one spouse. Figure 6- 16 shows
v:irious UML notations and cardinaliity examples. Note char in Figure 6· 16, the first
column shows a UML notation symbol that identifies the relationship shown in the
second column. The third column provides a typical example of che relationship,
which is described in the last column. In the first row of the figure, the UML notation
0.. • identifies a zero or many relation. The example is thar an employee can have no
payroll deductions or many deductions.
Figure 6-17 shows a class diagram for a sales order use case. Note rhat the sales
office has one sales manager who can have anpvhere from zero to many sales reps.
Each sales rep can have anywhere from zero to many customers, but each customer
has only one sales rep.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
- Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
- ·~•-fllllie<'f •,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
I
Phase 2
Systems Analysis
I91
6.8 The U nified Modeling Language (UML)
UML
Notation
Nature of the
Rellltlonshlp
o. •
Zero or many
Employee
Payroll Deduction
1
0 .• 1
1
Zero or one
One end only one
Description
Example
H
Manager H
Order
H
0. •
Employee
I
Office
One or many
Spouse
An employee can have no spouse or
one spouse
Sales Office
An olfoce manager manages one and
only one olfice.
Item Ordered
One order can include one or many
items ordered
0 .. 1
1
t:
An employee can have no payroll
deductions or many deductiOns
1
t..•
FIGURE 6· 16 Examples of UML notations that Indicate the narnre o f che relationship betwee n instances of one class
and instances of another class.
Manages
1
S11h!s Manager
Attributes
Methods
Methods
1
1
Assigned
Manages
o..•
Attributes
Methods
Methods
Includes
1..-
Items Ordered
Attributes
Attributes
Methods
Methods
FIGURE 6-17 Class diagram for a sales order· use case (attributes and
methods omitted for clarity).
CASE IN POINT 6.3:
TRAIN THE TRAl:."JERS, INC.
Train the Tralner develops seminars and workshops for corporate training managers, who in tum
train their employees. Your job at Train the Trainer is to put together the actual training materials.
Right now, you are up against a deadline. The new object modeling seminar has a chapter on
cardinality. and the client wants you to come up with at least three more examples for each of
the four cardinality categories listed in Figure 6-1 6. The four categories are zero or many. zero or
one. one and on"t one. and one or many. Even though you are under pressure, you are detennined
to use examples that are realistic and familiar to the students. What examples will you submit/
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Chapter 6
Object Modeling
6.8 The Unified Modeling Language (UML)
192
6.8.4 Seque nce Diagrams
A ~cqu ence diagram is a dynamic model of a use case, ~howing the inreracrion among
classes during a specified rime period. A sequence diagram graphically documents
the use case hy showing che classes, r:he messages, and the riming of the messages.
Sequence diagrams include symbols that represent classes, lifelines, messages, and
focuses. These symbols are shown in Figure 6-18.
a,,112
Life line
Message 1
Focus
Focus
Message 2
I
I
I ~
Lifeline
I
I
I
I
I
*
FIGURE 6 -18 A sequence diagram with two cla.nes. Notice the X that
indicates the end or the Cl.ASS 2 lifeline. Also noace that each message is
represented by a line with a label that describes the me=ge, and that each
class has a focus that shows che penod when messages are sent or received.
C LASSES: A class is idcnrified by a rectangle with the name inside. Classes char send
or receive messages arc shown ar the top of the sequence diagram.
LIFELINES: A lifeline is identified by a dashed line. The lifeline represents the time
during which the object above iris able ro interact with the other objects in the use
case. An X marks the end of rhe lifcljne.
MESSAGES: A message is identified by a line showing direction that runs between
two objecrs. The label shows the name of the message and can include additional
information abour the contencs.
A focus is identified by a narrow vertical shape that covers the lifeline.
The focus indicates when au object sends or receives a message.
Figure 6-19 shows a sequence diagram for the ADD NEW STUDENT use case in
the fitness center example. Note that the vertical position of each message indicates
the riming of the message.
FOCUSES:
6.8.S State Transition Diagrams
Earlier in this chapter, it was explained that state refers to an object's current status.
A state rran ~it ion diagra m shows how an object changes from one scare co another,
depending on events that affect the object. AU possible states must be documented in
the state transition diagram, as shown in Figure 6-20. A bank account, for example,
could be opened as a NEW account, change co an ACTIVE or EXISTING account,
and eventually become a CLOSED or FOR:vtER account. Another possible stare for a
bank account could be FROZEN, if the account's assers are legally anached.
(....,..... J:gi ( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,...... .,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
__.~~ c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
P hase 2
Systems A nalysis
193
6.8 The Unified Modeling language (U ML)
Request
fitness-class
Focus
I
I
I
I
I
I
I
I
I
I
I
Check
I
I
I
I
I
I
Notify
I
Pay
Register
*
FIGURE 6- 19 The sequence diagram for the ADD NEW STUDENT use case.The use case
dcscripdon for ADD NEW STUDENT Is shown in Figure 6-13.
Bank closes account
Opens
account
Makes l1rst
deposit
Customer closes account
Act
Existing
Assets
attached
Frozen
FIGURE 6 -20 An example of a sate crans1don diagram for a bank account.
ln a state transition diagram, the states appear as rounded rectangles with the
stare names inside. The small circle ro rhe left is rhe initial stare or rhe point where
the object first interacts with rhe system. Reading from left ro right, the lines show
direction and describe the action or event that causes a transition from one state to
another. The circle at the right with a hollow border is the final state.
6.8.6 Activity Diagrams
An acti\ity diagram resembles a horizontal flowchart that shows rhe actions and
evenrs as they occur. Activity diagrams show the order in which rhe actions rake
place and identify the outcomes. Figure 6-21 shows an activity diagram for a cash
withdrawal ::it an ATM machine. Note that the customer initiates the activity by
inserting an ATM c::ird and requesting cash. Activity diagrams also can display
multiple use cases in the form of a grid, where classes a re shown as vertical bars and
actions appear as horizontal arrows.
Sequence diagrams, state transition diagrams, and activity diagrams are dynamic
modeling tools that can help a systems analyst understand how objects behave and
interact with the system.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 6
Object Modeling
6.8 The Unified Modeling Language (U ML)
194
Card is
Customer
accepted
Custom41r
enters PIN
Inserts
ATM card
PIN ts
accepted
Customer
requests
~sh
Sufficlenl funds available
ATM
ATM
provides
ltd Justs
balance
cash
Sufficient funds nol available
ATM
notifies
customer
FIGURE 6-2 1 An activity diagram $howing the a.ction$ and evcnrs Involved In wlLhdrawlng cash from an ATM.
6.8. 7 Business Process Mode ling
In addirion to sequence diagrams and acrivity diagran1s, business process modeling
(BPM) can be used to represent the people, events, and interaction in a system. BPM
initially was discussed in Chapter 4 as a requircmenc diagramming tool, bur ir can be
used anytime during tbe systems development process. BPM works well with object
modeling, because both methods focus on the actors and the way they behave.
There arc a number of cools supporting BPM. For example, on Windows, the
Bizagi N!odclcr rool supports business process modeling and simulation using the
standard BP:tvl notation. On the w1ac, Visual Paradigm supports the creation of BP.M
diagrams {and several other modeling notations). Figure 6-22 shows a sample BPM
for an online discussion cycle.
~
Tl·-·
0••.
l'M•WflftN
Ollcv.on
Nt .. , . . .
•
...........
u-- -i ,,__
,_
r ..a;. .
~__,.i o--
.....
....
...
•
•
~
1--M')
.... ' _
,.. 111.
1oc• . -.......... .
IYOu9" • • Of c•••
- ....
.....,_
....
..
c .,,..nc. c.. 1----"
.,__
FIGURE 6-22 A BPM for an online discussion cycle.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
- Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
- ·~• -fllllie<'f •,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---t fta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-.. • ~-".....-""'*"....,.._...,.. ..
I'
I
I
Phase 2
Systems Analysis
6.10 Summary
6.9 TOOLS
Object modeling requires many types of diagrams to represent the proposed
system. Creating the diagrams by hand is time consuming and tedious, so systems
analysts rely on tools to speed up the process and provide an overall framework for
documenting the system components. In addition, cools ensure consistenq' and provide common links so that once objects are described and used in one pare of the
design, they can be reused mulriple times without further effort.
There arc many CASE tools tailored to UML. Tools such as Visio are popular for
drawing UM L diagrams, but they lack semanrics: T hey are useful for creating visually
pleasing figu re , but they have no knowledge of the underlying artifacts. This means a
system~ analyst can create diagrams tha t appear co be correct but are in fact incorrect
when it comes to rhe rules of the UM L.
To overcome this shortcoming, proper systems modeling tools, such as Cameo
Systems Modeler or IBM's Rational product fami ly, are typically used. These rool
underlttand t he meaning of the diagrams they hel!P create, wh ich suggests it's difficult to create a UM L diagrnm that is syntactically incorrect. These tools al!.o provide
traceability, an importa nt feature in the SDLC tha t links design a rtifacts backward ro
requirements a nd fo rward to development a nd testing.
Your company sent several staff members for UML training by an outside vendor.
Everyone who attended the training received a copy of the instructor s materials. which
included study guides and sample exam questions and solutions.
After completing the training course, you are eligible to sit a certification exam. If you
pass the exam, you will be credentialed as a "UML Expert" by an independent agency. You
can parlay these credentials into a higher salary and boost your career.
A coworker who did not attend the training asks for a copy of the training materials.
He wants to take the exam without "wasting his time in class." Should you give him a
copy of the training materials1 If you do, how might this diminish your accomplishments?
If you don't. would you be hurting the team by not helping another member become more
knowledgeable about the UMU
6.10 SUMMARY
T his chapter introduced object modeling, which is a popular technique th::it
describes a system in terms of objects. O bjects represent real people, places, events,
and rransactions. Unlike structured a nal ysis, which treats da ta and processes
separately, objects include data and processes t hat can affec t the data. During the
i.mplemenrntion process, systems analysts and programmers transform objects into
program code modules that can be optimized, tested, and reused as often as necessary.
0-0 terms include arrributcs, methods, messages, and classes. Attributes arc
characteristics that describe the object. Methods a re tasks or functions that the object
performs when it receives a command co do so. O bjects can send messages, or commands, that require other objects to perform certain methods, or tasks. The concept
that a message gives different meanings to different objects is called polymorphism. An
object resembles a black box with encapsulated, or self-contained, data and methods.
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~... . ... .,...~ • ........._ . ....._.,.,.. o-... ..,._.,,.,.. _ ..,.~ ,........., ................. .._... .., .,. ..,.~"
................... ..., ...................... .... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
195
Chapter 6
Object Modeling
6.10 Summary
196
Classes include objects that have similar attributes, or characteristics. Individual
members of a class are called object instances. Objeccs within a class can be grouped
into s ubclas~es, which are more specific categories within the class. A class also can
belong to a more general category called a superclass.
Afrer identifying the objecrs, classes, and relationships, an object relationship diagram is prepared chat hows the objecrs and how chey interact co perform business
fun crions and cransacrions. The Strongest relationship between object~ is inheritance.
The UML is a widely used method of visualizing and documenting an information system. UML techniques include use cases, use case diagrams, class diagram~,
sequence diagrams, state transition d iagrams, and activity diagrams.
A use case describes a business situation initiated by an actor, who interacts with
the information system. Each use case represenrs a specific transaction, or scenario.
A use case diagram is a visual summary of related use cases within a S)'Stem or subsystem. A class diagram represents a detailed view of a single use case, showing the
classes that participate in the underlying business transaction, and the relationship
among class instances, which is called cardinality. A sequence diagram is a dynamic
model of a use case, showing the interaction among classes during a specified time
period. Sequence diagrams include lifelines, messages, and focuses. A sta te transition
diagra m shows how an object changes from one state to another, depending on events
that affect the object. An activity diagram resembles a horizontal flowchart that
shows accions and events as they occur in a system.
In addition co object models, business process modeling (BPM) can be used ro represenc the people, evencs, and interaction in a sysrem.
CASE tools provide an overall framework for system documentation. CASE cools
can speed up rhe development process, ensure consistency, and provide common links
that enable reuse during 0 -0 analysis.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
I
Phase 2
Systems Analysis
197
Key Terms
Key Terms
acti\lt) J1<lgram A diai,-ram rh<lr re-.emble!> a borizonral flowcbarr chat •how~ the acnon; and eveni- 3\
the) occur. Act,.lt) diagram; sho" the order in which acno11> rake place and idennf) the out~ome.
actor An external emit) wnh a spectfic role. In a use case model. actors are used to model mtcran1on
with the system.
aunbutc A sm1dc char.icrensnc or fact about an ennty. An annbuce, or field, 1s the smallest p1«e of d.ua
that has meaning wnhm an informanon srstcm. For example, a Social Security number or company
o.ime could be examples of an anribute. In 0-0 analysis, ao attribure is parr of a d.t~s diagram that
describes the -.haractensuc, of ob1ccts in the class. Also kno" n as a data element.
black box A metaphor for a proces' or an action thar produces resulr; in a nun-tramparent or
non-ob,ervablc manner. In daca flow diagram,, a proces~ appears as a black bo" where chc input,,
output,, and 11cncral fonction of the procc\S arc known, but the undcrlyini; dcta1b arc nor ,hown.
cardinal1C) A concept that dc•cribe< how m<tancc• of one entity rdarc to imtancc< of nnuthcr cnmy.
De,eribcd in cntiry· rcl arion~hip dinwams by notation chm indicates comhination~ that include 1ero or
onc· to· mnny, onc·lo-onc, and many-ro·mnny.
child ln i.11herit.1nce, J child is 1he object thar derives one or more arrribuces from another object, called
tbe parem.
cl.ISS A cerm used 111 ob1ecc-or1e11red modelmg ro indic.1te a collection of snrul.ir ob1ec1s.
da,., dia11ra111 A detailed view of a ,inglc U'>c ca•c, ,howing rhc da,~ char parcicipatc in the U'>c ca'>C,
.md dc,.:umcnrini; rhc rclatinn•hip among rhc da<<es.
cncap,ulatoon The idea that all data and methods arc self-contained, as in a black bo"<.
focus In a sequence diagram, a focus md1carcs when an objecr sends or rec(wes a message. It 1s indicated
b) a narrow vertical rcctJngle thJt co,ers the lifeline.
iobcric.tncc At) pe of object relationslup. Inheritance enables an object to derive one or more of its
.i.tmbute~ from another objecc (t.g., an INSTRUCTOR object may lllhecit man) traus £rom che
L/\11'LOYll ob1ecr, such as hire dare).
in.,~n.:c A ,pcc1fic member of a da>s.
lifeline In a \cqucn"c diagram, a lifeline 1s u..cd ro represent the time during which rhc ob1c<t above it i~
able to mrcract with rhc orhcr objccrs in rb<" u..c ca<e. An X marks rhc end of a hfchnc.
message An 0 -0 command thac cells an ob1ec:t ro perform a certain method.
mcchod Defines sp«1fic casks chac an object must perform. Describes what and how an obiccr does
something.
object RepreM:nt\ a real person, place, C\'ent. or transaction.
objecc model Dc~crihe~ oh1ecr~, which combine darn and processes. Object models are chc cnJ produce
of O·O ana lybb.
objecc-orienced (0 -0 ) anJly~i; Describes an lnformarion system by idenrifymg things called objects.
An ob1ect reprc,cnt~ a real per<oon, place, evenr, or cransacnon. 0-0 :tnalysis is .1 popular appro,tch
that sees a ~ystem from the viewpoinr of rhc objecrs themselves ,1s they function and interact w1rh 1he
system.
parent Ill i11herirnncc, n parent i~ the objecr from which the other object, the child, derives one or more
Jttnbucc>.
polymorphm11 The con~cpt chat a me...age gives different meanings ro diffcrcm ob1cc1s (e.g., a GOOD
NIGi IT message m1ghr produce different rcsulrs depending if it 1s received by a child or the family
dog).
rclatiomhip<> Enable objccr' to communicate and inreract a~ rhey perfonn rhe btmncs' funcnoM and
transaction; required by a syo;tcm. Relationships describe wbar objects need to kno\\ abouc each other,
~ JD» (".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_ ._.... ~~
...
. ..............
_ .... ~---11rt~
-,..~---~ ~
.... . _
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Chapter 6
Object Modeling
Key Terms
198
how ob1ec1s r~pond to changes in orher objecrs, and 1he effccrs of mcmbcnh1p m classes, superdasscs. Jnd subclasses.
~cqucncc diagram A diagram rhat sho\\ s tht> timing of transactions bcrwcen ob1ccrs as 1he) occur.
\late An aJ1e~ri•e that de...:ribe; an oh1ecc's current scaru; (e.g., a ;rudmt could be a CURRENT,
rlITURF, or PAST ~1udenr).
•talc tr;m\ltmn J1a11ram !>how' how an oh1cct cbani:"-' from one \tat.: to another, depending on 1he
cvcnc- that affe<:t the object.
subclas\ A funhcr d1v1s1on of oh1ecrs m a class. Subclasses are more ~pccific categories w1rh1n a class.
superclass A more gener.1liicd category ro which objects may belong (e.g., a NOVEL cl.1ss might belong
10 J superclass called BOOK).
W\lcm boundary Shows wha1 is included and excluded from a >yMem. Depicted by n ,haded rccrangle
in u...: ca'c diagram>.
Unified M0Jdm1o: Lm11o:ua)lc (UML) A wicldy used method of vi,uali1.ing and documen1ini; >of1wnrc:
'Y'tcm' dc,ii;11. UM I u'c' 0-0 design concepts, but it;, independen t of ony 'Jl«cific rrui.1ra111mini;
lnni;nngc ond can he u~ccl m describe business processes and requirement' f;cncr:tlly.
use case Represents che s1eps in a specific business function or process in UML.
use c:t~c dc~criprion A dcscnprion in UML char documems the name of the use cJsc, 1he .1ctor, a
dcscrip1ion of the use case, a s1ep-by-srep lisc of the tJsks required for successful completion, and
01her key descnpnons and assumptions.
uw c;hc diai;r.:tm A vi,ual repre..enrarion chat illusrrare-. the interacuon between U'>e" anJ rhe
i11format1on 'l'rcm in UM!..
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
...............
_ .... ~---11rt~
-,..~---~ ~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
I
Phase 2
Systems Analysis
Exercises
Exercises
Questions
I. Whar 1s 0-0 analysis?
1. Define an ob1ect in an information system and provide rhree examples.
3. Define an attribute and provide rhrcc examples.
4. Define a method and provide rhree examples.
5. Define e11caps11/atio11 and explain how ir is used in 0-0 analysis.
6. Define a class, subclass, and superclass and provide rhree examples of each.
7. Explain rhe concept of inherirance in object relationships.
8. Draw an object relationshi p diagram for a rypical library system.
9. Define a use case and a use case diagram and prepare a sample of each.
I 0. Why is ir imporranr co use a modeling rool a nd nor just a diagramming rool
during 0-0 analysi~?
Discussion Topics
I. You arc an IT consulranr, and you arc asked co create a new sysrem for a small
real esrarc brokerage firm. You have no experience with 0-0 approach, and you
decide co rry ir. How will you begin? How will the tasks differ from ~rrucrurcd
analysis?
1. Some professionals believe char ir is harder for experienced analy~rs ro learn
object-modeling rechniques, because the analysts are accustomed to thinking
abour data and processes as separate entities. Ochers believe that ~olid analytical
skills are easily transferable and do not see a problem in crossing over ro the
newer approach. Whar do you chink, and why?
3. The concept that rhe same message gives different meanings ro different ob1ects
is called polymorphism. Can you chink of examples where this behavior may
provide une'<pected results?
4. You arc crearing a sysrcm for a bowling alley to manage information about its
leagues. During rhe modeling process, you create a scare transition diagram for
an objecr called League Bowlers. \Xl'har are rhe possible scares of a league bowler,
and what happens to a bowler who quits rhe league and rejoins the following
season?
5. The UML is a large and complex modeling language. How can an IT profc~sional
tell when a UML diagram is correct and nor just visually plea~ing?
Projects
l. Contact the IT htaff ar your school or ar a local business to learn if they use 0-0
programming languages. lf so, determine what languages and versions are used,
how long they have been in use, and why they were selected.
2. Create a prcscnrnrion explaining 0-0 analysis, including definitions of basic
terms, including objects, attributes, methods, messages, and classes.
3. Draw an acriviry diagram showing rhe actions and evenrs involved in depositing
a check to a bank accounr using a mobile app.
4. Investigate business process modeling languages, such as BPEL.
5. Prepare a report on at lease three cools char provide UML support. Use the
tools' capah1liries for crearing class diagrams and sequence diagrams as a key
requ1remenr.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
199
Chapter 7
Development Strategies
Development
Strategies
Cha pt e r 7 is the final chapter in the systems
analysis phase of the SDLC. The main objective of
the systems analysis phase is to build a logical model
of the new information system. Chapters 4, S, and 6
explained requirements modeling. data and process
modeling. and object modeling. Chapter 7 describes
the remaining activities In the systems analysis phase,
which include evaluation of alternative solutions,
preparation of the system requlremenu document,
and pre.s entation of the system requirementS
document to management. The chapter also explains
the transition to systems design.
The chapter includes three "Case in Point"
discussion questions to help contextualize the concepts
described in the text. The "Question of Ethics" concerns
how truthful an answer should be when submitting a
response to an RFP. Is a slight exaggeration acceptable if
it means the company will win the contract!
LEARNING OBJECTIVES
W/Jen you finish tbis chapter, you sl101tld be able
to:
CONTENTS
l. Explain the differences between traditional and
web-based S)Stems development
2. Explain how Web 2.0, cloud computing, and
mobile devices may affect systems development
3. Explain how to selecr one of the four in-house
:.oftware development options
4. Explain outsourcing
5. Explain the main advanrages and the unique
concerns of off:.hori ng
6. Describe rhe concept of Sofrware a~ a Service
7. Explain how a systems :rnalysr helps in selecting
a development strategy
8. Execute the five steps in the software acquisition
7. 1 Traditional Versus Web-Based Systems
Development
7.2 Evolving Trends
7.3 In-House Software Oevelopmenc Options
Case in Point 7 .1: Doug·s Sporting Goods
7 .4 Oursourcing
7 .5 Offshoring
Case in Point 7.2: Turnkey Services
7 .6 Software as a Service
7 .7 Selecting a Development Strategy
Case in Point 7.3: Sterling A~sociares
7.8 The Software Acquisition Process
7.9 Completion of Systems Ana lysis Tasks
A Question of Ethics
7.10 Summary
Key Terms
Exercises
process
9. Describe a requesr for proposal (RFP) and a
request for quotation (RFQ)
I 0. Summarize the rasks involved in completing the
sr stems analysis phase of rhe SDLC
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~....... .,...~ • ........._ . ....._.,.,.. o-... ..,._.,,.,.. _ ..,.~ ,........., ................. .._... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
Phase 2
Systems Analysis
201
7.1 Trad itional Versus Web-Based Systems Development
7.1 TRADITIONAL VERSUS Wee-BASED SYSTEMS DEVELOPMENT
]use a few years ago, a rypical company either developed software itself, purchased
a software package (which might need some modification), or hired consulcants or
outside resources to perform the work. Today, a company has many more choices for
software acquisition, including application service providers, web-hosted software
options, and firms that offer a variety of enterprise-\vide software solucions. This proliferarion of choices is due in part due to the enormous changes in business methods
and operarions made possible by the Internet.
A systems analyst must consider whether development will cake place in a rra·
ditional environment or in a web-centric framework. There are similarities and differences with both approaches. For example, in an Internet-based sy~tem, the web
become~ an inregral parr of the application, rather than jusr a communication channel, and systems analysts need new applicarion development tools and &olutions tO
handle the new systems.
Two represenrarive web-based development environmenrs are M icrosoft's .NET
and rhe open source MERN stack. Microsoft describes .NET as a developer platform for building and running a variety of applica tion types written in C# and
Visual Basic, including web-based, mobile, and traditional deskrop applications.
The acronym M ERN srands for MongoDB, Express, React, and Node. MERN
is used to develop universal applications in JavaScript. MongoDB is a darabase,
and Express, React, and Node arc libraries or frameworks used for full -srack web
development.
Although cherc is a major trend toward web-based architecture, many firms rely
on traditional systems, either because they arc using legacy applications that arc not
easily replaced, or because they do not require a web component to satisl) user needs.
To choose berween traditional and web-based development. consider some key differences between them. Building the application in a web-based environment can offer
greater benefits (and sometimes greater risks) when compared to a traditional environment. The following sections list some characteristics of traditional versus webbased development.
7. 1. 1 Traditional D evelopment In a t.radit.ional systems development.
environment.
•
•
•
•
•
•
•
Compatibility issues, including existing hardware and software platforms and
legacy system requirements, influence systems design.
Systems arc designed to run on local and wide-area company networks.
Systems often utilize Internet links and resources, but web-based featu res arc
treated as enhancemen ts rather than core elements of the design.
Development rypically follows one of three main paths: in-house development,
purchase of a boftware package with possible modific~Hion, or use of outside
consulta nts.
Scalability can be affected by network limitations and constraints.
Nlany applications require subsranrial desktop computing power and resources.
Security issues usually arc less complex than with web-based systems,
because the system operates on a private company network, rather than the
Internet.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
--
........... ......
"'Allf'W ~- .............. . ,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
__....
~~·~---- ···---~~-.,.-"~
Chapter 7
Development Strategies
7.2 Evolving Trends
202
7.1 .2 W eb-Based Development: In a web-based system s development
e nvironme nt
•
•
•
•
Systems arc developed and delivered in an Lncerncr-ba~d framework such as
.NET
lnrernet-bascd development rrears the web as rhe platform, rather than just a
communication channel.
Web-based systems are easily scalable and can run on multiple hardware
environments.
Large firms rend to deploy web-based sysrems as enterprise-wide software solutions for applications such as customer relationship management, order processing, and materials management.
•
Web-based software treats the software application as a service that is less
dependent on desktop computing power and resources.
•
When companies acquire web-based software as a service rather than a product
rhey purchase, they can limit in-house involvement and have rhe vendor insrall,
configure, and mainrain the system by paying agreed-upon fees.
•
Web-ba~ed softwa re us ually requires additional layers, called midd leware, to
commun icate with existing software and legacy systems.
•
Web-based solutions open more complex security issues that should be addressed.
7.2 EVOLVING TRENDS
In the consrantly changing world of IT, no area is more dynamic than lnrerner rechnology. Three examples of evolving trends arc Web 2.0, cloud compuring, and mobile
devices. Sysrems analysts shouJd be aware of these trends and consider them as they
plan large-scale sysrems.
Many IT professionals use the term \''cb 2.0 ro describe
a second generation of the web rhat enables people ro
NIST Cloud Computing Program - NCCP
collaborate, interact, and share information much more
effectively.
This new environment is based on conrinuously
DESCRIPTION
available user applications rather than Static HTJ\-1 L wcba.....,...i......
.......................
,
pages, wirhour limitations regarding rhe number of users o r
""""""....,..n..,...,••.
how they access, modify, and exchange data. The Web 2.0
NIST Cloud environmenr enhances interactive experiences, including
,
wikis and biogs, a nd social networking applications such as
Computing
Facebook, Linkedln, and Twiner.
....
fltolt•
Program
As shown in Figure 7- 1, the Nationa l Institute of Stanllltl'Klloa. TNldeuf
dards and Technology (NIST) defines cloud computing as
. . . ~.,"" ....... ~ . . . . . . . Will
"""*'
18M(f ........... "'*"" .......
.......Cf. . . . .
.. .
"a model f or enabling ubiquitous, convenient, o n-demand
••• """9(P'HSi,a-. ...
•• ...... tM-S ......
...................
.... hlkm.tlJl!rtiN ....
........
network access ro a shared pool of configurable computing
....,.,.. -....111• ...... .........,ta ........... ........,. ....... ........_ ... ca
resources (e.g., networks, servers, storage, applications, and
._,...,.nm..,..........
services) chat can be rapidly provisioned and relea ed with
llirClilwf~ . . . . ~"'~- ................................ ...
....._ •• __............. _......,.,._......,. ... w,,....,..,.
minimal management effort or service provider interacrion."
...............-.c...--................................ Ml'W"
............................................
_,a...
Cloud computing is often represented by a cloud symbol
.........
.......... WI*" • • kll .... ,.,...... . . . . . . .
..,.._.
that indicates a network or the Internet. Cloud computing
can be viewed as an onlioe SaaS and data environment supFIGURE 7- 1 NIST definition of cloud computing.
ported by powerful computers that makes Web 2.0 possible.
5-«< "'
..
........___,..,........ ...
.. ......
---.-_
~,.......,.
~
~ ..... !'@I. . . . .
--~,...~
Wwt.f~
~,_
~ CS...S~ C..."*'"
l#IW• ......
l(Q1l.
~~
~
~
~
......_.~
..............
~.._.
• ._..,..
0w.,,,.._._,..." ....... ,_,.,..,....,. -~,__.., ,,.......... ~~ij
(....,..... J:gl( . . . . . , _ , . . 41 11.,.. ~-""'_..,.Olp"
-·~·-"*<'f•,...
..,...,.......,..~
t11ru . . __.~~c.....,..~
r..a...w...,..._...., ..
.................
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
P hase 2
Systems A nalysis
203
7.3 In-House Software Development Options
Mobile device~ have become ubiquitous. Smartphones and tablets are now found
in personal use and across the enterprise in most organizations. Today's mobile
devices have enough computing power to provide processing "at the edge," which
means at the end of a network, in rhe user's hands. Developing apps for mobile
devices requires many new platforms, although many of today's development tools
support web-based and mobile application development at the same time.
7 .3 IN-HOUSE SOFTWARE DEVELOPMENT OPTIONS
A compan)' can choose to develop its own systems or purchase (and possibly customize) a sofrw:ire package. These development alternatives arc shown in Figure 7-2.
Although many factors influence this decision, rhe mosr important consideration is
rhe total cost of ownership (TCO), which was explained in Chapter 4. In addition to
rhcse options, comp:inies also develop user applications designed around commercial sofrw:ire packages, such as Microsoft Office, ro improve user productivity and
efficiency.
In-house syslem
software
Commercial
soltware
padtage
FIGURE 7-l Instead of outsourcing.a company can choose co develop a system in-house or
purchase and possibly aJstomize a commercial package..
7 .3. 1 Make or Buy Decision
The choice between developing ver[>uS purchasing software often is called a make
or buy, or build or buy, decision. The company's IT department makes, builds, and
develops in-hou\e \Oftware. A software package is obtained from a vendor or an
application service provider.
Tht: package might be a standard commercial application or a customized package designed specifically for the purchaser. Companies that develop f>ofrware for sale
are caUed software vendors. A firm that enhances a c.:ommercial package by add ing
custom features a nd configuring it for a panicular industry is called a value-added
reseller (VAR).
Software package~ are available for every type of business activity. A software
package that can be used by many different types <>f organizations is called a horizontal
application. An accounting package is a good example of a horizontal application
because man)' different businesses or separate divisions that exist in large, diversified
companies can utilize it.
In contrast, a software package developed co handle information requirements for
a specific type of business is called a vertical application. For example, organizations
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
--
........... ......
"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ..... ...... ... ~..
__....
~~·~---- ···---~~ - .,.-" ~
Chapter 7
Development Strategies
7.3 In-House Software Development Options
204
with special system requirements include colleges, banks, hospitals, insurance companies, construction companies, real estate firms, and airlines. Figure 7-3 shows a
typical restaurant point of sale (POS) system running on various devices. The organi7ations may need verrical applications to handle their unique business requirements
bur often use horizontal applications for basic business needs, such as payroll proce sing and accounts payable.
Thousands of Restaurants Use Restaurant Manager
Tne POS of Chc><ce f0t Restauronts for Neosty 30 Yeors
FIGURE 7-3 Restaurants use vertical applications like point of sale (POS)
systems to support their unique business requirements.
Sour<e; .- •
Of the in-house software acquisition options-developing a sy rem, bu) ing a
software package, or customizing a software package-each ha~ advantages, disadvantage~, and cosr considerations, as shown in Figure 7-4. These l>Ofrware acquisition
options are described in detail in the following sections.
REASONS FOR IN-HOUSE
DEVELOPMENT
REASONS FOR PURCHASING A
SOFTWARE PACKAGE
Saosfy unique business requireme nts
Lower costs
Minimize changes in business procedures
and policies
Requires less time to implement
Meet constraints of existing systems
Proven reliability and performance
benchmarks
Mee t constraints of existing technology
Requires less technical development staff
Develop Internal resources and capabilities
Future upgrades provided by the vendor
Satisfy uniqu e security requirements
Obtain input from other companies
FIGURE 7-4 Companies consider various factors when comparing in-house development with the purchase of a
software package.
7.3.2 Developing Software In-House
\Vith an enormous va riery of software packages available to handle horizontal
and vertical business operations, why would a firm choose to develop its own software? Typically, companies choose in-house development to satisfy unique business
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
Phase 2
Systems A nalysis
205
7.3 In-House Software Development Options
requirements, minimize changes in business procedures and policies, meet constraints
of existing systems and existing technology, and develop internal resources and
ca pa biliries.
Companies often decide to de velop
software in-house because no commercially available software package can meet
their unique business requirements. A college, for example, needs a course scheduling
system based o n curriculum requirements, student demand, classroom space, and
available instructors. A package delivery company needs a system to identif>• the
best combination of routes and loading panerns for the company's fleet of deliver y
trucks. If existing software packages cannot handle those requirements, then in-house
developed sofcware might be the only choice.
SATISFY UNIQUE BUSINESS REQUIREMENTS:
MINIMIZE CHANGES IN BUSINESS PROCEDURES AND POLICIES: A company
also might choose to develop its own software if available packages will require
changes in current business operations or processes. lnstalling a new software
package a lmost always requires some degree of clhange in how a company docs
business; however, if the insta llation of a purchased package wil l be too disruptive,
the organization might decide to develop its own software instead.
MEET CONSTRAINTS OF EXISTING SYSTEMS: Any new software installed must
work with existing systems. For example, if a new budgeting system must interface
with an existing accounting system, finding a sofrware package that works correctly
with the existing accounting system might prove difficult. If so, a company could
develop its own software to ensure that the new system will interface with the old
system.
MEET CONSTRAINTS OF EXISTING TECHNOLOGY: Another reason to develop
software in-house is chat rhe new system must work with existing hardware and
legacy systems. That could requi re a custom design, an upgrade ro the environment,
or in-house sofrware that can operate within those constraints. A systems analyst
addresses the issue of technical feasibiliry during the preliminary investigation. Now,
in the sy~tems analysis phase, the analyse muse determine whether in-house software
develo pment is the best overall solution.
DEVELOP INTERNAL RESOURCES AND CAPABILITIES: By designing a system
in-house, companies can develop and crain an IT staff who understands the
organization's business functions and information support needs. Many firms feel
that in-house IT resources and capabilities provide a competitive advantage because
an in-house ream can respond quickly when business problems or opportunities arise.
For example, if a company lacks internal resources, it must depend on an outside fi rm
for vital business support. Also, outsourcing options might be actraccive, but a series
of shore-term solutions would nor necessarily translate into lower TCO over the long
term. Top managers often feel more comfortable with an internal IT team to provide
overall guidance and long-term stability. In-house development also allows a firm co
leverage the skill set of the IT team, which is already on board and being compensated.
7.3.3 Purchasing a Softwa.r e Package
If a companr decides no t to o utsource, a commercially available software package
might be an attractive alternative co developing irs own software. Advantages of purchasing a software package over developing soft·Nare in-house include lower coses,
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 7
Development Strategies
7.3 In-House Software Development Options
206
less rime to implement a sysrem, proven reliabiliry and performance benchmarks, less
technical development staff, future upgrades chat are provided by the vendor, and
the ability to obrain input from other companies who already have implemented the
software.
LOWER COSTS: Because many companies use software packages, software vendors
spread the development costs over many customers. Compared with software
developed in-house, a software package almost always is less expensive, parricularly
in terms of initial i11vesnnent. However, even though the initial cost is less, purchased
software can involve expenses caused by business disruption, changing business
processes, and retraining employees.
REQUIRES LESS TIME TO IMPLEMENT: When a software package is purchased,
it already has been designed, programmed, rested, and documented. The in-house
rime normally spent on those tasks, therefore, is eliminated. Of course, rhe
sofrware must still be installed a nd integrated into the systems environment,
which can rake a significant amou nt of time. Also, even though implementation
is quicker, TCO ca n be higher due to added training expenses and softwa re
modifications.
PROVEN RELIABILITY AND PERFORMANCE BENCHMARKS: If the package has
been on the market for any lengcb of rime, any major problems probably have been
detected already and corrected by the vendor. if the product is popular, it almost
certainl y has been rated and evaluated by independent reviewers.
REQUIRES LESS TECHNICAL DEVELOPMENT STAFF: Companies that use
commercial software packages often are able to reduce the number of programmers
and systems analysts on the IT sraff. Using commercial software also means that
the IT staff can concentrate on systems whose requirements cannot be satisfied by
software packages.
FUTURE UPGRADES PROVIDED BYTHEVENDOR: Software vendors regularly
upgrade oftware packages by adding improvements and enhancements to create a
new ve rsion or release. A new release of a software package, for example, can include
drivers ro support a new laser printer or a new type of data srorage technology.
In many cases, the vendor receives input and suggestions from current users when
planning future upgrades.
INPUT FROM OTHER COMPANIES: Using a con11nercial software package means
that users in other companies can be contacted ro obtain their input and impressions.
Tryi ng rhe package or making a site visit to observe the system in operation may be
very usefu l before a final decision is made. Companies can make use of user groups ro
share experiences with a software package.
7.3.4 Customizing a Software Package
lf the standard version of a software product does not satisfy a company's requirements, the firm can consider adapting rbe package to meet its needs. Three ways to
customize a software package are as fo llows:
•
Purchase a basic package that vendors will customize to suit the project's
needs. Many vendors offer basic packages in a standard version with add-on
components rhat are configured individually. A vendor offers oprions when the
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
Phase 2
Systems A nalysis
207
7.3 In-House Software Development Options
•
•
standard applicarion will nor sarisfy all customers. A human resources informarion sysrem is a rypical example, because each compan)' handles employee
compensation and benefics differently.
1 cgotiatc directly with rhe software vendor to make enhanccmcntS to meet the
project's needs by paying for the changes.
Purchase the package and make project-specific modifications, if this is permissible under the rerms of the sofrware license. A disadvantage of this approach is
that srsrems analysrs and programmers might be unfamiliar with rhe sofnvarc
and will need time to learn the package and make the modifications correctly.
Addirionally, some advanrages of purchasing a standard package disappear if
the product must be cusromized. If the vendor does the customizing, the modified
package probably will cosr more and rake longer ro obrain. Another issue is fururc
support: Although vendors regularly upgrade their standard software packages, rhey
might not upgrade a customized version. In addition, if the modifications are done by
the company purchasing the sofrwarc, when a new release of the package becomes
available, the company might have to modify the new version on it~ own, because the
vendor will not support modifications installed by the customer.
7 .3.S Creating User Applications
Business requirements sometimes can be fulfilled by a user application, rather th;in a
formal information system or commercial package. User applications arc examples of
user productivity systems, which were discussed in Chapcer 1.
A user applicalion utilizes standard business s<>ftware, sucb as Microsoft Word or
Microsoft Excel, which has been configured in a specific manner to enhance user productiv1ry. For example, to help a sales rep respond rapidly co customer price requests,
an IT support person can sec up a form letter with links to a spreadsheet chat calculates mcencives and discounts. ln addition to configuring the sofnvare, che IT staff can
create a user interface, which includes screens, commands, concrols, and features that
enable users to interact more effectively with tbe application.
In some siruauons, user applications offer a simple, low-cost solution. Mosr IT
departments have a backlog of projects, and IT solutions for individuals or small
groups do not always receive a high priority. At the same time, application software
is more powerful, flexible, and user-friendly than ever. Companies such as Apple
and Microsoft offer software suites and integrated applications that can exchange
dara with programs that include rurorials, wizards, and H elp features to guide lessexpericnced users who know whar they need to do but do not know how to make it
happen.
Many companies empower lower-level employees by providing more access to dara
and more powerful data management tools. The main objective is co allow lower·
level employees more access ro the data rhey rcqUJire to perform their jobs, with no
intervenrion from the IT department. This can be accomplished by creating effecrive
user interfaces for company-wide applications, such as accounting, inventory, a nd
sa les systems. Another technique is to customize standard productivity software,
such as Microsoft \'Qo rd or Nlicrosofc Excel, ro create user applications. In either
case, empowerment makes the IT deparrment more productive because ir can spend
less time responding to rhe daily concerns and da{a needs of users and more rime on
high-impact systems development projects rhat support strategic business goals.
Empowerment reduces costs and makes good business sense, but Companie
chat adopt this approach muse provide the technical support that empowered users
require. In mo~t large- and medium-sized companies, a sen ice d~k within the IT
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapte r 7
Development Strategies
7.4 Outsourcing
208
deparnnenr is responsible for providing user support. The service desk offers services
such as hotline assistance, training, and guidance to users who need technical help.
Users typically requ ire spreadsheets, dacabase management programs, and other
software packages to meet t heir information needs. If user applications access corporate data, appropriate controls must be provided to ensure data security and integrity.
For example, some files should be hidden totally from view; other-; should have readonly properties, so users can view, bur nor change, the data.
CASE lN POINT 7.1:
Douc's S1•0RTING Goons
Doug's Sporting Goods sells hiking and camping supplies. The company has grown considerably
in the past tw0 years. They want to develop a customer order entry system and hired your
IT consulting firm to advise them about development strategies. They are leaning toward
in-house development because they do not want to depend on outside vendors and suppliers
for technical support and upgrades. They also S'irf they are not interested in selling on the Web,
but that could change in the future. They want to meet with you tomorrow to make a decision.
What will you say to them ac the meeting?
7 .4 OUTSOURCING
Outsourcing is the transfer of information sysrems development, operation, or maintenance roan outside firm char provides these services, for a fee, on a temporary or
long-term basis. Outsourcing can refer co relatively minor programming tasks: renting
software from a service provider, outsourcing a basic business process (often called
business process outsourcing, or BPO), or handling a company's enrire IT function.
7.4. 1 The Growth of Outsourcing
T raditionally, firms out~ourced IT tasks as a way of controlling coses and dealing \vith
r:ipid technologica l change. Oracle cites data that ~hows that businesses spend up ro
80°/o of their IT budgets maintaining existing software and !>Y!>tems, which forces IT
managers " ... to spend rime managing tedious upgrade~ in~tead of revenue-generating
IT projects." \Xlhile those reasons srilJ are valid, outsourcing has become part of ::1n
overall IT strategy for many organizations. T he outsourcing trend abo has ::1ffecred
software vendors, who have adjusted their ma rketing accordingly.
A fi rm drnr offers outsourcing solutions is called a service provider. Some service
providers concentra te on specific software a pplications; others offer business services
such as order processing a nd customer billing. Still o thers offer enrerprise-w idc softwa re solutions that integrate and manage functio ns such as accounting, manufacturing, and inventory contro l.
Two popular outsourcing options involve application service providers and firms
tha t offer Internet business services. These terms are explained in the fo llo wing
sections.
APPLICATION SERVICE PROVIDERS: An application sen ice provider (ASP) is a
firm t ha t delivers a software applica tion, or access to an application, by charging a
usage or sub~cription fee. An ASP provides more than a license to use the software;
it rents an operational package ro rbe cusromer. ASPs typically provide commercially
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
I'
I
P hase 2
Systems A nalysis
209
7.4 Outsourcing
available sofrwarc such as darabases and accounting packages. If a company uses an
ASP ro supply a dara managcmenr package, for example, rhe company does nor have
to design, develop, implemenr, or mainrain the package.
INTERNET BUSINESS SERVICES: Some firms offer Internet business ~er\ ices (lBSs),
which provide powerful web-based support for transactions such a~ order proce sing,
billing, and customer relationship managemenr. Another term for IBS is managed
hosting, because the outside firm (host) manages system operations.
An IBS solunon is attracrive to customers because it offers online data center support, mainframe computing power for mission-critical functions, and universal access
via the Internet. Many firms, such as Rackspace, compete in the managed cloud services marker, as shown in Figure 7-5.
o,.."'.,..
.._.. . ..,_
........ -·
-- -- ---
,
..
•
..
.. - .. - .... ............_.._____ ........
....... __... .
VDU CllOGSf thf Clouds. Wf'll Ma~ge Tll!m for You.
~
----
----
__.....
--~----,..
--
...., .._.
_.
--
·- -
FIGURE 7-S Rackspace managed cloud services.
Sourc.1~
.o;,
7.4.2 Outsourcing Fees
Firms thar offer Software as a Service, rather rhan a product, have developed fee
structures that are based on how rhe application is used by customers during a
specific time period. Several models exist, including fixed fee, subscription, and usage
or transaction. A fixed fee model uses a sec fee based on a specified level of service
and user support. A subscription model has a variable fee based on the number of
users or workstations that have access ro the application. Finally, a usage model
or transaction model charges a variable fee based on the volume of transactions or
operations performed by the application.
When a company considers outsourcing, it should estin1ate usage characteristics co
determine which fee structure would be most desirable and tben attempt co negotiate
a service provider contract based on that model.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~----···---~~-.,.-"~
Chapter 7
Development Strategies
7.S Offshoring
210
7.4.3 Outsourcing Issues and Concerns
\'(!hen a company decides to outsource IT functions, it takes an imponant srep
rhar can affecr the firm's resources, operations, and profitability. IVlission-crirical
IT ~ystems should be oursourced only if the resulr is a cosr-anracrive, reliable
business solution that fits the company's long-term business strategy and involves an
acceprable level of risk. Moving IT work overseas raises even more issue5, including
potential concerns about control, culture, communication, and security.
In addinon to long-term strategic consequences, outsourcing also can raise some
concerns. For example, a company must turn over sensiti\'e data to an external service
provider and trust the provider to maintain security, confidentiality, and quality. Also,
before oursourcing, a company must carefully review issues relating to insurance,
porenrial liability, licensing and information ownership, warranties, and disaster recovery.
Mosr important, a company considering outsourcing must realize that the solution ca n be only as good as the outsourcing firm that provides the service. A dynamic
economy can give rise to business failures and uncertainty about the furure. ln this
climate, it is especially important to review t he history and financial condition of an
outsourcing firm before making a commionent.
Mergers and acq uisitions a lso caa affect ou tsourcing clients. Even with large,
financ ially healthy fi rms, a merger o r acq uisition can have some impact on clients and
customers. If stability is importa nt, an outsourcing client shou ld consider these issues.
Outsourcing can be especially a ttractive co a company whose volume flucruates
widely, such as a defense contractor. In other situations, a company might decide ro
outsource application development rasks to an IT consu lring firm if che company
lacks the time or expertise to handle the work on its own. Outsourcing relieves a
company of che responsibility of add ing IT sta ff in busy rimes and downsizing when
the workload lightens. A major disadvantage of outsourcing is rhar it raises emplo>•ee
concerns about job security. Talented IT people usually prefer posinons where the
firm ts commirred to in-house IT development-if they do nor feel secure, they mighr
decide to work directly for the service provider.
7 .5 0FFSHORING
Off~horing, also known as offshore o utsourcing or global out~ourcing, refers ro the
practice of shifting IT development, support, and operations to other countries. In
a trend similar to the outflow of manufacturing jobs over a several-decade period,
many firms arc sending IT work overseas.
IT work can move offshore even fasrer than manufacturing, because it is easier to
ship work across networks and put consultants on airplanes tha n it is to ship bulky
raw materia ls, bui ld factor ies, and deal with tariffs and transportation issues. Several years ago, rhe IT consul ting firm Gartner, Inc., accurately forccasted the steady
growth of offsho re outsourcing and predicted that outsourcing would evolve from
labor-intensive main tenance and support to higher-level systems development and
sofrware design.
The main reason for offshoring is the same as domestic outsourcing: lower
bottom-line co~ts. Offshore outsourcing, however, involves some un ique risks and
concerns. For example, wo rkers, customers, and shareholders in some companies
have protested this tre nd and have raised public awarenes5 of possible economic
impact. Even more important, offshore outsourcing involves unique concerns regarding project control, security iss ues, djsparate cultures, and effecrive communicarion
with critical functions rhar might be located halfway around the globe.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
I
Phase 2
Systems Analysis
211
7.7 Selecting a Development Strategy
CASE IN POINT 7.2: T URNKEY SERVICES
Tumkey Services is an ASP that offers payroll and tax preparation services for hundreds
of businesses in the Midwest. The finn is considering a major expansion into accounting
and financial services and is looking into the possibility of supporting this move by hiring IT
subcontractors in several foreign countries. Turnkey's president has asked you to help him reach
a decist0n. Specifically. he wants you to cite the pros and cons of offshoring. He wants you to
present your views at a meeting of Turnkey managers next week. How will you proceed!
7 .6 SOFTWARE AS A SERVICE
In rhe tradirional model, sofrware vendors develop and sell application packages ro
customers. Typically, customers purchase licenses chat give t hem the righr to use the
software under the terms o f the license agreement. Although this model still acco unts
for a large percentage of software acq uisition, a new model, called Software as a
Ser vice (SaaS), is changing rhe picture dramaticallly.
SaaS is a model of software deploymenr in which an applicarion is hosred as a
service provided to customers over rhe lnrerner. SaaS reduces the customer's need for
software maintenance, operation, and support. ln effect, SaaS provides the funcrionaliry the customer needs, bur without the associated development, infrasrructure, and
maintenance costs.
In a highly compentive marketplace, major vendors constantly srrive co deliver
new and bercer ltolutions. For example, J\1icrosoft claims rhat irs SaaS plarform offers
the best solution and business value. One of their more popular consumer SaaS offering!> is Office 365, shown in Figure 7-6. This is a full-Aedged version of the tvl icro~ofr
Office smce char runs in a browser window.
:!. -Offo<•
Apps
Wood
hul
Documents
Reunt
-
FIGURE 7-6 Microsoft Office 365 provides web-based access to the complete Office suite.
SOU'rc~ l"'l tn
tC' itp01·14•,,
7. 7 SELECTING A DEVELOPMENT STRATEGY
Selecting the besr development scrategy is an imporraot decision thac requires companies co consider multiple factors. The syscems analyst has an imporcant role co
play in this decision-making process. In particular, anal)'zing the coses and benefics of
each development alcernative is a key co providing objective dara co managemenc. A
cosc-benefic checklisc can help guide chis analysis.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Chapter 7
Development Strategies
7. 7 Selecting a Development Strategy
212
7.7. 1 The Systems Analyst's Role
Ac ~ome poinc in the systems developmenc process, che company mu~c decide whether
m use an oucsourcing option, develop software in-house, acquire a software package,
develop u~er applications, or select some combination of these solutions. The dcci~ion
depends on che company's currenc and anticipared future needs. It will affccc che
remaining SDLC phases and the systems anal)'St's subsequenc involvement in the
pro1ect. The decision to develop software in-house, for example, will require more
parcic1parion from the sysrems analyst than outsourcing or choosing a commercial
p:ickage. ,\lfan:igcment usually makes a determination after receiving wrinen
recommendations from the IT staff a nd a formal presentation, which is described later
in this chapter.
Even a single system can use a mjx of sofrware alternati ves. For example, a company might purchase a standard software package to process its payroll and then
develop irs own sofrware to handle tbe interface berween the payroll package and rhc
company's in-house manufacturing cost analysis system.
The evaluation a nd selection of a lternatives is not a simple process. The objective
is co obrnin the product with rbe lowest TCO, but actual cost and performance can
be difficult to forecast. When selecting hardware and software, systems analysts often
work as an evaluation and selection ream. A team approach ensures that c ritical faccors arc not overlooked and that a sound choice is made. The evalua tion and selection
ream also must include users, who \viii participate in rhc selection process and feel a
sense of ownership in the new system.
The primary objective of the evaluation and selection ream is ro eliminate system
alrcrnarivcs that will nor meet requirements, rank the a lternatives rhar arc feasible,
and present the viable alternatives to management for a final decision. The process
begins wi th a careful srudy of the coses and benefits of each alternative, as explained
in rhc following section.
7.7.2 Analyzing Cost and Benefits
Financial analysis tools have been around for a long time. From the abacu~ to the
pocket calculator, people have always sought easier ways ro work with numbers. This
section describes cost and benefit analysis and explains popular roots rhar can help a
sysrem~ an::tl)'St examine an IT project.
Chapter 2 explained rhar economic feasibility is one of rhe four feasibility
mea~uremenrs that are made during the preliminary investigation of a systems
request. Now, ar the end of the systems analysis phase of the SDLC, financial analysis
rools and rechniques must be applied to evaluate development strategies and decide
how the project will move forward. Part C of the Systems Analyst's Toolkit describes
three popular rools, which are payback analysis, return on investment (ROI ), and net
present value (NPV). Payback ana lysis determines how long it takes an information
system co pay for itself through reduced costs and increased benefits. Rclurn o n
investmenl (RO I) is a percentage rare that compares the rota! ncr benefits (the return)
received from a project to the total costs (the investment) of the project. The net
present value (NPV) of a project is the total value of the benefits minus the total
value of the costs, with both costs and benefits adjusted ro reflect the point in rime at
which they occur.
These tools, and others, can be used to determine TCO, which was described in
Chapter 4. Ar this stage, the analyst will identify specific systems development srraregies and choose a course of action. For example, a company might find char its TCO
will be higher if it develops a system in-house, compared with outsourcing the project
or using an ASP.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
P hase 2
Systems A nalysis
213
7.7 Selecting a Development Strategy
An accurate forccasr ofTCO is critical, because nearly 80o/o of roral cosrs occur
after rhe purchase of rhc hardware and software, according to Carmer, Inc. An IT
departmenr can develop irs own TCO escimares or use TCO calculation rools offered
by vendor . For example, as hown in Figure 7-7, HP Enterprise offer-; several free
TCO calcularors ro dererrnine rhe ROI of various development straregies and migration options.
You Buy Once-But You Pay for the Llfecyde
......-.....,.,._..........
................_._..
..........
..... __..______
......_____
.. ___
...........-... --...,..,,..__.....,
....... ..,-"...,
n_,._...,..,......._..,,.......,.~.,,"_._...
~
~.,.,...,_--.,.
c..~(TCD)
............
........ ............
~
...........
..
...
.. ,,...,
·~ --~
"" ...................... C*:JO ................................................ ~ .....
._..,...., .. .,...._~--.,.,. .... w
__
-
WhyS ','nd ..... TCOwtaot•: 1eM1
~~--_..-
~.-....
UM Ow R-. Mo O' l a rlun TCO -
ROI~°''
FIGURE 7-7 HP Enterprise provides se11eral freeTCO calculacon.
Sourc..: tt1
r.
H
7.7 .3 Cost-Benefit Analysis Checklist
Chapter 2 explained how ro use rhe payback analysis tool during the preliminary
invescigarion ro help determine whcrher a project is economically feasible. Now, all
the financial analy~is rools will be used to evaluate various development strategics.
The best way to apply the tools is co develop a cost-bcnefir checklist with rhe following sreps:
•
•
List each development srrarcgy being cons~dcred.
Identify all cosrs and benefits for each alterna tive. Be sure to indicate when
co~ts will he incurred and benefirs realized.
•
Consider future growth and the need for scalability.
•
Include support costs for hardware and software.
•
Analyze various software licensing oprions, including fixed fees and formulas
based on the number of users or transactions.
•
Apply the finan cial analysis rools to each alremarive.
•
Srudy the resu lt~ and prepare a report ro management.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapte r 7
Development Strategies
7.8 The Software Acquisition Process
2 14
CASE IN POINT 7.3:
STERLING A ssoclATI.S
SterlingAssociates specializes in advising dients on IT projeccs and information systems development. Marketing is creating a brochure for prospective new clients, and they want you to
develop a section that describes payback analysis, ROI, and NPV in simple tenns and mentions
the pros and cons of each financial analysis tool. How do you proceed~
7.8 THE SOFTWARE ACQUISITION PROCESS
Although each situation is different, the following section describes a rypical example
of the issues and tasks involved in software acq uisition.
Ste p I: Evaluate the Information System Re quireme nts
Based on the analysis of the system requirements, the system's key features must be
identified; network and web-related issues considered; volume and future growth estimated; any hardware, software, or personnel constraints specified; and an RFP or a
quotation prepared.
IDENTIFY KEY FEATURES: Whether in-house development or outsourcing
options are being considered, the analyst must develop a clear, detailed list of
features that can serve as an overall specification for the system. Using the data
gathered during fact-finding, which was discussed in Chapter 4, list all system
requirements and critical features. T his information will be included in the system
rcquiremcnb document, which is cbe end product of the SDLC systems analysis
phase.
CONSIDER NETWORKANDWEB-RELATED ISSUES: As the system requirements
are evaluated, the network and web-related issues must be considered. The analyst
must decide whether the system will run on a network, the Internet, or a company
intranet and build these requirements into the design. Also, it must be determined
whether the system will exchange data with vendor or customer systems and ensure
that the system will be compatible.
ESTIMATE VOLUME AND FUTURE GROWTH: The analyse needs to know the
current volume of transactions and forecast futu re growth. Figure 7-8 shows volume
estimates for an ()rder processing system. In addition to current level~ , the figure
displays cwo forecasts; one based on the existing order processing procedures and
::inother char assumes a new website is operational.
A comp::irison of rhe two forecasts s hows chat the website will genera re more new
customers, process almost 80o/o more orders, and substantially reduces the need for
sa les rep~ and support staff. If in-house development is being considered, make sure
that the software and hardware can handle future transaction volumes and data
!.forage requirements. Conversely, if outsourcing is being considered, volume and
usage data is es~ential co analyze ASP fee structures and develop coi.t estimates for
outsourcing options.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
I'
I
Phase 2
Systems A nalysis
215
7.8 The Software Acquisition Process
Online Order Processing System Estimated Activity During Next 12-Month Period
CURRENT LEVEL
FUTURE GROW TH
(based on ex1sung
procedures)
FUTURE GROWTH
(assuming new website IS
operational)
Customers
36,500
40,1 50
63,875
Daily Orders
l,·435
1,579
2,8 11
Daily Order Lines
7,715
7,893
12.556
Sales Reps
29
32
12
O rder Processing
Support Staff
2
4
3
Producu
600
650
900
FIGURE 7-8 Volume estimates for an order processing system showing current activity levels and two forecasts: one based on
the existing order processing procedures and another that assumes a new website is operational.
SPECIFY HARDWARE, SOFTWARE, OR PERSONNEL CONSTRAINTS: The
analyst must determine whether existing hardware, software, or personnel issues wi ll
affect the acquisition decision. For example, if the firm has a large number of legacy
systems or if an Enterprise Resource Planning (ERP) strategy has been adopted, these
factors will have an impact on the decision. Also, the compa11y's policy regarding
outsourcing IT functions mu~t be investigated, and whether outsourcing is pare of a
long-rerm straregy. Wirh regard ro personnel issues, in-house sraffing requircmenrs
must be defined to develop, acquire, implement, and maintain the system-and
determine whether the compan}' is willing to commit to those staffing levels versus an
oursourcmg opnon.
PREPARE A REQUEST FOR PROPOSAL OR QUOTATION: To obtain the informa-
cion needed to m:ike a decision, che analyst should prepare an RFP or an RFQ. The
two documencs are similar but used in different sicuacions, based on whether or not a
specific software produce has been selected.
A request for proposal (RFP) is a documeot that describes the company, lists
the IT services or products needed, and specifies the features required. An RFP
helps ensure char the organizarion's business needs will be met. An RFP also spells
out the service and support levels required. Based on the RFP, vendors can decide
if rhey have a produce that will meet the company's needs. RFPs vary in size and
complexity, just like the systems they describe. An RFP for a large system can
contain dozens of pages with unique requirements and features. An RFP can be used
to designate some features as essential and others as desirable. An RFP also requests
specific pricing and paymcnr terms. There are several online sources where RFP
templates can be found.
When several responses to an RFP are evaluared, it is helpful to use an evaluation
model. An evaluation model is a technique that uses a common yardstick to measure
and compare vendor ratings.
Figure 7-9 s hows two evaluation models for a network project. The evaluation
model at the top of the figure simply lists the key elements and each vendor's score.
The model at the bottom of the figure adds a weight factor. ln this example, each
element receives a rating based on its relative importance. Although the initial scores
are the same 111 both models, note that vendor A has rhc highest point total in the top
example, bur ,·endor C emerges as the besr in the wcighred model.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ..............
__....
--
........... ......
. ,.. o-....._ ...... _ ... ,..,...,...,~..,._.. ........... ... ~..
~~·~---- ···---~~-.,.-"~
Chapter 7
Development Strategies
7.8 The Software Acquisition Process
216
Unweighte d Evaluation Model for a Network Project
Inst ructions: Rate each vendor on a scale from I (low) to I 0 (high). then add vendor scores
to calculate total points.
V ENDO R C
2
s
s
8
Layout/Design
8
8
5
References
10
6
3
TOTAL POINTS
26
24
25
Price
6
Completion Date
9
Weighte d Evaluation Model for a Network Project
Instruc tio n s: Rate each vendor on a scale from I (low) to I 0 (high), then multiply the vendor's
score by the weight factor. Add vendor scores to calculate tot.ii points.
~~~~~~~-
-~~~~~~~
WEIGHT
FACTOR
VENDOR A
VENDOR B
VENDOR C
Price
25
6 * 25=150
5 * 25 = 125
9 . 25 = 225
Compledon Date
25
2 * 25 =
so
5 " 25 = 125
8 . 25 = 200
Layout/Deslp
35
8 * 35 =280
8 . 35 = 280
s .. 35 = 175
References
IS
10 * IS= ISO
6 * 1S = 90
3 * IS = 4S
TOTAL POINTS
100
630
620
645
FIGURE 7 -9 The three vef\dors have che same initial raungs, but the two evaluauon models produce different
results. In the unweighted model at the top of the figure, vendor A has the highest toal points. However. after
applying we1ghong factors., vendor C is the winner. as shown in the model at the bottom of the figure.
o standard method exists for assigning the weight factors. Each firm will have
its own approach, which might be tailored to fit a specific situation. An analyse usu·
ally obtains as much input as possible and then circulates proposed values for further
comment and, hopefully, a consensus.
Evaluation models are valuable cools that can be used throughout the SDLC. A
spreadsheet program can be used to build an evaluation model, experiment with different weighting factors, and graph the results.
A request for quotation (RFQ) is more specific than an RFP. When an RFQ is
used, the speci fie product or service desired is already known; only price quotations
or bids a rc needed. RFQs can involve outright purchase or a variety of leasing options
and can include maintenance or tech.nical support terms. Some vendors even provide
convenient RFP o r RFQ forms on their websites. RFPs and RFQs have the same
objective: to obtain vendor replies that are clear, comparable, and responsive, so that
a well-informed selection decision can be made.
Step 2: Identify Potential Vendors or Outsourcing Options
The next step is to identify potential vendors or outsourcing providers. The Internet
is a primary marketplace for all IT products and services, and descriptive information
can be found on the web abour all major products and acquisition alrernacives.
~- )U,
- Woip-M ._..,..
r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
..
(....,..... J:gi( . . . . .
..,...,.......,..~
- ·~•-fllllie<'f •,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
__.~~c.....,..~
.........,..,. ..
._.,.,.,.......c:-..•~-".....-""'*"....,.._...,..
..
I'
I
P hase 2
Systems A nalysis
217
7.8 The Software Acquisition Process
If vercical applications for specific industries need ro be locared, industry rrade journals or websites can be used to find reviews for industry-specific sofrware. Industry trade
groups can often provide referrals to companies that offer specific software solutions.
Another approach 1 to work with a consulting firm. Many IT consulranrs offer
specialized services chat help companies select somvare packages. A major advantage
of using a consultant is that rhe analyst can tap into broad experience that is difficult
for any one company to acquire. Consultants can be located by contacting profcsional organizations or industry sources or simply b)' searching the Internet. Using a
consulranr involves additional expense but can prevent even more costly misrakes.
No matter what rhe topics of interest are, there are sure to be one or more on line
forum s where people gather to meet, offer support, and exchange ideas. Forums can
be hosted by private or public entities, or reside in larger communities such as Google
Groups or Reddit, which allow users to join existiug groups or start their own. A
web search can locate forums of interest, or the websites of specific companies, such
as Microsoft, and can provide a valuable source of information for IT professionals,
including biogs, forums, webcasts, and other resources, as shown in Figure 7-10.
·~I '--- -
Alie ""' Mlaooofl c - n i t y.
w.·,. here to help!
--= - - 0
,~
DJ
-
0
-- --- --e ---co --e
~
-·-
CJ.
L>
..
FIGURE 7- 10 Microsoft Community is a valuable resource for IT professionals.
Sovt<tet ~
..
,.
""
Step 3: Evaluate the Alternatives
After identifying the a lternatives, the analyst must select the one that best firs the
company's needs. Information abou t the options should be obtained from as many
sources as possible, including vendor presentations and literature, product documcntarion, trade publications, a nd companies that perform software testing and evaluation. To learn more abour particular software packages, search rhe Internet using
keywords that describe the application. Websites maintained by consu ltants and ~ofr­
ware publishers often include product references and links to vendors. As parr of the
evaluation process, try ro obtain information from existing users, tesr the application,
and benchmark the package.
EXISTING USERS: Existing users can be contacted to obtain feedback and learn
abour their experiences. For large-scale software packages, ASPs and vendors typically
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~----···---~~-.,.-"~
Chapter 7
Development Strategies
7.8 The Software Acqu isition Process
218
supply user references. User references are important because it must be known
whether the software package has worked well for similar companies. Be aware that
some vendors limit their reference lists to satisfied clients, so mostl y positive feedback
should be expected from those firms.
APPLICATION TESTING:
If a software package is one of the options, find out if it is
possible for users in the organization to try the product. For horizontal applications
or small systems, using a den10 copy to enter a few sample transacnons could be an
accepcable test. For vertical applications or large systems, a team of IT staff and users
might need several days or weeks to perform rests.
BENCHMARKING: To determine whether a package can handle a certain transac-
tion volume efficienrly, a benchmark rest can be performed. A benchmark measures
the time a pack;"tge takes co process a certain number of rrnnsacrions. For example, a
benchmark rest can measure the time needed to post l,000 sales rransacrions.
If benchmarks arc used, remember that a benchmark rest is conducted in a controlled environment, which might no t resemble the actual dtiy-ro-day situation tit the
project's company. Although benchmarking cannot predict project-specific resu lts,
benchmark resting is a good way co measure relative performance of cwo or more
competing produces in a srandard environment.
Many IT publications publish regular reviews of individutil ptickages, including
benchmark rests, and ofcen have annual surveys covering various categories of sofcwarc. Most of rhe publications now offer online and mobile versions, wich addicional
features, search capabiliry, and IT Links.
lnform<uion can also be obcained from independent firms that benchmark various
software packages and sell comparative analyses of the results, as shown m Figure 7- 11.
The Transticrion Processing Performance Council {TPC) is an ex.·unple of a nonprofit
organization that publishes standards and repons for its members and the general public.
TPC
-·-·-·-·
·---- ·--··Gctxwl
----· ~
-
(1
AHO::i , 1(1,1f1,
'"
CISCO
e
-
~
.If-
FUJITSU
IBlt
IOSpur
-
- - TTA i...,_,m
-
FIGURE 7-1 I The Transaction Processing Performance Council (TPC) is a
nonprofit organizauon chat publishes sundards and reports for Its members
and the general public.
Sour«:..
(....,..... J:gi( . . . . .
•
'"'~~ '1""'Nl' Cb.t'llt.(:C
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
Phase 2
Systems A nalysis
219
7.9 Completion of Systems Analysis Tasks
Finally, each package should be marched against the RFP features and rank the
choices. If some features are more important rhan others, give them a higher weight
using an evaluation model similar to rhe one shown in Figure 7- 11.
Step 4: Perform Cost-Benefit Analysis
Review the suggesrions in chis chapter and in Part C of che Systems Analyst's Toolkir to
develop a preadsheet ro idenrify and calculate TCO for each option being considered.
Be sure to include all cosrs, using rhe volume forecasts prepared. If outsourcing options
are being considered, carefully study the alternative fee structure models described
earlier. If possible, prepare charts to show the resulrs graphically, and build in what-if
capab1liry so rhe impact of one or more variables changing can be gauged.
If a software package is being considered, be sure to consider acquisition options.
When software is purchased, a ~oftware license is being boughL that give~ the purchaser
the right to use the software under certain cerms and conditions. For example, rhe licen~e
could a llow the software ro be used only on a single computer, a specified number of
computers, a network, or an entire site, depending on the terms of the agreement. Other
license restrictions could prohibit making the soft\vare available to others or modifying the
program. For desktop applications, software license terms and conditions usually cannot
be modified. For large-scale systems, license agreement terms often can be nt::gotiated.
Also consider user support issues, which can account for a significant part of TCO.
If an outsourcing alternative is selected, rhe arrangement probably will include cer·
rain technical support and maintenance. !I in-house development is chosen, the cost
of providing these services musr be considered. lI a software package is purchased,
consider a supplemental maintenance agreement, which offers additional support and
assistance from the vendor. The agreement might provide full support for a period
of time or list specific charges for particular services. Some sofnvare packages provide free technical support for a period of rime. Atterward, support is offered with a
charge per occurrence, or per minute or hour of technical support time. Some software vendors contact registered owners whenever a new release is available and usually offer the new release at a reduced price.
Step S: Prepare a Recommendation
T he anal)'St should prepare a recommendation that evaluates and describes rhe
alternatives, together with the coses, benefits, advantages, and disadvantages of each
option. At this point, it may be required to submit a formal system requirements
document and deliver a presentation. Review the suggestions for presenting
written proposals and oral presentations in Part A of the Sysrems Analyst's Toolkit.
Additional suggestions about preparing the system requirements document and the
management presenrarion are contained in the followi ng section.
7. 9 COMPLETION OF SYSTEMS ANALYSIS TASKS
To complete the systems analysis phase, the a nal)'St muse finalize the system requirements document, present their findings co management, a nd begin the transition ro
systems design.
7.9. 1 System Requirements Document
The system requirements document contains the requiremenrs for the new !>)'Stem,
describes rhe alternarives that were considered, and makes a specific recommendation to management. This important document is the starring point for measuring the
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 7
Development Strategies
220
7.9 Completion of Systems Analysis Tasks
performance, accuracy, and completeness of the finished system before entering the
systems design phase.
The system requirements document is like a contract that identifies what the system developer mu t deliver co users. Recall chat system requirements are identified
during the fact-finding process, and a system requirements checklist is c reated at char
nme. Various examples of system requiremenrs are listed in C hapter 4. The i.ystem
requirements document should be written in language that users can underscand so
they can offer input, suggest improvements, and approve the final version.
Because the system requirements document can be lengthy, they should be formatted and organized, so it is easy co read and use. The system requirements document
should include a cover page and a detailed cable of contents. An index and a glossary
of terms can be added to make the document easier to use. The content of the system requirements document will depend on the company and the complexiry of the
system.
7.9.2 Presentation to Managem e nt
The presentation tO management at tthe end of the systems analysis phase is one of the
most criric::il milestones in rhe systems development process. At this point, managers
make key decisions that affect the future development of the system.
Prior to a management presentation, two ocher presentations may be given: one co
the principal individuals in the IT department co keep chem posted, and another pre·
sentation to users co answer their questions and invite feedback. The system requirements document is the basis for all three presentations, and it (or a summary) should
be distributed in advance so the recipients can review it.
\Xr'hen preparing the presentation, review the suggestions in Part A of the Systems
Analyst's Toolkit, which can help design and deliver a successful presentation. If a
slide presentation is planned, review the Toolkit guidelines for effective presentations.
In addition to rhe rechniques found in the Toolkit, also keep rhe following suggestions
in mind:
•
•
•
•
•
Begin che presentation with a brief overview of the purpose and primary objectives of the system project, the objectives of thjs presentation, and what decisions need to be made.
ummarize rhe primary viable alternatives. For each a lternati ve, describe rhe
coses, advanrages, and clisadvantages.
Explain why the evaluation and selection team chose the recommended
a!tern:. rive.
Allow rime for discussion and for questions and answers.
Obtain a final decision from 1nanagemenr or agree on a timcrablc for rhe next
step in rhe process.
The objecr of the management presenrarion is to obtain approval for the develop·
ment of the system and to gain management's full support, including nece)sary financial resources. Managemenr probably will choose one of five alternatives: develop an
in-house system, modify a currenr system, purchase or customize a software package,
perform additional systems analysis work, or stop all further work. Depending on
their decision, the next task of rhe systems analyst will be one of the following:
•
lm plemenr an oursourcing alternative. If oursourcing is selected, the analyse
will work with representatives of the service provider to achieve a smooth transition to the new environment.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'
I
Phase 2
Systems A nalysis
221
7.9 Completion of Systems Analysis Tasks
•
•
Develop an in-house system. Begin systems design tasks, as described in
Chapters 8, 9, and 10.
Purchase or customize a software package_ Negotiate the purchase terms with
the software vendor for management approval. Then, if the package will be
used without modification, the analyst can begin planning the systems implementation phase. If modifications must be made to the package, the next step
is to start the systems design phase. If the vendor will make the modifications,
then the analyst's next step is to start planning the testing and documentation
of the modifications as part of the systems implementation phase, which is
described in Chapter l l.
•
Perform additional S)1Stems analysis work. Management might want the analyse
to invesngace certai n alternatives further, explore alternatives nor examined,
develop a prototype, reduce the project scope because of cost constraints, or
expand the project scope based on new developments. If necessary, the analyst
will perform the additional work and schedule a follow-up presentation.
•
Stop a ll further work. The decision mighr be based on the analyst's recommendation, a shift in priorities or costs, or for o ther reasons. Wha tever rhe reason,
if that is managemcm's decision, then there are no additional tas ks for the project o ther than ro file a ll the research in a logical location, so it can he retrieved
if the project is reopened in the furure.
After the presenrarion and management decision, the project will begin a transition
to the S)'Stems design phase of the SDLC. If an in-house system is being developed,
or a package is being modified, a model of the proposed system wiU be built, and the
analyst will srart designing the user interface, output, input, and dara structures.
7.9.3 Transition to Systems Design
In a traditional SDLC environment, systems design usually scarred when the systems
analysis phase was done. Using the system requirements specification as a blueprint,
developers transformed the logical design inro a working model that could be rested,
reviewed by users, and implemented. Today, the process is much more dynamic. In
general, systems developmen t is faster, more flexible, and more user oriented. The
introduction of agile development has changed rhe landscape significantly. Depending
on the project, system developers often blend tradirional and cutting-edge development methods, because what works in one siruarion might nor work in another.
This textbook discusses systems analysis in Chapters 4, 5, 6, and 7 and systems
design in Chapters 8, 9, and 10. However, in a typical IT workplace, a ll these tasksand more-are inregrated and managed together.
Regardle~s o f the developmenr method, systems design requires accurate documentation. Traditio nall y, a sy!>tem requirements document provided detai led specificatio ns
for output, input, dara, processes, and whatever else was needed. Although agile
merhocli. do not require :.t particular form of documenta tion, a s uccei.~ful develo pment
team must understand and record user requirements as they evolve during the project.
A logical design defines what must rake place, nor how it will be accomplished.
Logical designs do nor address the actual methods of implementation. In contrast,
a physical design is like a set of blueprints for the actual constructio n of a building.
Typically, a physical design describes the acrual processes of entering, verifying, and
scoring data; the physical layout of data files and sorting procedures; the format of
reports; and so on. Because logical and physical designs are related so closely, good
systems design is impossible wirhour careful, accurate systems analysis. For example,
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 7
Development Strategies
7.10 Summary
222
the analyst migh t return ro fact-finding if it was discovered that an important issue
was overlooked, if users had significant new needs, or if legal or governmental
requirements c hanged.
A junior analyst at a medium-sized IT consulting firm has been asked by her manager to
draft a response to an RFP from a large company that is seeking IT consulting services in
connection with a new accounting system.
As the analyst worked on the RFP. she noticed a specific question about her firm 's
recent experience on this type of system. To the best of her knowledge. the firm has only
worked on one other accounting project in the past three years. When the manager saw
the analyst's draft response, he was upset about the way she answered the question."You
don't have to be quite that candid," he said. " Even though we only had one formal project,
we do have several people who worked on accounting systems before they came here."
"Yes," the analyst replied," But that isn't what the question is asking." As he left her
office, the manager's final comment was, "If we wan t that job, we' ll have to come up with a
better answer." Thinking about it, the analyst isn't comfortable with anyth ing but a straight
answer. Is th is an ethical question? What are her options!
7. I 0 SUMMARY
This chapter described system development strategies and the preparation and presentation of the system requirements document.
Traditional systems must function in various hardware and software environments, be compatible with legacy systems, and operate within the constraints of company nerworks and desktop computing capability. Such systems utilize Internet links
and resources as enhancements. In contrast, Internet-based systems treat the web as
the platform, rather than just a communication channel. Many large companies use
web-based systems co handle enterprise-wide applications. Compared to traditional
systems, web-based systems are more scalable, less dependent on specific hardware
and software, and more adaptable to outsourcing the operation and support of a software application.
Systems analysts must consider •veb-based development environments such as
.NET, M ERN, and various outsourcing options, including ASPs and IBSs. ASPs charge
subscriprion fees for providing application sofrware packages. IBSs offer powerful
web-based servers, software hosti ng,, a nd IT support services ro customers.
The web generation called Web 2.0 is fueling the expansion of information sharing, user collaborarion, and social networking applications such a~ Twiner, Linkedfn,
and Faccbook. Another development, called cloud computing because of the commonly used cloud symbol for the Internet, describes an overall online software and
data environment, powered by supercomputer technology that i the ultimate form of
SaaS.
If a company chooses to handle ics own software development needs, it can create
in-house systems or purchase (and possibly customize) commercially available software packages from a software vendor or VAR.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
I'
I
P hase 2
Systems A nalysis
223
7.10 Summary
Compared with developing an in-house system, an existing commercial software
package can be an arrractive alrernative, because a package generally costs less,
takes less time to implement, has a proven track record, and is upgraded frequently.
In-house development or customizing a software package might be the best choice
when a standard software package cannot meet specific business requirements or
constraints. In addition to customizing software packages, companies can create
user applications based on standard software that has been specially configured ro
enhance user producnvity.
An 11nporcanr trend that views SaaS, rather than a product, has created new developmenr options. SaaS 1s a model of software deployment in which an application is
hosted as a service provided to customers over the lnterner.
Offshoring, :ilso known :is offshore outsourcing or global 011tso11rc111g, refers to
the practice of shifting TT development, support, and operations co other countries.
In a trend similar co the ourflow of manufacturing jobs over :1 several-decade period,
many firms are sending IT work overseas. The main reason for offshoring is the same
as domestic outsourcing: lower borrom-line costs. Offshore outsourcing, however,
involves some unique risks and concerns.
The systems analyst's role in the software development process depends 011 the
specific development strategy. In-house development requires much more involvement
than outsourcing or choosing a commercial package.
The most important facror in choosing a development strategy is TCO. Financial
analysis tools include payback analysis, which determines how long it takes for a system co pay for itself through reduced costs and increased benefits; ROI, which compares a project's total return with its total coses; and NPV, which analyzes the value of
a projecr by adjusting cosrs and benefits to reflecc che rime thar they occur.
The process of acquiring software involves a series of steps: Evaluate the system
requiremenrs, consider network and web-related issues, identify potential sofnvarc
vendors or outsourcing options, evaluate the alternatives, perform cost-benefit analysis, prepare a recommendation, and implement the solution. During software acquisition, a company can use an RFP or an RFQ. An Rf P invices vendors ro respond to a
list of &)·stem requirements and features; an RFQ seeks bids for a specific product or
service.
The S)'~tem requirements document is the deliverable, or end produce, of the systems analysis phase. The document derails all system requirements and constraints,
recommends the best ~olution, and provides cost and time estimate~ for future development work. The sr~rem requirements document is t11e basis for the management
presentation. At chis poim, the firm might decide to develop an in-house sy~tem, modify the current system, purchase or customize a software package, perform additional
systems analysis work, or stop all further work.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 7
Development Strategies
Key Terms
224
Ke y Te rms
applicauon \Ct\ ice pro' idtl (ASP) A finn chm delivers a wfrware applicauon, or aC(c.,s IO an appltcarion, h) chargoni; a u-.ai:c or 'ub..cnpnon fee.
h.,nchmark A mea\urc<. of rhe rime a package rak~ ro procc<s a certain numhcr of tram.1c11on,,
hu1ld or buy A choice between developmg 10-house sofrware and pur.:hasmg software, often called a
but Id or bu)', or make or buy, decision.
bu<ine<< procc<~ our<ourcing !BPOl The oucsourcing of a basic busin~s process. See a/50 outsourcing.
cloud computing An online <;<>ftware and da-i:a em~ronmenc in which applicanon' and 'crvice' arc
Jcce<.-cd and used ch rough an lncerner connection rather than on a local rnmpucer; refer> co the cloud
.,ymhol for the Internet.
evaluation .ind 'ck-.:tion team A group of people involved in ~deurni: h.irdwa rc and >Oft ware:. The group
111dudc' \)"tcm~ analy>t\ and users. A team a pproac:h cmurc' 1ha1 cnrical fnctor' arc nor overlooked
and that a sound choice is made.
evaluation model A technique rba r uses a common yardstick to mci1sure and comp.ire vendor ratings.
fixed fee model A service model thar charges a sec fee based on a specified level of service and user
supp0rt.
forum An on line di,cu,,ion on a parcicular copic, where people mecl, offer >upport, and e>echani;e idea,,
glob.ii out.,ourdni: The pracrke of ohifting IT development, >upport, and operation' w other countries.
boruon1al application A software pJckage char can be used by man) d1ffercm types of organwmons.
in-bouic >Oft\\ arc An mfonnation cenrer or help desk wubin the 11 dep.rnmem resp0ns1ble for providmg user supporr and offering sen-ices such as hodme ass1sr.111ce, tr.lllltng, and gu1d.1ncc ro users who
need teduuc.il belp.
Internet hu'1nC\\ \cn;cc\ (IBS' Scn•iccs rhar provide powerful wcb-bao,cd \upport for iran•action• •uch
a• order pmce<smg, billing, and customer relariomhip management.
l~ical dc,ign The definition of an information system's fun~-rions and feature-., and rhc relanon,hip<
among ir, componenn..
maintcnam:e agr.'Cmeot A >pecification of the condiuons, ch.uge;, .ind tune fr.une for u>efi to com.1ct
the vendor for assistance when che)' have system problems or quesuons.
mal..c or bu~ The choice between de,eloping in-house sofcware and purchasmg soft\\Jre often 1s called a
make or buy, or bm ld or buy, deos1on.
man.1gcd ho,t1ng 1\n opcrarion 1< managed by the oursidc firm, or hem. t\nothcr term for me;.,
middlcware Software rhat connects dissimilar applications and enables them to commun1cacc and
e-ichangc data. For exnrnple, rniddleware can link a deparnnentnl darnba'e to a wch server rhn r can
be aClC>~ed by tlienr computers via the Tnrcmet or a company intranct.
mobile dc,·icc )nrnrtphones, cablers, and orb.er computing devices t bar Jre nor permanenrly terhered ro a
desk. T hey connect to 1he ncrwork wirelessly.
nc1 present l'alue (Nl'V} The rocal va lue of rhe beneffrs minus the tota l v.1lue of the coqs, w ith both the
cost~ and benefits being adjusted to reAecr the poinr in tome .it which t hey occur.
off~horc outmurcini: The practice of shifting IT development, su pport, and operation~ m orhcr
coumrie~.
uff.,horing See nff'ihorc out~ourcing.
outwun.;ng Tbe transfer of information systems development, operJuon, or mamrenance tO an out~ide
tmn rbat pro\ldc; the~e ser\1ces, for a fee, on a temporary or long-term ba~•~.
p.i)b;icl.. anal~s·~ A deremurumon of ho\\ long it ca kes an informanoo sy~tcm to pa) for uself through
reduced costs and increased henefirs.
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
...............
_ .... ~---11rt~
-,..~---~ ~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
I'
I
I
Phase 2
Systems Analysis
225
Key Terms
ph},ical d~illJI A plan for che actual 1mplememarion of che system.
requc\t for propo.,.al (RFP) A wrinen Im of fearures and specificarioru. gi•en co pro>pe<:llve vendor:.
before a >pc.:ific product or pa~kaj\e has been ~b.'ted.
requto't for 1.1uot.auon (RI Q u.,cd 10 obtain a pnce quotanon or bid on a \pcctfic produu or packaj\e.
return on Ul\C\tmcm (ROI) A percemage rate that measure!. profitabw!} by comparing the total net benefirs (the return ) received from a pro1ecr ro rhe roral costs (rbe mvescment) of r:he project. ROI = (rotal
bcncfirs - 1otal cosrs)/total cosrs.
~en-ice d~k A centra lized resource staffed by IT professionals char provides users with the supporr they
need ro do cbeir )Obs. Also called help desk.
•en ice prm 1der A firm rhnr offer, oursourdng solucion~. Two popular outsourdng option., involve ASP~
and finm that offer IRS, .
Software J\ a )crvice (\an\) A mu<ld of >ofrwa re <lel i,•cry in which funcrionn liry i, <ldiverc<l 1111 demand
'"a ncrwurk-accc''ihlc '>Crvicc, ra ther rhan a' a tradicional ,o ftwa rc applica tion that ;, duwnlondcd
and in,ta llcd on the cusrnmcr\ compmcr.
sofcwarc license J\ legal agreemeni thar gives users rhe right rouse rhc software under certain cerms nnd
condirions.
softwMe pack.1gc ~frware that is purch.ised or leased from another firm. A corumercit1Uy produced
softw.tre produce. or fonuly or producrs.
'>'tcm requirement' Jo.:umcnt A uo<;ument rhat cunrains the requirement' for the new 'Y'tem, dc...:ribe'
the altcmattve' thar were considered, and makes a •pccific rccommcndattun to mana11cmcnt. It ;, rhc
end producr of rhe 'Y'rcm< nn'11y<i< pha<c.
,ofn,arc 'cndnr Company rh;ir de,·clops <ofr:ware for <ale.
subscription model A sen-ice model that charges a ,·ari<lble fee for an application based on the number
of users or worksrauons char haH' acctss ro che application.
cram.i.:uon model A sen-ict model r:hat charges a variable fee for an applicauon based on rhe \Olume of
transacuoos or oper.mons performed by rhe appltcacion. Also called a usage model.
u,aitc model Su cran,action model .
u~cr apploc.111un Progra1m 1ha1 utili1c ;randard bu~ine>s •oftwarc, •uch a> Mivowft Offilc, wh"h ha'
been confil\urcd in a •pec1fic manner ro enhance user product1v1ry.
mer interface Includes screens, commands, controls, and fea rures rhar enable users to mrernet more
effectively with an applicanon. See <1/so graphical user interface (GUI).
' 'alU•'-addcd rc-.dlcr (VAR ) A firm t ha t enhances a commercial package by adding custom feature~ and
conf1gunng 11 for a parucular md usrry.
vertical application A ,oftwan: package that has been develo ped ro handle informnrion requirement\ for
a •pcc1fic rype of bu,i ne,~.
\\'ch 2.0 A ' ccond 11cncr:irio n of 1hc web ihnt enables people to collaborate, interact, Jnd ,h,irc on formation much more dynamically, ba~ed on con cinuo usly avai lable user applications rather than Sto rie
HTML. web page~. lnrcracrivc experience is n ha llmark ofWeh 2.0.
~ JD» (".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_ ._.... ~~
...
. ..............
_ .... ~---11rt~
-,..~---~ ~
.... . _
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Chapter 7
Development Strategies
Exercises
226
Exercises
Questions
I. List three characreristics each of rraditional and web-based development.
2. How does cloud computing support Web 2.0 applications?
3. Why would a company choose in-house sofrware de,·elopment?
4. \Vhat 1s outsourcing?
5. List two reasons offshoring may be risky.
6. What is SaaS?
7. What i!> the primary objeetive of the evaluation and selection team in ~electing a development
strategy?
8. What are the five steps in rhe sofcware acquisition process?
9. What is an RFP, and how does it differ from an RFQ?
10. Explain the relationship between logical and physical design.
Discussion Topics
I. How has the prolifcrarion of mobile devices affected IT professionals?
2. A~ more companies outsource systems development, will there be less need for in-house system~ analysts? Why or why not?
3. Select a financial SaaS applicarion, and describe its main features.
4. Suppose you rned to explain the concept of weighted evaluation models to a manager, and she
responded by asking, "So, how do you set the weight factors? ls it just a subjecti\'e guess?" I low
would you reply?
5. What decisions might managemenr reach at rhe end of the systems analysis phase, and what would be
the next step in each case?
Projects
I. lnvestigate the ROI of cloud-based software development environments.
2. t-.1any financial cools :ire developed using t-.1icrosoft E.xcel. ldeotlfy three applications builr usmg
Excel, and describe how the)' are used in an organization.
3. Visit the IT deparnnem ar your school or at a local company, and dercrmine wherhcr the sysrcms were
developed in-house or purchased. If packages were acquired, find our whar customizing was done, if
any. Write a brief memo describing the results.
4. Profile three companies rhat provide offshore sofcware development services.
5. Various firms and organizations offer IT benchmarking. Locate an example on the Internet, and
describe its ~crv i ces.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
PHASE
SYSTEMS DESIGN
Systems design Is the third of five phases in the systems development life cycle. In the previous
phase, systems analysis, a logical model of the new system was developed. The output of that
phase, the system requirements document, is used as input to the systems design phase, where a
physical design is created that satisfies the system requirements.
The components of a system are interdependent; therefore, the design phase Is not a series of
clearly defined steps. Although work may start in one area, it is possible to be working with several
different elements at the same time. For example, a decision to change a report format might
require changes in data design or input screens. The design checklist will Include the user interface,
input and output procedures, data design, and system architecture. At the end of this phase, the
analyst prepares a systems design specification and delivers a presentation to management.
The goal of systems design is to build a system that is effective, reliable, and maintainable:
•
A system is effective if it supports business requirements and meets user needs.
•
A system is reliable if it handles input errors, processing errors, hardware failures, or
human mistakes. A good design will anticipate errors. detect them as early as possible,
make it easy to correct them, and prevent them from damaging the system itself. Other
characteristics of a reliable system include it being available nearly all of the time and
proper backups maintained in case of system failure.
•
A system is maintainable if it is flexible, scalable, and easily modified. Changes might be needed
to correct problems, adapt to user requirements, or take advantage of new technology.
Chapter 8 focuses on user interface design. This includes human-computer interaction, seven
habits of successful interface designers, guidelines for user interface design, source document and
form design, printed output, technology issues, security and control issues. and emerging trends.
Chapter 9 focuses on the data design skills that are necessary for a systems analyst to construct
the physical model of the information system. This includes DBMS components, web-based
design. data design terms, entity-relationship diagrams, data normalization, codes, data storage
and access. and data control.
Chapter I 0 focuses on system architecture, which translates the logical design of an Information
system into a physical blueprint. This includes an architecture checklist. the evolution of system
architecture, client/server architecture, the impact of the Internet, e-commerce architecture,
processing methods, network models, wireless networks, and systems design completion.
227
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ . ....._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... .., .,. ..,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Chapter 8
User Interface Design
•
• ••• • ••
•
•••• •••••••••••
•••••
• ••
•••••
•
······----····
·····---··-··
......
- ·····
---· --
User Interface
Design
Chapte r 8 is the first of three chapters in the systems design phase of the SDLC. User Interface design
is the first task in this phase. Designing the interface is
extremely important because everyone wants a system
that is easy to learn and use. This chapter explains how
to design an effective user Interface and how to handle
data security and control issues. The chapter stresses
the importance of user feedback and involvement in all
design decisions.
The chapter includes three "Case in Point" discussion questions to help con textualize the concepts
described in the text. The "Question of Ethics" considers the ethical (and possibly legal) constraints on how
far the creative work of others can be used without
crediting the source. for example, In the design of a
company's website.
LEARNING OBJECTIVES
When you fi11is/1 this chapter, you s/Jould be able
to:
CONTENTS
1. Explain user interfaces
2. Explain che concept of hum:m-computer imeracrion, including user-friendly interface design
3. Summarize th e seven habits of successful interface designers
4. Summarize rhe 10 guidelines for user interface
design
5. Design effective source documents a nd forms
6. Explain printed output report design guidelines
and principles
7. Describe three types of printed output reports
8. Discus~ output and input technology issues
8 . 1 User Interfaces
8.2 Human-Computer lntcracuon
Case in Point 8.1: Casual Observer Software
8 .3 Seven Habir5 of Successful lncerfoce Designers
8 .4 Guidelines for User lncerfoce Design
Case in Poinr 8.2: Boolean Toys
8.5 Source Documenc and Form Design
8.6 Printed Output
Case in Point 8.3: Laty Eddie
8 . 7 Technology Issues
8 .8 Securiry and Co ntrol Issues
8. 9 Emerging Trends
A Question of Ethics
8.10 Summar y
Key Terms
Exercises
9. Describe output and input security and conrrol
issues
10. Explain emerging user interface trends, including modular design, responsive web design, and
prototyp e~
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Phase l
Systems Design
229
8.1 User Interfaces
8.1 USER INTERFACES
A u~er interface (UT) describes how users interact with a computer system and consisrs of all the hardware, software, screens, menus, functions, output, and features
that affect rwo-way communications between the user and the computer. The user
interface is the key t0 usability, which includes user satisfaction, support for busines~
functions, and system effectiveness.
Traditionally, a chapter on user interface design started wirh a discussion of ourput
because ourpur •~ whar u~ers rouched, viewed, and needed to do their jobs. Today, the
situation is different, for several important reasons:
•
Users can design their own output. System designers are more aware of user
needs and desires. A system can maintain dara integrity and still allow users ro
view, sorr, filrcr, and examine dara in any way that helps them do rheir jobs.
There was a rime when rhe MIS depanmenr made those choices and users
had little or no ~ay in the matter. Today, successful applicarions are designed
quite differently-the system developer identifies user needs and then creates a
design that will s:icisfy users and meet corporate requirements.
•
Centralized IT departments no lo nger produce reams of printed reports. Those
reports often gathered dust while sitting on top of file cabinets. \Xlhile a few
examples mighr persist, the overwhelming trend has been to customer-designed
output. The customer might be an individual user, or a community of users,
such as a department. As Chapter 4 pointed out, the IT team must undersrand
user requiremcnrs before creating a solution.
•
The user inrcrfacc itself has evolved into a rwo-way channel, with powerful
output capability, and most user information needs can be met wirh creen-generated darn, which a user can print, view, or save. Well into the 1980s and
be)·ond, a user incerface was a blank character-based screen, which mighr or
mighc nor offer menu choices. ff a user entered a command improperly, che system responded w1rh an error message, which frustrated u ers and stifled product1v1ry. ~1any hardware-cenrric vendors did not understand the imporrance
of the user mrerface and irs implications.
Apple was a pioneer in user interface development, introducing the graphical user
interface (GUI), complete with mouse and screen icons, in the early 1980s. At char
point, nor many companies were ready for this concept. When software giant Microsoft
finally jumped on rhe GUI bandwagon with its Windows~ operating sysrem, the corporate doors swung open, and everyone from managers on down said, "How did we ever
do without chis?"
Many indu~try leaders believe chat rhe besr interfaces are the ones that users do
not even notice-they make sense because they do what user!> expect them ro do. For
example, as :.hown in Figure 8- J, Apple believes that designing an exceptiona l user
incerfoce is essentia l to a !>uccessful app. Apple has long di~cinguished itself from it5
competitor~ by the incuiciveness of its produces. Apple's command of che marker suggests that consumers are willing to pay a premium for products that "ju~t work."
When developing older systems, analysts typically designed all tbe printed and
screen output firsc and then worked on the inputs necessary to produce the re~ults.
Often, the user interface mainly consisted of process-control screenl> chat allowed the
user co send commands to rhe syscem. Thar approach worked well with tradirional
systems that simply cransformcd input data into structured output.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 8
User Interface Design
8.2 Human -Computer Interaction
230
-
-
- -
Designing for iPhone
Leam how to opi.,..ze the design of your app °'game
l0t the al-screen displays or 1Phone Xs, 1Phone Xs Max, end 1Phone XA
Down.,,.d,
FIGURE 8 - 1 Apple has long been a. leader in creating elegant user Interlaces for Its
products.
SOUi"(~ ~ .\- In<
As information management evolved from centraJized darn proces~ing to dynamic,
enterprise-wide systems, rhe primary focus also shifted-from rhe IT department to
the users themselves. The IT group became a supplier of information technology,
rather than a supplier of information. Today, tbe main focus is on users within and
outside the company, how they communicate with the information system, and how
the system supports the firm's business operations.
In a user-centered system, the distinction blurs between inpur, output, and the
interface itself. Most users work with a varied mix of input, screen ourput, and data
queries as the}' perform their day-to-day job fw1ctions. Because all those casks require
inrcraction with rhe compurer system, the user inrerface is a vital eleme nt in the S)'Stems design phase.
User interface design requires an understanding of human-computer interaction
and user-centered design principles, which are discussed in rhe next section.
8.2 HUMAN-COMPUTER INTERACTION
A user interface is based on basic principles of human-computer inreracrion.
Human-computer interaction (H Cij describes tbe relationship between computers
and the people who use rhcm ro perform rheir jobs, like the worker shown
in Figure 8-2. HCTconcepts apply to everything from smarrphones to globa l
networks. In its broadest sense, HCI includes all the commun ications and
instructions necessary ro enter inpul to the system and to obtain output in the form
of screen displays or printed reports.
Earl y user interfaces involved users ryping complex commands on a keyboard,
which displayed as green cexr on a black screen. Then came rhe GUI, which was a
huge improvement because it used icons, graphical objects, and pointing devices.
Today, designers strive to translate user behavior, needs, and desire& into an interface
that user!> don't really notice. 18,\.1 has stated char the best user interfaces are "almost
transparent-you can ee right through rhe interface to your own work." In ocher
words, a tran~parcnt interface does not disrracr the user and calls no attention to
itself.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
231
8.2 Human-Computer Interaction
FIGURE 8-2 HCI Is essential to employee product.ivicy. whether the work Is done In a
traditional office setting or on a construetion site like the one shown In this figure.
A systems analyst designs user interfaces for in-house-developed software and
customizes incerfaces for various commercial packages and user productivity applicarions. The main objective is ro create a user-friendly design that is easy to learn and
use.
Industry leaders Nlicrosofr and IBM both devote considerable resources to u~er
interface research. Figure 8-3 describes IBM Research's work on HCI. Their stated
goal is to "design ystems that a re easier and more deligbrfuJ for people to use."
Human-Computer Interaction and Data Visualization
-
:--..·- -
-=--I.:..:.- ..... = ..............,,............. o.. ....... . . .... : ·•di.·•• . ~J.~ --~
......... .,.., ..
,....OWl.tll~aMtir---....-
..c coWiiJrw
e - . ·'' j SOCl'"'I
otlon
&- .c "
~
.,.,.....,.,......,a"'49 ...
...
~till-
....... ....
Olllr~ .. to ftilt prodllC'bMI ..,_... .,..,............. .,..._
111•~·~-
l•chillilo:OC*:oew ..... HuMM~
_
______
...
.
...
ill'Wtlt'............... ,.,,., . . ~...._,. .. ,. . . . . . . ...... .
:[::(~-11=---·
:-~~,t
'
!
-
- ' • ' -·,-..Iii 1 • .. Cl)
'
I
!/j
............l'ld ..........."" ........... . ltd ................. '" ....
.. _
..... Ny
_,
..,...,.....,..,..........., .,..
. o.,.. ......................... ~ .. -~
td....._ •.,..,.,..
AtH011wad••••... ....,..,~ .. .....,..._... . .,....,,.. . ........
....,...,.,,_....,... ..... ,.,.,.,._..wMClw..,. ....et1n.,..ez• eacot..O•CHLM.1££t'VlS..,...C$CW ill
................."*,........... ~ ................
FIGURE 8-3 IBM's research division is a leAder in exploring human-computer
interaction (H CI).
Sowc•
.........""_.. ....-.................
_..__ ...................
("..,_..., llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~ --- - ·· · ---~~-.,.- " ~
Chapter 8
U ser Interface Design
8 .3 Seven Habits o f Successful Interface Designers
232
Because I ICI has a major impact on user productivity, it get!. lots of anentionespccially where multimillion-dollar issues are concerned. For example, in the article
"Human-Computer lnceraccion in EJeccronic Medical Records: From the Perspect ives
of Physicians and Dara ciencisrs" by E. Bologva er al. from Procedta Computer
Saence 100 (Elsevier, 2016), che authors describe how software usability has a major
impact on rhe medical profession, a nd noc everyone is happy about it-par ticularly
phy)icians who often struggle with electron ic health records ( !:'. HR\ ) systems that
are poorly designed. In her article, 1'1s. Ga rdner points out that physicians often
multirask, answering a question about one patient while writing a prescnpnon for
another, and EHR sofrware was nor designed around char rypc of workflow.
CASE IN POINT 8.1:
CASUAL OBSERVER So i:1 \\',\R E
Casual Observer Software's main product is a program that monitors and analyzes user keystrokes and mouse clicks to learn more about the way employees use their computer systems.
The problem Is that some users feel this is an unwarranted intrusion into their privacy. and
they prefer not to be observed. Some even fear that the data would be used for other reasons,
including performance appraisal. You are a consultant who has been hired by a client firm that is
trying to decide whether or not to use this software.
Before you advise the client, remember the Hawthorne effect, which suggests that
employees might behave differently when they know they are being observed. Finally,
think about the ethical issues that might be involved in this situation. What will you
advise your client, and why?
8.3 SEVEN HABITS OF SUCCESSFUL INTERFACE DESIGNERS
Although IT professionals have different views about interface design, most would
agree rhar good design depends on seven basic principles. Successful interface designers
use these basic principles as a matter of course-they become habits. These desirable
habits are described in the following sections.
8.3. 1 Understand the Business
The inrcrfocc designer must understand rhe u nderlyi ng business funcrions and how
the sysrem supports individual, departmental, and enrerprise goals. The overall objective is ro design an inrerface t har helps users to perform t heir jobs. A good srarting
point mighr be ro analyze a functional decom position diagra m (FDD). As descri bed in
Chapter 4, an FDD is a graph ical represenracion of business functions rhac srarcs wirh
major functions and rhen breaks rbem down inro several levels of derail. An FDD can
provide a checklist of user rasks rhat must be included in the interface design.
8.3.2 Maximize Graphical Effectiveness
Studies show chat people learn bener visually. T he immense popularity of Apple's
iOS and ~1icrosoft Windows is largely che result of their GUls that are easy to learn
and use. A well-designed interface can help users learn a new system rapidly and be
more productive. Also, in a graphical environment, a user can display and work wich
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Phase 3
Systems Design
233
8.3 Seven Habits of Successful Interface Designers
muhiple windows on a single screen and transfer data between programs. If the interface supports data entry, it must follow the guidelines for data entry screen design
that are discussed farer in this chapter.
8.3.3 Think like a User
A systems analyst should understand user experience, knowledge, and skill levels. If a
wide range of capability exists, the interface should be flexible enough ro accommodate novices as well as experienced users.
To develop a user-centered interface, the designer must learn ro think like a user
and see the S)'Stem through a user's eyes. The user interface must be easy to learn,
using terms and metaphors that arc familiar to users. Users are likely to have realworld experience with many other machines and devices char provide feedback, such
as automobiles, ATMs, and microwave ovens. Based on chat experience, users will
expect useful, undersrandable feedback from a computer systen1.
Carefully examine any poinr where users provide input or receive output. Input
processes shou ld be easy co follow, intuitive, and forgivi ng of errors. Predcsigncd output should be attractive a nd easy to understand, with an appropriate level of detail.
8.3.4 Use Models and Prototypes
From a user's viewpoint, rhe interface is the most critical part of the system design
because it is where he or ~he interacts with the sysrem-perhaps for many hours each
day. It is essenrial ro construct models and prorotypes for user approval. An interface
designer should obtain as much feedback as possible, as early as possible. Initial screen
designs can be presented to users in the form of a sroryboard, which is a sketch that
shows rhe general screen layout and design. The storyboard can be created with software
or drawn freehand. Users must test all aspects of che interface design and provide
feedback to the designers. User inpuc can be obtained in interviews, via questionnaires,
and by observanon. Interface designers also can obtain data, called usability metrics, by
using software chac can record and measure user inceracrion with the system.
8.3.S Focus on Usability
STUDENT SERVICES
- Register
The user interface should include all tasks, commands,
and communications berween users and the information
system. The opening screen should show the main options
(Figure 8-4 is an illustration). Each screen option leads to
another screen, with more options. The objective is ro offer
a reasonable number of choices that a user easily can comprehend. Too many options on one screen can confuse a
user-but coo few options increase the number of su bmenu
levels and complica te rhe navigation process. Often, an
effective strategy is to present the most common choice as a
default bur allow the u~er to select ocher options.
SludenlS
-
I
I
Pnnt Grade
Repof1S
Help
Enter Grades
Exll System
FIGURE 8-4 The opening screen displays the main
options for a student registration system.A user can click
an option to see lower-level actions and menu choices.
8.3.6 Invite Feedback
Even after the sysrem is operational, it is important to monitor
system usage and solicit user suggestions. The analyst can determine if system features are
being used as intended by observing and surveying users. Son1erin1es, full-scale operations
highlight problems char were nor apparent when the prototype was tested. Based on user
feedback, 1lclp screens might need re,;sion and design changes to allow the system ro
reach its full potential.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 8
User Interface Design
234
8.4 Guidelines for User Interface Design
8.3.7 Document Ever ything
All screen designs should be documenred for larer use by programmers. If a CASE
root or screen generaror is being used, the screen designs should be numbered and
saved in a hierarchy s imilar co a menu rree. U er-approved skerches and sroryboards
also can be used to document the user interface.
B)• applyi ng basic user-centered design principles, a systems analyst can plan,
design, and deliver a successful user farerface.
8.4 GUIDELINES FOR USER INTERFACE DESIGN
A system might have advanced cechoology and powe rful fearures, bur rhe real rest is
wherher users like it and feel that ir meets their needs. What follows is a set of general
guidelines for s uccessfu l user interface design. These guidelines arc disrilled from years
of best prncrices in the industry. There is some overlap because many of rhe main
guidelines share common elements.
Although there is no standard approach 10 interface
design, these guidelines are a starting point su itable for
rradirional systems development. User interface development
for web applicati.ons or for mobile apps has its own unique
considerations, above and beyond these general guidelines.
Perhaps rhe most important guideline is rhar not all of these
recommendations musr be followed-the best interface is the one
rhat works besr for the users.
8.4.1 C reat e an Inte rface That Is Easy t o Learn and Use
1. Focus on system design objectives, rather than calling arrention ro the interface.
I
I
Dau -•• IOildl Pluse s1an --..
Dat a ts nol sultablP.
3. Provide commands, actions, and ~y rem re~ponses that are
consistent and predictable.
a-It ti... 1ru.1rucuoru for t his
taslt and t i..."'""''°"' tast l
I
IT'"'
2. Create a design rbat is easy ro undersrand and remember.
Mainrain a common design in all modules of the interface,
including rbe use of color, screen placements, fonts, and rhe
overaU "look and feel."
4. Allow users ro correct errors easily.
Not enough a l• t o prOCHd.
5. Clearly label all controls, butrons, and icons.
6. Select familiar images thar users can understand, and provide
on-screen instructions that are logical, concise, and cle.1r. For
example, the top screen in Figure 8-5 shows four control
buttons, but none of them has an obvious meaning. Jn the
bottom screen, the first five messages provide little or no
information. The last message i.s rhc only one rhar is easy ro
understand.
data Is lncorrec:I.
Ple•stt use l he proper format:
Three lette.,. f ollowed by three
numMrs. w ith no~
EJtomple: CTSU$
FIGURE 8· 5 In the example at the top. the
icons do not have a clear menage. In the
Help text examples at the bottom. only one
message is understandable.The others would
frustrate and annoy most users.
(....,..... J:gi( . . . . .
7. Show all commands in a list of menu items, bur dim any
commands that are not available ro rhe user.
8. Make it easy to navigate or return ro any level in rhe menu
srructure.
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f •,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
235
8.4 Guidelines for User Interface Design
8.4.2 Enhance User Productivity
The interface is where a u er interacts with the system, so it can have a dramatic
effect on productivity. If the interface empowers a user and enables him or her to handle more complex tasks, the user becomes more productive. Conversely, if the interface 1~ difficult to work with, productivity declines.
I. Organize tasks, commands, a nd functions in groups that resemble actual business operations. Group functions and submenu items in a multilevel menu hierarchy, or rree, that is logical and reflects how users typically perform the tasks.
Figure 8-6 shows an example of a menu hierarchy for an order tracking system.
Customer Order Tracking System
Main Menu
Customers
Orders
Products
Add 11 New Customer
Enter a New Order
Enter a New Product
Update Customer Data
Modify Order Data
Update Product Data
Delete a Cuslomer
Csncel an Order
Deleta a Product
FIGURE 8-6 This menu hierarchy shows casks. commands. and functions organized into
logical groups and sequences. The structure resembles a functional decomposition diagram
(FOO). which is a model of business functions and processes.
2. Create alphabetical menu hsrs or place che selectioas used frequently at the
top of the menu list. No universally accepted approach co menu item placement exists. The best strategy is co design a prototype and obtain feedback
from users. Some applicacioas even allow menus to show recently used commands first. Some users like char feature, but ochers find it distracting. The best
approach is to offer a choice and lee users decide.
3. Provide shorrcurs for experienced users so they can avoid multiple menu levels.
Shortcuts can be created using hot keys that allow a user to press rhe Ale key +
the underlined lener of a command.
4. Use default values if the majority of values in a field are the same. For example,
if 90% of the firm's customers live in Albuquerque, use Albuquerque as the
default va lue in the City field.
5. Use a dup licate vnluc function that enables users co insert the value from the
same field in the previous record, bur allow users to turn this feature on or off
as they prefer.
6. Provide a fast-find feature chat displays a list of possible values a11 soon as users
enter the first few letters.
7. Lf available, consider a natural language feature chat allows users to type
commands or rcquesrs in normal text phrases. For example, many applicat1ons allow users to request Help by typing a question into a dialog box. The
software chen uses natural language technology to retrieve a list of topics that
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 8
User Interface Design
236
8.4 Guidelines for User Interface Design
match the request. Narural language technology is used in speech recognition
sy rems, text-to-speech synthesizers, automated voice response sysrems, web
search engines, text editors, and language insrrucrion material~.
8.4.3 Provide Flexibility
Suppose that a user wants a screen display of all customer balances that exceed
$5,000 in an accounts receivable system. How should that featu re be designed? The
program could be coded to check customer bala11ces against a fixed value of 5000,
which is a simple solution for both the progranuner and the user because no extra
keysrrokes are required to produce the display. However, thar approach is inflexible.
A berrer approach would be to let cite user enter the amount. Or Starr wirh a default
value that displays automatically. Users can press ENTER to accept rhc value or type
in another value. Ofcen the best design strategy is to offer severa I alternati ves, so users
can decide what will work best for them.
8.4.4 Provide Users with Help and Feedback
This is one of the most important guidelines because it has a high impact on users.
Never allow Help to slow a user down. Instead, make 1 lelp easy to find but not
around when users don't need it.
I. Ensure that help is always available on demand. Help screens should provide
informarion about menu choices, procedures, shortcut!>, and errors.
2. Provide user-selected help and context-sensitive help. User-selected help displays
information when rhe user requests it. By 1naking appropriate choices through
the menus and submenus, the user eventually reaches a screen with the desired
information. figure 8-7 shows the majn Help screen for the student regiscradon
S)'Srem. Context-sensitive help offers assistance for the task in progress.
Help Topics
Register Studeflts
Print Class Ros1ars
Enter Grades
Print Grade Reports
Index of Help T op1cs
~ct Tedi Supportj
FIGURE 8 -7 The main Help screi!n for a student registration
system.
3. Provide a direct route for users co return co the point from where help was
requeMed. Title every help screen co jdentify the topic, and keep help cext simple and concise. lnserr blank lines between paragraphs to make Help easier ro
read, and provide examples where appropriate.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f •,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
8.4 Guidelines for User Interface Design
237
4. Include conrnct information, such as a celephone extension or email addres if a
deparrment or help desk is responsible for assisting users.
5. Require user confirmation before data deletion (Are you sure?) and provide a
method of recovering data that is deleted inadvertently. Build in safeguards that
prevent critical data from being changed or erased.
6. Provide an "Undo" key or a menu choice rhar allows rhe user to undo rhe
results of rhc most recent command or action.
7. When a user-entered command contains a11 error, highlight the erroneous
part and allow the user to make the correction without rerypmg the entire
command.
8. Use hypertext links to assist users as rhey navigate help topics.
9. Display messages ac a logical place on the screen, and be consistent.
10. Alert users ro lengthy processing rimes or delays. Give users an on-screen progress report, especially if the delay is lengthy.
11. Allow messages to remain on the screen long enough for users to read them.
ln some cases, the screen should display messages until the user takes some
action.
12. Let the user know whether the task or operation was successfu l or not. For
example, use messages such as Update cornpleted, All transactions have been
posted, or The ID Number iuas not found.
13. Provide a text explanation if an icon or image is used on a control button.
This can be accomplished using a "mouse hover" to displar a pop-up box with
explanation when the mouse is moved over an icon or image.
14. Use messages that arc specific, understandable, and professional. Avoid messages that arc cute, cryptic, or vague, such as ERROR-You have entered a11
unacceptable L'alue, or Error DE-4-16. Better examples are as follows:
• l:.nter a number from 1 (low) to 5 (high)
• Customer 1111111ber 11111st be 1111meric
• Please re-enter a numeric LJalue
• Oil/ the Acco1111ti11g Department, Ext. 239 for assistance
8.4.5 Create an Attractive Layout and Design
This is a subjective area because reasonable people can differ on what is attractive.
The analyst should consider color, layout, and ease of use. Screen mock-ups and menu
trees can be created and tried on users to gee thei:r input. If in doubt, err on the side of
doing a bit less. For example, blinking messages initially may seem like a good idea,
they might noc be the best choice for the interface design. Also try to avoid too many
fonts, styles, and sizes, which can be distracting. Each separate style should communicate something-a different level of detail, another copic, mandatory versus optional
actions, and so on.
1. Use appropriate colors to highlight different areas of the screen; avoid gaudy
and bright colors.
2. Use special effects sparingly. For example, animation and sound might be
effective in some situations, but too many special effects can be distracting and
annoying to a user, especially if he or she must view them repeatedly.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
--
........... ......
"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ..... ......... ~..
__....
~~·~--- - ···---~~ - .,.-" ~
Chapter 8
User Interface Design
238
8.4 Guidelines for User Interface Design
3. Use hyperlinks that allow users to navigate to related topics.
4. Group related objects and information. Visualize the screen the way a user will
see it, and simulate the tasks that the user will perform.
5. Screen density is important. Keep screen displays uncluttered, with enough
white space co create an artracrive, readable design.
6. Display titles, messages, and instructions in a consistent manner and in the
same general locations on all screens.
7. Use consistent terminology. For example, do nor use the terms delete, cancel,
and erase co indicate the same action. Similarly, the ame sound always should
signal rhe same evenr.
8. Ensure that commands always will have the same effect. For example, if the
BACK control button returns a user to the prior screen, rhe BACK command
always shou ld perform that function throughout the application.
9. Ensure that similar mouse actions will produce the same results throughout
the application. The resu lts of pointing, clicking, and double-clicking should be
consistent and predictable.
l 0. \Xlhen the user enters data tha;c completely fills the field, do not move au tomatically co the next field. Instead, require the user to confirm the entry by pressing
the Enter key or Tab key at the end of every fill-in field.
I I. Remember that users are accustomed to a pattern of red stop, yellow caution, and green =go. Stick to that partern and use it when appropriate to reinforce on-screen instructions.
12. Provide a keystroke alternative for each menu command, with easy-to-remember
letters, such as File, Exit, and Help.
13. Use familiar commands if possible, such as Cur, Copy, and Paste.
14. Provide a \Vindows look and feel in the interface design if users are familiar
with Windows-based applications.
15. Avoid complex terms and technical jargon; instead,
select terms that come from ever)•day business processes and the vocabulary of a typical user.
=
___...._............
__
... __.... .
_,.,,.,..
.............
__
....
-
8.4.6 Enhance the Interface
A designer can include many features, such as menu bars,
roolbars, dialog boxes, text boxes, toggle buttons, list
boxes, scroll bars, drop-down list boxes, oprion burrons,
check boxes, command buttons, and calendar controls,
among others. Screen design requires a sense of aesrhctics as well as technical skills. U er feedback should be
obtained early and often as the design process continues .
...,..,.
..
FIGURE 8 -8 An e~mple of a switchboard introducing
TurboTax. The main options are tlearly displayed on an
uncluttered screen-something particularly Important for
users who are hkcly to be confused and/or ner<0us when
beginning the iax preparation process.
Souttg •
•,
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
=
~- )U,
..,...,.......,..~
1. The opening screen is especially important because it
introduces the application and allows users to view the
primary options. The starting point can be a ~witchboard
with well-placed command buttons that allow users to
navigate the system. Figure 8-8 shows the switchboard
of TurboTax introducing a tax preparation program.
The main options are clearly displayed on an uncluttered
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
239
8.4 Guidelines for User Interface Design
screen. The addition of che picrure showing cax professionals ready co help
provides a en e of calm and confidence co che user-someching parricularly
imporcanc for users who are likely co be confused and/or nervous when beginning the cax prepararion process.
2. Use a conunand buHon co initiace an action such as printing a form or requesting help. For example, when a user clicks the Find Student command button in
Figure 8-9, a dialog box opens wich instructions.
-
•
- ..
STUDENT REGISTRATION SYSTEM
r
Cont.ct IT Help at Ext. 2236
for user support
-..1cv...
2019-2020
City New Hope
E2I AdYhof Aj•ls~
Liil N•nwt H.amftton
ST PA
!atr•n.al~t Olt
rlot N..,.e R...,
Zlp l2J45
SSH 111.. 11.. 11 11
• rvll TlrM
HornePo"°""(S55)9"--
MI M ,
Street 607 w..15princ Strfft
O PMITune
Worll Pl>oM (555) SU--
Courses
Pref ·
MAT
OS
IUS
-·
x
0
• Nutnbel • SKtJon •
lU
2
l
Find Student
Print Record
HELP
-- ,_-r-ltudtnU
"'~""'
-by•h«llrit U., ol
Fond~
• P!Nse
a
x
ent~ a SocYl Security Numbe<.
use the format w u ·UU.
FIGURE 8-9 A dar.a enrry screen for a student registration system.This screen uses several design reacures
that are described in the text. When a user dicks the Find Student command button. a dialog box ls displayed
with instructions.
3. If a sofcware p:ickage is being used, check ro sec if it allows the creation of
cu:.tomized menu bars and coolbars. lf so, consider these opcions.
4. Add a shorccuc feature chac Ices a user select a menu command either by
clicking the desired choice or by pressing the Alt key+ the underlined letccr.
Some forms also use a coolbar that contains icons or buttons that represenc
shortcucs for cxecucing common commands.
5. lf variable inpuc daca is needed, provide a dialog box chat explains what is required.
6. A toggle bunon makes it easy to show on or off stacus-dicking che coggle
button switches co the ocher stare.
.........""_.. ... .-.................
_..__ ...................
("..,_..., llll!O( ...... . . - - . .\) ....... ~ "-> -
--
........... ......
"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ..... ...... ... ~..
__....
~~·~---- ···---~~ - .,.-" ~
Chapter 8
User Interface Design
240
8.4 Guidelines for User Interface Design
7. Use liq boxe~ rhar display rhe ava ilable choices. If rhe lisr docs n ot fir in rhe
box, a scro ll bar allows the user ro move through the available choices. Also, be
sure ro provide another way ro enter data rhat does not align with a specific lisr
choice.
8. Use an option b utton, or radio bunon, to control user choices. For exa1nple,
if the user can select only one option, display a smtable message (Choose one
item), but if chere is no restriction, display a d ifferent message (Choose all that
apply). Use a black dot to show selected options.
9. If check b oxes are used to select one or more choices from a group, show the
choices with a checkmark or an X.
10. \Xlhen dares must be entered, use a calendar control that allows the user to
select a dare that rhe system will use as a field value.
8.4. 7 Focus on Data Entry Screens
Data entry is especially important because it is in rh e job description of so many users.
I. Whenever possible, use a data entry method called form filling, where a blank
form that duplicates or resemb les rhe sou rce document is completed on the
screen.
2. Restrict user access ro screen locarions where data is entered. For example, in
the Eventbrirc event manage ment data entry when rh e screen in Figu re 8-10
appears, the sysrem should position the insertion point in rhe first data enrry
location. After rhe operator enters an event ride, rhe insertion point should
move auroma rically ro the enuy location for rhe next field (Location ). A user
should be able to position che insertion poinr only in places where data is
enrcrcd on rhe form.
4 I
--- -. o --
I
...
-- ----·-----a--
. -.....
-,_
FIGURE 8-10 In this data entry screen for creating ewints. the system generates start and end
dates and times automatically, but these can be changed by the user at any time.A red asterisk, as
shown beside Event Title, indicates required fields. Gray text within the data entry field leis the user
know what information to provide.This text is replaced with user input.
,......,
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,...... .,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
__.~~ c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
241
8.4 Guidelines for User Interface Design
3. Provide a way ro leave rhe data enrry screen ar any time without entering the
current record, such as a "Cancel" burron. Since che application shown in
Figure 8- I 0 is web based, chis can be accomplished by selecting the" Back"
bunon of rhe browser (not shown).
4. Provide a descriptive caption for every field, and show the user where co enter
the data and che required or maximum field size. Typically, wluce boxes show
the location and length of each field. Other methods used to indicate field locations are video highlighting, underscores, special symbols, or a combination of
these features.
5. Provide a means for users co move among fields on the form in a standard
order or 111 any o rde r the) choose. In a GUI, the user can override the standard
field order and select field locations using the mouse or arrow keys.
6. Allow users co add, change, delete, and vie'v records. Messages such as Apply
these changes? (YIN) o r Delete this record?. (YIN) should requfrc users co
confirm the accions. Highlighting che letter N as a defaulc response will avoid
problems if the user presses the Enter key by mistake.
7. Design rhe screen form layout ro march the layout of the source document. If
the i.ource dc>cumenr fie lds srarr at the mp of the form and run down in a column, the input screen shou ld use the same design.
8. Display a sample format if a user must enter values in a field in a specific format. For example, provide an on-screen instruction ro let users know that rhe
dare format is MMDDYY, and provide an example if rhe user must enter separators, such as slashes.
9. In addition to rhe sample format in che preceding rule, it might be better to
use an mput mas!-, which is a template or pattern that reMricts data entry
and prevents errors. Microsofr Access provides standard input masks for
fields such as dates, telephone numbers, postal codes, and Social Securit)'
numbers. In adduion, custom inpur masks can be c reated, as shown in
Figure 8-1 1. Note char a mask can have a specific format. For example, if a
user enters cext in lowercase letters, che input mask will capitalize the first
letter auromarically.
10. Require an ending keystroke for every field. Pressing the Enter key or che Tab
key should signify the end of a field entry. Avoid a design char moves auromarically 10 rhe next irem when rhe field is full. The latter approach requires an
ending keystroke only when the data entered is less rhan the maximum field
length. It is confusing rouse two different dara entry procedures.
11. Do not require users to type leading zeroes. for numeric fields. For example,
if a three-digit projecr number is 045, rhe operator should be able to type 45
instead of 045 before pressing the Enter key. An exception to that ru le might
occur when entering a date, where a leading zero is needed to identify singledigit monchs or days, such as 06-04-2013.
12. Do not require users to type trailing zeroes for numbers that include decimals.
For example, when a user rypes a value of 98, the system should interpret che
value as 98.00 if the field has been formatted to include numbers with rwo
decimal places. The decimal point is needed only ro indicate nonzero decunal
places, such as 98.76.
13. Display default values so operators can press the Enter key to accept the suggested value. If the default value is not appropriate, the operator can change ir.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 8
User Interface Design
242
8.4 Guidelines for User Interface Design
. .
..l_..... ............
-
Hllp
p
......,..__ ...........
__---.-----............. -
...........
...
-.,__
..........__ .......... ..
.........................................
---__..,.
-- -·-__
....... ..........
... ..............
--- .........
________
,..
.,..,,
....c- ... _.,.....__ ... ......,....._ ....
._,
- . . . . - - - - - - - . . . . . . c -.. - • • •
__...
Q:li. \lt- tti.l
_.,
--~---__,.
...................... ......,....,..
~
~"---~
-.---................
- -...
Htlp
...
•
. .
p
•
uw..._.. ....... .i . . .
t
u... ................
'----·-
llW•-·-..
* ................
.. ..............
..._ __ ........ _
..
'
.,...
~---·-
FIGURE 8 -1 1 MicrosoftAccess provides various input masks
for dates, phone numbers, and postcodes, among others. In
addition, it is easy to create a custom mask using the characters
shown here.
56u~e1 ~ e,....~7.00tl'
14. Use a default value when a field value will be constant for successive records or
throughout rhe data entry session. For example, if records are input in order by
dace, the dare used in che first transaction should be used as the default date until
a new date is entered, at which time the new date becomes the default value.
15. Display a list of acceptable values for fields, and provide meaningful error
messages if the user enters an unacceptable v:ilue. An even better method, which
was described under Rule 5: Enhance the Imerface, is co provide :i drop-down list
box containing acceptable values that allows the user co select a value by clicking.
16. Provide users with an opportunity to confirm the accuracy of input data before
entering it by displaying a message such as, Add this record? (YIN). A positive
response (Y) adds the record, clears the entry fields, and position~ rhe insertion
point in the first field so the user can input another record. If rhe response is
negative (N), the current record is nor added and the user can correct the errors.
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, ..,...,.......,..~
r..a...w...,..._...., ..
Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
.................,.t11ru ..
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
243
8.4 Guidelines for User Interface Design
Dara enrry screens should also anricipare furure needs. Consider a parts invenror}'
database rhar contains a one-character field for category, such as elecrrical, mechanical, or hydraulic. The design works well, bur whar if rhe compan)' decides ro break
these overall groups down inro more specific segmenrs? A bener design would anticipate pos~ible expansion ro two or more characters. For example, in 1999, there was
widespread concern about whar was called rhe Y2K issue because many older programs used only rwo characters co store the year and might not recogni1e the start of
a new century.
8.4.8 Use Validation Rules
Reducing inpur errors improves data quality. One way to reduce input errors is to
eliminate unnecessary data entry. For example, a user cannol misspell a customer
name if i1 is not entered or is entered automatically based on the user enrering the
customer ID. Similarly, an outdated item price cannot be used if the item price is
retrieved from a master file instead of being entered manually. The best defense
against incorrect dara is to identify and correct errors before they enrer the sysrcm by
using data validation rules, as shown in Figure 8-12. A data validation rule improves
input quality by testing rhe data and rejecting any entry that fails to meet specified
conditions. The design can include at least eight types of data validation ru les.
•
p
.......
-...
~-------
--___
•
...,,
...____
..... _....
..
,...,._
.....
_____
....-----.-.----.__.....,.
...-... ..._
.. _
.....____..,
-·-
._._
--~
-
........
_.....
-......
•
•
..
,.... . . _.....__.._.._...............
. ---......... ..•,....,_
•
l!OJ • _ _ _ _ ..._
-·•mtiau
- ..........
. __._
............. -_...51111
~
-~
..... .._,
s... ........................ _............
____ ,,,,. _ _ _ _
- - - - ...- •4 ... - - - - - -
........-
.......,......
FIGURE 8-12 Microsoft Access provides varidauon rules that
can improve daa quality by requiring the input to meet specific
requirements or conditions.
-
.........""_.. ... .-.................
c
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
--
........... ......
"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ..... ...... ... ~..
__....
~~·~----··----~~ - .,.-" ~
Chapter 8
User Interface Design
8.4 Guidelines for User Interface Design
244
I. A sequence check can be used when the data must be in some predetermined
sequence. If the user musr enter work orders in numerical sequence, for example,
then an our-of-sequence order number indicates an error, or if rhe user must
enter transactions chronologically, then a transaction with an out-of-sequence
dare indicates an error.
2. An existence check can apply to mandatory data items. For example, if an
employee record requires a Social SecUiity number, an existence check would
not a llow the user to save the record until he o r she enters a suitable value in
the Social Security number field.
3. A da ra I ) pc check can rest to ensure that a data item fits the required data
type. For example, a numeric field must have on ly numbers or numeric symbols, and an alphabetic field can contain only the characters A through Z (or a
through z).
4. A ra nge check can be used to verify that data items fall between a specified
minimum and 1naximum value. The daily hours worked by an employee, for
example, must fall within the range of 0 to 24. When the validation check
involves a minimum or a maximum value, but nor both, it is called a limit
check. Checking t hat a payment amount is greater than zero, but not specifying
a maximum value, is an example of a limit check.
5. A reasonableness check identi fies values that are questionable bur not necessarily wrong. For example, input payment values of $0.05 and $5,000,000.00
both pass a simple limit check for a payment value greater than zero, and yet
both values could be errors. Similarly, a daily-hours-worked value of 24 passes
a 0 to 24 range check; however, the v:tlue seems unusual, ,1nd the system should
verify it using a reasonableness check.
6. A validi ty check can be used for data items that muse have cerrain values. For
example, if an invenrory system has 20 valid item classes, then any input item
that docs nor march one of the valid classes will fail rhe check. Verifying that
a cusromer number on an order marches a customer number m rhc customer
file is another rypc of validity check. Because the value entered musr refer ro
another value, tha t type of check also is called referential integrity, which is
explained in Chaprcr 9, Dara Design. Another validity check might verify thar a
new cusromer number does nor march a number already stored in the customer
master file.
7. A combina tion check is performed on rwo or more fields to ensure that they
arc consistent or reasonable \Vben considered together. Even though all rhe
fields involved in a combination check might pass their individual validarion
checks, rhe combination of the field values might be inconsistent or unreasonable. For example, if an order input for 30 units of a particula r item has an
input discount rate applicable on ly for purchases of I 00 or mo re units, then
the combination is inval id; either the input order quantity or the input discount
rare i~ incorrect.
8. Barch controls are totals used to verify batch input. Batch controls might check
data items such as record counts and numeric field torals. For example, before
entering a batch of orders, a user might calculate the total number of orders
and rhe sum of all the order q uantities. When the batch of orders is entered,
the order system also calculates the same two totals. lf the system corals do
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
245
8.4 Guidelines for User Interface Design
nor match the input totals, then a data entry error has occurred. Unlike rhe
other validation checks, batch controls do nor idenrify specific errors. For
example, if the sum of all the order quantities does not march rhe batch control
total, the only thing known is that one or more orders in that batch were
entered incorrecrly or nor input. The batch control totals often are called ha ~h
total ~ because they are nor meaningful numbers themselves but are useful for
comparison purpo~es.
8.4.9 Manage Data Effectively
In addition to irs effect on users, data management impacrs company efficiency, producriviry, and security. To reduce input errors, the system should enter and verify dara
as soon as possible, and each dara irem should have a specific rype, such as alphabetic, numeric, or alphanumeric, and a range of acceptable values.
It is important ro collect inpur dara as close to irs source as possible. For insrance,
using barcode scanners r:icher rhan manual forms on a warehouse freight dock, or
having sa lespeople use rablers to record orders rather than filling in source documents. The easiest, mosr accur:ire, and least expensive dara input strategy is automated dara capture.
In an efficient design, data is en tered only once. For example, if input data for
a payroll system also is needed for a human resources system, the analyse could
design an interface co transfer data automatically, or a central data storage area
could be created char both systems can access. Chapter 9 describes normalizarion,
which is a sec of rules chat can help avoid data design problems. A secure sysrem
also includes audit trails rhat can log every instance of data entry and changes.
For example, the system should record when a customer's credit limit was sec,
by whom, and any ocher information necessary to consrruct the history of a
transaction.
8.4. 10 Reduce Input Volume
This is the final guideline, bur in some ways it sbouJd be the first because it affects all
the resr. When input volume is reduced, unnecessary labor coses are avoided, which in
turn gets the data inro rhe system more quickly and decreases the number of errors.
Therefore, the analyst should start by reducing the number of data items required for
each transaction.
1. Input necessary data onl)•. Do not input a data item unless it is needed by the
system. A completed order form, for exaJnplc, might contain the name of rhe
clerk who took rhe order. If that data is not needed by the system, the user
should nor enter it.
2. Do nor input dara rhar rhe user can retrieve from system files or ca lculate from
ocher dara. This reduces input errors and dara inconsistencies.
3. Do not input constant dara. lf orders are in batches with the same date, then
a user sho uld enter the order date only once for the firsr order in the batch. If
orders are entered online, then the user can retrieve the order date automatically using the current sysrem date.
4. Use code~. Codes arc shorter than the data they represent, and coded input can
reduce data entry rime. Codes are discussed more in Chapter 9.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 8
U ser Interface Design
8.5 Source Document and Form Design
246
CASE IN POINT 8.2:
BOOLEAN TOYS
Suppose you are a systems analyst swdying the order processing system at Boolean Toys. a
fast-growing developer of software for preschool children. You know that many data entry
users have complained about the input screens. Some users would prefer to rearrange the
order of the fields. others would like to change the background color on their screens. and still
others want shortcuts that would allow them to avoid a series of introductory screens.
What if Boolean's users could customize their own data entry screens without assistance from the IT staff by using a menu-driven utility program? What wou ld be the pros
and cons of such an approach1When should a systems analyst decide a design issue, and
when should users be allowed to select what works best for them?
8.5 SOURCE DOCUMENT ANO fORM DESIGN
No marrer how data enters a n information system, the quality of the output is
only as good as the quality of the input. The term garbage in, garbage out (G IGO)
is fami liar to IT professionals, who know that the best time to avoid problems
is when the data is entered. The main objective is to ensure the quality, accuracy,
and timeliness of input data. Unfortunately, the dream of a "paperless office" has
never been realized. Even with RFlD technology and automated data capture, we
still enter data on source documents and fo rms, and instead of a human-computer
interface, systems analysts muse deal with the challenge of a human-paper
interface.
A ~ource document collects inpur dara, rriggers or authorizes an input acrion,
and provides a record of the original transaction. During the input design stage, the
analyst develops source documents that are easy to complete and u e for dara entry.
Source documents generally are paper based but also can be pro,ided online. Eicher
wa)', the design considerarions are che same.
Consider a rime when it was a srruggle to complete a poorly designed form. There
mighc have been insufficient space, confusing instructions, or poor organ1.l.3non-all
symptoms of incorrect fonn layout.
Good form la)'OUt makes the form easy to complete and provides enough space,
both vercically and horizonrally, for users to enter the data. A form should indicate
data entry positions clearly using bla nk lines or boxes and descriptive captions. Also
consider using check boxes whenever possible, so users can select choices easily. However, be sure to include an option for any input that does not match a specific check
box.
The placement of information 011 a form a lso is important. Source documents
typically incl ude most of the zones shown in Figure 8-13. The heading zone
usua lly contains the company name or logo and the title and number of the
form. The control zone contains codes, identification information, numbers, and
dates rhat are used for storing completed forms. The instruction zone contains
instructions for completing rbe form. The main part of the form, called rhe body
zone, usually cakes up at least half of the space on the form and contains captions
and areas for entering variable data. If rota ls are included on the form, they
appear in the totals zone. Finally, the authorization zone contatns any required
signatures.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Phase l
Systems Design
24 7
8.6 Print ed Output
Heading
Control
Zone
Zone
lnstructioo Zone
Body
Zone
Totals
Zone
Authorization Zone
FIGU RE 8- 13 Source document zones.
lnformanon shou ld flow on a form from left co right and top to bottom to match
the way users read documents naturally. That layout makes the form easy to use for
the individual who completes the form and for users who enter daca into the system
using the completed form.
The same user-friendly design principles also apply to printed forms such a~
invoices and monthly statement , except that heading information usuall)' 1s preprinted. Column headmgs should be short but descriptive, avoiding non!>tandard
abbre\lat1on!>, wtch reasonable spacing becween columns for bener readability.
The order and placement of printed fields should be logical, and totals should be
identified clearly. When de~igning a preprinted form, contact the form's vendor for
advice on paper sizes, rype styles and sizes, paper and ink colors, field placement, and
other important form derails. The goal is to design a form that is anractive, readable,
and effective.
Layout and design a lso are important on web-based forms. TI1ere arc many
resources that will help with designing efficient, user-friendly forms. These include
websites that muse conform to the U.S. Federal Government's accessibi lity guidelines,
which can be found o nline ar http://www.section508.gov.
8.6 PRINTED OUTPUT
Before designing printed output, there arc several questions to consider:
•
•
Why is this being delivered as printed output, rather than screen-based information, with an option for users to view, print, or save as needed?
\'<'ho wants the information, why is it needed, and how will it be used?
•
•
\'<'hat specific informarion will be included?
\'V1ll the printed output be designed for a specific device?
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 8
User Interface Design
248
8.6 Printed Output
•
•
When and how will the information be delivered, and how ofren must it be
updated?
Do security or confidentialiry issues exist? How will they be managed?
The design process should not begin until these questions have been answe red.
ome information probably was gathered during the systems analysis phase. To gain
more understanding, the analyst should meet with users to find out exactly what kind
of output they are requesting. Prototypes and mock-ups can be u~ed to obtain feed back throughout the design process.
8.6. 1 Re port Design
Although many organizations strive to reduce the flow of paper and printed reports,
few firms have been able to eliminate printed output totally. Because they are porrable, printed reports are convenient and even necessary io some situations. Many users
find it handy to view screen output and then print the information they need for a
discussion or business meeting. Prinred output also is used in turnaround documents,
which :ire output documents rhat are later entered back into the sa me or another
information system. In some areas, the telephone or utility bill, for exa mple, might be
a turnaround document printed by the company's billing system. When the required
portion of rhe bill is returned with payment, rhe bil l is scanned into the company's
accounts receivable system to record the payment acc urately.
Designers use a variety of styles, fonts, and images ro produce reports that arc
attractive and user-friendly. Whether printed or viewed on-screen, reports must be
easy to read and well organized. Rightl y or wrongly, some managers judge an entire
project by the quality of the reports t hey receive.
Databa~e programs such as ~1icrosofr Access include a variery of report design
tools, including a Re port Wizard, which is a menu-driven fearure that designers can
use to create reports quickly and easily. Many online web-based database systems also
provide similar report design guidelines.
Although the vast majorit}' of reports are designed graphically, some S)'Stems srill
produce one or more ch aracter-based reports that use a characcer set with fixed spacing. Pruning character-based reports on high-speed impact pnncer~ 1s a fasr, inexpensive method for producing large-scale reports, such as payroll or mventory reports, or
registra tion rosters at a school. This is especially true if multiple copie :ire required.
Users should approve all report designs in advance. The best approach is ro prepare a sample report, called a mock-up, or prototype, for users to review. The sample
should include typical field values and contain enough records to show all the design
features. Depending on the type of printed output, a Microsoft \"Qord documenc can
be created, or a report generator used, to create mock-up reports.
8.6.2 Re port Design Principles
Printed reporrs must be att ractive, professional, and easy to read. For example, a
well-designed report should provide totals and subtotals for numeric fields. In the
reporr shown in Figure 8- 14, nore thar when the value of a control field, s uch as Store
Number, changes, a control break occurs. A control break usually causes specific
actions, such as printing subtotals for a gro up of records. Thar rype of derail report is
called a control break repo rt. To produce a control break report, the records must be
arranged, o r sorred, in control field order.
Good report design requires effort and attention to detail. To produce a welldesigned report, the analyst must consider design features )uch as reporr headers and
footers, page headers and footers, column headings and alignment, column spacing,
field order, and grouping of detail lines.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
249
8.6 Print ed Output
REPORT HEADER.S AND FOOTERS: Every report should have a report header and
a report footer. The report header, which appears at the beginning of the report, identifies the report and contains the report title, date, and other necessary information.
The report footer, which appears ac che end of rhe report, can include grand totals for
numeric fields and ocher end-of-report information. as shown in Figure 8-14.
Every page should include a page header, which
appears at the rop of rhe page and includes the column headings that identify the
PAGE HEADERS AND FOOTERS:
lden~fying ftelds
hours fields
Employee Hours
Week end ing date: 6128/2019
Store
Number
Emp loyee
Name
Position
Regular
Hours
Overtime
Hours
Total
Hours
8
8
8
8
8
8
Andres, Marguerite
Bogema, Michelle
Davenport, Kim
Lemka, Susan
Ramirez, Rudy
Ullery, Ruth
Clerk
Clerk
Asst Mgr
Clerk
Manager
Clerk
20.0
12.5
40.0
32.7
40.0
20.0
0.0
0.0
5.0
8.5
0.0
20.0
12.5
45.0
32.7
48.5
20.0
Store 8 totals:
165.2
13.5
178.7
Clerk
Manager
Cterk
Clerk
Clerk
40.0
40.0
40.0
20.0
32.0
8.4
00
11 0
00
00
48.4
40.0
51.0
20.0
32.0
Store 17 totals:
172.0
19 4
191.4
Grand totals:
337.2
32.9
control break
on Store
Number field
17
17
17
17
17
De Mar!Jnl, Jenniler
Haff Lisa
R1ttenbery, Sandra
Wyer. Elizabeth
Zeogler Cealle
o.o
}
}
report header
page header
}
group footer
370.1
}
report footer
Page 1
}
page footer
FI GU RE 8 - 14 The Employee Hours report is a detailed report with concrol breaks, subtotals, and grand totals. N ote that a report
header identifies the report. a p~ge header contains column headings, a group footer contains subtotals for each score. a report
footer contains grand totals, and a page footer identifies the page number.
data. The head ings s hould be shorr but descriptive. Avoid abbreviations unless the
users will unde rstand them clearly. Either a page header or a page footer, which
appears ar rhe borrom of the page, is used ro display rhe report title and the page
number.
Database programs such as Microsoft Access make it easy ro create groups and
!>ubgroup~ based on particular fields. The report can also calculate and display torn Ii.,
average~, record counts, and orher data for any group or subgroup. For example, a
large company might want to see total sales and number of sales broken down by
product within each of the 50 stares. The information shown in Figure 8-15 is part
of Acct!l>!>' on line help that refers co a step-by-step process for creating multilevel
group mg.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 8
User Interface Design
8.6 Printed Output
250
Create a grouped or summary report
OOt....
-'019.-20•8,-2t!1--~ !),
lnlonna1lon IS often ID undlnland when~ IS inlO groupL For_,_., . report lhet groups
by NglOn can hlgllloghl tnnds tNll ,,._,.. moghl go u11110Ciced In lddi1'0t\ ~ tOCllll c.ICh a
...... or a>•~ ot lhl tnl ol wh graup., your repor1 can replKe a lol ol menuel ln!inclO'l ,..th 1
ClbAa!or
.-.:c.a mel;ee worldng "'"" giouped teports 911SY. 'lb.I Cll1 . . . . . . bulc grouped report by ...ng lhl
~ Wlzald. )IOU can edd ~ng and son.>g to an OXlltJng t9pOtl. or )IOU can -
grouping and
IOt""O Oll(IOnt tnet have en.ly been dellned.
Not•: Tl* -
_ , , llllPll'
pUllll9l1 Ol'lllne
"'----tho
kind"' d i ! _ you deolgn- -
.,.,
In this article
C..ata a quick grouped or sorted report
Build 1 new grouped report by us.ng the Report Wlzatt:I
Acid or modlly Q""""'111 and sort.ng in an elOSbng report
FIGURE 8 - IS MicrosoftAccess includes an easy-co-use tool for grouping data.
Sourc:.. M roi a-- r "'P'
.JOfl
REPEATING FIELDS: Report design is an art, noc a science. User involvemcnc is
csscnrial, hue users ofcen don'r know whar they want without seeing samples. for
example, consider che issue of repeating fields. The sample report in Figure 8- 14
repeats the store number on every row. Is chat a good thing? The best advice is co ask
users what they think and be guided accordingly. A similar issue exiscs with regard to
the overtime hours column. ls ir bener co print the zero·O\'ertime data, or only print
actual hours, so che data srands our clearly? Again, the best answer is usually the one
that works best for users.
CONSISTENT DESIGN: Look and feel are important to users, so reports should
be uniform and consiscenr. When a system produces multiple reports, each reporr
should share common design elements. For example, the date and page numbers
should print in the same place on each report page. Abbreviations used in reporcs also
should be consistent. For example, when indicating a ntuneric value, it is confusing
for one reporc to use#, anorher NO, and a chi.rd NUM. ltems in a report also should
be consistent. ff one report displays the inventor)' location as a shelf number column
followed by a bin number column, that same layout should be used on all inventory
location reports.
8.6.3 Types of Re ports
To be useful, ::i report must include the information that a user needs. From a user's
point of view, a report with too Little information is of no value. Too much information, however, can make a report confusing and difficult to understand. When design·
ing reports, the essential goal is ro match the report co the user's specific informarion
needs. Depending on rhcir job functions, users might need one or more of the reports
described in rhe following sections.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
251
8.7 Technology Issues
DETAIL REPORTS: A derail report produces one or more lines of ourpur for each
record processed. Because it contains one or more lines for each record, a derail
report can be quite lengthy. Consider, for example, a large auto parts bu5iness. If the
firm stocks 3,000 parts, then rhe derail report would include 3,000 derail lines on
approximately 50 printed pages. A user who wants to locate any part in short supply
has ro examine 3,000 derail lines ro find the critical items. A better alternative might
be an exceprion reporr.
EXCEPTION REPORTS: An exception report displays only those records that meet
a specific condinon or conditions. Exception reports are useful when the user wanrs
information only on records char might require action bur does not need to know the
derails. For example, a credit manager might use an exception report ro identify only
those customers with pasr-duc accounts, or a customer service n1anager might want a
report on all packages tha t were not delivered wi-rhin a specified time period.
SUMMARY REPORTS: Upper-level managers often wa nt ro sec toral figu res a nd do
nor need supporting details. A sales manager, for example, might want ro know total
sales fo r each sa les representa tive but not want a derail report listing every sale made
by them. In rhat case, a ~ ummary report is approp riate. Simila rl y, a personnel 111:111ager might need ro know the rota I regular and overtime hours worked by employees
in each store bu r might nor be interested in the number of hours worked by each
employee.
CASE JN POINT 8.3:
L AZY EoorE
Lazy Eddie is a furniture chain specializing in recliners. Their management has asked you to
review the large number of printed reports that are distributed to Lazy Eddie's 35 store
managers. Management is not sure that the managers actually read or use the reports,
even though the store managers say they want them. Store visits have shown many of the
reports end up sucked on top of filing cabinets. seemingly untouched.
To determine if store managers really use the p rinted reports. management has asked
you to create a procedure that requires users to review and justify their information
needs. You could design a form that asks if the information still is required, and why. You
could try to get users co decide if a report is worth che cost of producing it. How do you
proceed!
8. 7 TECHNOLOGY Issues
Unlike early innovations such as the mouse and the inkjet printer, most tech nology
advances today affect both output and input. In a very real sense, output and input
have become interdependent, as rhey are in a user interface, and it is difficult to cite
examples of changes in one that wo uld acn cause, or at least encourage, changes in
the other. For example, new touch-screen input technology generates output that
must be properly designed and sized for a panicllllar device, which might be a smarcphone, a tablcr, or a 23-inch desktop monitor.
The following sections discuss outpur and input technology separately, bur interface designers should always be al ere to the possible opportunities, or potential problems, of input/output linkage.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ . ....._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... .., .,. ..,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Chapter 8
User Interface Design
252
8.7 Technology Issues
8.7.1 OutputTechnology
Alrhough business information systems srill provide mosr output as screen di~plays
and printed matter, technology is having an enormous impact on how people communicate and obtain information. This rrend is especial!)' important ro firms char
use informarion technology to lower their costS, improve employee producriv1ry, and
communicate effectively with their customers.
In addirion to screen output and printed matter, output can be delivered m many
wa)'S. The system requirementS document probably identified user output needs.
Now, in the systems design phase, rhe analyst creates the actual forms, reports, documents, and orher rypes of output that might be accessed from workstarions, notebooks, tablets, smarrphones, and other devices. How the information will be used,
stored, and retrieved must also be considered. The following subsections explain va rious output types and technologies.
INTERNET-BASED INFORMATION DELIVERY: Millions of fi rms use the Internet to
reach new customers and markets around the world. To support rhe explosive growth
in e-commerce, web dcsi&rners must provide user-friendly screen inte rfaces that display
ourpur and nccept input from cusromers. For example, a business can link irs invenmry system to its website so the o urput from the inven tory system is displayed as an
o n line cam log. Customers visiting the site can review the items, obtain current prices,
and check product availabiliry.
Another example of web-based o utput is a system that provides customized
re~ponses to product or technical questions. When a user enters a product inquiry or
requests technical support, the system responds with appropriate information from
an on-site knowledge base. Web- based delivery a llows users to download a universe
of fi les and documents to support their information needs. For example, the web provides consumers with instant access to brochures, product manual , and parts lists,
while prospective homeburers can obtain instant quotes on mortgages, insurance, and
other financial services.
To reach prospective customers and investors, companies also use a live or prerecorded \.. ebcast, which is an audio or video media file distributed over the Internet.
Radio and TV stations also use this technique to broadcast program material to their
a udiences.
Email is an essential means of internal and external business communication. Employees send and receive email on local or wide area networks, including the
Internet. Companies send new product information to customers via email, and financial services companies use email messages ro confirm on line srock trades. Employees
use ema il to exchange documents, data, a nd schedules and to share business-related
information they need to perform th eir jobs. In ma ny firms, email has virtually
replaced traditio nal memos and pri nted correspondence.
EMAIL:
BLOGS: \Xleb-based logs, called biogs, are anorher form of web-based output.
Because biogs are journals written from a particular point o f view, rhey nor only
deliver facts to web readers bur also provide opinjons. Biogs are useful for po~ting
news, reviewing currenr events, and promoting products.
INSTANT MESSAGING: This popular form of communication is another way for
individuals and companies ro communicate effectively over the Internet. Although
some users feel that it can be a distraction, others like rhe constant flow of communication, especially as a team member in a collaborative situation.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
253
8.7 Technology Issues
WIRELESS DEVICES:
~1cssages and data can be transmitted to a wide array of
mobile devices, including rabler computers, smarrphones, and similar wireless produces rhar combine porrable computing power, multimedia capabilit)', and lnterncr
access.
DIGITAL AUDIO, IMAGES, AND V I DEO: Sounds, images, and video clips can be cap-
tured, srored in d1g1ral format, and cransmirred as output to users who can reproduce
the content.
Audio or video ourput can be attached to an email message or inserred as a clip in
a Nlicrosofr \Xlord document. Businesses also use automated systems to handle voice
transactions and provide information ro customers. For example, using a telephone
keypad, a cusromer can confirm an airline seat assignment, check a credir card balance, or derermine rhe current price of a mutual fund.
If a picture i!> worrh a rhousand words, then digital images and video clips certainly are high-value ourpur types char offer a whole new dimension. For example, an
insurance adjuster with a digita l camera phone can take a picture, submit the image
via a wireless device, and receive immediate authorization to pay a claim on the bpOt.
1f unages are a valuable form of output, video clips are even better in some situations.
for example, video clips provide online virtual tours that allow realtors to show off
the best features of homes they are marketing. The user can zoom in or out and rota re
the iJnage in any direction.
An automated fax or f~back sy:.rem allows a
customer ro request a fax using email, via the company website, or by telephone.
AUTOMATED FAX SYSTEMS:
The respon e is transmitted in a matter of seconds back co the user's fax machine.
Although most users prefer to download documents from the web, many established
organizations still offer an automated faxback service as another way to provide
inunediate response 24 hours a day to a certain ser of customers. Certain industries
in particular, such as drug scores and doctor's offices, insurance companies, and real
estate brokers, still rely on fax machines as a primary way of communication.
PODCASTS:
A podcast is a specially formaned digital audio file that can be down-
loaded by internet users from a variety of content providers. Many firms use podcasts
as sales and marketing cools and to communicate witb their own employees. Using
software such as iTunes, users can receive a podcast, launch the file on tbeir computer,
and store it on their porrable player. Podcasrs can include images, sounds, and video.
COMPUTER OUTPUT TO DIGITAL MEDIA: This process is used when many paper
docun1ents muse be sc::inned, stored in digital format, and retrieved quickly. For example, if an insurance company stores rhousands of paper applic::ition forms, special
software can treat the documents as data and extract inforn1ation from a particular
column or area on rhe form. Digita l storage media can include n1agnetic tape, CDs,
DVDs, and high-density laser disks.
An incredibly diverse marketplace requires
many forms of specialized output and devices. For example:
SPECIALIZED FORMS OF OUTPUT:
•
•
Portable, web-connected devices that can run multiple apps, handle multimedia
output, and provide powerful, mulripurpose communication for users
Retail poinr-of-sale terminals rhat handle computer-based credit cord transactions, print receipts, and updare inventory records
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 8
User Interface Design
2 54
8.7 Technology Issues
•
•
Auromaric relier machines (AT Ms) that can process bank transacrions and
print deposir and withdrawal slips
Special-purpose printers rhat can produce labels, employee ID cards, driver's
licenses, gasoline pump receipts, and, in some states, lottery rickets
•
Plotters that can produce high-quality images such as blueprints, maps, and
electronic circuit diagrams
•
Electronic detection of dara einbedded in credir cards, bank cards, and
employee identification cards
8.7.2 lnputTechnology
Input rechnology has changed dramarically in recent years. ln addition ro traditional
devices and methods, there has been a rapid expansion of new hardware and ways to
capture and enter data into a system, some of which are shown in Figure 8-16. Businesses are using the new rechnology to speed up the input process, reduce cosrs, and
capture daca in new forms, such as digital signatures.
INPUT TECHNOLOGY
Traditional
Evolving
Emerging
Keyboard
Body motion detection
Brain-computer interfaoe (BCI)
Mouse
Advanced voice recognition
Neural networks
Polnhng devices
Biological feedback
Arllfcal intelligence (Al)
MicrophOne
Embedded magnetic data
Advanced motion sensors
OCR (optical character
recogn1lion)
RAD
Two-way satellite interface
MICA (magnetic mk character
recognnion)
Advanced opt'Cal recogn&tiOl'I
V1nual environments
Graphic input devices
Physical adaptaoon dev>ees
3·0 tecnnok>gy
FIGURE 8- 16 Input devtees can be very traditional or based on the latest technology.
Input methods should be cost-efficient, timely, and as simple a~ possible. Systems
analysts study transactions and business operarions to determine how and when data
should enter the system. Usually, the first decision is whether to use batch or online
inpul meLhods. Each metbod has advantages and disadvantages, and the systems analyst must consider the following factors.
BATCH INPUT: Using batch input, data entry usually is performed on a specified
rime schedule, such as dai ly, weekly, monthly, or longer. For example, batch input
occurs when a payroll department collcctS rime cards at the end of the week and
enters the data as a barch. Anorher example is a school that enters all grades for the
academic term in a batch.
ONLINE INPUT: Although batch input is used in specific situations, most busi-
ness activity requires o nline data en t ry. The online method offers major advantages,
including the immediate validation and availability of data. A popular online input
method is ~o u rce da ta a uto mation, which combines online dara entry and automated
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
255
8.8 Security and Control Issues
data capture using input devices such as radio frequency idenrificario n(RFID) tags,
magnetic data srrips, or even smarrphones. Source data automation is fast and accurate and minimizes human invokement in the translation process.
~1any large companies use a combination of source daca automation and a powerful communication network to manage global operations insranrl)'· Some common
examples of source data automation are as follows:
•
Businesses that use point-of-sale (POS) terminals equipped with bar code scanners and magnetic swipe scanners ro input credit card data
•
Automatic teller machine (ATMs) that read data srrip on bank cards
•
Factory employees who use magnetic ID cards to clock on and off specific jobs
so the company can track production coSts accurately
•
Hospitals that imprint bar codes on patient identification bracelets and use
portable scanners when gathering data on patient treatment and medic:ition
•
Retail stores that use porrablc bar code scanners to log new shipments a nd
update inventory dara
•
Libraries that use hand held scanners co read optical strips on books
TRADE-OFFS: Although on line input offers man y advantages, it does have some dis-
advanrages. For example, unless source data automation is used, manual data entry
is slower and more expensive than batch input because it is performed at the rime the
transaction occur5 and often done when computer demand is at its highest.
The decision to use batch or online input depends on business requirements. For
example, hotel reservations must be entered and processed immediately, bur hotels
can enter their monthly performance figures in a batch. ln fact, some input occurs
naturally in batches. A cable TV provider, for example, receives customer paymenrs an
batches when the mail arrives.
8.8 SECURITY AND CONTROL Issues
A company must do everything in its power to protect its data. This includes not only
the firm's own information bur that of its customers, en1ployees, and suppliers. Most
assers have a value, bu r corporate data is priceless because without safe, secure, and
accurate data, a company cannot function.
The following sections discuss output and input data security and control.
8.8.1 Output Security and Control
Ourpur must be accurate, complete, current, and secure. Companies use various
output control methods to main rain output integrity and secu rity. For example, every
reporr ~hou ld include an appropriate title, report number or code, printing date, and
time period covered. Reporrs should have pages that are numbered consecutively,
identified <lS Page 1111 of nn, <lnd the end of the report should be labeled cle<lrly.
Control totals and record counrs should be reconciled against input totals and
counts. Reports should be selected at random for a thorough check of correctness <lnd
completeness. All processing errors or interruptions must be logged so they can be
analyzed.
Output ~ecuri ty protects privacy rights and shields the organization's proprietary
data from theft or unauthori.ted access. To ensure o utput securirr, several important
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 8
User Interface Design
8.8 Security and Control Issues
256
tasks must be performed. First, limit the number of printed copies and use a tracking
procedure to account for each copy. \'(Then printed ourput is distributed from a central
location, !>pecific procedures should be used ro ensure th3t the output is delivered to
3Uthonzed recipienrs only. Thar is especially true when reports contam sensirive inform3non, such 3S payroll data. All sensitive reporrs should be stored in secure 3re3s. All
p3ges of confidential reports should be labeled appropriately.
As shown 111 Figure 8-17, it is important to shred sensitive reporcs, our-of-date
reporrs, and output from aborted print runs. Blank check forms must be stored in a
secure loc3tion and be inventoried regularly to verify that no forms 3re missing. If signarure scamps 3re used, they must be stored in a secure locanon away from the forms
storage location.
FIGURE 8 - 17 To maintain output security.it is important to shred sensitive
material.
In most organizations, the IT department is responsible for coordinating output
control and security measures. Systems analyses must be concerned with security
issues as they design, implement, and support information systems. \Xlhenever pos·
sible, security should be designed into the system by using passwords, shielding sensitive data, and controlling user access. Physical security a lways will be necess3ry,
especially in the case of printed output that is tangible and can be viewed and h3n·
died easily.
Enterprise-wide daca access creates a whole new ser of security and control issues.
Many firms have responded to those concerns by installing disk less workstations. A
di ~ klcss wo rkstation is a network terminal that supports 3 full -featured user interface
but limits the printing or copying of data, except to certain network resources rhar
can be monitored and controlled. This concept would typically preclude rhe use of
portable storage devices, such as USB thumb drives.
8.8.2 Input Security and Control
Input control includes the necessary measures to ensure that input data is correct,
complete, and secure. lnput control must be the focus during every phase of input
design, starting with source documents that promote data accuracy and quality. \Vhen
a batch input method is used, the computer can produce an input log file thar identi·
fies and documents the data entered.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
257
8.9 Emerging Trends
Every piece of informarion should be craceabJe back ro the inpur dara rhar
produced ir. Thar means rhe analysr muse provide an audir rrail rhat records rhc
source of each dara ircm and when ir enrered the sysrem. In addirion ro recording
the original source, an audi r rrail must show how and when data 1s accessed or
changed, and by whom. All those actions must be logged in an audic rrail file and
monirored carefull}.
A company must have procedures for handling source documents co ensure char
data is nor lost before ic cnrers che system. All source documents char origmare from
outside rhe organi1.acion should be logged when they are received. Whenever source
documents pass between dcparnnenrs, che transfer should be recorded.
Data securit)' policies and procedures protect dara from loss or damage, which is a
viral goal in every organization. If the safeguards are nor 100% effective, dara recovery utilities should be able co restore lost or damaged data. Once data is entered, che
company should srore source documents in a safe locacion for some specified length
of time. The company should have a records rerention policy that meets all legal
requirements and business needs.
Audit trail files and reports should be stored a nd saved. Then, if a data file is
damaged, the information can be used to reconstruct the lost data. Dara security
also involves protecting data from unauthorized access. System sign-on procedures
should prevent unauchorized individuals from enttering rhe sysrem, and users should
change their passwords regularly. Having several levels of access also is advisable. For
example, a data enrry person mighr be allowed co view a credit Limit but nor change
ic. Sensitive data can be encrypted, or coded, in a process called encryption, so only
users wich decoding software can read ir.
8. 9 EMERGING TRENDS
The user interface conri nues ro evolve. The widespread use of mobile devices such
as the iPad and other tablcrs, coupled with the ubiquiry of the iPhone and ocher
smarcphones, has greacly influenced user inrerface design. lndeed, key user experience
lessons from chese devices have been rcflecced back into the user interface for mainscream operaring sy~rems such as Mac OS X and Microsoft Windows.
le is d1fficulc ro predict the future, but the introducrion of che Apple \Xlacch, G<x>glc's Wear OS, Ficbit's fimess crackers, and other wearable devices promises ro furrher
shake up user incerface design principles. Advanced technology will supporr rhe evolurion, but rhe real driving force will be user empowerment, which re~u lts in customer
:.atisfacrion, increased producrivity, and bottom-Line savings.
8.9. 1 Modular D esign
ln a modular dc~ign , individual compo nenrs, called modules, are created rhat connccr
to a higher-level program or process. In a scrucrured design, each module represents a
specific process, which is shown on a DFD and documented in a process description.
If an object-oriented design is being used, as described in Chapter 6, code modules
rcpresenc classes. Modula r design is explained in more detail in C ha peer I I, which
describes systems implemenrarion.
Modules should be designed ro perform a single funcrion. Indcpendenc modules
provide grearcr Aexihiliry because they can be developed and rested individually and
rhen combined or reused larer in che developmem: process. ~1odular design is especially imporranr in designing large-scale systems because separare reams of analysrs
and programmer can work on different a reas and then integrate the resulrs.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 8
User Interface Design
258
8.9 Emerging Trends
8.9.2 Responsive Web Design
Today's conccnc is viewed by users on mulriple devices: compucers, cablcts, and smartphones. Each device has irs own form factors char can limir rhe user experience. For
example, rhc physical dimensions of a smartphone preclude rhe use of wide mcnusw1thour forcing rhe user to scroll horizontally coo much.
Responsive web design is an emerging trend chat renders web concent properly,
independencly of rhe device in use. This means the developer only has to focus on
essential user incerfoce issues; how che GUI arrifoccs are presented on che device
is handled automatically by the underling framework. Responsive web design
addre ses various nonfunctional anribuces, including usability, performance, and
maintainability.
Responsive web design relies on a number of underlying technologies, including
CSS3, flexible images, and fluid grids. Page clements are expressed in relative ccrms
(e.g., perccnragcs), racher than absolute cerms (e.g., pixels). This a llows rhe conrenr to
"flow " properly in the user interface, irrespective of the display device.
8.9.3 Prototyping
Prototyping produces an early, rapid ly conscructed working version o f the proposed
information system, called a procotype. Prototyping, which involves a reperirive
sequence of analysis, design, modeling, and testing, is a common technique rhac can
be used co design a nything from a ne w home co a computer network. For example,
engineers use a prororype co evaluate an aircraft design before production begins, as
shown in rhe wind runnel testing in Figure 8- 18.
FIGURE 8- 18 Wind tunnel t esting is a typical example of prototyping.
t-o:J·1.esy off'lAS.A
User inpur and feedback is essenrial ar every srage of the systems devclopmcnr
process. Prororyping allows users co examine a model rhar accurately represenrs
sysrem o urpurs, inpurs, inrerfaces, and processes. Users can " tesr-drivc" rhc model in
a risk-free environmenr a nd eirher approve ir or request changes. In some siruarions,
the protorype evolves inro the final version of rhe information system. In orher
cases, rhc prororype is inrended o nly ro validate user requirements and is disca rded
afterward.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
259
8.9 Emerging Trends
Perhaps the most intense form of prororyping occurs when agile methods are u~cd.
As described in Chapter I, agile methods build a sysrem by creating a series of prototypes and constanrly adjusting them to user requirements. As the agile process continues, developers revise, extend, and merge earlier versions into the final product. An
agile approach empha~i1es continuous feedback, and each incremental step •~affected
by what was learned in the prior steps.
Systems analysts generally use two protoryping methods: system protoryping and
design protoryping.
SYSTEM PROTOTYPING: System prototyping produces a full-featured, working
model of the information system. A system prototype that meets all requirements is
ready for implementation, as shown in Figure 8-19. Because the model is "on track"
for implementation, it is especially important to obtain user feedback and to be sure
that the prototype meets all requirements of users and management.
Planning
/
Implement
the system
FIG URE 8- 19 The end product of system prototyping is a working model of
the information system. ready for proper implementation.
DESIGN PROTOTYPING: Systems analyses also use protoryping to verif)' user
requirements, after which the procorype is discarded and implementation continues.
The approach is called design protot)'ping, or throwaway prototyping. ln this case,
the prororyping objectives arc more limited but no less important. The end product
of design procoryping is a user-approved model tha t documents and benchmarks the
features of the finished system. Design prototyping makes it possible ro capture user
input and approval while continuing co develop the system within che framework of
the SDLC. Systems analyses typically use design prototyping as they construct outputs, inputs, and user interfaces.
TRADE- OFFS:
Prororyping offers many benefits, including rhe following:
•
Users and systems developers can avoid misunderstandings.
•
System developers can create accurate specifications for the finished system
ba11ed on the prototype.
•
,\ lanagers can evaluate a working model more eHectivelr than a paper
specification.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~----···---~~-.,.-"~
Chapter 8 User Interface Design
8.10 Summary
260
•
•
S>•Stcms analysts can use a prototype ro develop resring and training procedures
before rhe finished sysrem is available.
Prototyping reduces the risk and potential financial exposure char occur when
a finished system fails co support business needs.
Alrhough most systems analysts believe rhar rhe advantages of prororypmg far outweigh any disadvantages, the following porenrial problems should be considered:
•
•
•
•
The rapid pace of development can creare quality problems, which are nor discovered until the finished system is operarionaJ.
Other sysrem requiremenrs, such as reliability and mamtainabiliry, cannot be
rested adequately using a prororype.
In very complex systems, the prototype can become unwieldy and difficult ro
manage.
A client or user might wanr to adopt the prototype with few to no changes,
mistakenl y thinking that the prororype will meet their needs though it may
need further customization, leading to increased maintenance costs later in che
SDLC.
One of the systems analysts on the project team thought that he dad a good job of designing the company's tech support webpage, but his supervisor isn't so sure. His supervisor is
concerned that the design is very similar to a page used by the company's major competitor, and she asked him whether he had used any HTML code from that site in his design.
Although the analyst didn't copy any of the code. he did examine it in his web browser to
see how they handled some design issues.
The supervisor asked the analyst to investigate webpage copyright issues and report
back to her. In his research, the analyst learned that outright copying would be a copyright
violation, but merely viewing other sites to get design ideas would be permissible. What
is not so clear is the gray area in the middle. The analyst asked you, as a friend, for your
opinion on this question: Even if no acrual copying is involved, are there ethical constraints
on how far you should go in using the creative work of others! How would you answer!
8. I 0 SUMMARY
The chaprer began with a discussion of user inrerface design and HCI concepts. A
GUI uses visu::tl objects and techniques tha r allow users to communicate effecrively
with the system. User-centered design principles include understanding rhe business,
maximizing graphic effectiveness, thinking like a user, using models and prororypes,
focusing on usabiliry, inviting feedback, and documenting everything.
When designing rhe user inrerface, it should be transparent; create an inrerface
that is easy to learn and use; enhance user productivity; make ir easy ro obtain help or
correct errors; minimize inpur dara problems; provide feedback; create an attractive
layout and design; and use famjliar terms and images. Control features, such as menu
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~... . ... .,...~ • ........._ . ....._.,.,.. o-... ..,._.,,.,.. _ ..,.~ ,........., ................. .._... .., .,. ..,.~"
................... ..., ...................... .... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
Phase l
Systems Design
26 1
8.10 Summary
bars, toolbars, drop-down lisr boxes, dialog boxes, toggle burrons, list boxes, oprion
burrons, check boxes, and command burrons can also be added. Controls are placed
on a main swirchhoard, which is like a graphical version of a main menu.
The discussion of input design began with a description of source documents and
the various 1.ones in a document, including the heading zone, the control zone, rhe
instruction zone, the body 1one, the totals zone, and the authorization 1one. The discussion of darn enrry screen design explained the use of input masks and vahdauon
rules to reduce data errors. Input masks are like templates rhar only permit certain
combinations of characters, and data validation rules can provide checks ro ensure
that inappropriate data is prevented from enreri11g the system. These checks can
include dara sequence, existence, range and limit, reasonableness, and validity, among
others.
The chapter described various rypes of printed reports, including detail, exception,
and summary reports. The features and sections of reports, including control fields,
control breaks, report headers and footers, page headers and footers, and group headers and footers were explained. Other types of output, such as web-based information
delivery, audio output, instant messagi.ng, podcasts, email, and other specialized forms
of output were also discussed.
Batch and on line input methods were also described, as were input media and procedures, and input volume. Input methods include data capture and data entry. Dara
capture, which may be automated, involves identifying and recording source dara.
Dara entry involves converting source data into a computer-readable form and entering it inro rhe system. New technology offers optical and voice recognition systems,
biological feedback devices, morion sensors, and a variery of graphical input devices.
Securiry and conrrol were discussed. Ourpur control includes physical protection
of data and reporrs and control of unauthorized ports or devices that can extract data
from rhc system. Input conrrols include audir trails, encryption, password security,
data security, and rhe creation of access levels ro limit persons authorized to view or
use data.
Finally, che emerging trends of modular design, responsive web design, and prototyping were discussed.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 8
User Interface Design
Key Terms
262
Ke y Te rms
audit cra1I A re.:ord of the ;ource of each daca item and when 11 l!ncercd a >y>tem. In add111on IO recording the cmgmal 'ource, an audu trail mu_\~ sho\\ how and when tbt.1 '' 3l"<:C\\Cd or changed, and hy
"horn. \II the'>e action> mu>t he logged in an audit trail file and monitored carefullr.
authori1,;uion zone Part of a form that contajns any required \lgnaturc'>.
automated f.ix A system rhar allows a cusromer ro request a fax using cmJil, the company website. or
a telephone. The response is cransmirrcd i:n a matter of seconds back to cbe user"s fax ma,hme. See
fall back.
batch A group of dara, usually mpurted mto an mfoananon system at the same mne.
b.uch uintrol A 1n1al u,ed to verify batch input. Batch control> might check data item\ wch 3'> r..-cord
count~ and numeric field totals. For example, before cnterin11 a hatch of order,, a lt'>tr mi11ht .:.1kulatc the roral number of order; and rhe <um of all rhc order quantiric~. When the hatch of order< i'>
enrcrcd, rhc order i.ystem al'>o ca lculates rhe same cwo IOtak If the ;y~tcm meals do not match the
111put torn I,, rhcn a tbt:t entry error has t>ecurred.
batch input A proces' where d:ua enrry is performed on a ~pecified cime ~chcdu lc:, ~uch O'> daily, weekly.
monrhl)', or longer. For example, hatch input occur~ when a payroll dq>arm1c11t collect' mne c.1rd' at
the end of the week and enters the data as a batch.
blog An onlme journJl. The rerm is a conrraction of "web log."
calendar control A calendar control allows che user to select a dJtc that the system will d1spla> and store
JS .1 field value.
character·ha'>cd report J\ report created using a single mono-'>paced characcer ...:c.
chccl. box U.;ed to '>elect one or more choices from a group. A check mark, or an X, repre-cnr- .;elected
option'>.
combuuuon chc:d A t) pe of d.11a \ alidacjon check that LS perfonned oo cwo or more field; to ensure
chJt che) arc con~mcnr or reasonable when considered together. ben though Jll the fields involved m
a combmauon check m1ghc pass rheir individual \alidation checks, the comhmauon of chc field values
might be incontjstent or lillrcasonable.
command button Onscreen button that initiates an action such as prinung a form or re<Juesnng Help.
contc"·'cn,irhc A fearurc that i< sen~itive ro rhe currenr conditions when it i\ imokcd. For example,
conte"t·\en'>!tiq: hdp offer- :i5sisrance for a rask in progress.
control hrcJk A control break u~uall y causes specific a•-rion~ to occur, ~ud1 .I'> pnn11n11 >ubtotal> for a
11roup of records.
control break report A detail rcporr that focuses on control breaks.
control field order In a conrrol break reporr, the records are arranged or sorted on the same order as the
cont rol fields.
data security Prorccrion of darn from loss or damage and recovers darn when it is lost or damaged.
dam rypc check A type of darn va li dation check rhat is used ro ensure thar o darn item fir~ the requi red
dJm type. For example, a numeric ticld must have onl) numbers or numeric ~ymbt>I~. and an alpha·
bc11c field can contain only chc characters A through Z or the character~ a through t..
datJ 'alidJtion rule: A me.::hanism to improve input quality by tesung tbe datJ .ind re1e~11ng .111y entry
that f.111~ to meet specified condmons.
default \aluc A "alue that a system displays auroma11cally.
dc\1gn prototyping Creating a protocypc of user requirements, after whu:h the prororypc 1s d1..cardcd
and 1mplementarion connnues. Also called rhrowawar promryping.
detail report A derail report produces one or more lines of output for each record proccs<ed.
dialo11 bo'< Allows a u~r ro enrcr information about a cask that a system wtll perform.
~ JD» (".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_ ._.... ~~
...
. ..............
_ .... ~---11rt~
-,..~---~ ~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Phase l
Systems Design
263
Key Terms
d1\klc\\ \\Orl.\lauon A nc1work 1crminal 1ha1 <upportS a full-foarurcd user mtcrfaL"C hu1 limit\ 1he prinl·
ing or cop)·mg of data, c"<ct'pt to certain network r~urccs chac can be monitored and conrrolled
more ea;il).
electronic hcahh record EHR An electronic record of a patienc's bealch information gencrJtcd as the
paacm encounters various health-care prondcrs and shared among muluplc facwncs Jnd a@.enc1~.
cncr)pllon A proce;; where data 1s coded (converted into unreadable characters) ;o that only tho;e wuh
cbe required au1hor1z.tnon can access the data (usuallr via decoding software ).
cucpllon rcpor1 A d1xumcn1 di,playing only 1ho"' rc.:ords chat meet a \p«1lic cunditmn or L·ondit11111\.
Fxccption rcpom arc u\eful when the u<;er wane• information on ly on records that might require
aL"tllln hut doc.; nor need m know rhe derail~.
exi\tcnce check A cype of d:im validation check chat is used for mandmory darn item\. For cx:imple, if
an employc:c record rc4uirc' a Social Securiry number, an exisrence check would no1 allow the ui.er to
,.we 1hc record u111il he or \he enter., a .,uitable value in the SSN field.
faxback See .1urom.11cd fox .
Conn fillins A very effcc1ivc method of online data enrry where a blank form thJt duplicates or resem·
hies the source document i~ completed on the screen. The user enters rhe da!l1 and rhen movcs to the
11ext field.
form layoul The phr•ical appearance and placemem of data on a form. Form layout make~ the form
ca') m complete and provide' enough ~pace, horh vertically and horizomally, for U\t!f\ m enter the
data.
garb;age m, g.irb.li;c ou1 (GIGO! The concept that rhe quality of rhe ourpur" only"' good'" rhe qual1ry
of the in put.
graphical user interface (GUI) Inc usc of graphical objects and techniques allowing user~ 10 commum·
cate with a s~·srem. A well-designed GUI can help users learn a new S)Stem rapidl) and work with rhe
sys1cm effecuvcl).
bash totals !\ot meaningful numbers 1hentieh es but are u.>eful for comparison purposes. Also knO\\ n as
batch control 101.ils.
human-cnmpu1er 1n1craL"linn (I ICH A d~cnpnon of the n:lanon~hip between computer~ and the people
who u>e them to perform hu~inc<i~·rclarcd ra5ks. HO concepts appl)' to cvcry-rhing from a PC' de~krop
to the marn menu for a glohal network.
inpul comrol The ntxc''"'1 me:hure• ro ensure rhar input d ata is correct, complete, and \ecurc. 1\ '>Y•·
tern~ anal)M mu\I focu'> on rnput conrrol during every p h ase of input design, srnmng wi1h \ourcc doc·
umcms 1h:t1 promote d:ua a''uraq and quality.
mput mas!. femplare or pattern char makes 1r easier for users to enter data. Often used 111 automated
forms to guide an unfamiliar user.
limi1 check Occurs when a va lidmion check involl'~ a minimum or a maximum value, hut nor both.
Checking 1hat a payment amount is greater than zero, bur nor specifying a maxim um value. i; an
example of n lunic check.
1;,, box An output mcchani>m that di>plays a liM of choices rhar the user can >elcLl.
menu b.1r A >Ct of user->clcLtable •ofrware applicariun uptiom, usually locarcu acro~s 1hc rop of Lhc
>erccn.
mocl.·up When dc;,igmng a report, a 'ample report is prepared, which 1s a mcxk·up, or pro101ypc, for
users 10re\1cw. rhc s.1mple should include ryp1cal field va lues and com.tin enough records to ~how all
the de~ign fcamrc\.
modular dc,1gn A deMgn that can be broken down into logical block» Abo known a; partirionmg, or
top-down deMgn.
~ JD» (".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_ ._.... ~~
...
. ..............
_ .... ~---11rt~
-,..~---~ ~
.... . _
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Chapter 8
User Interface Design
Key Terms
264
module Rel:ued program code or:ganaed into small uruts that Jn~ eaS) to undent.rnd and m.umam. A
complex program could have hundreds or even chousands of modules.
n~tural l~n11ua11c A \<Jftwarc feature that allows u~~ to l)'J>C command, or re<1u"'t' m normal En11l"h
(or other lan1,'llai;c) phra'>CS.
onl1nc dat;i cnin A data enrry method used for most hu~ine'~ activ11)'. The onlinc mcrhod offer. major
advanca~es. mduding che immediate \•alidation and arnilability of data.
opuon button Radio bunons that represenc groups of options. The user can select only one option at a
ume; a ~ele-:ted op11011 contains a black dot. Se!' also radio button.
outpu1 control Methods to mrumam ourpur mregrity and secunry. l'or cx.1mple, C\ery report should
include an appropriate title, repon number or code. primmg dare, and tune period covered. Reporn
should ha\'C pages that arc numbered consecutively, 1dcnn6cd as 1'.1gc X'X of xx, .ind the end of rhc
rcpor1 should be labeled clearly.
output i.ccuri1y Ourpur security prorects privacy rights and bhield~ the nri;ani1ario11·~ propricrnry darn
from 1hch or unnuchorizcd accc,~s.
pa11c footer Appears at rhc hotcom of rhe page and is used to display the name of chc report and 1hc
pa11c numhcr.
pjgc header Appears .u the top of the page and mdudes the coh1lllll he.1dmgs tl1Jt 1denrif) rhe dara.
podcast A wcb-b.1scd broadcast that allows J user ro receive .1udio or 111ulumcd1,1 file5 using music
pla)Cr sofrware such as iTunes, and listen to them on a PC or download them ro a portable MP3
pla}er or smart phone.
protol)pt An e.~rl)', rapidly con<rrucced working ver;ion of rhe propo-.cd mformarion ~y<tcm.
promr) pini; The merhod br which a prorocype is developed. Jc inH>lve- a repc:riri\c ~equcnt:c of an:ilr~i<,
de\l)ln, modclm11, and te;ung. It 1~ a common technique chat can be u-.cd m de\1i;n an) th11111 from a
new home ma computer nerwork.
radio button 8unons rhar represent groups of options. The user can select onl) one opuon ;u .1 ume; a
selected opuon contains a black dor. See also option button.
radio frcqucn() idenrific:iuon RFID) tag An input de,ice used in source data au1oma11on.
range check A type of dara ,·alidation check chac tests data icems ro "enfy chat they fall l'Crwcen a specified minimum and maximum \'alue. The daily hours worked b) an employee, for e\amplc, mu<c fall
\\ 11h111 1hc rani;e of 0 IO 24.
rca,onahlcnev, check A t) pc ot data validation check tha1 idcmific> v;ilue> 1ha1 arc <1uc,tionablc but not
necc<sanly wrong. For c"Xamplc, input payment va lues of $0.05 and $5,000,000.00 borh pass a sim·
pie limit check for a payment value greater than 1ero, and yet both va lue' could he error,,
record~ retention policy Rules designed co meet all legal requirements and busm~s needs for keeping records.
rcpnr1 fonrer Appears at the end of the report, can include grand ror.1ls for numeric fields Jnd ocher endof-rcporr information.
report header Appears oc the beginning of a report and identifies 1hc report a\ well a• the report title,
d.1rt, and o ther nc,c.sar)' information.
,croll bar In ll>Cr imcrface design, a scroll b:tr allows the user IO movt' through 1hc av11i lablc choice; for
Jn input field.
(Cqucm:c chccl A t) pe of daia validation check rha1 is used when the data musl be Ill ~omc
predetermined ,equence. If rhc user must enrcr work orders in numerical sequence, for example,
then Jn out-of-,equence order number indicate. an error. lf the user must corer rr:tnSJuions
1.hronolog1c.ill). then a rra~acnon with an out-of-s'<!ueu'c dare 111tLcatts .m error.
~ JD» (".............. .-\l ........... .,.... _.,."'flllll.~-....-.. - "*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_ ._.... ~~
...
. ..............
_ .... ~---11rt~
-,..~---~ ~
.... . _
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Phase l
Systems Design
265
Key Terms
soun:e d;ua auromation A popular onhne inpur method char combines oaline data enrrv and auromarcd
data upturc u<,ing input de"'""' 5Ulh ~ magnenc data scrip> or .wipe ..:aaacri..
source documcm A form used to request and coUect input data, trigger or authorue .in mput .llllon• .inJ
provide a record of the original rransacnoa. During che input design stage. you deYelop source documents that arc caS} ro complcrc and inexpensive.
noryhoard Skt>tchc~ u~ during promtypmg ro ~how rhe general screen layour and d~1gn.
'ummal) rcpon A reporr 11-.cd h)' indi,idual' at higher lcvch in the organi7ation that indudc' le'~ dct.1il
than report• u-.cd b) lower· le,·el employees.
"'itchboard The U\C of 'ommand burrnns in a u-;er inrerfoce to enable users ro navigate a 'Y'tem and
-eled from 11rou1h of related ta\k-.
sy~tcm prototyping l'roducmg a full-featured, working model of the inform.ttiou sy;tem being
developed.
throwaway protot)pin11 See dc~ign prorocypin11.
tu!(!\lc hutton A GUl clcmcnr used tn rcprc'Cnt on or nff statu•. Clicking the COffillc button >Witchc' tu
the other >rntu•.
wnlhar A Gln clement that contain• icom or button~ that represent •hnrtcurs for executing common
command~.
t0tals zone If ,1 form h.1s dat.1 totals, they will appear in this secrion of rhe form.
1tan}pJrent intcrfocc A user mterfoce thar users don't reaUy notice-a user-friendly interface that does
not dmr.ict rhr usrr .ind c.alls no arrencion to uself.
turnaround dt><.-umcnt Output doc.:umcnt that 1;, later entered back into the ~amc or another 1nforma·
tion 'Y'tcm. A telephone or utility hill, for example, might be a turnaround document printed by the
company·, hilhng ,Y'tcm. When the bill 1' returned with pa)ment, it i' <canned into the company''
account\ rcceivahlc '>)"'>tem m record the payment accuraTely.
u.\ahilu> In u\cr 1ntcrfo1.:c de-1i11n. include< u...:r satisfaction, support for busin"'' funcuon,, and '>'tern
etie~tivenC\\.
u~abilit~ mcuic~ D.tta that u11erface designers can obratn by usmg sofrware chat C.lll re.:ord and measure
user mteracuo11> with the s~srem.
"'er-centered A term that 1nd1carcs the pnmaf)' focus 1s upon rhe user. ln a user-centered system, the d1'·
fincrion blurs between input, output, and the interface irselI.
u'cr interface (Ul) The mechanism rhrough which the user interact' with the system. The interface can
be graphical, textual, aura l, or a combinarion of differenr mode~ of interaction.
\•alidity d1e1.:k A rypc ol darn "alidation check that is used for dara icem' rhat mu~t have certain values. f'or example, if an 111\'cntory ;,y,tcm has 20 ,·alid llcm da~~c;,, thcn any input nem that doc' no1
mJtch one of the va lid dass<'s will foi l the check.
wcbc.1st A onc·WJ) tr.111sm1s~ion of information or training materi.1ls, such as a Wcbinar session, .ivailablc on demand or for a specific period co online participants.
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
...............
_ .... ~---11rt~
-,..~---~ ~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Chapter 8
User Interface Design
Exercises
266
Exercises
Question s
I. Explain Apple's view of user imerfoce design, especially for apps.
2. What is l-ICI?
3. \Xfhy 1s a transparent interface desirable?
4. What are the SC\'en habits of successful interface designers?
5. How would you rank the I 0 guidelines for user interface design in order of importance? Explain your
answer.
6. What are the main principles of source document design?
7. What is che difference berween a derail report, a summary report, and an exception report?
8. How has input technology changed in recent years?
9. What is output security?
10. What are three emerging trends in user interface design?
Discussion Topics
I . Some sy~tem~ analysts argue, "Give users what they ask for. If they want lot~ of report& and reams
of data, then chat is what you should provide. Otherwise, they will feel that you are crying co cell
them how to do their job~." Others say, "Systems analysts should let users know what information
can be obtained from the system. If you Listen to users, you'll never get anywhere because rhey really
don't know wh::u they want and don't understand information systems." What do }'OU think of these
arguments?
2. Some systems analysts maintain chat source documents are unnecessary. They say that all input can be
entered directly into the system, without wasting rime in an intermediate step. Do you agree? Can you
think of an)' situations where source documents are essential?
3. Suppose your network support company employs 75 technicians who travel constancl) and work ar
customer sires. Your task is co design an informarion system chat provides techmcal data and informanon to the field team. \Vhat rrpes of output aod mformarion delivery would you suggest for the
system?
4. A user interface can be quite restrictive. For example, rhe interface design might nor allow a user to
exit co a Window!t desktop or co log on co rhe Internee. Should a user interface include such restrictions? Why or why nor?
5. How is che increased use of smarrphones and tablets, with their smaller screen site, affecting user
inLerface design practices?
Projects
I. Yihit rhc administrative office at your school or a local company. Ask co sec examples of input
screens. Analyze che design and appearance of each screen and try to identify at least one possible
improvement.
2. Search the web co find an especial ly good example of a user interface that includes guidelines in chis
chapter. Document your research and discuss it with your class.
3. Re' iew Seccion 8.2 and the comments abouc EHR usability. Research the currenc status of EHR
usability and de!tcnbe all noteworthy developments.
4. Suggest at lea~r two good examples and rwo bad examples of source document design.
5. Explore the cmergmg area of wearable computing, such as the Apple \Vatch, and comment on the
impact of thehe dences on user interface design.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
~ JIJ»C....... ~ Al RlilfD
~ ... _
l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.: ......,_ . . . ,_.,~-.lit .......... .._.,._.__..,~•\
. . . _ . .... ..., ~...,.._,_..,..., J\&."9 ... --.11 ......... ~ C'dptl"~~d.tt ...... -
............ -
..... -
..........
-.-.....w--...-.11
Chapter 9
Data Design
Data Design
Chapte r 9 is the second of three chapters in the
systems design phase of the SOLC. During the systems
analysis phase, a logical model of the system was
created. Now, it must be decided how data will be
organized, stored, and managed. These are important
issues that affect data quality and consistency. This
chapter focuses on the data design skills that are
necessary for a systems analyst to construct the physical
model of the information system.
The chapter includes three "Case in Point"
discussion questions to help contextualize the concepts
described in the text. The "Question of Ethics" raises
the important and timely issue of sharing customer data
w ithout their explicit consent.
LEARNING OBJECTIVES
Wl1e11 you finis/J t/Jis c/Japter, you should be
able to:
CONTENTS
l. E..xplain basic data design conceprs, including
data srrucrures, DBMSs, and rhe evolution of the
relariot1al databa~e model
2. Explain the mam components of a DB~1S
3. Define the major characrcrisrics of web-based
design
4. Define dara design rerminology
5. Draw enriry-rel::irionship diagram~
6. Apply data normalization
7. Utilize codes to sim plify ourpur, input, ;:ind dara
formats
8. Explain dara storage roots and techniques,
including logical versus physical srorage
9. 1
9.2
9 .3
9.4
9 .5
Dara Design Conceprs
DBMS Components
\'<'eh-Based Design
Data Design Terms
E.ntiry-Relarionship Dtagrams
Case in Point 9.1: TopText Publishing
9.6 Dara 'ormalization
Case in Point 9 .2: CyberTo)'S
9 .7 Codes
Case in Point 9.3: Madera Tools
9.8 Dara Storage and Access
9.9 Dara Control
A Question of Ethics
9 . 1O Summary
Key Terms
Exercises
9. Explain data coding
I 0. Explain darn control mea~urcs
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Phase l
Systems Design
269
9.1 Data Design Concepts
9.1
DATA DESIGN CONCEPTS
Systems analysts must understand basic data design concepts, including data structures and the evolution of the relational database model.
9. 1. I Data Structures
A data \trucrure is a framework for organizing, storing, and managing data. Dara
structure'> consist of files or rabies char inreracr in various ways. Each file or rable
contains dara about people, places, things, or events. For example, one file or rable
might conrain darn about customers, and other files or cables might store data about
products, orders, suppliers, or employees.
Many older legacy systems urilized file processjng because it worked well with
mainframe hardware and batch input. Some companies still use this merhod to handle
large volumes of srructured data on a regular basis because can be cost-effective in
certain situations. For example, consider a credit card company that posts thous::inds
of daily transactions from a TRANSACTIONS fille to account b::i lances stored in ::i
CUSTOMERS file, as shown in Figure 9-1. For that relatively simple process, file
processing might be an option.
CUSTOMERS
r;w______.. ~lliiM
~
53914
Transaction ' Cuatomff
flumber
, Number
O.te
ICode
lunovnt
109823497
53914
11-03 2019
°'4<g!!
no.so
2100485/6
53914
11-04 2019
Re1 .. n
23.98
994184424
X9810
11 04 -2019
Owlrgr
62.67
U ·ll-2019
86.S2
FIGURE 9- 1 A credit card company that posts thousands of daily transactions might consider a file processing
option.
Over time, the modern relational darabase became a standard model for systems
developers. The following example of an auto service shop will compare the rwo
concepts.
9. 1.2 Mario and Danica: A Data Design Example
Figure 9-2 shows an auto shop mechanic at work. Imagine two shops that arc very
similar bur use two different informarion system .designs. Let's call them Mario's Auto
Shop and Danica's Auto Shop. Mario uses two file-oriented S)'Stems, while Danica
uses a database management system.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 9
Data Design
9.1 Data Design Concepts
270
MARIO'S AUTO SHOP: Ivlario relics on rwo
file-<>riented systems, sometimes called file processing systems, to manage his business. The two
sysrems store data in separate files that arc not
connected or linked. Figure 9-3 ~how Mario's
file-<>riented systems:
• The JvlECHA !JC SYSTEM u~es the
MECHANIC file to store dara abour shop
en1ployees
• The JOB SYSTE~I uses the JOB file ro ~tore
data about work performed ar the shop.
Unforrunarely, using rwo separate systems
means that some dara is stored in rwo different
FIGURE 9 -2 In the example shown here. data about the
places, and the data might o r might not be conmechanic, the customer, and the brake job might be stored in a
file-oriented system or In a dacabase system.
sistent. For example, rliree data items (Mechanic
No, Name, :111d Pay Rate) are srorcd in both
files. This redundancy is a major disadvantage of file-oriented systems because it threatens data quality and inregriry. In face,
Figure 9-3 includes a typical discrepancy: Jim J ones' pay rate is s hown as $18.90 in
the Ivl ECHANIC SYSTEM. file a nd$ L9.80 in the JOB SYSTEM file.
r
-No
-
MECHANIC
MECHANIC SYSTEM
,.,,_
""°"'
......,....,.
5UIUS
!:i! MIOW«
112
11
13
. Pay Rate . HtreOate .
Name
Mecham< N, •
a
Le•ir, Robert
Jones, Jim
$15.00
$15.70
~lotus
4/17/'lfJlO PMt time
1/15/1998 full ti""'
. ''™"•nee .
No
y.,.
r
~
~
JOB
JOB SYSTEM
JobNo
Worl: Coclf
Houn
Dolt
r..wchan.cNo
~
Poy Rlt•
,!:ll IOll
lob No ··
i'"'
1110
...
1.14
Wot~ Cod.
. Hoon .
0.•~
. M«hanlc No .
TUN £
l .2
l\IW<CS
... 0
U/6/l019 U
U/)/201q 11
ALIGN
.J.O
12/6/lOJS 2J
N""'"
. P.y AAte •
l Pilf. Rotwr'
s1~.oo
J.,.,...,fm
SllSO
"""'"' \\ .. y
$20.00
'
FIGURE 9-3 Mario's shop uses cwo separate systems, so certain data must be entered twice. This
redundancy Is Inefficient and can produce erron.
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~---tfta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
271
9.1 Data Design Concepts
DANICA'S AUTO SHOP: Danica uses a database managemenr system (DBMS)
wirh rwo separate rabies rhar are joined, so they ace like one l:irge cable, :is shown in
Figure 9-4. In Danica\ SHOP OPERATIONS SYSTEi\1, the cables are linked by the
Mech:inic 1 o field, which is called a common field because it connects the rabies.
Note that except for the common field, no ocher d:ica items are duplicated. The
DB~IS design, also called a relarional database or relatio nal model, was introduced
in the 1970s and continues to be the dominant approach for organizing, scoring, and
managing business data.
SHOP
OPERATIONS
SYSTEM
._
.......
.....
...,._,..
...
,.,Mt
..,..,..
......
....... .., •
.....
• fYr Miit • · - Ollllt • . . . . • ......... • -
... • WQril, c.- • ...,,,, .
0.. •
t:1
,., .._,.
lti C10
'411'7Df0 ,..,._.. No
tt1
0.N
)'
•l'IJnOpt
ti
..........
.... .-i_
l lSl'CI
'10111
tJt:'Jtl'Jlllf ...... V•
1IO
lM
(iqN(l.S
fl
:SO
IZWl!H9
H
1 ti-1n:r.-- Y•
M.-oN
l~n
FIGURE 9 . 4 Danica's SHOP OPERATIONS SYSTEM uses a databa$e design, which
avoids duplication. The data can be viewed as if it were one large table. regardless of
where che data is physically stored.
t.1ario's file-oriented systems show rwo different pay rares for Jim Jones, most
likely because of a darn enrry error in one of chem . Thar type of error could nor occur
in Danica's relational database, because an employee's
pay rate is srorcd in only one place. However, DBMSs are
nor immune ro dara entry problems, which are discussed
in derail lacer m chis chapter.
9. 1.3 Database Management Systems
A database provides an overall framework rhac avoids
data redundancy and l>Upports a real-time, dynamic environment. Figure 9-5 shows a company-wide data base
that supports four separate information systems.
A database management system (DBMS) is a collection of cools, features, and interfaces that enables users
to add, update, man:igc, access, and analyze data. From
a user's point of view, the main advantage of a DBMS is
that it offers timely, inrcracrive, and flexible data access.
Specific DB,VIS advantages include the following:
SALES
DATABASE
• Scalability. Scalability means chat a system can be
expanded, modified, or downsized easily co meet
the rapidlr changing needs of a business enterprise.
.........""_.. ... .-.................
_..__ ...................
FIGURE 9-5 In chis enmple, a sales dacabase an
support four separate business systems.
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~----···---~~-.,.-"~
Chapter 9
Data Design
9.2 DBMS Components
272
•
For example, if a company decides to add data about secondary suppliers of
material it uses, a new table can be added to the relational database and linked
with a common field.
£co110111y of scale. Database design allows becrer utilization of hardware. If a
company maintains an enterprise-wide database, processing is less expensive
using powerful servers and communication nerworks. The inherent efficiency
of high-volume processing on larger computers is called economy of scale.
• enterprise-wide a{Jplicatio11. A DBMS is typically managed by a person called
a database administrator (OBA). The OBA assesses overall requirements and
maintains the database for the benefit of the entire organization rather than a
single department or user. Database systems can support enterprise-wide applications more effectively than file processing systems.
• Stronger standards. Effective database administration helps ensure that stan·
<lards for data names, formats, and documentation are followed uniformly
throughout the organization.
• Better security. The OBA can define authorization procedures to ensure char
only legitimate users can access the database ancl can allow differem users ro
have different levels of access. Most DB1v1Ss provide sophistica ted security
support.
• Data i11depe11.de11ce. Systems that interact with a DBMS are relatively independent of
how the physical data is maintained. That design provides the DBA Aexibiliry ro airer
data strucn1res without modifying information systems char use the data.
Alchough che trend is toward enrerprise-wide dacabase design, man)' companies
still use a combination of centralized DBMSs and smaller, department-level dacabasc
systems. This is because most large businesses view data as a company-wide resource
that must be accessible to users throughout the company. Ar the same time, other
factors encourage a decenrraJized design, including network expense; a reluctance to
n1ove away from smaller, more flexible systems; and a realization that enterprise-wide
DBMSs can be higl1ly complex and expensive to
maintain. The compromise, in many cases, is a
Database
clienr/server design, where processing is shared
1
Adm n1s1rators
among several computers. Client/server systems are
described in detail in Chapter 10. As with many
design decisions, the best solution depends on rhe
organization's needs and particular circumstances.
9.2 DBMS COMPONENTS
Users
Relatedt J
Systems
Information
FIGURE 9-6 In addition to interfac.es for useN. database
administratoN, and related information systems. a DBMS also has
a data manipulation language. a sc.hema and subschemas, and a
physkal data repository.
A DBMS provides an interface between a database
and users who need to access the data. Although
users are concerned primarily with an easy-to-use
interface and support for their business requirements, a systems analyst must understand all of the
components of a DBMS. ln addition ro interfaces
for users, DBAs, and related systems, a DBMS also
has a data manipulation language, a schema and
subschemas, and a physical data repository, as
shown in Figure 9-6.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
273
9.2 DBM S Components
9.2.1 Interfaces for Users, Database Administrators, and Related Systems
When user~, DBAs, and related information systems request data and senrices, the DBMS
processes che request, manipulate:. the dara, and provides a response. A data manipulation
language (OMI .) conrrols database operations, including storing, retrieving, updating,
and deleting data. tvlost commercial DB~1Ss, such as Oracle and IBM's 082, use a 0~1L.
Some database products, 'iuch as ~1icrosofc Access, also provide an easy-to-use graphical
environment rhat enables users co control operations with menu-dri\"en commands.
Users typically work with predefined queries and switchboard commands
but also use query languages to access stored data. A query language allows a user
co specify a task without specifying how the task will be accomplished. Some query
languages use narural language com1nands chat resemble ordjnary English sentences.
\Xlith a quer y by example (QBE) language, che user provides an example of the data
requested. Many database programs also use Strucrured Query Lang uage (SQL),
·which is a language that a llows client workstations to co1nrnurucate with servers and
mainframe computers. Figure 9-7 shows a QBE request for all Lime Squeeze or Blue
Candy 2019 Ford Fusions with a power moonroof. The QBE request generates the
SQL commands shown a t the bottom of Figure 9-7.
USERS:
DATABASE ADMINISTRATORS:
--·- --
A DBA is
responsible for DBMS management and supporrOBAs are concerned with dam security and inregriry,
preventing unauthorized access, providjng backup and
recovery, audit trails, maintaining the database, and
supporting user need:•. Mo~r DBMSs provide uriliry
programs ro assist the DBA in creanng and updating
data Mructures, collecting and reporting parrems of
database usage, and detecting and reporting database
irregularities.
-- ---____......
- --- --• ... --• ..-- __
---__ -.. .
.._
-= ~--
QBE
ll
II
) request
•
"
_,..,......,._,.......,.._ ,..
....
~-===-=·~··
~
~.....
SOL
) commands
_..,.
- . c - ..............
FIGURE 9-7 Using QBE.a user can display all 2019 Ford
A DBMS
Fusions that have a power moonroof and are either Ume
can support several related information systems that
Squeeze or Blue Candy color.
provide input to, and require specific data from, che
DBMS. Unlike a user interface, no human intervention is required for rwo-way
communication between the DBMS and the related systems.
RELATED INFORMATION SYSTEMS:
9.2.2 Schema
The complete definition of a database, including descriptions of all fields, tables,
and relationships, is called a schema. One or more subschemas can a lso be defined.
A subschema is a view of the database used by one or more systems or users. A
subschema defines only chose portions of the database tbar a particular system or user
needs or is allowed ro access. For example, ro protect indjvidua l privacy, rhe project
management system should nor be permitted to retrieve employee pay rares. In that
case, che project management system subschema would nor include the pay rare field.
Database designers also use subschemas co restrict the level of access permitted. For
example, specific users, sysrems, or locations mjgfhr be permirred ro create, retrieve,
update, or delete data, depending on rheir needs and the company's security policies.
9.2.3 Physical Data Repository
Chapter 5 discussed a dara dictionary, wruch describes all data elements included
in the logical dei.ign. At this stage of rhe systems development process, the data
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
--
........... ......
"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ..... ......... ~..
__....
~~·~--- - ···---~~ - .,.-" ~
Chapter 9
Data Design
9.3 Web-Based Design
274
dictionary is transformed into a physical data repository, which also contains the
schema and subschemas. The physical repository might be centrnli1ed, or it might
be distributed at several locations. In addition, the smred data might be managed by
a single DBMS, or several systems. To resolve potential database connectivity and
access problems, companies use OD BC-compliant software that enables communication among various systems and DB:VISs. Open database connecti,it) (O OBC) is an
industry-standard protocol that makes it possible for software from different vendors
to interact and exchange dara. ODBC uses SQL statements that the DBMS understands and can execute, similar ro the ones shown in Figure 9-7. Another common
standard is called java database connecti,;ty (JDBC). J DBC enables J:iv:i :ipplicarions
to exchange data with any database that uses SQL statements and is JD BC-compliant.
Physical design issues are described in Chapter I0, which discusses system :irchitccture,
and in Chapter 11 , which discusses system implementation and data conversion.
9.3 Wee-BASED DESIGN
Figure 9-8 lists some major characteristics of web-based design. Ln a web-based design,
the Internet serves as the front end, or interface, for the DBMS. internet technology
provides enormous power and flexibility because the related information system is
oot tied to any specific combinarion of hardware and software. Access to the database
requi res only a web browser and an Internet connection. \~eb-based ~ystems are popular
because they offer ease of access, cost-effectiveness, and worldwide connecriviry-all of
which are vital to companies that must compete in a global economy.
CHARACTERISTIC
EXPLANATION
Global access
The Internet enables worldwide access, using existing infrastructure
and standard telecommunications protocols.
Web browsers provide a familiar interface that 1s user-friendly and
easily learned.
Ease of use
Multiple platforms
Cost effectiveness
Security issues
Adaptability Issues
Web-based design is not dependent on a specific combination of
hardware or software. All that is required is a browser and an
Internet connection.
Initial investment is relatively low because the Internet serves as the
communication network. Users require only a browser. and webbased systems do not require powerful workstations. Flexibility is
high because numerous outsourcing options exist for development,
hosting. maintenance. and system support.
Security is a universal issue, but Internet connectivity raises special
concerns. These can be addressed with a combination of good design,
software that can protect the system and detect intrusion, stringent
rules for passwords and user identification, and vigilant users and
managers.
The Internet offers many advantages in terms of access, connectivity.
and flexibility. Migrating a traditional database design to the web,
however, can require design modification, additional software, and
some added expense.
FIGURE 9-8 Web-based design characteristics include global access, ease of use. multiple platforms. cost-effectiveness,
security iuues. and adapability issues. In a web-Wed design. the Internet serves as the front end. or interlace. to die
cbcab;lse management system. Access to die database requires only a web browser and an lnU!met conneeuon.
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
275
9.4 Data Design Terms
To access data in a web-based system, the database must be connected to the Internet
or inrranet. The daraba e and the Internet speak rwo different languages, howc\·cr.
Databases are created and managed by using \'arious languages and commands that
ha,·e nothing to do with HT~I L, which is the language of the web. The objecti\e is ro
connect the database to the web and enable data to be viewed and updated.
To bridge the gap, it is necessary to use middleware, which is a software that
integrates different applications and allows them to exchange data. ~liddleware can
interpret client requests in HT~1L form and translate the requescs into commands
that the database can execute. When the database responds to the commands,
m1ddleware translates the results into HT~tl pages that can be displayed by the
user's browser, as shown in Figure 9-9. Nore char the four steps in the process can
take place using the Internee or a company intranet as the communications channel.
Middleware is discussed in more detail in Chapter 10.
lw•-
.......,_,
IOM-
)--·--
-
4bul0-
FIGURE 9-9 When a client worl<staaon requests a web page ( 1), the web server uses middleware to
generate a data query t0 the database server (2). The database server responds (3). and the mtddleware
translates the retrieved data into an HTML page tN.t can be sent by the web server and displayed by rhe
user's browser (4).
Web-based data must be secure, yet easily accessible co authorized users. To achieve
thjs goal, well-designed systems provide security atr three levels: the database itself, che
web server, and the telecommunication links that connect the components of che system.
Dara security is discu~sed in more derail in Section 9.9 and in Chapter 12.
9.4 DATA DESIGN TERMS
Using the concepts discussed in the previous sections, a systems analyse can select a
design approach and begin co construct the systetn. The first step is to understand
data design terminology.
9.4. 1 Definitions
Data design terms include cnrity, table, file, field, record, tuple, and key field. These
terms arc explained in the following sections.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 9
Data Design
9.4 Data Design Terms
276
ENTITY: An entiry is a person, a pl~ce, a thing, or an event for which data is
collected and maintained. For example, an online sales system may include enricies named CUSTOMER, ORDER, PRODUCT, and SUPPLIER. \'<lhen DFDs were
prepared during the systems analysis phase, various entities and data stores were
identified. Now the rela tionships among the entities wall be considered.
TABLE OR FILE: Data is organhed into tables or files. A table, or file, contains a set
of related records that store data about a specific entity. Tables and files are shown
as two-dimensional structures tbat consist of vertical columns and horizontal rows.
Each column represents a field, or characteristic of the entity, and each row represents
a record, which is an individual instance, or occurrence of the entity. For example, if
a company has 10,000 customers, the CUSTOMER table will include J0,000 records,
each representing a specific customer.
Although they can have different meanings in a specific context, the rerms table
and file often can be used interchangeably.
FIELD:
A fi eld, a lso called an attribute, is a single characteristic or fact abour
an entity. For example, a CUSTOMER enrity might include th.e Customer ID,
Firsr Name, Last Name, Address, City, Stare, Postal Code, and Email Address.
A common fi eld is an attribute thar appears in mo re than one enrity. Common
fields can be used to link entities in various types of relationships.
A record, also called a tu ple (rh)'mes with couple), is a set of related fields
that describes one instance, or occurrence, of an entity, s uch a~ one customer, one
RECORD:
order, or one product. A record might have one or dozens of Cields, depending on
what information is needed.
9.4.2 Key Fields
During the systems design phase, ke}1 fields are used to organize, access, and maintain
data structures. The four types of keys are primary keys, candidate keys, foreign keys,
and secondary keys.
PRIMARY KEY: A primary key is a field or combinarion of fields that uniquely and
minimally identifies a particular member of an entity. For example, in a customer
rnble, the customer number is a unique primary key because no rwo customers can
have the same customer number. That key also is minimal because ir contains no
information beyond what is needed to identify the customer. In a CUSTOMER table,
a Customer ID might be used as a unique primary key. Customer ID is an example of
a primary key based on a single field!.
A primary key a lso can be composed of t\VO or more fields. For example, if a
student registers for three courses, his or her student number will nppear in three
records in the registration system. If one of those courses has 20 srudenrs, 20 separate
records will exist for that course number-<>ne record for each student who registered.
In the registration file, neither the student number nor the cou rse ID is unique, so
neither field can be a primary key. To identify a specific student in a specific cou rse,
the primary key must be a combination of student number a nd course ID. In that
case, the primary key is called a combination key. A combination key a lso can be
called a composite key, concatena ted key, or multivalued key.
Figure 9-10 shows four different tables: STUDENT, ADVISOR, COURSE, and
GRADE. Three of these tables have single-field primary ke ys. Note thar in the
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
277
9.4 Data Design Terms
GRADE rable, however, the primary key is a combination of rwo fields: STUDENT
NUMBER and COURSE 'UMBER.
STUDENT
NUMBER
I STUDENT
TOTAl
CREDITS
' GPA
NAME
1035
Linda Mllrk
14
3.40
49
3397
SamCerr
9
3. 75
49
407D
Kelly Goldman
8
2.50
23
1'
I ADVISOR
NUMBER
i -- - - 1 common fields ,_ _ _.,
23
Alice Jones
8 230
49
Carlton Smith
0 ·331
~====~+======~}k•~~~~---11~~ 1
STUDENT
NUMBER
II
COURSE
NUMBER
I GRADE
I
I COURSE
I CREDIT
DESCRIPTION
1 HOURS
CHM112
General Chemistry I
s
CSClSl
Computer Science I
3
ENG101
EnsfLSh Composition
3
MKT2U
Macfoeting Management
3
COURSE
NUMBER
FIGURE 9- 10 Examples of common fields, primary keys. candidate keys. foreign keys, and seconcbry keys.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ..............
__....
--
........... ......
. ,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
~~·~---- ···---~~-.,.-"~
Chapter 9
Data Design
278
9.4 Dat a Design Terms
Sometimes tbere is a choice of fields or field combinations ro use
as the primary key. Any field that can serve as a primary key is called a candidate kc} .
For example, if every employee has a unique employee number, then it could be used
as a primary key. Note that an employee's Social ecurity number would not be a
good choice for a candidate key: Con trary to popular belief, Social Security numbers
are not unique. Because only one field can be designated as a primary key, the field
that contains the least amount of data and is the easiest to use should be ~elected. Any
field that is not a primary key or a candidate key is called a nonkey field .
The primary keys shown in Figure 9-10 also are candidate keys. Another candidate key is the COURSE DESCRTPTTO field in the COURSE table. What about the
OFFICE field in the ADVJSOR r.able? lt could not be a candidate key because more
than one advisor might share the same office.
CANDIDATE KEY:
FOREIGN KEY: Recall that a common field exists in more than one table and
can be u~ed to form a relationship, or link, between the tables. For example, in
Figure 9- 10, the ADVJSOR NUMBE R fie ld appea rs in both the STUDENT table and
the ADVISOR table a nd joins t he tables together. Note that ADVISOR NUMBER is
a primaqr key in the ADVJSO R table, where it uniq uely identifies each advisor, and
is a foreign key in the STUDENT table. A foreig n key is a field in one table that must
match a primnry key value in another table in order to establish the relationship
between the two rabies.
Unlike a primary key, a foreign key need not be unique. For example, Carlton
Smith has advi~or number 49. T he value 49 must be a unique vnlue in the ADVISOR
table because it is the primary key, but 49 can appear any number of rime!. in the
STUDENT ca hie, where the advisor number serve5 as a foreign key.
Figure 9-10 also shows how rwo foreign keys can serve as n composite primary
key in another rable. Consider the GRADE table at the bottom of the figure. The two
fields that form the primary key for the GRADE table are both foreign keys: the STUDE IT NUMBER field, which must match a student number in the STUDE1'1T cable,
and the COURSE NU.t\IBER field, which must march one of the course IDs in the
COURSE cable.
How can these rwo foreign keys serve as a primary key in the GRADE table? Nore
rhat srudenr numbers and course IDs can appear any number of times in the table, bur
rhe combi11atio11 of a specific student and a specific course occurs onl>• once. For example, srudent 1035 appears four rimes and course CSC 151 appears rhree rimes-but
there is only one combined instance of student l 035 and course CSC 151. Because the
combinarion of the specific student (1035) and the specific course (CSC 151 ) is unique,
it ensures rhat rhe grade (B) will be assigned to the proper student in the proper course.
A secondary key is a field or combination of fields that can be
used to access o r retrieve records. Secondary key values a re not unique. For example,
to access records for only those customers in a specific postal code, the postal code
field wou ld be used as a secondary key. Seconda ry keys a lso can be used to sort or
display records in a certain order. For example, the G PA field in a STUDENT fi le
could be used ro displny records for a ll students in grade point order.
The need for a secondary key arises because a table can have on ly one primary
key. In a CUSTOMER fi le, the CUSTOMER NUMBER is the primary key, ~o it must
be unique. The customer's name might be known, but not the customer's number. For
example, to access a customer named James tvlorgan without knowing hi~ cusromer
number, the table is searched using the CUSTOMER Atvl E field as n secondary key.
The records for all customers named James Morgan are retrieved and then the correcr
record il> selected.
SECONDARY KEY:
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,...... .,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
279
9.4 Data Design Terms
In Figure 9-10, student name and advisor names are idenrified as secondary keys,
but other fields also could be used. For example, to find all students who have a particular advisor, the ADVISOR NUMBER field in the STUDENT table could be used
as a secondary key.
9.4.3 Referential Integrity
Validity checks can help avoid data input errors. One type of validity check, called
referential incegrity, is a set of rules that avoids daca inconsistency and quality problems.
In a relational database, referential integrity means that a foreign key value cannot be
entered in one table unless It marches an existing primary key in another table. For
example, referential integrity would prevent a customer order from bemg enrered in an
order table unless that customer already exists in the customer table. Without referennal
i111egrity, there might be an order called an orphan, because it had no related customer.
In the example shown in Figure 9- 10, referenda! integrity will not allow a user
to enter an advisor number (foreign key value) in the STUDENT table un less a va lid
advisor number (primary key value) already exists in the ADVISOR table.
Referential integrity can also prevent the deletion of a record if the record h as a
pri1nary key that marches foreign keys in another table. For example, suppose that an
advisor resigns to :iccept a position at another school. The advisor cannot be deleted
from the ADVISOR table while records in the STUDENT t able still refer to that
advisor number. Otherwise, the STUDENT records would be orphans. To avoid the
problem, students must be reassigned ro other advisors by changing the value in the
ADVISOR NUMBER field; then the advisor record can be deleted.
When crearing a relational darabase, referential integrity can be built int o rhe
design. Figure 9-11 shows a Microsoft Access screen thar identifies a common field
and allows rhc user ro enforce referential integrity rules.
x
JOB
lOONo
Woft.Codir
Houn
-
MlCHAN:C
°"''
-·
IM<NIN<No
P ly RM>
Patble
Httt O•tt
status
1
Edll Re~11onsh1ps
lmutanc:t
~
x
!l,datm Table}lue-y:
.., JOB
..,
.., Mechanic No
,..
•]
0~§!..c:r~t'f!_"!L~!!l~ti
CCCildo ~ ll<l&:.d Fields
c..c.do ~ l!da:.d ~ds
FIGURE 9· I I Microsoft Access allows a user to specify that referential integrity rules will ~
enforced In a relational database design.
.........""_.. ....-.................
_..__ ...................
("..,_..., llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ·· · ---~~-.,.- " ~
Chapter 9
Data Design
9.5 Entity-Relationship Diagrams
280
9.5 ENTITY•RELATIONSHIP DIAGRAMS
Recall rhar an entiry is a person, a place, a thing, or an event for which dara is
collected and mainrained. For example, entities might be cuscomers, sales regions,
produces, or o rders. An information system muse recognize the relationships a mo ng
encities. For example, a CUSTONlER entiry can have several instances of an ORDER
cnriry, and an E~ I PLOYEE enriry can have one instance, or none, of a SPOUSE entity.
An entity-relationship diagram (ERD) is a model char shows the logical rclarionships and interaction among syscem entities. An ERD provides an overall view of rhe
syscem and a blueprint for creating rhe physical data st ructures.
9.5. 1 Drawing an ERO
The first step is co list the entities chat were idenrified during rhe systems analysis phase and ro consider the nacure of the re larion~hips rhar
link chem. Ar rhis stage, a simplified method can be used ro show rhe
relations hi ps between entities.
Although there a re different ways co draw ERDs, a popular merhod
is ro represen t entities as recta ngles and re lationships as diamond
shapes. T he enti ry rectangles are labeled with s ingular nouns, and
the relarionshi p diamo nds a re labeled with verbs, usually in a cop-tobottom and left-to-right fashion. Fo r example, in Figure 9- l2, a DOCTOR entity treats a PATIENT entiry. Unlike dara flow diagrams, ERDs
depict relationships, not data or information flows.
DOCTOR
A doctor
treats
a patient
TREATS
PATIENT
9.5.2 Types of Relationships
T hree rypes of relationships can exist between entities: one-co-one,
one-to-many, and many-to-many.
A one-to-one relationship, abbreviated 1: l , exists when exactly
one of the second entity occurs for each instance of rhe first entity.
Figure 9-13 shows examples of several l: l relationships. A number
I is placed alongside e ach of the two connecting lines ro indicate the
I: I relationship.
A one-to-man)' relationship,
abbreviated l :M, exists when one occur1
rence of the first entity can relate to many
HEADS
OFFICE
insrances of the second enriry, bur each
instance of rhe second entity can associate
wirh only one insrance of rhe first enri1y.
For example, rhc re lationship herween
1
ASSIGNED
VEHICLE
DEPARTMENT a nd EM PLOYEE is
TO
one-to-ma ny: One depa rrmen t can have
many employees, but each employee
works in only one deparcmenr at a time.
1
ASSIGNED
PERSON
Figure 9-14 shows several l:M relaTO
tionships. T he line connccring the many
entity is labeled with the Jeerer M, and
the number l labels the other connect1
CHAIRS
DEPARTMENT
ing line. How many is many? The first
I :NI relationship shown in Figure 9-14
shows the entities IN DIVIDUAL and
FIGURE 9 - 12 In an enuty-relaaonship
diagram, entities are labeled with singular
nouns and relationships are labeled with
verbs. The rebuonship is interpreted as
a Slmple Enghsh sentence
OFFICE
MANAGER
1
VEHICLE ID
NUMBER
1
SOCIAL
SECURITY
1
DEPARTMENT
HEAD
1
FIGURE 9- 13 Examples of one-to-one ( 1:1) relationships.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
281
9.5 Entity-Re lationship Diagrams
AUTOMOBILE. One individual mighr
own five auromobile , or one, or none.
Thus, many can mean any number,
including 1ero.
A man y-to-man} relation\hip, abbreviared M :N , exisrs when one instance of the
first entity can relate ro man y instances
of rhe second enriry, and one instance
of the second entit)' can relate to many
instances of the first entity. The relation·
ship between STUDENT and CLASS, for
example, is many-ro-many-one student
can take many classes, and one class can
have many students enrolled. Figure 9-15
shows several M:N entity relationships.
One of the connecting lines is labeled
with the letter M, and the lctrer N labels
the other connection.
DEPARTMENT
EMPLOYS
INDIVIDUAL
OINNS
M
1
- - - ' AUTOMOBILE
M
CUSTOMER
PLACES
FACULTY
ADVISOR
ADVISES
ORDER
M
STUDENT
FIGURE 9-14 Examples of one-to-many (l :M) relationships.
N
M
ENROLLS
IN
STUDENT
EMPLOYEE
CLASS
REGISTRATION
M
N
RESERVES
SEATON
PASSENGER
RESERVATION
--- - - - - - - - - - - --l assocoahve entity
N
M
ORDER
LISTS
FLIGHT
PRODUCT
ORDER LINE
FIGURE 9-15 Examples of many-co-many (M:N) ~lationships. Notice that the event or transaction that llnlu the
cwo entitles Is an associative entry with its own sec -of attributes and characteristics.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
--
........... ......
"'Allf'W ~- .............. . ,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
__....
~~·~---- ···---~~-.,.-"~
Chapter 9
Data Design
9.5 Entity-Relationship Diagrams
282
Note that an M:N relationship is different from 1:1 o r l:M relationships because
the event or transacrion that links the two entities is acrually a third entity, called an
a \sociati ve entity, that has irs own characteristics. In the first example in Figure 9-15,
the ENROLL IN symbol represents a REGISTRATIO encity chat records each
instance of a specific student enrolling in a specific course. Similar!)·, the RF-SERVES
SEAT ON symbol represents a RESERVATION entity that records each instance of a
specific passenger reserving a sear on a specific flight. In che ch1rd example, the LISTS
symbol represents an ORDER LINE entity that records each instance of a specific
product listed in a specific customer order.
Figure 9-16 shows an ERD for a sales system. Note the various entities and relationships shown in the figure, including the associative entity named ORDER LINE.
The detailed nature of these relationships is called cardinality. An analyst must
understand cardinality in order to create a data design that accurately reflects all
relationships among system entities.
SALES REP
1
SERVES
M
M
CUSTOMER
PLACES
ORDER
WAREHOUSE
M
ORDER LINE
assocla11ve
enllty
/
STORES
LISTS
N
M
PRODUCT
FIGURE 9- 16 An entity-relationship diagram for SALES REP. CUSTOMER. ORDER. PRODUCT. and
WAREHOUSE. Notice that the ORDER and PRODUCT entities arc joined by an associative entity named
ORDER LINE.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
283
9.5 Entity-Re lationship Diagrams
9.5.3 Cardina lity
Afcer an analyst draws an initial ERD,
he or she must define the relationships
in more detail hy u~mg a technique
called cardinality. Cardinality describes
the numeric relationship between two
entities and shows how instances of one
entity relate to instances of another entity.
For example, consider the relationship
between two entities: CUSTOMER and
ORDER. One customer can have one
order, many orders, or none, but each
order must have one and only one customer. An analyst can model this interaction by adding cardinality notation,
which uses special symbols to represent
the relationship.
A common method of cardina lity
notation is called crow'~ foot notation
because of the shapes, which include
circles, bars, and symbols that indicate
various possibilities. A single bar indicates
one, a double bar indicates one and only
one, a circle indicates zero, and a crow's
foot indicates many. Figure 9- 17 shows
various cardinality symbols, their meanings, and the UML representations of rhe
relationships. As described 111 Chapter 4,
the Unified Modeling Language (UML) is
a widely used method of visualizing and
documenting software ~ystems design.
In Figure 9-18, four examples of cardinality notation are shown. In the first
example, one and only one CUSTOMER
can place anywhere from zero to many
of the ORDER entity. In the second
example, one and only one ORDER can
include one ITEM ORDERED or many.
In the third example, one and only one
EMPLOYEE can have one SPOUSE
or none. Jn rhe fourth example, one
EMPLOYEE, or many employees, or
none, can be assigned to one PROJECT,
or many projects, or none.
Most CASE products support the
drawing of ERDs from entities in the
data repository. Figure 9- 19 shows part
of a library system ERD drawn using
the Visible Analyst CASE cool. Nore that
crow's foot notation i~ used to show the
nature of the relarionship~. which are
described in both directions.
.........""_.. ... .-.................
MEANING
UML
REPRESENTATION
I
One •nd only one
1
Oneorm•ny
1.:
Zero, or one,
or m•ny
o.:
Zero, or one
0 ..1
111
I
p1
po
I
I
I
0
I
FIGURE 9- 17 Crow's foot notation Is a common method of indicating
cardinality. The four examples show how various symbols can be used to
describe che relationships between entitles.
EXAMPLES OF CARDINALITY NOTATION
CUSTOMER
PLACES
ORDER
One and only one CUSTOMER can place anywhere from zero 10 many of !he
ORDER entity.
ORDER
ITEM
ORDERED
INCLUDES
One and only one ORDER can Include one ITEM ORDERED or many.
EMPLOYEE
SPOUSE
HAS
One and only one EMPLOYEE can have one SPOUSE or NONE.
EMPLOYEE
ASSIGNED
TO
PROJECT
One EMPLOYEE, or many employees, or none, can be asS<gned lo one
PROJECT, or many projec1s. or none.
FI GURE 9- 18 In the first example of cardinality notation.one and only one
CUSTOMER an place anywhere from zero to many of the ORDER entity. In the
second example. one and only one ORDER can include one ITEM ORDERED or
many. In the third example, one ~d only one EMPLOYEE an tl3Ye one SPOUSE
or none. In the fourth eicample. one EMPLOYEE.or many employees.or none.
can be assigned ro one PROJECT. or many projecu. or none.
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
SYMBOL
--
........... ......
"'Allf'W ~- .............. . ,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
__....
~~·~----···---~~-.,.-"~
Chapter 9
Data Design
9.6 Data Normalization
284
l..ibracy System Data Model
USER
BOOK
ADO NEW
BOOK
AUTHOR
FI GURE 9. 19 An ERO for a library synem drawn with V1S1bleAnalyst. Nott<:e that crow·s foot
notation has been used and relationships are descnbed m both d1rect10M.
CASE IN POINT 9.1: T orTE..' \I Pusus11L'\ G
TopText Publishing is a textbook publishing company with a headquarters location. a warehouse, and three sales offices that each has a sales manager and sales reps. TopText sells to
schools, colleges, and individual customers. Many authors write more than one book for
TopText, and more than one author writes some books. TopText maintains an active list of
more than 100 books, each identified by a unive rsal code called an ISBN. How would you
draw an ERO for the TopText information system, including cardinality notation!
9.6 DATA NORMALIZATION
Normalizatio n is the process of c reating table designs by assign ing specific fields
or attributes to each table in t he da tabase. A ta ble design specifics the fields a nd
identifies the primary key in a particular table or file . Working with a set of initial
table designs, normalization is used to develop an overall database design tha t is
simple, Acxiblc, and free of data redundancy. Normalization involves applying a
set of ru les chat can help identify and correct inherent problems and complexities
in table designs. The concept of normalization is based on the work of Edgar Codd,
a British computer scientist, who for mulated the basic principles of relational
database design.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Phase l
Systems Design
285
9.6 Data N ormalizat ion
The normalizarion proces~ rypically involves four stages: unnormalized design,
firsr normal form, econd normal form, and rhird normal form. The three normal forms consrirure a progression in which third normal form represents the best
design. Most business-related databases musr be designed in third normal form. Note
that normal forms beyond 3NF exist, but they rarely are used in business-oriented
systems.
9 .6. 1 Standard Notation Format
Designing rabies is easier if a ~tandard notation format is used to show a table'!> structure, fields, and primary key. The standard notation format in the following examples
of an ORDl:.R S)'Stem starts with the name of the cable, followed by a parenthetical
expression that contains the field names separated by commas. The primary key
field(s) is/are underlined, like this:
NAME (FIELD 1, FIELD 2, FIELD 3)
During data design, the analyst must be able to recognize a repeating group of
fields. A repeating group is a set of one or more fields that can occur any number of
times in a single record, with each occurrence having different va lues.
A rypical example of a repeating grou p is s hown in Figu re 9-20. If a company
used written source documents to record orders, they might look like this. As
Figure 9-20 shows, two orders contain multiple items, which constitute repeating
groups within rhe same order number. Note that in addition to the order number
and date, the records with mulriple products contain repetitions of the product
number, description, number ordered, supplier number, supplier name, and I 0
status. A repeating group can be thought of as a set of child (s ubsidiary) records
contained within the parent (main ) record.
pnmary key
primary key tor
for ORDER
repeating group
OllDER (Unnor11 1H1 1ii)
OllD£R
DATt
'1
ii
'M>l>UCT
NUMllll
I DUCall'TION
NUMUll
OllOfll!D
I
SU,"1.1£11
NVMllll
SVl'Plllll
NAME
ISO
304
Bluepdget
7
A-602
Ac:me
Yes
these two
orders have
633
~v
1
J 9'1S
J~
No
repeating
684
Sui-sizmo
4
C-876
Cebot
YM
121!
Stttlw•
12
A-602
Ac~
Ye•
304
Bluepdget
3
A-602
Ac:me
ve,
304
Blue gadget
144
A·602
Ac:me
Yes
86223
9·1l 2019
croups
86390
86467
g 14 2019
9- l S-2019
FIGURE 9·20 In the ORDER table design. cwo orders have repeating groups that contain several products.
ORDER is the primary key for the ORDER cable. and PRODUCT N UMBER serves as a primary key for the
repeating group. Becaun it contains repeating groups. the ORDER table is unnormalized.
A table design rhar contains a repcaring group is called un.normali1ed. The
srandard norarion merhod for representing an unnormalized design is ro enclose
rhe repeating group of fields within a second ser of parentheses. An example of an
unnormali7ed table looks like chis:
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 9
Data Design
9.6 Data Normalization
286
AME (FIELD 1, FIELD 2, FIELD 3, (REPEATING FIELD I, REPEATING
FIELD 2))
Now review the unnormalized ORDER table design shown in Figure 9-20.
Following the notation guidelines, rhe design can be described as follows:
ORDER (ORDER, DATE, (PRODUCT ruMBER, DESCRIPTI01 , NUi\1BER
ORDERED, SUPPLIER U.\.lBER, SUPPLIER NA~1E, I 0 ))
The notation indicates char che ORDER table de~ign contain~ eight fields, which
are listed within the outer parencheses. TI1e ORDER field is underlined to show
that it is the primary kc)'· The PRODUCT NUMBER, DESCRIPTION, NU~tBER
ORDERED, SUPPLIER NUMBER, SUPPLIER NAME, and ISO and NUMBER
ORDERED fields arc enclosed within an inner set of parentheses to indicate that
they arc fields within a repeating group. Note that PRODUCT NUMBER also is
underlined because it acts as the prunary key of the repeating group. If a customer
orders three different products in one order, tbcn six fie lds must be repeated for each
product, as shown in Figure 9-20.
9.6.2 First No rmal Form
A table is in first normal form (INF) if it does not contain a repeating group. To
convert an unnormalized design to 1 NF, the table's primary key must be expanded to
include the primary key of the repeating group.
For example, in the ORDER cable shown in Figure 9-20, the repeating group
consists of six fields: PRODUCT NUMBER, DESCRlPTJON, NUMBER ORDERED,
SUPPLI ER NU.tvl BER, SUPPLIER NAME, and ISO. Of the three fields, only
PRODUCT NUMBER can be a primary key becau~e it uniquely identifies each
inMance of the repeating group. Tbe DESCRlPTIOr cannot be a primar)• key because
it might or might nor be unique. For example, a company might sell a large number
of parts with the same descriptive name, such as washer, relymg on a coded part
number to identify uniquel)' each washer size.
\Vhen rhe primary key of the ORDER table is expanded to include PRODUCT
NUMBER, the repeating group is elimmated, and the ORDER table is now in lNF,
as shown:
ORDER (ORDER, DATE, PRODUCT NUMBER, DESCRWflO , NUMBER
ORDERED, SUPPLIER NUMBER , SUPPLIER NAME, JSO)
Figure 9-21 shows the ORDER table in lNF. Note that when the repealing group
is eliminated, additional records emerge-one for each combination of a specific
order and a specific product. The result is more records but a greatly simplified
design. In the new version, che repeatmg group for order number 86223 has become
three separate records, and the repeating group for order number 86390 has become
two separate records. Therefore, when a table is in lNF, each record stores data about
a single instance of a specific order and a specific product.
Also note that the !NF design shown in Figure 9-2 1 has a combination primary
key. The primary key of the lNF design cannot be the ORDER field a lone, because
the order number does not uniquely identify eacb product in a multiple-item order.
Similarly, PRODUCT NUMBER cannot be me primary key, because it appears more
than once if several orders include the same product. Because each record must reflect
a specific product in a specific order, both fields are needed, ORDER and PRODUCT
NUtvl BER, to identify a single record uniquely. T herefore, the primary key is the
combi11atio11 of rwo fields: ORDER and PRODUCT NUMBER.
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, ..,...,.......,..~
r..a...w...,..._...., ..
Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
.................,.t11ru ..
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
287
9.6 Data Normalization
in 1NF. 1he primary key Is a unique
combmabon of a specific ORDER
and a speofic PRODUCT NUMBER
ORDER lnlNF
OllDER I
DAT£
PRODUCT : DESCltll'TlON
NUMBER I
I
NUMBER I
ORDERED '
SUPPLIER
NUMBER
SUPPLIER
NAME
!
ISO
I
86223
9-13·2019
304
Blue gadget
7
A-602
Acme
Yes
86223
9·13·2019
633
Assembly
1
J·995
Jones
No
86223
9·13 2019
684
Super gmno
4
C·876
ca bot
Yes
86390
9·14 2019
128
Steel widget
12
A·602
Acme
Yes
86390
9·14·2019
304
Blue gadget
3
A-602
Acme
Yes
86467
9·15·2019
304
Blue gadget
144
A·602
Acme
Yes
t
t
1n 1NF
• There are no repeating groups
• The pnmary key Is a unique combination of lWo foretgn key values:
ORDER and PRODUCT NUMBER
• All fields depend on lhe pnmary key, bul some fields do not depend on
1he whole key - only part of it
FIGURE 9·2 1 The ORDER cable as 11 appears in INF.The repeadng groups have been ehminated. Notke that
the repeating group for order 86223 has become three sepante records, and the repeating group for order
86390 has become two sepante records. The I NF primary key is a combination of ORDER and PRODUCT
NUMBER. which uniquely Identifies each record.
9.6.3 Second NormaJ Form
To understand second normal form (2NF), rbe concept of functional dependence must
be understood. For example, Field A is functionally dependent on Field B if the value
of Field A depends on Field B. For example, in Figure 9-21, cbe DATE value is func·
tionally dependent on the ORDER, because for a specific order number, there can be
only one date. ln concrasr, a produce description is not dependent oo the order number. For a panicular order number, there mighr be several product descriptions--<>ne
for each item ordered.
A cable design is in second normal form (2NF) if iris in lNF and if all fields char
arc not part of chc primary key are functionally dependent on the entire primary key.
lf any field in :i INF cable depends on only one of the fields in a combination primary
key, rhen the table is not in 2 IF.
Note rhar if a l NF design has a primary key rhac consists of only one field, the problem of partial dependence docs not arise-because rhe entire primary key is a single
field. Therefore, a I NF table with a single-field primary key is automatically in 2 F.
Now reexamine the I NF design for the ORDER table shown in Figure 9-2 1:
ORDER (ORPER, DATE, PRODUCT NUMBER, DESCRIPTION, NUMBER
ORDERED, SUPPLIER NUMBER, SUPPLIER NA.i\llE, ISO)
Recall that the primary key is the combination of the order number and the
product number. The NUMBER ORDERED field depends on the entire primary key
because NUMBER ORDERED refers to a specific product number and a specific
order number. In contrast, the DATE field depends on the order number, which is only
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 9
Data Design
9.6 Data Normalization
288
a part of rhe primary key. Similarly, the DESCRIPTION field depends on the product number, which also is only a part of rhe primary key. Because some fields are nor
dependenr on rhe entire primary key, rhe design is nor in 2NF.
A standard process exists for converting a cable from 1NF to 2NF. The objective is
to break the original table into two or more new tables and rea'iStgn the fields so that
each nonkey field will depend on rhe enrire primary key in its table. To accomplish
this, the following steps should be followed:
I. Create and name a scparare cable for each field in rhe existing primarr kcr.
For example, in Figure 9-21, rhe ORDER rable's primary key has two fields,
ORDER and PRODUCT NUMBER, so rwo rabies muse be created. The ellipsis
(... ) indicates thar fields will be assigned lacer. The result is:
ORDER (ORDER, ... )
PRODUCT (PRODUCT NUMBER, ... )
2. Create ::i new table for each possible combination of the origina l primary key
fields. In rhe Figure 9-21 example, a new table would be created wirh a combination primary key of ORDER and PRODUCT NUMBER. This rable describes
individual lines in an order, so it is named ORDER LINE, as shown:
ORDER LINE (ORDER, PRODUCT NUMBER)
3. Study rhe three rabies and place each field wirh irs appropriate primary key,
which is the m111imal key on which ir fw1crionally depends. When all rhe fields
have been placed, remove any cable that did nor have any additional fields
assigned co it. The remaining tables are the 2NF version of rhe original cable.
The chree rabies can be shown as:
ORDER (ORDER, DATE)
PRODUCT (PRODUCT NUMBER, DESCRIPTION, SUPPLIER
1UMBER, SUPPLIER 1AME, ISO)
ORDER LINE (ORDER, PRODUCT NUr.1BERl
Figure 9-22 shows rbe 2NF cable designs. By following the seeps, rhe original lNF
table has been converted into three 2NF rabies.
\Vhy is ir important ro move from INF ro 2NF? Four kinds of problems are found
with 1 rF designs char do nor exist in 2NF:
I. Consider rhe work necessary to change a particular product's description. Suppose 500 current orders exist for product number 304. Changing the product
description involves modifying 500 records for product number 304. Updating
all 500 records would be cumbersome and expensive.
2. I NF rabies ca n conrain inconsistent data. Because someone must enter the
product description in each record, nothing prevents producr number 304 from
having different product descriptions in different records. In face, if product
number 304 appears in a large number of order records, some of rhe marching product descriptions might be inaccurate or improperly spelled. Even the
presence or absence of a hyphen in the orders for all-purpose gadget would
create consistency problems. If a data entry person must enter a term such
as 10 I Queue Controlfer numerous times, ir certainly is possible char some
inconsisrcncy will result.
3. Adding a new product is a problem. Because the primary key muse include an
order number and a produce number, values arc needed for borh fields in order
to add a record. What value should be used for the order number when no
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
289
9.6 Data N ormalizat ion
ORDER ln2NF
PRODUCT In 2NF
ORDER
ORDER
DATE
PRODUCT
NUMBER
DESCRI PTION
86223
9-13·2019
128
86390
9 · 14·2019
9·1S·2019
86467
j
I SUPPLIER SUPPLIER
1
'
ISO
NUMBER
NAME
Steel widget
A-602
Acme
Yes
304
Blue gadget
A ·602
Acme
Yes
633
Assembly
1·995
Jones
No
684
Supergjzmo
C·876
Cabot
Yes
'
·~
ICJWll UNE In JNf
I
OllOEll
PilOOUCT
NUMll£11
86225
504
7
86225
635
1
86225
68'
4
116390
128
.l2
116390
!!04
3
16467
304
144
•
on 2NF the primary key of ORDER LINE IS a
un
combonat1on of two foreign keys
FIGURE 9-l l ORDER. PRODUCT. and ORDER LINE tables in 2NF. All fields are functionally dependent on
die pnrmry key
c ustomer has ordered che product? A dummy order numbe r could be used and
later replaced with a real order number when the product is ordered ro solve
the pro blem, bur char solution also creates difficulties.
4. Deleting a produce is a problem. If all the related records are deleted once an
order is filled and paid for, whar happens if the only record that contains product number 633 is deleted? The information about that product number and its
description is lost.
I las the 2 f design eliminated all potential problems? To change a product
description, now just one PRODUCT record needs to be changed. Multiple, inconsistent values for the product description are impossible because the description appears
in only one location. To add a new product, a new PRODUCT record is created,
instead of creating a dummy order record. When the last ORDER LINE record for a
particular product number is removed, that product number and its description is not
lost because the PRODUCT record still exists. The four potential problems are eliminated, and the three 2NF designs are superior ro both the original unnormalized rable
and the INF design.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Cha p ter 9
Data Design
9.6 Data Nor malizat ion
290
9.6.4 Third Normal Fo rm
A popular ru le of t humb is that a design is in 3NF if every non key field depends o n
the key, the whole key, and nothing but the key. A 3 NF d esign avoids redunda ncy
and dara inccgriC) probl ems cha t Still can exisr in 2NF designs.
Conti nui ng th e ORDER example, now review che PRODUCT rable design in
Figu re 9-23:
PRODUCT (PRODUCT NUMBER, DESCRIPTION, SUPPLIER NUMBER,
SUPPLfER NAtvlE, ISO)
PRODUCT In 2NF
~~~~~~~~
'
IDESCRIPTION
128
Steel widget
A-602
304
Blue gadget
A-602
633
Assembly
684
Super gizmo
PRODUCT
NUMBER
•••
••
•
..•
.
I ISO
SUPPLIER : SUPPLIER
NUMBER ; NAME
•
: Acme
Yes
Acme
Yes
J-995
Jones
No
C-876
Cabot
Yes
••
....................•
'
SUPPLIER In 3NF
PRODUCT In 3NF
PRODUCT
NUMBER
'
DESCRIPTION
128
'''
'
ISUPPLIER 11so
NUMBER
SUPPLIER
NUMBER
Steel widget
A-602
A-602
Acme
Yes
304
Blue gadget
A- 602
J-995
Jones
No
633
Assembly
J-995
C876
Cabot
Yes
684
Supergizmo
C-876
ISUPPLIER
NAME
FIGURE 9-23 Wilen tile PRODUCT table Is transformed from 2NF to JNF, tile result Is cwo separate
tables: PRODUCT and SUPPLIER. Note mat In JNF, all fields depend on tile key alone.
The PRODUCT cable is in J NF because ic has no repeacing group~. T he c:i ble a lso
is in 2NF bcc:iusc the primary key is a single fi eld. But the table still has four po tcncial problems:
I. To cha nge a supplier na me, every record in which tha t na me a ppears must be
cha nged. With hundreds, o r even thousands o f record s, the process would be
slow, expensive, and subject to input erro rs.
2. T he 2NF d esign a llows a supplier co ha ve a different name or ISO sta rus in
different recor ds.
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
29 1
9.6 Data N ormalization
3. Because the supplier name is included in che O RDER cable, a dummy ORDER
record muse be created co add a new supplier who has not yec been received
any orders.
4. If all the orders for a supplier are deleted, that supplier's number and name will
be lost.
Those potential problems are caused because the design is not in 3NF. A cable
design is m thi rd nom1al fonn (3NF) if it is in 2NF and if no nonkey field is dependent on another nonkey field. Remember that a nonkey field is a field that is not a
candidate ke)' for the primary key.
T he PRODUCT table at the top of Figure 9-23 is not in 3NF because two nonkey
fields, SUPPLI ER NAME and ISO, both depend on another nonkey field, SUPPLIER
NUMBER.
To converr the rable to 3NF, all fields from the 2NF table that depend on another
nonkey field must be removed and placed in a new table that uses the nonkey field as a
primary key. In the PRODUCT example, SUPPLIER NAME and ISO must be removed
and placed into a new table that uses SUPPUER NUMBER as the primary key. As
shown in Figure 9-23, 3NF divides the 2NF version into two scp<uace 3NF tables:
PRODUCT (PRODUCT NU MBER, DESCRIPTION, SUPPLIER NUMBER)
SUPPLI ER (SUPPLIER NUMBER, SUPPLIER NAME, ISO)
CASE IN POINT 9.2:
CYBERTOYS
You handle administrative support for CyberToys, a small chain that sells computer hardware and
software and specializes in personal service. The company has four stores located at malls and is
planning more. Each store has a manager. a technician, and between one and four sales reps.
The owners want to create a personnel records database, and they asked you co
review a cable chat they had designed. They suggested fields for score number. location,
score telephone, manager name, and manager home telephone. They also wane fields for
technician name and technician home telephone and fields for up co four sales rep names
and sales rep home telephones.
Draw their suggested design and analyze it using the normali"Zation concepts you
learned in the chapter. What do you think o f their design and why/ W hat would you
propose?
9.6.5 Two Re al-World Examples
A good way to learn about norma lization is to apply the
r ules to a representative situa tion. This section presents
two diffe rent scenarios: first a school a nd tben a rechnical
service company. If a step-by-step process is followed, data
designs can be created tha t a re efficient, maincainable, and
er ror-resistant.
Crossroads Co llege: Consider the fami liar
situation in Figure 9-24, which depicts several entities
in the Crossroads College advising system: ADVlSOR,
COURSE, and STUDENT. The relationships among the
three entities are shown in the ERO in Figure 9-25. The
following secnons discuss normali1.arion rules for these
three entities.
EXAMPLE I :
FIG URE 9·24 A faculty advisor, who represents an
em1ty, can advise many students, each of whom can
reginer for one or many courses.
"'
r
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Chapter 9
Data Design
9 .6 Data Normalization
292
Before the normaliz~nion process is
scarred, it is noted that the TUDENT
cable contains field5 rhar rclarc ro rhe
ADVISOR and COURSE cnrirics, so a
d ecision is made co begin with the initial
design for the STUDEl\'T cable, which
is shown m Figure 9-26. Nore rhac the
rable design includes the student number,
student name, coral credits taken, grade
point average (GPA), advisor number,
advisor name, and, for every course the
student has taken, the course number,
course description, number of credits, and
grade received.
The STUDENT table in Figure 9-26 is
m1nor111aljzed because it has a repeating
group. Tbe STUDENT table design can be
written as:
M
ADVISOR
STUDENT
ADVISES
TAKES
N
COURSE
FIGURE 9°25 An Initial entity-relationship diagram for ADVISOR, STUDENT.
and COURSE.
STUDENT (STUDENT NUMBER, STUDENT NAME, TOTAL CREDITS,
Gl'A, ADVISOR NUMBER, ADVfSOR NAME, OFFICE, (COURSf.. ~l..!.i.~B~R,
CREDIT HOURS, GRADE))
To convert the STUDENT record to I NF, the primary key must be expanded co
include the key of the repeating grou p, producing:
STUDENT (STUDENT NUMBER, STUDENT NAME, TOTAL CREDITS, CPA,
ADVISOR NUNlBER, ADVISOR NAME, OFFICE, COURSE NUMBER, CREDIT
HOURS, GRADE)
STUDENT(Umom...lnd)
STUDENT
NUMIEll
101)
3397
4070
I STUDENT TOTAL I GPA I ADVISOR I ADVISOll I OFRCE
NAME
CREDITS
Unda
41
Sam
Kelly
29
14
NUMBEll
l.fiO
].(]()
2.90
! NAME
Smith
49
49
Smtih
Jones
23
82.12
8212
C333
'1
COUllSE
NUMIEll
I CREOIT I GllAOE
HOURS
CSCUl
4
a
MKT212
3
A
ENGlOl
3
a
CHM112
4
A
BUS105
2
A
ENGlOl
l
A
MKT212
!
CSCl.Sl
4
c
a
CSCUl
4
B
CHMlU
4
ENG101
3
BUS1~
2
c
c
c
FIGURE 9-26 The STUDENT table is unnormalized because It contains ;a repeating group that represents the
course each student has taken.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f •,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
293
9.6 Data Normalization
Figure 9-27 shows the 1NF version of rhe sample STUDENT data. Do any of the
fields in the l F STUDENT table depend on only a portion of the primary key? The
student name, total credits, GPA, advisor number, and advisor name all relate only
to the student number and have no relationship to che course number. The course
description depend~ on che course number but not on the srudent number. Onl)' che
GRADE field depends on the entire primary key.
111 1NF. 1he pnmary key is a unique combmatlO!l ol a
STUDENT NUMBER and a speofic COURSE NUMBER
STUDENT In lNF
1035
Un.U
47
3.60
49
Smith
82U
CSCl.51
4
8
1015
unda
47
3.60
49
Smlllt
82U
MICTU2
l
A
1015
Lindi
41
J.60
49
Sm1th
B2U
ENGlOl
l
B
1035
l..nd1
47
3.60
49
Smrth
B2U
CHMll2
4
A
1015
Un.U
47
3.60
49
Smith
Blll
8US105
2
A
3397
Sam
29
l.00
49
Smith
82U
ENG101
l
A
3397
5.tm
29
l.00
49
Smith
82U
MICT2U
3
c
3397
s.tm
29
3.00
82U
CSCUl
4
B
4(J7Q
kelty
14
2.90
"'
Sm1th
23
Jones
033
CSClSl
4
8
<IOJO
Kelly
14
2.90
23
Jones
C333
CHM Ill
4
c
<IO'IO
Kelly
14
2.90
23
JO<> es
Clll
ENGIOl
3
"°'°
Kelly
14
2.90
23
Jones
013
lkJSUIS
2
c
c
rn 1NF.
• There are no repeating groups
• The prmary key Is a unique combtnahon of two foretgn key values: STUDENT NUMBER
and COURSE NUMBER
• All field$ depend on Ille primary key. but some fields do not depend on the whole key - only
part of ii
FIGURE 9-27 The student cable in I NF. Notice that the primary key has been expanded to include STUDENT
NUMBER and COURSE NUMBER.
Following the I NF-2 F conversion process described earlier, a new table would
be created for each field and combination o f fields in rhe primary key, and rhe other
fields would be placed with their appropriate key. The result is:
STUDENT (STUDENT NUMBER, STUDENT NAME, TOTAL CRED ITS, GPA,
ADVISOR NUMBER, ADVISOR NAME, OFFICE)
COURSE (COURSE NUMBER, CREDIT HOURS)
GRADE (STUDENT NUMBER, COURSE NUMBER, GRADE)
The original I F STUD ENT rable has now been convened into three tables, all in
2NF. In each table, every nonkcy field depends on che entire primary key.
Figure 9-28 shows the 2NF STUDENT, COURSE, and GRADE designs and
sample data. Are all three tables STUDENT in 3NF? The COURSE and GRADE
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 9
Data Design
9 .6 Data Normalization
294
rabies arc in 3NF. STUDENT is not in 3 F, however, because rhe ADVISOR NAME
and OFFICF fields depend on the ADV1SOR 1UN1BER field, which 1s nor part of che
STUDFNT primary key. To convert STUDENT co 3NF, the ADVI OR NAME and
OFFICE fields are removed from che STUDE. T cable and placed into a cable with
ADVISOR NUtvl BER as che primary key.
COURSE In ZNF
STUDENT In ZNF
STUDENT I STUDENT
NUMBEll , NAME
lOlS
''
llr>da
ITOTAL I GPA
47
'
CREDIT
HOURS
ADVISOR
NAME
3.60
49
Smith
B2U
BUSlOS
2
CREDITS
OFFICE
COUllSE
NUMBER
ADVISOR
NUMBER
I'
3397
Sam
l.00
49
Smith
B2U
CHM112
4
4070
Kelly
2.90
23
Jones
C333
CSClSl
4
ENG101
3
MKTlU
3
GRADElnZNF
STUDENT
! COURSE
I GRADE
'
'
'
+
'
'
'
NUMBER
NUMBER
I
I
1n2NF
• All fields now depend
on the whole pnmary
key, but some fields
aleo might depend on
other fields lhat are nol
pan of the pnrnary key
• The pnrnary key of
GRADE ls a unique
combination of two
foreign key values.
STUDENT NUMBER
and COURSE NUMBER
1035
CSCJ.51
B
1035
MKT212
A
103S
ENGlOl
a
lOlS
CHMU2
A
lOlS
BUSlOS
A
3397
ENG101
A
3397
MICT2U
c
3397
CSCUl
a
4070
CSCUl
a
4070
OiMlU
c
4070
ENG101
c
4070
BUSlOS
c
c.........
FIGURE 9-28 The STUDENT, COURSE, and GRADE tables In 2NF. Notice that all fields are functionally
dependent on the entire primary key of their o-espective tables.
Figure 9-29 shows the 3NF versions of rhe sample data for ST UDENT, ADVISOR,
COURSE, and GRADE. The final 3.NF design is:
ST UDENT (STUDENT NUMBER, STUDE1''T NAME, TOTAL CREDITS, GPA,
ADVISOR NUNIBER)
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
- Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
- ·~• -fllllie<'f •,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Sys tems Design
295
9.6 Data N ormalizat ion
ADVISOR (ADVISOR NUMBER, ADVISOR A?vlE, OFFICE)
COURSE (COURSE NUMBER, CREDIT HOURS)
GRADE (STUDENT NUMBER, COURSE NUfy1BER, GRADE)
STUDENT In ZNF
STUDENT
NUMBER
I
STUDENT
NAME
I
TOTAL
CREDITS
IGPA I ADVISOR
. ADVISOR I OFFICE
NUMBER : NAME
1035
Linda
47
3.60
49
Smith
8212
3397
Sam
29
3.00
49
Smith
8212
4070
Kelly
14
2.90
23
Jones
033
....•............
'
STUDENT In 3NF
'
ADVISOR In 3NF
I
ICREDITS I
NUMBER NAME
STUDENT
STUDENT
101)
3397
TOTAL
GPA
47
Sam
4070
14
'''
INUMBER
ADVISOR
'
ADVISOR
I ADVISOR I OFFICE
NUMBER
NAME
3.60
49
Smith
B2U
3.00
23
Jones
C333
2.90
23
FIG URE 9-29 STUDENT. ADVISOR. COURSE. and GRADE tables in lNF. When the STUDENT table 1s
transformed from lNF to lNF, che result is tw0 tables: STUDENT and ADVISOR.
Figure 9-30 hows
the complere ERD after
normalizarion. Now rhere
are four entities: STUDENT,
ADVISOR, COURSE,
and GRADE (which is
an associative entiry).
Note how Figure 9-25,
which was drawn before
GRADE was identified as
an entity, shows that che
M:N relationship between
STUDENT and COURSE
has been converted inco
two l:M relationships:
one relationship between
STUDENT and GRADE
and rhe other rclacionship
bcrween COURSE and
GRADE.
.........""_.. ... .-.................
1
ADVISOR
ADVISES
M
STUDENT
1
RECEIVES
M
1
COURSE
SHOWS
M
GRADE
l
assoc1atm
enllty
FIGURE 9 °30 The entity-relationship diagram for STUDENT. ADVISOR. and COURSE after
normaliution. The GRADE entry was idemified during the normaliution process. GRADE is an
associative enoty that links the STUDENT and COURSE tables
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 9
Data Design
9.6 Data Normalization
296
-,..._
- .
To creare 3NF designs, the nanire of first, second, and
rhird normal forms must be understood. A S)' rems analyst will encounter designs that are much more complex
than the examples in this chapter.
,. .......
-- \• -----·- . .--- ....I -·\.. -·------ I
-T-
•
•
•
Magic J\i\ aintenance: .Nlagic Maintenance
provides on-sire service for eleccronic equipment. Figure 9-31
shows the overall database design drnr such a finn might use.
The 6guce contains examples of many concepts described
earlier. The database consists of seven separate rabies, all
joined by common 6elds, so they form an integral data
scructure.
Figure 9-32 shows even more derail, including sample
dara, primary keys, and common fields. Nore rhat rhe
eariries include customers, technicians, service calls,
EXAMPLE 2:
~
FIGURE 9-31 A relational database design for a
computer service company uses common fields co link
the cables and form an overall daca structure. Notice the
one-to-many notation symbols and the primary keys.
which are indicated with gold-colored key symbols.
s
".J <Um>MIR
lW IAIOll ('OOf \
lAllOR COD£
HOURLY-RATl •
• A
•
•
Sl5.00
$<U.OO
. 0
SMOO
•c
• 1456
• 1913
• 2S16
• 6121
• ll7<iO
~soo
CAU· NUM • lABOR-CODE
'10796
" cA
107'6
10791
B
10799
c
10799
D
A
10801
::;J SEIMCC Pi ITTOfTAll \
CAU·lllUM
PART·NUM
107'6
00-9192
SS·llll
10796
10797
AB-6784
10799
AB-6784
10799
XC-3133
SS-1024
10800
.
I i1] PARTS \
'
PART· NUM
• AB-6784
• 00-9192
• SS-1024
I
• SS-1099
• 5$-lUI
• XC·llll
CUSHAST · ' CVSHlllST • ' CUST·A~S • CUH-Cll'f • CUU·STAT( ·
Dtnv..JonH
Albo'1
•J0.11.DrM
co
1011 H1lllop Rood Chotlott•
~c
vatdt:J
1nn1
Gonutez
67UthSttHt
Stott It
WA
Jul"I
--- ....
· 1848
:::J SUMCl 1.-'- OOAll'
-
x
C~T-NUM ·
a.111
thly
SAruono
JIC~le
. lABOR·HOURS .
,
3;JlSm!1hUM
CAU·N~JM
. CUST·NUM .
14)6
• 10796
• 10797
• 10791
• 10799
LS
2.0
s.o
LS
I
1.S
101 MJlti Slfoet
~ SOMCf <ALl\
x
s." Jat1nto
CA
'""•bt"V c..... .......,
1456
6J21
14)6
- 10800
Fl
H\.ldlOn
x
T
OATf
. T[(H·NUM .
U/U/2019 04
U/13/2019 17
11/13/201' 04
12/l.S/2019 21
U/16/201' 21
1211"'2019 09
2136
• 10801
"'A
2.5
x
. QTY .
;:J TI'OI
'
TECH NUM
4
• 04
2
• 0'9
x
. T£CH·lAST . TECH FIRST . HlRE·OATI .
Robison
Wh1tf1eld
Kaplan
Chood
Johnson
~ 17
6
1
• 20
• . 21
15
GefTY
oa..d
~··
L11land
Mane
6/1/'1008
8/1/2001
1/1/l'J93
U/1/2003
10/1/2014
8
x
. PART·DESC . Tcosr. PRICE . QTY-ON·HANO .
MffiR
DISC
COVER
EMBLEM
JUMPER
CABLE
SL30
$125.00 33
$1.69 220
$16.00
$19.7'9 71
S38.00
S50.00 41
SlS.00 3
$98.50
SU.SO
<:6 75
•'
Primary Keys
Common fields
<=7.9!1 77
FIGURE 9-ll Sample data, promary keys, and common fields for the database shown in Figure 9-31 .
The design is in )NF. Notice that all nonkey fields functionally depend on a primary key alone.
~- )U,
-Woip-M ._..,..
r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
..
(....,..... J:gl( . . . . .
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
__.~~c.....,..~
.........,..,. ..
._.,.,.,.......c:-..•~-".....-""'*"....,.._...,..
..
Phase l
Systems Design
29 7
9.7 Codes
and parts. Orher tahles srore dara abour labor and pans char are used on specific
service calls. Also nore that all rabies use a single field as a primary key, except the
SERVICE-L.ABOR-DFTAIL and SERVICE-PARTS-DETAIL rabies, where the primary
key requires a combinarion of rwo fields to uniquely identify each record.
9.7 CODES
A code is a ser of letters or numbers thar represents a data item. Codes can be used to
simplify outpur, inpur, and data formars.
9.7. I Ove rview of Code s
Because codes can represent dara, they are encountered constantly in everyday life.
Student numbers, for example, are unique codes to identify srudents in a school
regisrr:irion ~ystem. Three srudents with the name j ohn Turner might be enrolled ar
the same school, bur <lnly one is srudenr number 268960.
A poswl code is another common example. A nine-digit posta l code contain~ n lot
of inform:irion. Por example, the first digit idenciifies 1 of 10 main geographical areas
in the United St:Jtes. The combinarion of the next three digits idencifies a major city
or m:ijor distribution poinc. The fifth digit identifies an individual post office, an :irea
within a city, or a specific delivery unit. The lasr four digirs identify a post office box
or a specific ~rreet address.
For example, consider the zip code 3290 1-6975 shown in Figure 9-33. This is
called the "5+4" zip code format. The first digit, 3, indicares a broad geographical
area in the southea~rem Unired Srares. The nex't two digits, 29, indicate the area
east of Orlando in Florida. The next rwo digits, 01, represent the city of Nlelbourne,
Florida. The last four digits represent the specific location of the Florida institute of
Technology: 150 W. University Blvd.
Codes can be used in many ways. Because codes are shorter than the data they
represent, they save storage space and costs, reduce dara transmission time, and
decrease data entry rime. Codes also can be used ro reveal or conceal information.
The last two digits of a seven-digit part number, for example, mighr represent the
supplier number or the maximum discounr thar a salesperson can offer.
Finall)', codes can reduce dara input errors in situations when the coded data is
easier to remember and enter than the original source data, when only certain valid
codes arc allowed, and when something within the code itself can provide immediate
verification that the entr y is correct.
Broad geographical
locallon In
soUlheastem US
FL
Ot1ando
East
Melbourne
3
29
01
Florida Tech
150 W. Unlvers11y Blvd.
6975
F IG URE 9 -33 A zip code Is an example of a significant digit code that
uses groups and subgroups to store data. Th is example is for the zip code
32901-6975. which Is the location of the Florida Institute or Technology in
Melbourne, Florida.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 9
Data Design
9.7 Codes
298
9.7.2 Types of Codes
Companies use many djfferent cocling methods. Because information system users
mu~c work wirh coded data, the codes should be ea!>y to learn and apply. If it is planned
to create new codes or change existing oaes, comments and feedback from u~rs should
be obtained. The following section describes seven cominon coding methods.
1. Sequence codes are numbers or leners assigned in a specific order. equcncc
codes contain no additional information ocher than an indicarion of order of
enrry into the sy tern. For example, a human resource sysrem issues consccurive
cmplo)•ec numbers ro identify employees. Because the codes arc as~igned in the
orde r in which employees are hired, rhe code can be used to 'ce thar employee
number 584 was hired after employee number 433. The code, however, does
not indicate the starting date of either person's emplo)'ment.
2. Block sequence codes use blocks of numbers for different classifications. College course numbers usually are assigned using a block sequence code. JOO-level
courses, such as Chemistry 110 and Mathematics 125, are freshman-level
courses, whereas course numbers in the 200s indicate sophomore-level courses.
Within a particular block, the sequence of numbers can have some addirional
meaning, such as when English 151 is rhe prerequisite for English 152.
3. Alpha betic codes use alphabet lecters to distinguish one item from another
ba~ed on a category, an abbreviation, or an easy-to-remember value, called a
mnemonic code.1'tlany classification codes fir more than one of the following
definitions:
a. Category codes identify a group of related items. For example, a local
department store uses a two-character category code ro identify the
department in which a product is
sold: GN for gardening supplies,
....
HW for hardware, and EL for
electronics.
b. AbbreYiation codes are alphabetic
abbreviations. For example, standard
state codes include NY for New York,
ME for ~l aine, and MN for Minne.................
sota. Some abbreviation codes arc
called mnemonic codes because they
..
_
.
__
....
use a specific combination of lcncrs
_,........ ..
.....
that arc easy to remember. Many
three-character airport codes such
_, _____. .....
..... .......
as those pictured in Figure 9-34 arc
mnemonic codes, such as ATL for
Atlanta and MIA for Miami. I Iowcver,
.............
.........
..-... ....
----·~
some airport codes arc not mnemonic,
such as ORD (Chicago O'Hare) or
FIG UR E 9-3 4 Abbreviations for some of the world's busiest airports.
MCO (Orlando).
' "
ATL
ORO
u-IR
HNO
LAX
__
-------oFW FRA aDG
OEN
-·--- AMS
···PHX
IAH
HKG
--- LAS
--- MAD
-.-... . ._
.
MSP o1W
-·-- aKK SFO MIA
JFK
LGW
EWR
SIN
NRT
---·- -~....... ...
PEK
_._
- sTL
------ seA
-·---- MCO VY!
4. Significant digit codes distinguish items by using a series of subgroups of digits.
Postal codes, for example, are significant digit codes. Ocher such codes include
inventory location codes that consist of a rwo-digit warehouse code, followed
by a one-digir floor number code, a two-digit section code, a one-digit aisle
number, and a two-digit bin number code. Figure 9-35 illustrates the invenrory
locarion code l 1205327. \~bat looks like a large eight-digit number is actually
five separarc numbers, each of which has significance.
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, ..,...,.......,..~
r..a...w...,..._...., ..
Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
.................,.t11ru ..
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
299
9.7 Codes
Section code
Warehouse location code
Bin number
'
11
'
2
05
3
'
27
A
Floor number - - - - - - -
~------ Aisle number
FIGURE 9.35 »mple o( a code that uses signifle3nt digits to pinpoint the loation of an inventory item.
5. Derivation codes combine data from different
item attributes, or characteristics. Most magazine subscription codes arc derivation codes.
For example, one popular magazine uses a
subscriber's five-digit postal code, followedl by
31749 ADE 34 EBE
the first, third, and fourth letters of the subscriber's last name, the last two digits of the
subscriber's house number, and the first, third,
FIGURE 9-36 A magazine subscriber code is derived from
and fourth letters of the subscriber's street
various parts of the name and addreu.
name. A sample is shown in Figure 9-36.
6. Cipher codes use a keyword to encode a number. A retail store, for example,
might use a 10-letter word, such as CAMPGROUND, to code wholesale prices,
where the letter C represents 1, A represents 2, and so on. Thus, the code,
GRAND, indicates that the store paid $562.90 for the item.
7. Action codes indicate what action is to be taken with an associated item.
For example, a student records program might prompt a user to enter or dick
an action code such as D (to display a record), A (to add a record), and X (to
exit the program).
9.7.3 Designing Codes
H ere arc some code design suggestions:
• Keep codes concise. Do not create codes that are longer than necessary. For example,
if a code is needed to identify each of 250 customers, a six-digit code is not needed.
• A/10111 for expansion. A coding scheme must allow for reasonable growth
in the number of assigned codes. For example, if the company currently has
eight warehouses, do not use a one-digit code for the warehouse number. If
rwo more warehouses are added, rhe code must be increased ro two digits
or changed ro a character code in order to identify each location. The rule
also applies to u~ing a single letter as a character code hecause more than 26
data items might be needed in the future. Of course, more characters can be
added, which is just what the airline industry has done. Most airlines now use
six-character codes char allow millions of combinations.
• Keep codes stable. Changes in codes can cause consistency problems and
require data updates. During the changeover period, all the stored occurrences
of a particular code and all documencs containing the old code will have to
change as users switch ro the new code. Usually, both the old and new codes
arc used for an interim period, and special procedures arc required to handle
the two codes. For example, when telephone area codes change, either area
code (old or new) can be used for a certain time period.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~----···---~~-.,.-"~
Chapter 9
Data Design
300
9.7 Codes
• Make codes unique. Codes used for idencification purposes must be unique co
have meaning. If che code H\V can indicace hardware or houscware, che code is
nor ver)' usefu I.
•
Use sortable codes. If products with three-digic codes in the I OOs or the 300s
are of one type, while produces with codes in the 200s are a different type, a
simple sort will nor group all t he products of one type together. In addition,
be careful rhar single-digit character codes will sort properly with double-digit
codes-in some cases a leading zero must be added (0 1, 02, 03, ere.) to ensure
char codes sorr correcrly.
•
Use a simple structure. Do noc code some part numbers wich two letters, a
hyphen, and one digit, and ot hers with one letter, a h)•phen, and two digits.
Avoid allowing both letters and numbers to occupy the same positions wichin a
code because some of those are easily confused. This situation mighc be a good
place co u~e an inpuc mask to assure that the correct data type b entered.
•
Avoid co11f11sio11. It is easy ro confuse the number zero (0) and the uppercase
letter 0, o r the num ber o ne (1 ) with the lowercase lette r L (I) or uppercase
lcrrer I. For example, rhe five-character code 5Z08 l easi ly can be misread as
5Z08I, o r 52081.
• Make codes meaningful. Codes should be easy to remember, user-friend ly,
convenient, and easy to interpret. Using S\Xl as a code for the southwest sa les
region, for example, has far more mea ning than t he code 14. Using ENG as t he
code for t he English department is easier to interpret and remember than eicher
XVA or 132.
•
•
Use a code for a single purpose. Do not use a code co classify unrelaced attributes. For example, if a single code is used to identify the combination of an
employee's depa rtment and t he employee's insurance plan C)'pe, users will have
difficulty idenrifying all the subscribers of a particular plan, or all the workers
1n a particular depa rtment, or both. A separare code for each separate characteristic makes much more sense.
Keep codes consistent. Foe example, if the payroll system al ready is using twodigir codes for departments, do not create a new, different coding scheme for
rhe personnel sysrcm. lf the two systems already arc using differen t coding
schemes, cry to esrablish a consistent coding scheme.
CASE IN POINT 9.3: MADERA TOOLS
Madera Tools operates a small business that specializes in hard-to-find woodworking
tools. The firm advertises in various woodworking magazines and currently accepts mail
and telephone orders. Madera Is planning a website that will be the firm's primary sales
channel. The site will feature an online catalog. powerful search capabilities, and links to
woodworking information and resources.
Madera has asked you, an IT consu leant, whether a set of codes would be
advantageous. What codes would you suggest? Provide at least two choices for a
customer code and at least two choices for a product code. Be sure to describe your
choices and provide some specific examples. Also include an explanation of why you
selected these particular codes and what advantages they might offer.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
Phase l
Systems Design
301
9.8 Data Storage and Access
9.8 DATA STORAGE AND Access
Data storage and access involve scraregic business cools, such as data warehousing
and data mining software, as well as logical and physical storage issues, selecrion of
data storage formats, and special considerations regarding storage of date fields.
9.8. 1 Tools a nd Techniques
Companies use data warehousing and data minj11g as srraregic tools to help manage
the huge quanriries of data they need for business operations and decisions. A large
number of sofr.vare vendors compete for business in chis fast-growing IT sector.
Large firms maintain many darabases, which mtght or
might not be linked together inro an overall structure. To provide rapid access to this
i11formation, companies use software packages that organize and store data in special
configurations called data warehouses. A data warehouse is an integrated collection
of daca that can include seemingly unrelated information, no matter where it is stored
in the company. Because it can link various in£0C1Ination systems and databases, a data
warehouse provides an enterprise-wide view to supporc management analysis and
decision making.
A darn warehouse allows users to specify certain din1ensions, or characteristics. By
selecting values for each characteristic, a user can obtain multidimensional information from the stored data. For example, in a typical company, n1ost data is generated
by transaction-based systems, such as order processing systems, inventory systems,
and payroll systems. If a user wants ro identify the customer on sales order 34071, he
or she can retrieve the data easily
DliMn•lon•
from the order processing system
by entering an order number.
On the other hand, suppose rhat
Sales
a user warns co see June 2019 sales
T!ITl8Penod
results for che sales rep assigned
to jo-l\1ar lndusrne . The data 1s
stored 111 rwo different systems
wirh different darabases: the sales
information ~ystcm and the human
DATA WAREHOUSE
resources informarion ~ystem, as
!.hown in Figure 9-37. Without a
Human
data warehouse, it would be diffiResources
cult for a user to extract darn char
Information
Information
Results
System
spans several information systems
System
Sates ref)<esenta1ive 121
and time frames. Rather than
sold $375.784 10 Jo·Mar
Input data
Input data
accessing separate system~, a data
lndustnea during Juno 2019
warehouse stores transaction data
in a format that allows users to
FIG URE 9-3 7 A data warehouse stores dat3 frolTl several systems. By selecting data
retrieve and analyze the data easily.
dimensions. a user can retrieve specific Information without having to know how or
where the data is stored.
While a data warehouse typically spans the entire enterprise,
many firms prefer to use a data mart, which is designed to serve the needs of a specific department, such as sales, marketing, or finance. Each data mart includes only
the data that users in that depanmcnc require co perform their jobs. There arc pros
and cons to both approaches, and the best solution usually depends on the s pecific
situation.
DATA WAREHOUSING:
\
1
I
r
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
1
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 9
Data Design
9.8 Data Storage and Access
302
Regard less of rhe overall approach, storing large quanriries of dara is like building
a house-ir doesn'r jusr happen. A well-constructed dara warehouse needs an archirecrure rhar includes derailed planning and specifications.
DATA MINING: Da ta mining software looks for meaningful data patterns and rela-
tionships. For example, dara mining sofrware could help a consumer products firm
identify porenrial customers based on their prior purchases. lnformalion about customer behavior is valuable, but data mining also raises serious ethical and privacy
issues, such as the example in the Question of Ethics feature in rhis chapter.
The enormous growrh in e-commerce has focused attention on dara mining as a
marketing tool. In an article called "Data Mining on the Web" that appeared in the
January 2000 issue of New Architect, a web-based magazine, Dan R. Greening noted
thar web hosrs rypically possess a lot of information about visito rs, bur most of it is
of lirrle value. His article mentions tbar smart marketers and business analysts are
using data mining techniq ues, which he describes as "machine learning algorirhms
thar find buried parrerns in databases, and report or act on those findings." He concludes by saying tha r "the great advan tage of web marketing is thar you can measure
visiror interactions more effectively rhan in brick-and-morrar srores or direct mail.
Dara mining works best when you have clear, meas urab le goals." Some of rhc goals he
suggesrs are :is follows:
•
Increase the number of pages viewed per session.
•
•
Increase the number of referred customers.
Reduce clicks to d ose, which means average page views to accomplish a pur-
chase or obtain desired information.
•
Increase checkouts per visit.
•
Increase average profit per cbeckour.
This t)'pe of darn garhering is sometimes called clickstteam storage. Armed with
this inform:ition, a skillful web designer could build a profile of typical new cusromers,
returning customers, :ind customers who browse but do not buy. Although this inform:irion would be very valua ble to rhe retailer, clicksrream storage could raise serious legal
:ind privacy issues if an unscrupulous firm sought to link :i customer's web behavior to
:i specific n:ime or email address and then sell or otherwise misuse the informarion.
Because ir can derect parrerns and trends in large amounts of data, dara mining is
a valu:ible rool for m:inagers. There is a well-known story about a chain of superm:irkers that performed a derailed affiniry analysis of purchases and found chat beer and
diapers were often purchased rogetber. Ir is unclear whether or not this story is true,
but without actempting to explain this correlation, the obvious tactic for a retailer
would be to display these irems in the same area of the store. This data mining technique relies on associariou r u.le learning and is often called mar ket basker a nalysis.
9.8.2 Logical Versus Physical Storage
It is important to uuderstand the difference between logical stornge and physical
storage. Logical sto rage refers to data that a user can view, undersrand, and access,
regardless of how or where that information actually is organized or stored. Tn contrast, phy~ical storage is strictly hardware related because it involves the process of
reading and writing binary data ro physical media such as a hard drive, CD/DVD, or
network-based sroragc device. For example, portions of a documenr migh t be stored
in differcnr physical locations on a hard drive, but the user secs the document as a
single logical entiry on the compurer screen.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase 3
Systems Design
303
9.8 Data Storage and Access
Logical storage consists of alphaberic and numeric characters, such as rhe letter A
or the number 9. As de cribed earlier in rhis chapter, a sec of related characters forms
a field, which dc~cribes a single characteristic, or anribure, of a person, a place, a
thing, or an event. A field also is called a data element or a data item.
When designing fields, space should be provided for che largesr values char can be
ancicipared, wichour allocaring unnecessarily large storage capacities char will nor be
used. For example, suppose a cuscomer order enrry sysrem is being designed for a firm
with 800 cusromers. Ir would be a mistake co lim ic the customer numher field to chrce
or even four characters. Instead, a five-character field wirh leading zeros thar could
store cusromer numbers from 00001 ro 99999 should be considered.
A mix of alphabetic and numeric characters can also be considered, which many
people find easier co view and use. Alphabetic characcers expand the storage capacity
because there arc 26 possible values for each character position. Mose airlines now
use six alphabetic characters as a record locator, which has over 300 million possible
value!>.
A logicaJ record is a set of field values that describes a single person, place, thing,
or event. For example, a logical customer record contains specific field values for a
single customer, including the customer ntunber, name, address, telephone number,
credit limit, and so on. Application programs see a logical record as a group of related
fields, regardless of how or where t he data is stored physically.
The term record usually refers ro a logical record. Whenever an application progran1 issues a read or write command, the operating system supplies one logical
record to the program or acceprs one logical record from the program. The physical
data might be stored on one or more servers, in the same building or thousands of
miles away, bur all rhc applicarion program sees is rhe logical rccord-rhe physical
srorage locacion is irrelevant.
9.8.3 Data Coding
Computers represent data as bits (shorr for binary digits) that have only two possible
values: I and 0. A computer understands a group of bits as a digital code that can
be transmitted, received, and stored. Computers use various data coding and storage
schemes, such as EBCDIC, ASCII, and binary. A more recent coding standard called
Unicode also i!> popular. Also, the storage of dates raises some design issues that mu~t
be considered.
EBCDIC, ASCII, AND BINARY: EBCDIC (pronounced EB-see-dik), which stands
for Extended Binary Coded Decimal Interchange Code, is a coding method used on
mainframe compurers and high-capacity servers. ASCII (pronounced ASK-cc), which
stands for American Standard Code for In£ormatJion Interchange, is a coding method
used on mosr personal computers. EBCDIC and ASCII both require eight bits, or one
byre, for each characrer. For example, the name Ann requires 3 bytes of srorage, chc
number 12.345 requires 5 bytes of storage, and the number 1,234,567,890 requires
10 byres of storage.
Compared with character-based formats, a binary storage format offers a more
efficient storage method because it represents numbers as actual binary values, rather
than as coded numeric digits. For example, an integer format uses only 16 bits, or
nvo byres, to represent the number 12,345 in binary form. A long integer format uses
32 bits, or four bytes, co represenr the number 1,234,567,890 in binary form.
UNICODE: Unicode is a more recent coding srandard rhar uses two byres per
character, rather than one. This expanded scheme enables Unicode co represent more
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 9
Data Design
9.8 Data Storage and Access
304
than 65,000 unique, mu ltilingual characters. Why is this important? Consider rhe
challenge of running a multinational information system or developing a program
that will be sold in Asia, Europe, and North America. Because it supports \irtually all
languages, Unicode has become a global standard.
Traditionally, domestic software firms developed a product in English and rhen
tran lated t he program inro one or more languages. This process was e\.pcnsive,
slow, and error-prone. In contrast, Unicode creates translatable content right from
the srart. Today, most popular operating systems support Unicode, and the Unicode
Consornum maintains standa rds and support, as shown in Figure 9-38.
~ The Unicode Consortium
c.-. .,, , .,. _ , s-
---- .
... _
.
-.
_
..
-.
,.Q
n.c
n.-- ...
OuktlUr>b
C:-0-
•
•••
n.u............
..
.............. (C\.OllQ
"1t• I w.-O.
..
......... o...
UTC_,.._
•
a.Oii
QJTC
•
7
CW-11-
..
UTC~ ........
•
........
• -- ~~.Jd!Llf!JA&Ht0soctrQl.llll t''
't W l:lV'IVGil
-·~
wr--110 . . pp1t• l'll.._~
l!lll.Lll!lllllll.Jj--.il!C-
,_., ...,
FIGURE 9-38 Unicode Is an international coding format that represents charaeters as Integers, using 16 bits (two bytes)
per character. The Unicode Consortium maintains standards and support for Unicode.
SouK.t ""'
,,,... "'
STORING DATES: What is the best wa)' to store dares? ·me answer depends on how
the dates will be displayed and wbether rhey will be used in calculations.
At the beginning of the twenty-first century, man)' firms that used only two digits
to represent t he yea r were faced wirh a major problem called the Y2K issue. Based
on rhar experience, most date formats now are based on the model established b)' the
International Organization for Standardization (ISO), which requires a format of four
digits for rhe year, rwo for the month, and two for the day (YYYYMMDD). A dare
stored in rha r format can be soned easily and used in comparisons. If a dare in lSO
form is larger rhan another date in the san1e form, then the first date is later. For example, 20150504 (May 4, 20 15) is later than 2013092 7 (September 27, 20 L3 ).
But wbat if dates must be used in calculations? For
example, if a manufacturing order placed on June 23 takes
three weeks co complete, when will the order be ready? If a
• .!. •
•
1 M
payment due o n August 13 is nor paid until April 27 of the
DI
, following year, exactl y how late is the payment a nd how
c
0
t
•
•
much inteTesr is owed? In these s ituatio ns, it is easier rouse
2'
1
absolu te daces.
•s
An absolute date is the total number of da ys from some
specific
base date. To calculate the number of days berween
'I,
rwo absolute daces, one dare is suhtracccd from rhc other.
t(21fU
•
For example, if the base date is January I, 1900, then May
10
UIS
4, 2015, bas an absolute date of 42 128. Similar!)', Seprember
,,11
27, 20 13, has an absolute date value of 41 544. If rhe earlier
FIGURE 9.39 Microsoft Excel uses absolute dates In
dace value is subtracted from the later one, che re ult is 584
calculations. In this example. May 4, 2019, ls displayed as
days. A spreadsheet can be used ro determine and displa)
43589.and September 27. 2015.ls displayed as 42274.
The difference between the dates Is 13 I5 days.
a bsolute daces easily, as shown in hgure 9-39.
- ..
-·
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,...... .,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
__.~~ c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
305
9.9 Data Control
9.9 DATA CONTROL
]use as it is important co secure the physical part of the syscem, as shown in
Figure 9-40, file and database control must include all measures necessary to ensure
that data storage is correct, complete, and secure. File and database control is also
related to input and ourpur techniques discussed earlier.
FIGURE 9_.0 In addition to network monitoring, system securicy includes access codes, data
encryption, pa,sswords. and audit crails.
A well-de 1gned DBM must provide built-in control and secunty features, including subschemas, passwords, encryption, audit rrajl files, and backup and recovery
procedures to maintain data. The analyst's main responsibility is to ensure that the
DBMS features are used properly.
Earlier in this chapcer, it was explained that a subschema can be u ed ro provide a
limited view of the database to a specific user or level of users. Limiting accei.s to files
and database& is the most common way of procecting stored data. Users must furnish
a proper ui.er ID and password co access a file or database. Different privileges, also
called permi~si on~, can he associated wid1 differenc users, so some employees can be
limited ro read-only access, while ocher users might be allowed ro update or delere
data. For highly sensitive data, additional access codes can be established thar restrict
i.pecific records or fields within records. Stored data also can be encrypted to pre·
vent unauthorized access. Encr yption is the process of converting readable data into
unreadable charnccers to prevent unauthorized access to the data.
All system fi les and databases must be backed up regularly and a series of
backup copies must be retained for a specified period of time. In the event of a file
catastrophe, recovery procedures can be used to restore the file or database to its
current state at the time of the last backup. Audfr log fil es, which record details
of all accesses and changes to the file or database, can be used to recover changes
made since the last backup. Audit fields, which are special fields within data
records to provide additional control or security information, can also be included.
Typical audit fields include the date the record \Vas created or modified, the name
of the user who performed the action, and the number of times the record has been
accessed.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter 9
Data Design
9.10 Summary
306
Tip Top Toys is a relatively small division ofWorldwide Enterprises. Worldwide has nine
other divisio ns, which include insurance, health-care products. and financial planning
services, to name a few.
The cor porate marketing director for Worldwide has requested Tip Top's customer
shopping data to target people who might be likely to purchase items o r ser vices from
other Worldwide divisions. The database manager is not totally comfortable wich chis and
pointed out Tip Top's web privacy policy, which states "Tip Top Toys. a division of Worldwide Enterprises, will not share personal data with other companies without a customer's
consent."
The marketing director replied that the statement only applies to outside companiesnoc other Worldwide divisions. He said he checked with the corporate legal department.
and they agreed. The database manager replied, "Even if it is legally OK, it's not the right
thing co do. Many people take our statement co mean that their data does not leave Tip
Top. At the very least, we should give customers a choice, and share the data only with
their consent."
Do you agree with the marketing director? Why or why not?
9. I 0 SUMMARY
This chaprer conrinued the scudy of the systen1s design phase of rhe SDLC. Ir was
explained rhar files and tables contain data abour people, places, things, or evenrs that
affect the information system. File-oriented systems, also called file processing systems, manage data stored in separate.
A database consisrs of linked tables that form an overall data St ructure. A DB~1S
is a collection of tools, features, and inrerfaces that enable users to add, update, manage, access, and analrze dara in a dat abase.
DBMS designs are more powerful and flexible than crad1tional file-oriented srstems. A database environment offers scalabiliry, support for organization-wide access,
economy of scale, data sharing among user groups, balancing of conflicring user
requirements, enforcement of standards, controlled redundancy, effective security,
flexibility, better programmer productivity, and data independence. Large-scale databases are complex and require extensive security and backup/recovery features.
DBMS components include interfaces for users, DBAs, and related systems; a
DM L; a schema; and a physical data repository. Other data management techniques
include data warehousing, which stores data in an easily accessible form for user
access, and da ta mini ng, which looks for meaningful patterns and relationships
among d:ira. Dara mining also includes clickstrearn storage, which records how users
interact with :i site, :ind marker baskec analysis, which c:in iJentify pro<luct relacionships :ind consumer buying patterns.
In a web-based design, the Internet serves as the front end, or interface, for che
DBMS. Access to the database requires only a web browser client and an Internee
conne<..-cion. Middleware can interpret client requests in HTML form :ind cranslate
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
Phase l
Systems Design
307
9.10 Summary
the requesrs into commands rhar rhe database can execute. \'Veb-based dara must he
secure, yet easily accessible ro authorized users. To achieve this goal, well-designed
systems provide security ar rhree levels: rhe database itself, the web server, and the
telecommunication links that connect rhe componencs of the system
In an information system, an entity is a person, a place, a thing, or an event for
which dara is collected and maintained. A field, or attribute, is a single characteristic
of an entity. A record, or tuple, is a set of related fields that describes one msrance of
an entity. Dara 1s 5torcd in files (in a file-oriented system) and cables (in a database
environment).
A primary key is the field or field combination that uniquely and mimmally identifies a specific record; a candidare kc)' is any field rhat could serve as a primary key. A
foreign key is a field or field combination that muse match rhe primary key of another
file or table. A secondary key is a field or field combination used as the basis for sorting or retrieving records.
An ERD is a graphic representation of all system entities and the relationships
among them. The ERD is based o n entities and data stores in DFDs prepared during
rhe systems analysis phase. The three basic relationships represented in an ERD are
one-to-one ( l: 1 ), one-co-many ( J :M), and many-to-many (M:N). In a M:N relationship, the two entities arc linked by an associative entity.
The relationship between cwo entities also is referred to as cardinality. A common
form of cardinality notation is called crow's foot norarion, which uses various symbols co describe rhe characteristics of the relationship.
Normalization is a process for avoiding problems in data design. A I NF record
has no repeating groups. A record is in 2NF if it is in I NF and all nonkcy fields
depend on chc cncirc primary key. A record is in 3NF if it is in 2NF and if no field
depends on a non key field.
Dara design tasks include creating an initial ERD; assigning data elements ro an
entity; normalizing all table designs; and completing the data dictionary entries for
files, records, and data clements.
A code is a set of letters or numbers used to represenr data 111 a system. Using
codes can speed up data entry, reduce data storage space, and reduce transmission
time. Codes also can be used to reveal or to conceal informacion. The main types
of codes are ~equence codes, block sequence codes, classification codes, alphaberic
codes (e.g., caregory codes, abbreviation codes, and mnemonic codes), sig111ficanr digit
code5, dcnvarion code~, cipher codes, and action codes.
Logical storage is information seen through a user's eyes, regardless of how or
where rhat information actually is organized or stored. Physical srorage 1s hardware
related and involves reading and writing binary data to physical media. A logical
record is a related set of field values that describes a single person, place, thing, or
event. Dara storage formats include EBCDIC, ASCH, binary, and Unicode. Dares can
be siored in several formats, including ISO and absolute forma t.
File and database control measures include limiting access to the data, data
encryption, backup/recovery procedures, audit trail files, and internal audit fields.
.........""_.. ....-.................
_..__ ...................
("..,_..., llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ·· · ---~~-.,.- " ~
Chapter 9
Data Design
Key Terms
308
Key Terms
I: I .\ type of en!lt) rcl:111onsh1p. A one-ro-one relarionship, abbreviated I: I, e'1srs when exactl) one of
the ~ond enm) occurs for e-.ich instance of the first eouty.
I :M A rype ol cnnn rc'3rion)h1p. A one-to-man>• refanomhip, abbre,·iatctl I :M, cx1>t> when one <><:cur·
rcm.e of the finr cnt1ry .:an be related ro many 0<:currcncc\ of the '-"LOntl cnnty, hut each ou:urrcncc
of the -.ccontl enriry can be associated with only one occurrence of the fil'or cnnl)'.
ahhrc~iat;on cock Alphal>etic ahhreviarion. For example, ~randartl \t,lle codt..., include '"Y for '-:ew
York, ME for ~faine, 3nd MN for Minnesot:L
abwlute date lbe total number oi days from some specific bnse date. fo calcufotc the number of da)'S
between two .1bsolute dat.-s, subtract one date from the other. For example, usmg a bJse date of Janu·
Jr) 1, 1900, September 27, 2012, has an absolute date "alue of 4117!1 Jnd Jul) JJ, 2011, has an absolute dare of 40737. If rhc earlier dar<' value is subrracted from the IJtcr one, the result is 442 d,1rs.
acuon code Indicates whJt ,1crion is robe taken with an associJted Item. For exJmple, a student records
progrnm might prompt a user ro enter or click an action code such as D (to d1spla> the student's
record}, A (ro add a record), and X (co exit the program).
alphabetic rntlc Use' alphab"c leacr~ to tlisringuish one item from another ha\Cd on a catci:ory, an
Jbhrcvint1011, C>r an ea,y·tC>-remcmber value, ca lled a mnemonic code.
A~Cll
ScanJ, for American Standa rd C.<Jde for Information lntcrchani:c, a lLita 'mrasc coding method
u'ed on mo~t pcrmna I computers and workstation<.
a~~ociath·e cnriry An enriry thar hns its own set of .irrributes .rnd ch,uacrcnstics. AssoctJt1\·e enrirics are
used to link between many-to-many (M:N) relationships.
attribute A srngle chJractenstic or fact abottt an entiry. An arrnbute. or field. 1s the smallest piece of dJta
th.u h.is meanmg within ao information system. For example • .t 5oc1JJ ~urtC) number or company
n.1me could l>e examples of an armbure. Ln ob1ect-oneored .m.ilys1s, an atmbute as pan of J class d1a·
gram th.it describes the characrenstics of objects in the class. Also kno\\n as J data elemeot.
3.udu field\ <;pccial fields ,~;rhin data records ro provide additional control or '>«Uri!)' informarion.
T)•pical audu fields include rhe dare the record was created or modified, the name of the user who
performed rhe action, and the number oi rimes che record hJ'> been an:.,.,.,.,J.
:audit IO)I file\ Roxord detail~ of all accesses and change> co a file or tl.naha\C and can he u'>Ctl to nx:o•cr
changes made since the last backup.
bad.up fhe process of saving a series of file or data copies to be retJtned for a specified period of mne.
Data can he hacked up conunuously, or ar prescribed intervals.
binary qora~e format A formar that offers efficient storage of numeric data . For t.'xample, when numeric
data t) pes are specified using Microsoft Access, there are a variety of sroragc formats choices, includ·
mg mteger and long mteger, among others.
bit The 'niallc.i unit of darn is one bin:try digit.
block ;cqucncc code Cipher that u;e; blocks of numberb for different cla;~ification'>.
by1e A group of e1ghr bus is called a byre, or a character. A ser of byres forms .1 field, which is an ind1v1tl·
u.11 f.1ct about a person, a pl.ace, a thi11g, or an event.
candidate key ~omctim~ iris po<sible ro have a choice of field~ or field comhinauon~ to use as the pri·
mary key. Anr field thac could serve as a primary key is called a candid.ire kc).
cardinaliC) i\ concept rhar de<cribes how instances of one cnnl)· relate to instance< of another cnriry.
Described in FRDs br norarion rhar indicates combinarions rhat include 1cro or one·rn·many, one-co·
one, anti many-to-man}.
c.ud1naht) notation Code rhat shows relationships between emmes.
o;'jtci;ory cod.~ Cipher;. that identify a group of related 1tem>. !'or e.,a.mplc, j lo..al tlepJrtmcnr >tore ma>
use a l'•o·charactcr category code ro identify the deparrmenr 1n whKh a produll "sold.
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
...............
_ .... ~---11rt~
-,..~---~~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Phase l
Systems Design
309
Key Terms
char.1c1cr A i:roup of c111h1 hot> i~ .:ailed a characrer, or a brre. A ..et of brr~ fonm a field, which i, an
1nd1V1dual f.11.t ahouc a pcr\on, a place, a rhing, or an cvenr.
cipher cod<:'> Use of a kcrword 10 encode a number. A reratl srore, for example, may use a I 0-lctter
word, \uch as Cl\Ml'GROU:-<D, ro code wholes.ile prices, where chc lcncr C reprcscnr~ I, A rep·
rescncs 2, and so on. Thus, the code, GRA:>.D, would indicate char the store paid $562.90 for che
uecn.
clich 10 close fhe average number of page views 10 accomplish a purchase or obtam des1ted
mformJt1on.
did..,trcam \10ra11c R<-<;ordini; wch Vl\itor hchav10r and traffic trend, for later dara m1n1ni:. U\c.
cudc A -.er of lcrter\ or numhef\ chat represents a data item. Codes can be used to ,;mplify output, input,
and darn formats.
combination key A type of dara validation check d1at is performed on rwo or more fields 10 ensure that
they arc consistenr or reasonable when considered rogecher. Even diough all the fields involved in J
combutauon check might pass th~ir ind iHdual validation checks, the combi11,11io11 of the field v.1lue>
nught be inconsasccnr or unreasonable.
common field An attnburc rhar appears in more rhan one euriry. Common fields can be used ro link
entities in vacious types of relarionships.
compmire key Somcrime< it i< nccc<<ary for a primary ker m comi\I of a combination of field,. In that
case, the primary key i< called a comhinarion key, composite key, concatenated key, or multivalued key.
conca1e11atcd key Sec ;:on•P<hllc kc) .
cro" ·, £001 oot.iuon A type of cardinaLit) notation. Ir is called crow·s foot 1101atio11 because o( rhe shapes,
wruch uiclude c1tdes, bars, and S)'mbols. that mdtcate vanous poss1btlmes. A sangle bar uid1c.11es one, a
double b.lr and1c.11es one and onl) one, a cU'cle mdicares zero. and a crow's foot mdicates m.iny.
data clement A single char.1ctcrm1c or fact about an enriry. Adara element, field, or .mnbute cs the
smallest pac~ce of data that bas meanmg within an information system. for ex.implc, a Social Sccurit)
number or comp.in) name could be ei..amples of a data l'lemenr. The rean d.J/J item is also used.
data 11cm Sec Jara clement.
data manipulation h1n11uai.:c (0\.fl) A DML controls database operations. including ~torini:. rctncving,
up<latini;, and dclc11n11 data. Mo<e commercial DBMSs, such as Oracle and IBM\ DBl, use J DMI..
data lllMI A spe<1ahled d.u.1base designed 10 serve the needs of a spectfic department, such JS sales,
m.irkeung, or finance. Each data marr includes only rhe dara rhat users m rhac dep.irtment require to
perform their 1obs.
daca mining Lookmg for meaningful patterns and relationships among dt\ca. For example, data mm
ing software could help a consumer products firm identify potential cw.tomers based on their prior
purchases.
data 'tructurc A mcaninf;fu l combination of related daca clements that is indudcd in a data flow or
retained in a d<1ra >tore. A framcwork for organizi ng and storing data.
data woirchnu~c An inrcgrarcd collccrion of darn that can Sltpporr managemcnr analysi~ and dcci~ion
making.
dntaba~c odmoniHr.itM (OBA! Someone who manages a DBMS. The DBA assesses overall requirement~
and ma1or.11ns the darabai.c for the benefit of the entire organuacion rather than a smgle deparrmenr
or user.
Jatab.i>e mJna11cmcn1 >) ;ccm (OBMS i A rnllecnon of cools, features, .ind interface> that enable> u>er> co
add, update, manage, acce~~. and analpe dara in a darabase.
dcnv01tion code Comhonmg dara from different item attributes, or charactcrisnc~, ro build rhc code.
Mo\t magazine sulxcnpnon codes are dcrivarron codes.
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
...............
_ .... ~---11rt~
-,..~---~ ~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Chapter 9
Data Design
Key Terms
3 10
f BCOIC Stands for E..'l.tended Bina!") Coded Decimal lntercbaoge Code, a cod mg method used on mamframe .:ompmers and M>me high-capacity secvers.
cwnonl\ of ,~.de The inhcrenr cfficienc)' of high-volume proces>ing on larger <omputer>. Databa>e
de"gn allmY'> better uulizanon of hardware. If a company maintain\ an enrerpri,e-w1dc databa...,, procc<>\lng i~ le<>\ ex~n'i"e using a po\vcrful mainframe server instead of u~ing <.C\'eral \mailer compmers.
cncrn>tinn A proce-;~ where data i~ coded (convened into unreadable char.1cter•) '>O rhar only tho~ wirh
the required nurhori1ation can access rhe data (usuallr via de<oding ,oftware)
entity A person, a place, a thing, or an e'·enr for which dara is coUcacd and mamtJ1ned. ~or example, an
onlme sales S)Stem may inc.:lude entities named CUSTOM..l:.R, ORDJ:.R. l'RODUCf, and SUPl'UER.
cnllt)·-rclauon>lup diagram (ERO) A grapluca1 model of the mformation system that depicts the relanonslups among system enri11es.
fidd A 'inglc ~harnctcrl<,tic or fact about an cntiry. A field, or attribute, i' the 'mallc~t piece of data that
ha' meaning with in an infnnnation ')'stem. For example, a Social Sccurit)' numhcr or company name
cou ld he examples of a field. The terms data element, data item, and field are u'cd intcrchani;cably.
file Each file or rahlc comnins dam a hour people, p laces, things, or evenLs that intera..-1 w ith the informa-
tion 'Yl>lcm.
iile-oricnicd sy~tcm A ftle-onented system, also called a file processlllg system, stores .ind manages d.ita
Ill one or more separare files.
first normal form ( LNI') A record is said to be in lNF 1£ 1t does not contain a repe.mng group (,1 set of
data items that can occur any number of times in a single record).
forci~n key A field in one table that must match a primary key \"aluc: in another table in order ro esrab-
ll\h rhc rcl;uion'>hip between the two tables.
fun•'tionall) dcp<ndent Funnional dependence is an imponant concept for under\tanding the 2l-.'F. The
field X "'aid to be fun,·wm.11ly dependent on rhe fidd Y 1f the \·aluc of X depend, on the \·alue of Y.
For example, an order date is dependent on an order number. for a pamwlar order numhcr, rherc 1s
only one \'alue for rhe order dare. Jn conrra<r, rhe product de-;cription os not dependent on the order
number. For a panicular order number, there might be ~veral product dc><:ription\, one tor each item
ordered.
lntemauonal OrganiLation for 5tandardiLation (150) A networL. of nauon.il ~tand.irds 1m111u1es lrom
over a hundred counmes working in pannership wub 1mcrnanon.il orgaml.lnons, govcmmenrs,
industncs, and bus111css and consumer representanves. The ISO acts as a hndgc llCtween public and
private seetors.
ja\a databa\c conncctivit) UDBC) A >tandar d that enables Java application~ to cxch;mge data with any
darJbase th.It uses SQL statements and is ODBC-compliant.
key field\ Ui,ed during the ~)''terns design phase ro organi1e, accc>>, and mainrnon data \tructure,, The
four typt·~ of key fields arc primary keys, candidate key>, foreign keys, and ~crnndary key~.
lo11ica l record A lo11ical record concain< field values that describe a ~inglc pcr>on, place, thin11, or event.
Applicncion program< see a logica l record as a set of field<, rcgard lcs'> of how or where the data is
'torcd phy<1cally.
logical \tOraAc Refer& to informa tion as seen th rough a user's eyes, regardlcs~ of how or where that
information 1; organiLed or srored.
M:l\ A rype of encity relationship. A man}·to-m.1.n} relauouslup, abbrevi.ued M:N, exist> when one
instance of the firq enrity can be related ro many instance<> of the second enmy, and one 1n~t.incc of
the ~ond cnm) can he related 10 many instances of the first ent1t).
man}-to-man) rdatiomhip See \{:N.
markrt h.1d.:et analy<i< A rype of analysis rhat can derecr pattern~ and trend~ in large amounts of data.
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
...............
_ .... ~---11rt~
-,..~---~~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Phase l
Systems Design
311
Key Terms
m1ddlc\\arc 5oft\\arc that conne.:t~ d1\>1m1br apphcanons and enables them to communicate and
c'\,hange data. For c\amplc, m1ddlcwarc can lmk a dcpa rtmcntal databa..c to a \\ cb \cn·cr 1ha1 can
be accessed by client computers via rhe lnrcmcc or a company inrranet.
mnemonic code Cipher~ u~ing a ~p«1fic combanarion of lerrers that arc easr co rcmembcr. Man)'
thrce<haractcr J1rpon codes are mnemonic codes. For example, LAX represents Lo> Angeles.
mulcivalued kc~ Someumes Jt 1s necessary for a primary key co consist of a comb111Jrion of fields. In that
case, the prill1Jry key 1; ~ailed a combuiauon ke), composite key, concatenated key, or mulm alued key.
nookcy field Any field that i'> nor a primar) kc)' or a candidate key;,, called a nonkey field.
nor1nal1uuon A pr<"'"" hv which analy'll• 1dent1fy and corn-ct inherent problems and complc\illc' m
their record dc,ign,.
one·to-man) rclat1on~h1p See J :M.
one-to-one rclauon\hip Sel' I: I.
open databa>c connectivity (ODBC) An inclusrry-standard protocol that make' it po~'ihlc for ;oftwa1·c
from different vendors ro inrcrncr nnd exchange dnrn.
orphan An unassociared or unrelared record or field. An orphan could be created if J cusromer order
was emercd in an order table where rhar cuscomer did nor already exist in che cuscomer tJble. Refer·
cntial integrity would prevent rhc creation of thi~ orphan.
permissions Uscr-spcc1f1c pnv1ley.es th.Jr derermme the rype of access a user has to a dacabJsc, file, or
dtrectory. Also called user nghrs.
phrical 'tl'f1111t Information 'ttorai;c mcd1ani'rn that is <tri~Tly hardwari; related, ~"t;rnw it invuh·c-- the
process of rcadmg Jnd writing binaf) data to physical me<lia. such .is a h•ud dri\e, fl.ish drive. or DVD.
primal) t..,") \ field or comhm:mon of fields rhar uniquely and minimally identifie' a particular member
of an cnut). For example, 111 a c.:u,t0mer mhle the cu~tomer number is a umquc pnmal') kc) hct:au-.e
no mo c.:u>tomcr' .:an have the !hlmc ~-u>tomer number. That kc) aho i~ m1n11nal bccau-.e n contain.,
no mfnrmannn bcrond what " needed ro identify rhc cusromcr.
query b) c~ampk QRf 1 A language allow~ the user co pro,;dc an example of the data reque,ted.
quef) lanRuagc Allows a user ro ~rcc1f)· a task wirhour spccif)'ing how the task wtll be accomplished.
Some query languagrs use natural language commands that resemble ordinaf) English senrencrs
record A set of related fields that describes one instance, or member of an emit), ;uch as one customer,
one order, or one produu. A record m1gl11 have one or doreus of fields, depeudmg ou "hat mformauon 1s needed. Al~o called a ruple.
rcco,cry procedure Pmce" for resrorin11 data and rcsrarrin~ a ~ys1cm after an interruption. Recovery
procedure' can be UM"d m rc<rorc a file or database ro its current state at the time of rhc la~r backup.
referential integrity A rypc of validity check. Referential inregriry i< a sec of rule<> thar avoid< dara incon
'i~tcncy and quality problem\.
rela1iooal databa~c A darahnse in which rnhles are related by common fields, creating a unified d.1C,1
strucrnre th.11 provides improved data qua licy and access.
relational model A model u;ed in relational databases. The relattonal model was mtroduced du rang the
1970; and be'ame popular bec.1usc n was fleXtble and powerful.
rcpca111111 group A >CC of one or more field; char can occur any number of rime; in a single rc<:ord, wuh
each occurrence having d1ffcrenr values.
scalabtlit) A characrcri~ric implying rhc system can be expanded, modified, or dowmi1cd easily m meet
che raptdl> changing need~ of a business enterprise.
~cbema The complete definmon of a database, indudmg descriptions of all fields, records, and
relaoon;lups.
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
. ..............
_ .... ~---11rt~
-,..~---~ ~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Chapter 9
Data Design
Key Terms
312
~c~ond normal form (2'\1- A record design is in 2NF if ic is Ill l;\J and
uall fields thar arc not pan of
che pnmJI) Ley are depeudem on the enure primar) ke). lf .Ill) field in .1 l~ l rC\:orJ depend; on only
one of rhe fu~lds ma combmanon prunary key, then the record 1s not m 2::-;1. A I ::-;1 record wirh a
primary key rhac ts a single field is aucomaricallr m 2::>:F.
\ccondal') kC} .\ field or comhinarion of fields char can be u~ ro a•CC\S or rcrric,·e rcc:ord\. ~ondary
key \'.llue; are nm unique. For example, co acces; records for only tho..e lu,comcr\ m a '11<!dfic p<>'>-ral
rndc. rhc Jl(l\CJI •ode field could he used as a secondary ke).
\cquenlc wdc Number- ()r letter- assigned in a specific order. Sequcnlc: rndc\ lontain no add111onal
information other than an indicanon of order of entry inro a ;y\ttm.
s111nific;m1 d1111c code Cipher rhar d1srmguishes items by usmg a series of subgroups of dagm. U.S. l'osra l
Service ii p codes, for example, arc significant digir codes.
\Candard nocarion formm A rcprcscnrnrion cha r makes designing cables easier as ic clearly ~how~ a mblc's
s1ruc1ure, fields, and primary key.
Strucrna·cd Query Uinguagc (SQL) t\ query language char allows PC u~er' co communica te with 'crver.,
and mainframe computcn..
'ubi.d1cma t\ view nf rhc datab:isc used by one or mo re: syMem; or u;cr;. t\ .,ub.,lhcma defi ne., only
rho' c p<>rtiom of the database char a parncular ' YStcm o r u' cr need' or i' allowed m accc".
rablc Lach file or r-.ible contains darn abour people, places, thmgs, or events ch.11 uueracc wirh rhe uuormauon S)'~tem.
rablc de\ign Speofies the fields and identifies che primary key in a p.1rricular rable or file.
third normal form ( 3"11') A record design is in 3:-.'F if it i< in 2NF and if no mmkC)' field i< dcpcndcm on
anocher nonkey field. A nonkey field is a field that is nm a candidare ke) for the pram:iry key.
ruplc ,\ ruple (rhyme., with .:ouple), or record, is a >et of relace<l ltcld... chat de-..:nbc<. one in~t:1nce, or
mc:mhc:r of an c:ntatv, wch a; one: c~romcr, one order, or one: produ~'t. A cu pie nui:ht h;l\c: one or do7cn< of field<, depending on whac information is needed.
l.,nacode A relam·dy recem coding merhod thar represents duracrers JS mcegers. Unlike l:.BC.:DIC and
ASCII, which use e1gh1 btts for each characrer, Unicode requires 16 bars per characcer, which allows IC
to rcpr~nr more than 65,000 unique cbaracrers.
Uru6c<l \iodclmg Language (Ui\il) A widely used method of vi!.uafumg and documenung sofrware
sy.rems des111.n. U~lL uses ob1ecc--0nemed design conceprs, but 1t 1s tndepcndent of any specific
progra nurnng language and can be used to descrihe busmess processes .ind requaremcms genera II).
unnonnali1cd ;\ record rhar contains a repeating group. wh ich mean> rhac a "ngle record ha> mu lt iple
uccurrcnce< of a particular field, with each occurrence having diffcrcnr value<.
Y2K i\\UC 1\ problem faced by mnny fi rm< in rhe rear 2000 hecau'e their C()mpurcr '>Y'>tcam used only
f \\ O di1:1r' IO represent rhc yc:ar; most dares now use 11 four-digit format for rhc yea r (YYYYM MDD ).
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
...............
_ .... ~---11rt~
-,..~---~ ~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Phase 3
Systems Design
313
Exercises
Questions
I. \Xlhar is a dam srrucrurc?
1. Brief!)' describe the componenrs of a DB.\ILS.
3. Lisr the major characrerisrics of web-based design.
4. l:.xpl;un primary key, candidate key, secondary key, and foreign key.
5. What arc ERDs and how are they used?
6. How do you convert an unnormalized design to lNF? Lo your answer, refer ro specific pages and
figures in rh1s chapter.
7. How arc codes used in data design?
8. Whar is data warehousing and dara mining?
9. How would a specific date, such as March 15, 2019, be represented as an absolute date?
I 0. How arc permissions used ro control access ro data?
Discussion Topics
I. Jn the auto shop examples in Section 9.1.2, what arc some problems thar might arise in Mario's
system? \Xlhy won 'r Danica run into the same problems? Provide ~pecific C'Camples in your answer.
2. Many large organizations have had tbeir database system hacked and customer dara srolen. How
should rhe secunry for rhe database be differenr than security for the resr of rhe system? Does ir make
a difference for web-based dara designs? lf so, how?
3. Suggesr rhree rypical business siruacions where referenrial integnry avoids data problems.
4. \Xie use tors of codes m our personal and business live!>. How many can you name?
5. Are there erhical issues ro consider when planning a database? For example, should sensitive personal
dara (such as medical information) be stored in the same DBMS rhar manages employee salary and
benefirs data? \Vhy or why nor?
Projects
I. Consider an automobile dealership with chree locations. Dara fields exist for srock number, vehicle
identificarion number, make, model, year, color, and invoice cost. Identify rhe possible candidate keys,
the likely primary key, a probable foreign key, and porenrial secondary keys.
2. Vis1r the bookstore ar your school or in your area. Interview the manager or store employees ro learn
more about the business and the entiries rbar are involved m book~tore operations. Remember that
an cmiry is a person, a place, a thing, or an event that affects an information system. Draw an ERD,
including cardinality, which describes the bookstore's operarions.
3. Cludadwy Chairs sells a parented sear rhar spectarors can take ro youth soccer games. The scat folds
so it is small enough ro fir in rhc glove box of most vehicles. The company opcr:ites a facrory in Kansas and also contr:icts irs manufacturing projects ro small firms in Canada and Mexico.
An unusual problem has occurred for this small multinationa l company: People are gemng confused about dares in internal memos, purchase orders, and email. When the company's database was
originally designed, the designer was nor aware that the format for dares in Canada and Mex~ico
was different from the format used in the Unired Stares. For example, in Canada and Nlexico, the
notation 7/ 1/19 indicates January 7, 2019, whereas in the Uni red Stares the same norarion indicates
July l, 2019. Although ir seems like a small point, the date confusion has resulted in several order
cancellations.
Cludadw) Chairs has asked for your advice. You could suggest writing a simple program ro convert
the dares automaticall)' or design a switchboard command thar would allow users ro select a date
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~... . ... .,...~ • ........._ . ....._.,.,.. o-... ..,._.,,.,.. _ ..,.~ ,........., ................. .._... .., .,. ..,.~"
................... ..., ...................... .... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
Chapter 9
314
Data Design
Exercises
formar as d:na is cnrcrcd. You reali1e, however, rhac Cludadwy Chairs mighr wanr ro do business in
orhcr councrics in rhe fururc. \Xlhar would be che besc course of accion? Should rhc compan)' adapr ro
rhc ~randard of each counrry, or should ic mainrain a single international formar? \Xlhar arc che argumenrs for each opnon?
4. Use ~11crosofc Access or sinular dacabase software co create a DBMS for the imaginar)' company
called TopTexc Publishing, which is dt'scribed in Cast' in Poinr 9.1. Add several sample records co each
rable and report 10 the class on your progress.
5. Search rhe internet to find information about date formats. Determine whether rhe date formar used
in chc Unired Stares is rhe most common formac.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
~ JIJ»C....... ~ Al RlilfD
~ ... _
l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.: ......,_ . . . ,_.,~-.lit .......... .._.,._.__..,~•\
. . . _ . .... ..., ~...,.._,_..,..., J\&."9 ... --.11 ......... ~ C'dptl"~~d.tt ...... -
............ -
..... -
..........
-.-.....w--...-.11
Chapter I 0
System Architecture
System
Architecture
Chapter I 0 is the final chapter in the systems design
phase of the SDLC. This chapter describes system
architecture. which translates the logical design of an
information system into a physical blueprint. Designing
the system architecture requires consideration of servers.
clients, processing methods, networks, and related issues.
The chapter includes three "Case in Point"
discussion questions to help contextualize the concepts
described in the text. The "Question of Ethics" explores
the trade-offs between the potential benefits of Installing
tracking software on users' computers to Improve the
system's response to common usage patterns versus the
ethical issues related to invasion of privacy by constant
monitoring of employees' online activity.
LEARNING OBJECTIVES
W/Jen you finis/, this chapter, yo11 should be able
to:
CONTENTS
I . Provide a checklist of issues ro consider when
selecting a system architecture
2. Trace the evolution of !>ysrem architecrure from
mainframes ro current designs
3. Explain client/server architecture
4. Describe Lhe impacl of the lnterner on syi.rem
archirecrure
5. Compare in-house e-commerce dcvclopmenr
with packaged solutions and service providers
6. Explain online and barch processing
7. Describe network models, including hierarchical,
bus, ring, star, and mesh topologies
8. Explain network devices, including routers, gateways, and proxy servers
9. Describe wireless networking, including wireless
standards, topologies, and trends
I 0. 1 Architecn1re Checklist
Case in Point I 0. J: ABC Systems
I 0.2 The Evolution of Sysrcm Archirccrurc
I 0.3 Client/Server Arcbirecturc
I 0.4 The Impact of the lnrcrnct
I O.S E-Commerce Architecture
Case in Poinr 10.2: Small Poraroc~
I 0.6 Processing l\1cthods
I 0. 7
crwork Models
I 0.8 Wireless Networks
Case in Point 10.3: Spider IT Services
I 0. 9 Sysrems Design Completion
A Question of Ethics
I 0. 10 Su mmary
Key Terms
Exercises
IO. Explain rhe final activities in rhe systems design
phase
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
Phase l
Systems Design
317
I 0.1 Architecture Checklist
I 0.1 ARCHITECTURE CHECKLIST
At this point in the SDLC, the objecrive is ro determine an overaU architecture to
implement the information system. System architecture translates the logical design
of an informarion system into a physical structure that includes hardware, sofrware,
network support, processing methods, and security. The end product of the systems
design phase is the system design specification. If this document is approved, the next
step i systems implementation.
Just as an architect begins a project wirh a lisr of the owner's requirements, a system analyst must consider several issues char will affect the architecture choice. This
is done with an overall architecture checklist:
•
Corporate organiz.arion and culrure
•
Enterpri c resource planning (ERP)
•
Initial and total cost of ownership (TCO)
•
•
Scalability
Web integration
•
Legacy system interface requirements
•
Processing options
•
Secu riry issues
•
Corporate portals
I 0.1.1 Corporate Organization and Culture
To be successful, an information S)'Stem must perform well in a company's
organization and culture. For example, consider cwo large bicycle brands, Green Bikes
and Blue Bikes. Each firm has three operating di,·isions: an Asian subsidiary that
manufactures the bicycles, a factory in Los Angeles that produces bike accessories and
clothing, and a plant in Canada that makes bike carriers, racks, and custom trailers.
On the surface, the t\\ o fi rms are similar, bur they have very different
organ11.ations and corporate culrures. Green Bikes is highly cenrrali1ed and oversees
day-co-day operations from its Los Angeles office. Blue Bikes also has a Los Angeles
executive office hut allows its three business unirs co operate separatel)•, with minimal
corporate oversight. Both firms are successful, and it is unlikely that their managerial
sryles will change anytime soon.
Suppose borh firms asked a consultant to suggest a n IT architecture that would
boost productivity and reduce costs. How might corporate organization and
culture issues affect the consultant's recommendation? l11ere is no easy a nswer ro
that question. The best approach probably would be to srudy day-to-day business
functions, talk ro users at a ll levels, and focus on operational feasibility issues, jusr as
was done earlier in the development process.
I 0. 1.2 Enterprise Resource Planning (ERP)
Many companies use e nterpri~e resource planning (ERP) software to establish a
company-wide strategy for using IT chat includes a specific architecture, standards
for data, processing, nerwork, and user interface design. A main advantage of ERP is
that it describes a specific hardware and software environment, also called a platform,
which ensures connectivity and easy inregrarion of furure systems, including in-house
sofrware and commercial packages.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I 0
System Architecture
I 0.1 Architecture Checklist
318
Many companies are extending internal ERP systems to their suppliers and customers, using a concept called supply chain management ( CM). For example, in a
totally integrated supply chain system, a customer order could cau~c a manufacturing
system to schedule a work o rder, which in n1m rriggers a call for more parts from one
or more suppliers. In a dynamic, highl)' competitive economy, CM can help companies achieve faster res ponse, bener customer service, and lower operating costs.
Oracle 1s an example of a company offering ERP solutions. A~ shown in Figure 10-1,
Oracle's ERP products are cloud-based services that support emplO)'ec collaboration,
provide access to information from mobile devices, and deliver data analytics capabilities co gain insight into business processes.
FIGURE I 0- 1 Oracle offcn ERP solunons as a cloud-based service.
Sour«:~O
•
I 0.1.3 Initial Cost and TCO
The importance of considering economic feasibility and TCO during systems planning and analysis was discussed earl ier. TCO includes tangible purchases, fees, a nd
contracts called hard costs. However, additional soft costs of mnnagement, supporr,
training, and downtime are just as important but more difficult to measure.
A TCO analysis should address tbe following questions:
•
If in-house development was selected as the best altcrnarive initially, is it still
rhe best choice? ls rhe necessary technical expertise avai lable, and docs the
o riginal cost estimate appear r ealistic?
•
If a specific package was chosen in itially, is it still the best choice? Arc newer
versions or competitive products available? H ave any changes occurred in pricing or support?
Have any new rypes of outsourcing become available?
I lave any economic, governmental, or regulatory events occurred that could
affect chc proposed project?
•
•
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
319
I 0.1 Architecture Checklist
•
•
•
Have any significanr rechnical developments occurred char could affect rhe proposed project?
I lave any major assumprions changed since the compan)' made the build versus
buy decision?
Are chere an)' merger or acquisirion issues ro consider, whereby rhe company
might require comparibiliry wirh a specific environment?
•
Have any new crends occurred in the markerplace? Are new products or technologies on rhe verge of being introduced?
•
Have rhe original TCO estimates been updaced? If so, are there any significanr
differences?
The answers ro rhese questions mighr affecr the initial cost and TCO for the proposed
system. The system requirements and alternarivcs should be reviewed now, before
proceeding ro design rhc sysrem architecture.
I 0. 1.4 Scalability
A nerwork is composed of individual nodes. A node represents a physical device,
wired or wireless, rhar can send, receive, or manage network data. For example,
nodes can be servers, compurers, shared printers, mass storage devices, wireless access
points, or tablets.
Scalability, somerimes also called exrensibiliry, refers co a system's ability co
expand, change, or downsize co meet the changing needs of a business enterprise.
Scalability is especially important in implementing systems char are volume relared,
such as rrans::iction processing S)'Stems. A scalable system il> necessary to suppon a
dynamic, growing business. For example, a scalable nerwork could handle anywhere
from a few dozen nodes co thousands of nodes, and a scalable DB!vlS could supporr
the ::icquisition of an enrire new sales division. When invesring large amounts of
money in a projecr, management is especially concerned about scalability issues rhar
could ::iffecr the system's life expectancy.
I 0.1.S W eb Integration
An mformation system includes applications, which are programs that handle rhe
input, manage the processing logic, and provide the required ourpur. The systems
analyst must know if a new application will be pan of an e-commerce strategy and
the degree of integration with ocher web-based components. As mentioned earlier, a
web-centric architecture follows internee design protocols and enables a company co
integrate the new application into its e-commerce strategy. Even where e-commerce is
not i1wolved, a web-centric application can run on the luterner or a company inrraner
or cxrrancr. A web-based application avoids many of the connectivity and compatibility problems rhar typically arise when different hardware envirornncnrs arc involved.
In a web-based environment, a firm's external business partners can use standard web
browsers to import and export data.
I 0.1.6 Legacy Systems
A new system might have co interface with one or more legacy systems, which arc
older systems that use ourdared rechnology bur still are functional. For example, a
new markering information system might need co report sales data co a server-b::iscd
accounring system and obtain product cosr data from a legacy manufacturing S)' rem.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~----···---~~-.,.-"~
Chapter I 0
System Architecture
I 0.1 Architecture Checklist
320
Interfacing a new system wirh a legacy system involves analysis of data formats
and compatibility. In some cases, a company will need co convert legacy fil e data,
which can be an expensive and rime-consuming process. ~1iddleware, which is
di cussed later in this c hapter, might be needed to pass dara between new systems
and legacy systems. Finally, to select the best architecture, rhe analyst mu~t know
if the new application eventually will replace the legacy system or will coexist
With it.
I 0. 1.7 Processing Options
In planning the architecture, designers also must consider how the S)'Stem will process
dara: on line or in batches. For example, a high-capacit)' transacrion processing system, such as an order entry system, requires more network, processing, and darn storage resources than a monthly billing system that handles data in batches. Also, if the
system must operate online, 24 hours a day and seven days a week (24/7), provision
must be made for backup and speedy recovery in tbe event of system failure.
The c haracteristics of on.line and batch processing methods are described later in
this chapter, with examples of each type.
I 0. 1.8 Security Issues
From the simple password prorecrion shown in Figure I 0-2 ro complex intrusion
detecrion systems, security th.rea rs and defenses are a major concern co a systems analyst. As the physical design is translated into specific hardware and software, the analyst must consider security issues and determine
how the company will address rhem. Security is
especially imporrant when dara or processing is
performed at remorc locarions, rather than at a
cenrralized facility. In mission-critical systems,
securiry issues will have a major impact on system architectu re and design.
Web-based systems introduce addmonal security
concerns, as critical data muse be protected in che
lnrerner environment. Also, firms that use e-commerce applications must assure custo mers rhar
their pen.onal dara is safe and secure. The lamentable number of high-profile securiry breaches in
large corporations in recent years suggest~ that
security issues should play an even larger role in
FIGURE I 0 -2 User IDs and passwords are tr:tditional elements of
system architecture considerations. System secusyscem security.
rity concepts a nd strategies are discussed in detail
in Chapter 12.
I 0. 1.9 Corporate Portals
Depending o n the system, the planned architecture might include a corporate
portal. A portal is an entrance co a multifunction website. After entering a portal, a
user can navigate to a desrinarion using various tools and features provided by the
portal designer. A corporate portal can provide access for customers, employees,
suppliers, and the public. A well-designed portal can integrate with various other
systems and provide a consistent look and feel across multiple organizational
divisions.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
I 0.2 The Evo lut ion of System Archite ctu r e
CASE IN POINT 10.1:
ABC SYSlRiS
You are a systems analyst at ABC Systems, a fast-growing IT consulting finn, that provides a wide
range of services to companies that wane co establish e-commerce operations. During the past
18 months, ABC acquired two smaller finns and sec up a new division that specializes 1n SCM.
AligningABC's intemal systems was quite a challenge, and top management was not especially
happy With the integration cost or the timetable. To avoid furure problems, you have decided
to suggest an ERP strategy, and you plan to present your views at the staff meeting tomorrow.
ABC's management team is very informal and prefers a loose, flexible style of management.
How will you persuade them that ERP is the Wirf to go?
I 0.2 THE EVOLUTION OF SYSTEM ARCHITECTURE
Every business informarion sysrem musr carry ou r three mai n functions:
•
Ma nage applications tha r perform che processing logic
•
Handle dara sroragc a nd access
•
Provide ~1n interface rhar allows users ro i1ueract with the system
Depending on the archi recrurc, rhc three functions are performed on a server, on a
clienr, or arc divided berwecn rhc server and che clienr. During system design, rhc analyst must dererminc where rhe functions will be carried our and ascertain the advanrages and disadvanrages of each design approach.
I 0.2. 1 Mainframe Archite cture
A sen er 1s a computer thac supplies dara, p rocessing services, or other support to
one or more compurers, called client>. The earliesr servers were mainframe computers, and a sy~rem design where che server performs all rhe p rocessing someume~ is
described as mainframe architecture. Alt hough che actual server does nor have robe a
mainframe, the term mainframe architecture typicalJy describes a multiuser environment where the ~erver is significanrly more powerful than the client). A sy~tem) :inalysr should know the history of mainfrrune architecrure ro understand the :.erver's role
in modern system design.
In the I 960:., mai nfra me architecture was che 011/y choice. In addition to centralized data processing, the earl iest systems performed all data input and outpur at a
centra l locat ion, often called a data processing center. Physical dara was delivered or
tra nsmitted in some manner ro the data processirng center, where it was enrered into
rhe sysrem. Users in the o rga nization had no input or o utput capa biliry, except for
pri nted reporrs rhat were d istri b uted by a corpora te IT depa rtment.
As nerwork technology adva nced, compa nies inst alled terminals a t remote locations, so t ha t use rs could c nrer a nd access da ta from a nyw he re in the organization,
regardless of where rhe ccnr ralized computer was locared. A terminal included a
keyboard and display screen co handle in put a nd o utput but lacked independenr processing capabi liry. In a cenrralized design, as shown in Figure 10-3, rhe remote user's
keystrokes arc cransmirred from his or her renninal to the mai nframe, which responds
by sending screen outpur back co che user's screen.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
321
Chapter I 0
System Architecture
I0.2 The Evolution of System Architecture
322
Today, mainframe architecntre still is used in indusrrie~
that require large amounts of processing that can be done
at a centra l location. For example, a bank might use mainframe servers to update customer balances each night. In a
blend of old and new technology, man y organi1arions arc
moving s ome of thei r dara processmg off their mainframes
and into the cloud. Indeed, a mainframe can be used ro
implement part of a cloud co mpunng infrastruccure.
Mainframe
I0.2.2 Impact of the Personal Computer
FIGURE I O·l In a centralized design. the remote user's
keystrokes are transmitted to the mainframe, which
responds by sending screen output back to the user's
screen.
Pnnter
When PC tecl1nology exploded in the 1990s, powerful
microcomputers quickly appeared on corporate desktops.
Users found that they could run their own word pro·
cessing, spreadsheet, and database applications, without
assistance from the IT group, in a mode caJJed stand-alone computing. Before long,
companies linked the stand-alone computers into networks that enabled the user cli ents to exchange data and perform local processing.
When an individual user works in stand-alone mode, the workstocion performs
a II the functions of a server by storing, accessing, and processing do ca, as well as
providing a user interface. Although stand-alone PCs improved employee productivity
and a llowed users to perform tasks that previously required IT department assistance,
~rand -a l one computing could be inefficient and expensive. Even worse, mainraining
data on individual workscarions ra ised major CODCerns about data security, inregrity,
and consistency. Without a central srorage location, it was impossible to protect and
back up valuable business data, a nd companies were exposed ro enormous risks. In
some cases, users who were frustrated by a lack
of support and services from the IT department
Scanner
created and managed their own d:nabases. In
addition co security concerns, rhis led ro data
inconsistency and unreliability.
I 0.2.3 Network Evolution
As technology become available, companies
resolved the problems of stand-alone computing
by joining clients into a local area ncl\\Ork
Client
(LAN) that allows haring of data and hardware
resources, as shown in figure 10-4. One or
more LANs, in turn, can connect to a centralized
server. further adv;:inces in technology made it
possible to creote powerful nerworks that could
use satelUte li11ks, high-speed fiber-optic lines, or
AllUllil
Client
the
Internet to share data.
Client
A wide area network (WAN) spans long
FIGURE I 0-4 A LAN allows sharing of data and hardware, such as
distances and can connect LANs rhat are conprinters and scanners.
tinents apart, as shown in Figure 10·5. \Xlhen
a user accesses data on a LAN or WAN, the network is transparent because users see
the data as if it were stored on t heir own workstation. Company-wide systems that
connect one or more LANs or WANs are called distributed systems. The capabilities
of a distributed system depend on the power and capacity of the underlying data
LAN
I
(....,..... J:gi( . . . . .
'Q
····-
I_,.. 41 11.,.. .................,.t11ru
- Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
- ·~•-fllllie<'f •,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
323
I 0.3 ClientlServer Architecture
communication network. Compared to mainframe architecture, distributed systems
increase concerns about data securiry and integriry because many individual clients
require access to perform processing.
'- ToronlO
I
I.AN
London
WAN
I
~:Jv
LAN
Brisbane
FIGURE I 0-5 A WA N can connect many LANs and link
users who are continents apart.
I 0.3 CLIENT/SERVER ARCHITECTURE
Today's interconnected world requires an information architecture that spans the
entire enterprise. Whether it's a departmental net'.vork or a multinational corporation,
a systems analyst works with a distributed computing strategy called client/server
architecture.
The term clienr/server generally refers to systems that divide processing between
one or more networked clients and a central server. In a typical client/sen·er system,
the client handles the entire user interface, including data entry, data query, and screen
presentation logic. The server stores the daca and provides data access and database
management functions. Application logic is divided in some manner between the
server and the clients.
In a client/server interaction, the client submits a request for information from
the server, which carries out the operation and responds ro the client. As shown in
Figure 10-6, the data file is not transferred from the server to the client--only the
request and lhe result arc transmitted across the network. To fulfill a request from a
client, the server might contact other servers fo r data or processing support, but that
process is transparent to the client.
cue111 submits data
query 10 ser.ier
Q
Client
Server 1tan&mits onto/ the
'9$uftS Of lhe client query
0
CINJnl
FIGURE I 0-6 In a client/server design.data is stored and usually processed on the 5enlel".
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "-> -
--
........... ......
"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ..... ...... ... ~..
__....
~~·~---- ···---~~ - .,.-" ~
Chapter I 0
System Architecture
324
I 0.3 Client/Server Architecture
Figure I 0-7 lists some major differences between clienc/server and traditional mainframe systems. M any early client/server systems did nor produce expected savings
because few clear standards existed, and development costs often were higher than
anticipated. Implementation was expensive because clients needed powerful hardware
and software to handle shared processing tasks. In addition, many companies had an
installed base of data, called legacy data, which was difficult to access and transport
to a client/server environment.
Comparison of Client/Server and Mainframe Systems
Characteristics
ClientlServer
Mainframe
Basic archHecture
Very ftex1b!e
Very rigid
Appl1cabon
dollelopmont
Flexible
Fast
Objecl -oriented
Highly structured
Slow
Traditional
User environment
PC-based
GUI
Empowers the user
Improves productivity
Uses terminals
Text interlace
Constrains the user
Limited options
Security and control
fealures
Decentralized
DifficuJt to control
Centralized
Easier to con1rol
Processing options
Can be shared and
configured In any form
desired
Extensive and
programmable
Data storage
options
Can be distributed to
AUdata 1s stored centrally
place data closer to users
1-tardWare/sottware
1ntegrabon
Very l1;ex1ble
MultJvendor model
Very 1191<1
Single proprietary 119ndor
FIGURE I 0-7 Comparison of the characteristics of d1entlserver and
rrn11nframe systems.
As large-scale networks grew more powerful, client/server systems became more
cost-effccrive. Many companies invested in clienr/server systems to achieve a unique
combinacion of computing power, flexibility, and support for changing business operacions.
Today, client/server architecture remains a popular form of systems design, using
Internet protocols and nerwork models such as the ones described later in this chapter.
As businesses form new alliances with customers and suppliers, the clienr/scrver concept
continues ro expand tO include clientS and servers outside the organization. Serviccoriented architecture (SOA) is an example of a networked system where a service can be a
client and a server simulta neously, and it can exist ourside of corporate boundaries.
Cloud computing is seen by some observers as an entirely new concept. Others sec
it as the u ltimate form of client/server architecture, where Internet-based computing
becomes the server part of client/server and hand les processing rasks, while che T1nernet itself becomes the platform that r eplaces traditional networks. The bottom line is
chat it doesn't marcer whether cloud computing is part of a client/server evolution or
a whole new way of thinking about computing. Eicher way, successfu l systems must
support business requirements, and system archirecnrre is an imporranr step in the
systems development process.
I 0.3.1 The Client's Role
The client/server relationship must specify how the processing will be divided between
the client a nd the server. A fat client, also called a chick client, design locates all or
(....,..... J:gi ( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,...... .,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
__.~~ c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~- " .....- ""'*" ....,.._...,.. ..
Phase l
Systems Design
325
I 0.3 ClientlServer Architecture
most of the application processing logic at the client. A chin client design locaccs all or
most of the processing logic at rhe sen •er.
In the late 1990s, un Microsystems (now part of Oracle) was a strong advocate
of thin-client computing, which was also referred to as net-centric computing. The
thin client was a Java-powered terminal, which communicated using standard
Internet protocol~ with powerful servers. Thin cliencs were expected co provide lower
T CO, since maintenance was centralized. However, many users rebelled at the hmtted
funcnonaliry provided by thin clients (e.g., no Microsoft Office) and the latency
problems mherenr in network access to remote applications and dara. In the end, far
clients (e.g., regular PCs) remained popular, even with all their management issues
and higher T CO.
Today's l:iptop computers, cablets, and smarrphones a re so powerful rhat the allure
of thin clients has mostly passed, with the exception of access to the cloud for large
datasets and specialized processing needs. The app ecosystem has also changed the
TCO equation in favor of powerful computing for clients at the edge of the system
architecture.
I 0.3.2 Client/Server Tiers
Early client/server designs were called two-tier designs. In a two-tier design, the user
interface resides on the client, all da ta resides on t he server., and tbe application logic
can run either on the server or on the client or be divided between the client and the
server.
Another form of client/server desit,'11, called a mree-rier design, has become more
popular. In a three-tier dcsi~ , the user interface runs on the client and the dara is
stored on the server, just as with a rwo-cier design. A three-tier design also has a
middle l:tyer between the client and server that processes the client requests and
translate!. them inm data access commands that can be understood and carried
our by rhe server, a'> shown in Figure 10-8 . The middle larer can be considered an
application \ en cr, because it provides rhe application logic, or bu ~inc~~ logic, required
by che system. Three-tier design~ also are called 1r-rier design~ . to indicate char some
designs use more than one intermediate layer.
Application logic
0818
Two-tier
Three-tier
Server
..,.. ____ _
-- --
_____ ,..
Application
serwr
-
User interface
-- --
Cllenl
Client
FIGURE I 0-8 C~racteristJcs of two-tier versus three-tier client/server de$ign.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I 0
System Architecture
I0.3 Client/Server Architecture
326
The advantage of the application logic layer is thac a three-tier design may enhance
overall performance by reducing rhe data server's workload. The separate application
logic la)'er also relieves clients of complex processing tasks. Because it can run on a
sen·cr that is much more powerful than the typical client work'itarions, the middle
layer i'> more efficient and cost-effective in large-scale sy~ems. Figure I 0-9 hows
where the data, the application logic, and the user interface a re located on various
architectures. In a diem/server system, the tiers communicate using software called
middleware, as described in the following section.
Data
Apphcat1on
Logic
User
Interlace
x
x
x
x
x
Client
x --
Sland·alone
client
Sel'ller
1
l\.vo·tier
cllenVserver
Sel'ller
Architecture
Cenlral data
processing center
Central server with
remote terminals
Server
Client
Server
x
x
Client
Client
Application server
,.Client
x
---,
x
•
I
I
x
Data server
Three-tier
cllenVserver
x
x
x
x
I
x
I
FIGURE I 0-9 The location ol the data. the application logic, and the user Interlace
depend on the type of architecwre .
I 0.3.3 Middleware
In a multitier system, special software called middlev.'aJ'C enables the tiers to communicace
and pass data back and forth. Middle·.vare is sometimes called glueware because it i'i
used co connecr two or more software components in a federated system archirccrure.
Middleware plays an important role in integrating legacy systems and web-based and/
or cloud-based applicarjons. !vtiddleware can also be seen a<: representing the slash in che
term clie11tlser11er.
I 0.3.4 C ost-Benefit Issues
To support business requirements, information systems need co he scalable, powerful,
and flexible. For most companies, client/server systems offer the best combination of
features co meet those needs. Whether a business is t:xpanding or downsizing, client/
server systems enable the firm to scale the system in a rapidl y changing environment.
As the size of t he business changes, it is easier to adjust the number of clients and
the processing functions they perform than it is to a lter the capability of a large-scale
cencra I server.
Client/server computing also allows companies to transfer applications from
expensive mainframes to less-expensive client platforms, sometimes moving heavyweight processing needs ro rhe cloud\. ln addition, using common languages such as
SQL, clients and servers can communicate across multiple platforms. Thar difference
is important because many businesses have substantial investments in a variety of
hardware and software environments.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
327
I 0.4 The Impact of the Internet
Finally, client/server systems can influence nerwork load and improve response
times. For example, consider a user at a company headquarrers who wants information about total sales figures. In a client/server system, che server locates the data, performs the necessary processing, and responds immediately co the client's request. The
data retrieval and proces~ing functions are transparent to the client because they are
done on the server, not the client.
I0.3.S Performance Issues
\Xlhile it provides many ad\'ancages, client/server architecture does involve performance is~ues that relate co che separation of server-based daca and networked clients
chat must access che data.
Consider che difference between clienc/server design and a centralized environment,
where a server-based program issues a command that is executed by the server's own
CPU. Processing speed is enhanced because program instructions and data boch travel
on an internal syscem bus, which moves data more efficiently than an external network.
In contrast co the centralized system, a clienc/server design separates applications
and data. Nerworked clients submit data requests ro the server, which responds by
sending data back to che clients. When the number of clients and che demand for
services increases beyond a certain level, network capacity becomes a constraint and
syscem performance declines dramatically.
According co IBM, the performance characteristics of a clienc/server system arc
nor the same as a centralized processing environment. Clienc/server response times
increase gradually as more requests are made, but then rise dramatically when rhe
sysrem nears its capacity. This point is called the knee of the curve, because it marks a
sharp decline in che system's speed and efficiency. To deliver and maintain acceptable
performance, system developers must anricipace the number of users, network rraffic,
:.erver size and locarion, and design a clienc/server architecture that can support current and furure business needs.
To enhance performance, client/server systems musr be designed so the client contacts the server only when necessary and makes as few rrips as pos~ible. This is one of
the goab of the HITP/2 prorocol used berween a server and a web brow~er.
Another issue that affecrs client/server performance is data storage. Jusc as processing can be done at various places, data can be stored in more than one location using
a di~tributed databa\e management ~y~tem (DDBMS). Using a DDBMS offers several
advantages: Dara stored closer ro users can reduce network traffic; the sysrem is scalable, so new data sires can be added without reworking the system design; and with
data scored in various locations, the system is less likely to experience a cacasrrophic
failure. A potential disadvantage of distributed data storage involves data security: It
can be more difficult to maintain controls and standards when data is stored in various locations. In addition, the architecture of a DDBMS is more complex a nd difficult
to manage. From a system design standpoint, the challenge is that companies often
want it both ways-they want the control that comes with centralization and the
flexib il ity associated with decentralization.
I 0.4 THE IMPACT OF THE INTERNET
The internet has had an enormous impact on system archirecrure. The internee has
become more than a communication channel-many IT observers see it as a fundamentally different environment for system development.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I 0
System Architecture
I 0.4 The Impact of the Internet
328
I 0.4. 1 Internet -Based Architecture
Recall rhar in a rradirional client/server system, rhe client handles the user interface,
a~ shown in Figure 10-9 , and the server (or servers in a mulritier system) handles
the dara and application logic. In a sense, part of che syscem run~ on che client, part
on che server. In contrast, in an Internet-based architecture, in addition co data and
application logic, the entire user ince rface is provided by che web server in the form
of HTML documents char are displayed by the client's browser. hifnng the responsib1liry for the interface from the client co the server simplifies data transmission and
results m lower hardware cost and complexiry.
The advantages of Internet-based architecture have changed fundamental ideas
about how computer systems should be designed, and we are moving rapidly to a
coral on line environment. At the same time, millions of people arc using web-based
collaboration and social networking applications to accomplish casks that used to be
done in person, over the phone, or by more traditional Internet channels.
I 0.4.2 Cloud Computing
C loud com puring refers to tbe cloud sy1ubol that often is used ro represent the Internet. The cloud computing concept envisions a cloud of remote computers rhar provide a total on line software and data environment thac is hosted by third parties. For
example, a user's computer does not perform all the processing or computing tasks-the cloud dues some or all of it. This concept is in contrast to today's computing
model, which is based on networks that strategically distribute processing and data
across che enterprise. In a sense, the cloud of computers aces as one giant computer
that performs rasks for users.
Figure I 0- 10 shows users connected co che cloud, which performs che computing
work. Inscead of requiring specific hardware and software cm che user's compucer,
cloud computing spreads rhe workload co powerful remote ~)'Mems chac are part of
che cloud. The user appears to
be work ing on a local c;ystem,
but all compuring is acrually
performed in rhe cloud. o
Cloud
sofcware updates or system
maintenance are required of the
user.
Cloud computing effectively
eliminates comparibilit)' issues,
because the Internet itself is the
platform. This architecture also
provides scaling on demand,
which marches resources to
needs at any given time. For
Web server
example, during peak loads,
additional cloud servers mighr
come online auromarically ro
support rhe workload.
Cloud com puring is an ideal
platform for powerful Software
as a Service (SaaS) applications.
As described in Chapter 7,
SaaS is a popular deployment
FIGURE I 0-10 Cloud computing.
c
,/\
D I
8 8
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l
Systems Design
329
I 0.5 E-Commerce Architecture
method where software is nor purchased bur is paid for as a service, much like one
pays for electricity or cable TV each month. In rhis a rchitecn1re, service providers can
easily make updates and changes ro services without involving the users.
Even though cloud computing has tremendous advantages, some concerns exist.
First, cloud computing may require more bandwidth (the amount of data that can
be transferred in a fixed rime period) than traditional clienrl erver networks. Second,
because cloud compurmg is Internet-based, if a user's Internee connecnon becomes
unavailable, the user will be unable to access any cloud-based services. In addition,
there are security concerns associated with sending large amouncs of data over the
Internet, as well as concerns about scoring it securely. Finally, there 1s the issue of
control. Becau e a service provider hosts the resources and manages data storage
and access, rhe provider has complete control of the system. Many firms are wary of
handing over control of mission-critical data and systems to a third-parry provider.
This is particularly true when the cloud provider's servers arc physically located in
another jurisdkrion or country.
Future technology advances will make cloud computing even more feasible, desirable, and secure. As the IT industry moves coward a web-based architecture, cloud
computing is being marketed aggressively and growing rapidly. Ir has become a cornerstone of enterprise system a rchitecture and will continue to be for the foreseeab le
future.
I 0.4.l W eb 2.0
The shifc to Internee-based collaboration has been so powerful and compelling that it
has been named \Xleb 2.0. \Xleb 2.0 is not a reference to a more technically advanced
version of the current web. Rather., Web 2.0 envisions a second generation of the web
that will enable people co collaborate, interact, and share information more dynamical!)'· Some view Web 2.0 as a stepping stone toward the semantic web, called \Xleb
3.0 b)• !>Orne, where the documents shared on the Internee have semantics (meaning)
and not just syntax (I IT.ML markup).
Social networking sires, such as Facebook, T\viner., and Linkedln, are seeing explosive growth in the Web 2.0 environment. Another form of social collaboration is
called a wiki. A wiki is a web-based repository of information char anyone can access,
contribute to, or modify. In a sense, a wikj representS the collective knowledge of a
group of people. One of the best-known wikis is \Vikipedia.org, bur smaller-scale
wikis arc growing rapidly at businesses, schools, and other organizations thar want to
compile and share informarion.
One of rhe goals of Web 2.0 is to enhance creativity, interaction, and shared ideas.
In rhis regard, the \Xleb 2.0 concept resembles the agile development proces~ and
the open-source software movement. Web 2.0 communities and services are based
on a body of dat~1 created by users. As users collaborate, new layers of informarion
are added in an overa ll environment known as the Internet operating system. These
layers can contain text, audio, images, and video clips rhat are shared with the user
community.
I 0.5 E-COMMERCE ARCHITECTURE
The huge expansion of online commerce is reshaping the IT landscape. Internet business solutions must be efficient, reliable, and cost-effective. When planning an e-commerce architecture, analysts can examine in-house development, packaged solutions,
and service providers. The following sections discuss these options.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I 0
System Architecture
330
I 0 .5 E-Com me r c e A rch itectu re
I O.S. I In-H ouse Solutions
Chaprer 7 descri bed how to analyze adva ntages and disadvantages of in-house de\'clopmenr versus purchasing a software package. The same basic principles apply to
system design.
If a decision is made to proceed with an in-house solution, there musr be an
overall plan to help achieve the project's goals. Figure I 0-1 t offers guidelines for
companies developing e-commerce st rategies. An in-house solution usually requi res a
greater mirial invest ment but provides more fl exibility for a company tha t must ada pr
quickl)• in a dyna mic e-commerce en\'iron ment. By working m-house, a company
has more freedom to inregrarc wit h c usromers a nd suppliers and is less dependent o n
vendor-specific solutions.
Guidelines for In-house E-commerce Site Development
'
Analyze 1he company's busmess needs and dovelop a clear stalement ol
your goals. Consider the experienoe of other companies wllh similar
projects.
Obtain lnpu1 from users who understand lhe business and technology
Issues involved in the projecL Plan for future growth, but alm lor ease of
use.
Oe1ermme whether the rT staff has the necessary skills and experience to
lmplomenl the project. Consider tra1n1ng, additional resources, and the
use or consultants 1r necessary
Consider integration requirements for ex1st1ng legacy systems or
emerprise resource planning. Select a physical 1nfras1ructure carolully so
It will support the appt1cat1on, now and later.
Develop the project in modular form so users can lest and approve the
funchonal elements as )IOU go along
Connect the applicaooo to ex1shng in·house systems and verdy
interactivity
Test every aspect of the site exhauslively. Consider a preliminary rollout to
a pilot group to oblain feedback before a lul launch
FIGURE I 0- 1 1 G uidelines for companies developing e·commerce strategies.
For s ma ller companies, the decision about in-house web development is even mo re
critical, because this approach will require fina ncial resources a nd management attentio n tha t many small companies might be unable or unwilling to commi t. An in-house
strategy, ho weve r, can pro vide valua ble benefits, including the fo llowing:
•
•
•
•
•
A unique website, with a look and feel consistenr with the compa ny's orher
ma rketing effo rts
Complete control over the orga nization o f the site, the num ber of pages, a nd
the size of the fil es
A scala ble structure to handle increases in sales a nd producr offerings in rhe
fu ru re
More flex ibi lity to modify a nd manage the site as the company changes
T he opp<irrun iry to integrate rbe fi rm's web-based business systems with its
o ther informa rion systems, c reating rhe po tential for more savings a nd berrer
customer service
(....,..... J:gi ( . . . . . I_,.. 41 11.,.. ~- )U, ..,...,...... .,..~
r..a...w...,..._...., ..
Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. - ~--- t fta111&....-.~~ ij
.................,.t11ru ..
__.~~ c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase 3
Systems Design
331
I 0.5 E-Commerce Architecture
Whether a firm uses an in-house or a packaged design, the decision abour web hosting is a separare issue. Alrhough inremal hosring has some advanrages, such as grearcr
control and security, the expense would be much greater, especially for a small- ro
medium-s11ed firm.
I 0.5.2 Packaged Solutions
If a small company is reluctant ro cake on che challenge and complexity of developing
an Internee commerce ~ire in-house, an alternati,·e can be a packaged olurion. rh1~
is crue even for medium- to large-sited firms. Many vendors, including IBM and
Microsoft, offer turnkey systems for companies thac wanr to get an e-busmess up
and running quickly, as shown 111 Figure 10-12 . For large-scale sysrems thac mu~t
integrate wirh exisring applications, packaged solutions might be less attractive.
- ---
IBM
82C and 828 commerce platform for your omnichannel business
Willl •
.,...,......._._....
.......,.. . wtl~--·
.._.,.._
................. 9',...... , ..............,.CM.............._..,... .. ,._....___
~--
ZldtA
a
·~
... .,............
.................. .._,......... ...,...,_.-.r1 ... ...--
(
I .........
FIGURE I 0-12 IBM WcbSphere Commerce offers software solutions for companies that want to get an e-business up and
running quickly.
SoUll"C:.: I
O'
I WI
I 0.5.3 Service Providers
Another a lternative is to use an application service provider (ASP). As explained in
Chapter 7, an ASP provides applications, or access to applications, by charging a
usage or s ubscription fee. Today, many ASPs offer full-scale lntcrnet business services
for companies char decide to outsource rhose functions.
A sysrcms analys r confronrs a bewildering array of producrs and strategics when
implementing Lntcrnet-bascd sysrcms. A good starring point might be to conJ.ider the
experience of other companies in the same industry. Many firms offer the names of
clients and customers, along wirh chcir success stories. Alrhough chis information may
nor be reliable, it can provide valuable knowledge regarding a vendor's products and
services.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I 0
System Architecture
I0.6 Processing Methods
332
CASE IN POINT 10.2:
S.\tALL PoTAT0 1.~s
Small Potatoes is a family-operated seed business that has grown rapidly. It specializes in supplying home gardeners with the finest seeds and gardening supplies. Until now, the finn has done all
i ts business by placing ads in gardening and health magazines and taking orders using a toll-free
telephone number.
Now, the family has decided to establish a website and sell online. but there 1s some
disagreement about the best way to proceed. Some say it would be better to develop the
site on their own, and one of the employees, who is a recent computer science graduate,
believes she can handle the task. Others feel it wou ld be better to outsource the site and
focus on the business itself. Suppose t he family asked for your opinion. What would you
say? What addit ional questions would you ask?
I 0.6 PROCESSING METHODS
ln selecting an architecture, the systems analyst must determine which transactions
will be handled online, and what functions, if any, can be carried out using a batch
processing method.
I 0.6. 1 Online Processing
Early computer systems were designed to handle data records as a group, or batch.
Fewer systems use that model today. H owever, even the most advanced online systems
must perform maintenance, post large quantities of data during off-hours when
network traffic is low, and carry out housekeeping tasks just as their legacy computer
ancestors did. This section discusses the online processing capability that is at the core
of powerful, modern systems, and the following section describes the evolution of
batch processing.
An online system handles transactions when and where they occur and provides
output directly to users. Because it is interactive, online processing avoids delays and
allows a constant dialog between the user and the system.
An airline reservations system is a familia r example of online processing. When
on line customers visit the ai rline's we bsite, they can enter their origin, destination,
travel dates, and rravel times. The system searches a database and responds by
displaying avai lable Aighrs, rimes, and prices. The customer can make a reservation, enter a name, address, credit card informa tion, and other required data, and
the sysrem creates the reservation, assigns a seat, and updates the flight datab~1se
immed iately.
Online processing also can be used with fi le-oriented systems. Figure 10-13
s hows what happens when a customer uses an ATM to inqu ire about an account
balance. After the ATM verifies the customer's card and password, rhe customer
enters the request (Step l ). Then, the system accesses the account master file using
the account number as the primary key and retrieves the customer'i> record (Step 2).
The system verifies the account number and displays the balance (Step 3). Data is
retrieved and rhe system transmits the current balance to the AT~1, which prints it
for rhe customer.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Phase 3
Systems Design
333
I 0.6 Processing Methods
Online processing systems have four typical
characteristics:
ATM QUERY PROCESS
1. The system processes transacrions completely when and where they occur.
2. Users interact direct!) with the informaaon !>ystem.
3. Users can access data randomly.
4. The information system must be available
whenever neces~ary to support business
functions.
J_§~j
E
Step 1:
Customer enters his or
her account number and
requests an account
balance
St ep 2:
Retrieves current
account balance
St ep 3:
Verifies bank account
number and displays
balance on ATM screen
E
J :::::::::::31
ONLINE
PROCESSING
SYSTEM
I 0.6.2 Batch Processing
Batch processing means char data is managed in
groups or batches. That was an acccprable choice
in the 1960s, and for most firms, it was the only
choice. Today, all businesses need real-rime inforCUSTOMER
FILE
mation to operate, and batch processing is not
always desirable. However, batch methods can
be efficient and convenient in some siruations.
FIGURE I 0 - 13 When a customer requests a balance. the ATM
For example, batch processing can be used
system verifies the account number. submits the query. retrieves the
for large amounts of daca rhat must be procurrent balance, and displays the balance on the ATM screen.
cessed on a routine schedule, such as weekly
paychecks, daily credit card transaction updates,
or clo~ing stock data that must be calculated and published in the following da)•'s
new!> media. The advantages of batch methods include the following:
•
Tasks can be planned and run on a predetermined schedule, without user
mvolvement.
•
Batch programs that require major network resources can run at nmes when
costs, and impact on other t raffic, will be lowest.
•
A batch method is well suited to address securicy, audit, and privacy concerns,
because it runs in a relatively controlled environment.
I 0.6.3 Example
The diagram in Figure I 0- 14 shows how a point-of-sale (POS) terminal, such as that
used in a supermarket, migh t trigger a series of onJinc and batch processing events.
Note rhat chc sysrcm uses onlinc processing to handle data entry and inventory
updates, while reports a nd accou nring entries are performed in a batch. A company
would choose a mix of onlinc and batch processi111g when it makes good business
sense. Consider t he following scenario in a typical retai l store:
•
•
During business hours, a salesperson enters a sale on a POS terminal, which is
part of an on line system that handles daily sales transactions and maintains an
up-co-date invencory file.
\Vhen the salesperson enters the transaction, online processing occurs. The
sy~tem performs calcularions, updates the inventory file, and produces output
on the POS rerminal in the form of a screen display and a printed receipt. At the
same time, each sales transaction creates input data for day-end hatch processing.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I 0
System Architecture
334
I0.7 Netwo rk Models
When rhe ~core closes, rhe system uses the sales transactions to produce che
daily 5ales report, perform the relaced accounting enrries, and ::maly1e rhe data
to idencify slow- or fasr-moving irems, sales crends, and related issue -such as
store discounrs for rhe next day.
•
POINT-OF-SALE (POS) PROCESS ING
POS
Terminal
-4 -
...
POS
Sales
Daily Sales
Program
Transaction
File
Program
(Online)
(Batch)
_ .,.
Daily
Sales
Report
t
t
Accounllng
Files
Inventory
FIGURE 10- 14 Many retailel"l use a combination of online and batch processing.When a salesperlon enters the sale
on the POS terminal, the online system retrieves data from the item file, updates the quantity in stock, and produces a
sales transaction record. At the end of the day. a batch processing program produces a daily sales report and updates the
accounting system.
Online or barch processing are totally different bur can work well together. In this
scenario, an online system bandies POS processing, wbich must be done as it occurs,
while a batch mechod provides routine, overnight processing and marketing analysis.
Online processing allows tbe daca to be entered and validated immediately, so the
informarion always is up ro date. However, a heavy volume of online transaction~ can
be expensive for smaller firms, and data backup and recover)' also add to IT costs. In
contrast, when used properly, bacch processing can be cost-effective and less vulnerable to system disruption.
I 0. 7 NETWORK MODELS
A network allows rhe sharing of hardware, software, and data resources in order
co reduce expenses and provide more capability co users. When planning a network
design, chc sysccms analyst must consider network terms and concepts, including the
OSI model, network modeling tools, network topology, network protocols, and wireless networks, which arc covered in rhis secrion. Other imporranc issues, such as nccwork performance and security, arc covered in Chapter 12.
10.7. 1 The OSI Model
The discussion of system architeccure earlier in this chapter already inrroduced basic
network terms such as client, server, LAN, WAN, clienr/scrver architccrurc, cicrs, middlcwarc, and cloud computing. To fully understand how nerworks are configured, che
Open Sy~rcm~ Interconnection (OSI) model should also be understood. The OSI model
describes how data moves from an application on one computer to an applicarion on
anorher nenvorked compuccr. The OSI model consists of seven layers, and each layer
performs a specific function. The OSI model provides physical design srandards rhar
assure seamless nerwork connectivicy, regardless of che specific hardware environmcnc.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,...
..,...,.......,..~
__.~~c.....,..~
r..a...w...,..._...., ..
.................,.t11ru ..
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase 3
Systems Design
335
I 0.7 Network Models
10.7.2 Ne tworkTopology
The way a necwork is configured is called the net\>.'ork copology. Topology can
refer co a physical or a logical view of che network. For example, phy~ical copology
describes che actual network cabling and connections, while logical copology
describes che way the components inceract. le is importanc to understand the
disnncrion, because a specific physical topology might be able co support more than
one logical topology. For example, it is noc uncommon to run cabling in a certain
pauern because of physical installation and cosc issues but to use a different partern
for the log1cal topology.
Compucers may be physically arranged in a circular shape, but that mighc or might
not reflect che network topology. The examples shown in Figures 10-15 to 10-19
represent a logical copology, as seen by network users, who may not know or care
about che physical cabling panern.
LAN and WAN networks cypically arc arranged in four patterns: hierarchical, bus,
ring, and star. The concepts are the same regardless of the size of the network, but the
physical implementation is different for a large-scale WAN that spans an entire business enterprise compared wi th a sma ll LAN in a single department. These four common topologies arc described in the following sections.
HIERARCHICAL NETWORK: Jn a hierarchical network, as shown in Figure 10- 15,
one or more powerful servers control the entire nerwork. Departmental servers control lower levels of processing and network devices. An example of a hierarchical network might he a retail clothing chain, with a central computer rhac store& data about
sales activity :ind inventory levels and local compucers char handle ~core-level operations. The ~tore:. tran:.mit data co the central computer, which analyze~ ~ales trend~,
detennine~ optimum stock levels, and coordinates a SCM system. In chis l>ituacion, a
hierarchical network might be used, because it mirrors the acrual operational flow in
the organizanon.
--
FIGURE 10- 15 A hierarchical network with a single server that controls the network.
.........""_.. ... .-.................
_..__ ...................
("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ............... ,.. o-....._ ...... _
__....
--
........... ......
... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~
Chapter I 0
System Architecture
I0.7 N etwork Models
336
One disad,·antage of a hierarchical network is that if
a business adds additional processing levels, the network becomes more complex and expensive ro operate and maintain. Hierarchical networks were often
used in traditional mainframe-ba<;ed S)'Stems but are
less common today.
PC
g
-
g
PC
~B>--~~-- ~
U
Termnals
Q --Ci}
PC
PC
s
Ci}
In a bu~ net\\ Ork, as shown m
Figure 10-16 , a single communication path connects
cbe central server, departmental servers, workstations,
and peripheral devices. [nformation is transmirted
in either direction between networked devices, and
all messages travel over the same central bus. Bus
networks require less cabling than ocher topologies,
because only a single cable is used. Devices can also be
attached or detached from the network at any point
without disturbing the rest of the network. Jn addirion,
a fa ilure in one workstation on the network does nor
necessaril y affect other workstations on the network.
O ne major disadvan tage of a bus network is that
if rhe central bus becomes damaged or defective, the
entire network shuts down. Anorher disadvantage is
that overall performance decl ines as more users and
devices are added, because all message traffic must
flow along the central bu~. This does nor occur in the
treelike srruccure of a hierarchical nerwork or the huband-spoke design of a star network, where nerwork
paths are more isolated and independent.
The bus nerwork is one of the oldest LAl ropol·
ogies and is a simple way co connect mulriple work·
scarions. Before the proliferation of scar nerworks,
bus networks were very common. They share char·
acceriscics of hardware bus nerworks. Today, che bus
design is less popular, but some fim1s have retained
bus networks co avoid the expense of new wiring and
hardware.
BUS NETWORK:
Te1mina1s
~/
FIGURE I 0-1 6 A bus network with all the devices
connected to a single communication path.
g
RING NETWORK: Although ring networks arc
st ill around, they are somewhat outdated. rBM
was a leader in ring network technology when they
introduced their token ring LAN, and large companies
who use [BNl mainframe equipment sti ll deploy the
ring network design. A rinA network, as shown in
Figure L0- 17 , resembles a circle where the data flows
Oepartmon1a11etver
in only one direction from one device to the nexr. In
function, a ring network can be thought of as a bus
FIGURE I 0 - 17 A ring network with a set of computers that
network with rhe ends connected. One di~advanrnge
sends and receives data flowing In one d1rect1on.
of a ring network is that if a network device (e.g.,
a PC or a server) fails, the devices downstream from the foiled device cannot
communicate with the network.
PC
PC
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase 3
Systems Design
337
I 0.7 Network Models
STAR NETWORK: Because of its speed and versa-
tility, the star network i a popular LAN topology.
A ~tar network has a central networking device
called a switch, which manages the network and
Oepartmenllll
acts a~ a communications conduit for all network
traffic. In the past, a device known as a hub was
used to connect star ncrworks, but a switch offers
advanced technology and much better performance. A hub or switch functions like a familiar
mulnsocket power strip but with network devices
such as servers, workstations, and printers plugged
in rather than electrical appliances. The hub broad~nner
casts network traffic, called data frames, to all
connected devices. In concrasr, a switch enhances
network performance by sending traffic only ro
specific network devices that need co receive the
data.
A star configuration, as shown in Figure 10-18,
FIGURE I 0-18 A star network with a switch, departmental server,
provides a high degree of network control, because
and connected computers and devices.
all traffic flows into and our of the switch. An inherent disadvanragc of the srar design is rhar rhe entire
network is dependent on the switch. However, in most large star networks, backup
switches arc available immediately