_,
.. •
,
•
..
•
~~
..,.,
f~-
,,
~
'
•
-•
•,
...
....
,,
•
Jeffrey L. Whitten
Professor
)>
::)
Lonnie D. Bentley
Professor
Both at Purdue University
West Lafayette, IN
With contributions by
GaryRandolp?
Purdue University
0
-<
(/)
- ·
(/)
0
::)
Q_
0
(1)
SEVENTH EDITION
(/)
co
::)
s
(D
--t-
:T
0
Q_
(/)
ID McGraw-Hiii
tti1ii lrwln
Boston Burr Ridge, IL Dubuque, IA Madison, WI New York San Francisco St. Louis
Bangkok Bogota Caracas Kuala Lumpur Lisbon London Madrid Mexico City
Milan Montreal New Delhi Santiago Seoul Singapore Sydney Taipei Toronto
111#1 McGraw Hiil Co:np=J#ls
la McGraw-Hiii
D
lrwln
SYSTEMS ANALYSIS AND DESIGN METHODS
Pllblisb?d by McGraw-HiJVlrwio. a busins u.nitof'fbe ~fc(lraw-Hill Companies. hie.. 122 I
Avenue. of the Americas. New York. NY 1•)020. Copyright () 2007 by The ~fc(lraw-Hill
Companje.s, Ioc. AU rights NSen-ed. No pu'lof thjs publicatioo may be replOduced or distributed
in any form or by any moons. or stored in 1 dab.base or retrieval system. witlx>ut th?. prior -·ritten
coosentof'fbe ~fc(lraw-Hill Companies. hie.. ircludiog. but not Limited to. in any D?twort: or
other elec:t10nic storage or transmission. or broad:ast for dfatanoe. learniog.
Some ancillaries, includjog eleclronic alXI priot compooenlS. may rot be. a,•ailable. lO customers
outside th?. United Slates.
This book is P"inted oo ocid-free paper.
123456 7890VNHNNH 0 98765
ISBN- I3: 978-0-07-305233-5
ISBN-10: 0-07-305233-7
Editaial director. Brettt Gordo11
Executi,-e.edilOr: Poul Duchont
Projoct manager: 1W11a Hauger
Marketing manager: Satlkha Basu
Media producer: Greg Bales
Projoct manager: Kristin Bmdley
Le-ad proouction .super,•isor: Michoel R. McCor,.nit:"k
Senior desigper: Kami Carier
Photo rese.vch CCXX"dinator. Ihri Kramu
Media project manager: LyM M. Bluhm
Cowr de.sigi.,: Kami Carter
Interior desigo: Kami Carter
Cowr image: C Cabis
Typeface: IOIJ2 Garamo1td Light
Compositor. ~Los Mgtles, CA Campus
Printer: ~,. H<ff.1110M Corpororio1t
uorary orl:oognss u.11uogrng-1n-Yooucauo• Uat•
Whitten. Jeffre.y L.
Systems analysis and design metlxx:ls/ Jaffrey L. Whitteo. l..on.nje D. Beotle.y.- 7th ed.
p. cm.
locludes bibHographicaJ references and index.
ISBN-I 3: 978-0-07-305233-5 (alk. Pl-l)?r)
ISBN-10: ~ 07-305233-7 (aik. pap?r)
I. System de.sigi.,. 2. System analysis. J. Bentley. Lonnie. D. IL nue.
Q..\76.9.S88W48 2007
OOJ.2' l---dc22
2005054019
wwwmhlur:nm
-
0
To my lovely wile Cheryl and my children Robert, Heath, and Coty. To my
a,author and good friend Jeff and our twenty years of writing side by side.
-Lonnie
CD
Q_
n
0
----+·
To my father. You instilled in me the work ethic, perseverance, and curiosity for
l.iowledge that has made this book possible.
-Jell
0
::J
(1)
u
0
'--4-
> Intended Audience
SystenJSAn.alysts at1d Design ,lJethods, se,--enth edition, is intended to support one or
more practlcal courses in information systems development. These courses are nor.
(1)
mally taught to both information systems and business majors at the sophomore,
I.....
jtmlor, senior, or graduate le,"'el.
Q_
We recommend tl1..1t students take a computer- and lnformation systems-Ute.racy
course before using this text. Wlille not requlre.d or assumed, a programming cotttse
can significantly enhance the leunlng experience provided by thls textbook.
>
Why We Wrote This Book
,_lore than ever, today's student! are ..consumer-0riented," due ln part to the changing
world economy, which promotes quality, competition, and professional currency. Thei•
expect to walk away from a course wJth more d1an a grade and a promise that lhey1l
someday appreciate what the)"'-e learned.11,ey want to •practice" the application of
concepts, not Just study applications of concepts. We wrote this book (1) to balanre the
coverage of concepts, tools, tedmlques, and their appllcatlon, (2) to provide the most
cxrunplc.s of system analysis and dcslgn dclivcmblcs ava.ilabl-c in any book, and (3) to bal-
ance the coverage of classJc methods (such as structured analysis and lnfor,nation.
eughU1'rrlt1g) and emerging methods (e.g., object-oriented analysis, agile develop»umt,
and rapid appllcatlon developmenl).Addltionally, our goal ls to serve the reader by providing a postcourse, prof~ional reference for the best current practices.
We have written the book uslng a lively, conversational tone. This approach (and
the numerous examples) dell\o't'rs a comprehensive text that still connects with the
student throughout the learning process.
> Changes for the Seventh Edition
Reorganization for Better Cfarlty, The object-oriented analysis diapter has
become O,apter IO to better position It alongside the structttred analysis
chapters (Chapters 8 and 9). Other chapters ha>-. been reorganized Internally. For
example, Chapter 9, ln response to reviewer comments, has undergone extensive
reorganlz;itlon. Also, the discussion of sequential versus Jteratfve deveJopmenr has
been moved to O>apter 3 to pL1ce it with related methodology concepts.
E.-.:paoded Object-Oriented Coverage, As object-oriented analysis and design
grows ln importance, coverage continues to increase.111e seventh edition more
fully expL1tns the object-Orlenced approach and cracks both where tc follows the
same path as the traditional, ~uctLU'ed approach and where the two approaciles
part ways.11,e object-oriented analysis chapter (Oupter 10) features expanded
co,-.rage of activity diagrams. New to this edition In Otapter 10 ls coverage ol
system sequence dhtgrams. Oupter 18 features expanded coverage of objectoriented design. Persistence and system design das.,es are discussed as well as
entity, controller, and lnterface design classes. '01e discussion of sequence diagrams
and CRC cards has been expanded, and their role In the design process explained
more fully. co,-erage of design pattenis llas been greatly expanded with a dlsc,~slon
of the Gang of Four panems tnd an examination of two of the patterns.
UML 2.0, Both Chapter 1O and a,apter 18 ha,-e beet1 revised to cover the UML
2.0 specification. Each UJ\IL 2.0 dL1gram Is listed with an explanation of its
purpose. In Chapters 7, 10, and 18, lh-e of the tl1lrteen UJ\IL 2.0 diagrams are
developed in depth and tl1ree more are shown and discussed.
E.-.:pauded Discussion of Feaslblllty, The discussion of feasibility now includes
leg.11 feasiblllty and cultural (or political) feasibility as well as our tt2ditional four
tests of feaslblllry (oper2tlon,~ economic, schedule, and technical).
Use of Context Diagrams: Even as the move away from dara flow d11grams and
to U}.fl diagrams contlnues, 1he context d11gram continues ro be Jmportant as a
tool for w1derstandfng ~stem scope. It h ..,s bee.n added to the tools used lo
a,apter 5 and can be employed In the cla55room ,s a first modeling asslgnma,t..
Updated Teclmology References: The extensfve references to example
tedu1ologies has been continued In the seventh edition and updated to reflect
tedu1ological changes, version updates, and mergers and acqulsJtlons of
tedu1ology comp:ulies.
Revisio11 of the So,1ndStage Ru1ulh1g C1.se: The SoundStage case h,,s beetl
condetl.Sed,changed from a dialogue format to a n ..natt,--e format, and lntegrated
Into the openlng of each chapter. Fearurlng the perspectlve of a just.graduated
5)-sterns analyst In hls first assignment, SoundStage briefly Introduces the concepts
taught In each diapter and underscores d1elr Importance In a real S)'Slems project.
>
Pedagogical Use of Color
The seventh edition continues d1e use of color applied to an adaptatio11 ofZachman 's
Fra-,nett:ork for I11for111atf-011 Syste111s Architectu.re. The color mapplogs are displayed
In the Inside front cover of the textbook.
The infonnation ~'Stem.s building blocks matrtx uses these colors to introduce recurring concepts. System models then reinforce those concepts wlth 3. eotlSistent use
of the same colors.
>
Organization
Syswms Analysis a,uf Desfg11 Metbods, sevend1 edition, Is divided Into four parts. Toe
text's organization is flexJble enough to allow instructors to omit and resequence
d1apters according to what they feel is Important to thelr audience. Every effort has
beet1 made to decouple chapters from one another as much as possible to assi.st lo resequencing the materL1l- even to the extent of reintroducing selected concepts :u1d
terminology.
P:irt One, *The Context of ~stems Development Projects," presents the lnfonnatlon ;,ystems developmet1t scenario and process. Chapters 1 tlvough 4 introduce the
student to ~'Stems analysts, other p roject team members (h1duding users and management), Information systetllS building blocks (based on the Zad,man framework), a
Information Systems Framework
Color ls used consistet1tly througl1out tl1e text's framework to Introduce recurring concepts.
represents methods
represents data :u1cVor knowledge
represents process
represents communlcaUon/interface
represents people
v
contemporary systems development llfe cycJe, and project nw1..1gement. Part One can
be covered relatively qulddy. Some readers may prefer to omit project management
or delay It until the end of the book.
Part Two, "Systems Analysis Methods," covers the froot-et1d life-cycle acti,itles,
tools, and rechnJques for analyzlng business problems, specifying business require-
ments for an lnformatlon $)'stem, and proposing a business and ~stem solution.
Coverage ln Ch.apters 5 through 11 includes requirements gathering, use cases, data
modeling with entlty-relatioosillp diagrams, process modeling with data flow diagrams, object-oriented analysis.and solution ldentificatlon and the system proposal.
Part 11,ree, •Systems Design Methods," covers the mlddle life-cycle activities, tools,
and techniques. Chapters 12 through 18 Include coverage of both groeral and detailed design, with a partlctdar emphasis on application architecture, rapid development and prototyping, externtl design (inputs, outputs, and Interfaces), internal
design (e.g., database and software engineering), and object-oriented design.
Part Four, •eeyond Systems Analysis and Design; Is a capstone unit that places systems analysis and design Into perspective by surveying the back-,,od life-cycle activities. Specifically, Chapters 19 and 20 examlne system Implementation, sttw<>rt,
maintenance, and reenglneerlng.
>
Supplements and Instructional Resources
It has always been our intent to provJde a complete course, not Jlist a textbook. We
are especially excited about this edltJ011's comprehensJve support package. It
includes Web-hosted support, software bundles, and other resources for both t11e
student and the instructor. 1be supplements for the sevent11 edition include t11e
following componet1ts.
Web Site/OLC
A complete.ly redesJgned Web site provides easy-to-find resources for lnstructors and
students.
e
e
SYSTEMS ANALYSIS
& DESIGN METHODS
o,,,,..,e,...: TO~J',~•m:i W.ir'\\00 l)(.~()IHht .c:oic.oon Ql ~l)~.,6$ wdl t~ l)(fV.«11
edit:onol 1111$book. the-author~ '""1tleto 11,.. ~nce the CO*Cl'"Ot d COl'IOl$a,tools,tedTllQutt,
¥1d0'\fif .s:il)lt.;10f'4, .,...Otol)"O'ol~e ti'$ m(" e,4r~ <I 5'1Sttm •n.o1t.is ¥<14"-i;n
det,,cr4bles 4f.iil11blt i~4r'lf book The te,)1bc,o't 4lso 1ent$ the re4der 11$ 11 C!fOfenton.ol
lllf~,11~0 ' " l:i!Y.t ( U'l'llf'C: l)r'.;a;1Ck,
fnoo, -
.... ,. ...i;t,. , r,i,.....~.,.
"' )'.~... ,"'st:•:~,;;:!'..~=~~1!':.!:;=t.!'.;.:;r.:.:r.~~~....... ,..,,..tu-.,
vt
For the Instructor
Web Site/OLC
The book's Web sJte at www.mhhe.com/Whitten provJdes resources for instructors
and ,tudenrs using the text. The Online Learning Center (OLC) builds on the hook's
pedagogy and features with self-assessment quizzes,ext:ra material not found In the
text, \X'eb links, and other re.sources.111e Instructor side of the site offers a sea,re
location for downloading the L1test supplemental resources.
,0
Instructor's Monuol with PowerPoint Presentations
The lnstructor's manual ls offered on the Instructor's CD-ROAi, as well as on the
hook's Web site. This manual includes course planning materL1ls, teadllng guldeUnes
and PowerPolnr slides, tempL1tes, and ai1SWers to end-0f<l1..1pter problems, exercises,
and mitlicases.
The PowerPolnt presentations on the CD-RO?tt include o,-er 400 slides. All slides
are romplete with Instructor notes that provide teaching gttldellnes and tips. Instructors can (I) pick and choose the slides they wish to use, (2) customlze sUdes to thelr
own preferences, and (3) add new slides. Slides can be org,mlzed Into electronic pre,
t-Pnt~lon.c. nr l'W" pf'intP<l :as. rr:an.,:;p:1rPnrlP~ o r tr;in.,;parpnry m!l!':tf>f'Jll.
Test Bank
O The Instructor's CD-RO,lf also lndudes ait electronic test bank coverlng all the
diapters. COmputerized/NetworkTestlng wlth Brownstone Diploma software Is f,tliy
networkahle for LAN test admlnistration. Each chapter offers 75 questions in the following formats: true/false, multiple choice, setttence completion, and matching. The
test b.1nk and answers are cross-referenced to the page numbers in the textbook. A
levek>f-dlfflcttlty rating is also assigned to each question.
>
Packages
'o Student Resource CD
Ead1 text Includes a student CD with two case projects, templates and forms for
the projects, the same PowerPolt1~ slides provided to the Instructor, and a l 2o.day
evaluation copy of Mlcrosoft Projec~ accompanled by a stepby-step tutorL1l.
,0 System Architect Student Edition Version 8
An optional package combines d,e textbook, Student Resource CD, and a student
version of System Architect. System Archltect is a powerful, repository-based enterprise modeUng tool whlch supports a comprehensive set of cllagr.unmlng tedmlques
and learures, Including all nlne UML diagram types, business etllerprlse modeling, data
modeling, business modellt,g with IDEFO and IDEF3 notations, plus many more.
O
Visible Analyst Workbench
Anod1er optional package combines the textbook, Student Resource CD, and Vlslhle Analyst Workbench. This tool ltllegrates business function analysis, data modeling
and database design, process modellng, and object modeling In one easy-t<>-<rse package. Prhtt versions of each case can be ordered through ,_lcGraw-HJU's Custom J>ub.
llshlng group by visiting www.prlmiscontentcenter.com. A build yo·u r 0 1v1i project
modeJ ls retained for lnstructors and studettts who want to m.1xhnize '\o"alue by leveraging srudents• past and current work ex:perlence or for use with a Uve<lient project,.
II Primis Content Center
Primis Online
Print versions of projects and cases, :is well as other ?.(IS content, can be ordered
through McGrnw-Hlll's custom Publishlt1g Group.
vii
(/)
.....__
c
Q)
E
Q)
0)
uQ)
5
0
c
u
....:::L.
<{
\X'e are indebted to many indJvJduals who cootrlbuted to the development of this edition:
Grant Alex.ander, 1\ rortbeasterti Oklaho111a
State U11.iverslty
Rlcharo J. Averbeck, DeVry /11stitu.tes
Emerson (BUI) Batley, Park U11tverstty
Jack Briner, a,a,Jeston So·u therti U1ilversil)'
Jimmie Carraway, Old Do·1nl1ilo11 University
Casey Ceglelskl,Au.bum U11tversr.ty
,_Under 01et1, Geor~ il.fason U11iverslty
Gletlll Dietrich, Universf.ty of'lexas-Sa11
A11..to1i.to
Dorothy Dologite, Baruch College, CUNY
Tom Erickson, Unfversfty ofVirgln fa~
Vlrg/11/a Center for Cont/11:utng and
Professlo·,,al F.ducatto·n
Bob Kiimer, Mess/ab College
Avram Malkin, DeVry College of'IIH:Jmologv
Dat-Dao Nguyen, Galiji:m1ta State
Universlty-Norrbrltfge
Parag C. Pendharkar, Pe1i11 State University
Leah Pietron, Universf.ty of
Nebraska- Omaha
a,arlene Riggle, University of Sou.th
Florida-Sarasota,/Jlfan.atee
A special thank-you ls extended to the following focus group partlclpanrs:
Jeffrey Parsons, Memorial U11tversf.ty of
1\feU,fo·u11dland
Parag C. Pendharkar, Pe1i11 State University
Carl Scon, University of Houston
Ron n1ompson, Wake Forest Utilversr.ty
Steve W.'llczak, Colorado Ut1.iversity- De1J.Vtr
\X'e also are lndd>ted to many lndtvfduals wh.o
contrlbuted to the de1i--elopment of the prevJo tL"' Pciltiont- of thit- rPTI
Jeanne M. Alm, Moorhead State U11tverslty
O,aries P. Bilbrey, James Matllso11 Uttlverstty
Ned a,aph1, catljomr.a State
University-Hayward
Carol Clark, Mldtlle 'le1111essee State
University
GaU Corbitt, calljomia State
University-Cb/co
L"ry W. ComweU, Bradley U11tversf.ty
Barbara B. Denison, Wrlgbt State University
Unda Duxbury, Garleton Utttverslty
Dana Edberg, University of Nevada-Reno
Graig W. Fisher,Marlst College
Raot~ J. Freeman, Galljomla State
Universlty-Do·1rtl11gu.ez Hiiis
Detmis D. Gagi1on, Santa Barbara
Cf.ty College
Abhl)lt Gopa~ Uttlversity of catgary
viii
P:ltrlda). Guinan, Boston U11iverstty
BUI C. Harograve, U11tversf.ty of
Arka11sas-Fa)rettevllle
Alexander Hars, University ofSo·u tbern
catljornia
Rlcharo C. Housley, Golden Gate U11tver,f.ty
Constance Knapp. Pace University
Riki S. Kuchel<, Orange Coast College
Thom Luce, Ohio University
a,arles M. Lurz, Utah State University
Ross MaL1g,1, U11tverstty of
,lfaryland-Balrr.1nore Cou.1u:y
Ollp McGhlllls, Park College
William H. ,_loate.s, /1idfana State University
Ron.aid J. Norman, San Diego State U11tvtrslty
a,arles E. Paddock, U11tversf.ty of
1\ revada- Las Vegas
Jtme A. Parsons, Northeni ,lficblga11
Ut1-l1,'<W&f.ty
Harry Reli, james Madlso11 Universr.ty
Gall L Reln, SUNY-Buffalo
Rebecca H. Rutherfoord,Sou.them College of
'/eclmology
Graig W. SUnkmatl, University of
1e.ws-Arli1igto11
John SmUey,Ho(y Famt(y College
,_laryThurber, 1\tortbern Alberta /11str.n,te of
'/eclmology
Jerry1111man,Appalachian State Universf.ty
Jonathan Trower, Baylor Un lversity
Margaret S. Wu, University of Iowa
Jacqueline E. Wyatt, Middle 'llmnessee State
U1itverstty
Vlneetll C. Yetl, Wright State Universf.ty
Ahmed S. Zaki, College of William anti Mary
Flnally, we acknowledge the contributions,
encouraaemet1t. and patience of the su.ff at
McGraw-Hill. Special thanks to Brent Gordo11,
publisher; Paul Ducham, sponsoring editor;
Trina Hauger, developmental editor~ Greta
Kleinert, marketing manager; Kristh1 Bradley,
p roject manager; and Kami Carter, designer.
We also thank Judy Kausal, photo research coordinator; ~Uchael McConnlck, production
supervisor; Greg Bates, media producer~ and
Rose Range, supplemet1t coordinator.
To those of you who used our previous edJ..
tlons, thank you for your continued support.
For tl1ose ush1g the text for tl1e first time, we
l1ope you see a dlfferet1ce in this text. We
eagerly awalt yoltr reactions, comments, and
suggestions.
Jeffrey L. WNtte,,
Lo1111ie D. Bentley
(Brief Contents
Preface vi
PART ONE
The Context of Systems
Development Projects 3
1 The Conte21.'t of Systems Analysis and
Design Methods 4
2 Information System Building Blocks 42
3 Information Systems Development 66
4 Project Mrumgeme11t 118
PART TWO
Systems Analysis Methods 157
S Systems Analysis 158
6 Fact-Finding Tedmiques for
Req\1irements Discovery 206
7 Modeling System Requirements with
Use Otses 242
8 Data Modeling and Analysis 268
9 Process Modeling 314
1o Object-Oriented Analysis and Modeling
Using the UML 368
11 Feasibility Analysis and the System
Proposal 412
PART THREE
Systems Design Methods 443
12
13
Systems Design 444
Application Ard1itecture and
Modeling 474
14 Database Design 516
1 S Output Design and
Prototyping 548
16 In put Design and
Prototyping 580
17 User Interface Design 612
18 Object-Oriented Design and Modeling
Using the UML 646
PART FOUR
Beyond Systems Analysis
and Design 681
Systems Construction and
Implementation 682
20 Systems Operations and
Support 700
19
Photo Credits
720
Glossary,;Index 721
Ix
( Contents
Preface
vi
2
PART ONE
The Context of Systems Development
Projects 3
1
THE CONTEXT OF SYSTEMS
ANALYSIS AND DESIGN
METHODS 4
INFORMATION SYSTEM BUILDING
BLOCKS 42
Introduction 44
The Product- Information Systems 44
A Framework for lnforntation Systems
Ardlitccturc 46
KNOWl.l!DGI! B11i/dl11g Blocks 47
PRoa!ss B11i/dl11g Blocks 51
COA£llUNICA.110A''S Bu.t(dl11g Blocks 55
lntrodttctiat 6
A nan,ework fur ~ystems Analysis and IJcsign 6
The Player,-Systcm Stakeholders 7
Ncrwori< Technologies and the IS Building
Blocks 58
Syste111.1, Ou,,wrs 7
Systet11J Users
7
Systet11J Desig ners JO
Svsterm Bu.1/ders IO
svste111J A11alvsts 1 I
E.WemaJ Service Providers
The PrGj ect Mrmager J6
(3- -1-N-FO
- RMA
- -J-I O_N_s_YSTEMS
\._ DEVELOPMENT 66
Introduction (,8
The Procr:ss of Systems Develop ment (,8
16
The Capabllitv Matu.rf.ty Model 6!)
Business Dri,jt ts for Today's Information
Syste.ms 16
Globall:mtf.011 o f tbe Econo1nv 17
Electro·u lc Cotutuerce and Business
Life C}m versus Met/Jodology 70
UtJ.derlvtng Prlncip(es fo r Systetns
Devefop1ne1J.t 72
18
Security a11d Prlwcv 19
Collaboration and Partnership 20
K11-0t1Jt«lge Asset Afa11.age,11e11.t 2 I
Conrt,i:11ou.s l1nprovet11e111 and 1btal Quality
Afu1111sJJ11wn1
22
Technology Drivers for Today's Information
Systems 22
Netu,'OrlJs and' the /11ter11.et
22
Mobile and Wireless Teclmologtes 24
Ob/ect Tech11ologles 25
Collaborative Technologies 25
Enterprise APplicatlons 26
A Simp le System Oe,..,lopmcnt Process 30
svste,n. /11.:ltiatio,i 32
Systertl A.11alysfs 32
Svstem J)(!slg n 33
Svstern. In1plet1ientatto·n 33
svste11i su.pport and Contitiuous
/111-prove,netJ.t 33
x
76
Where Do Systems Development Projects Come
From? 77
The FAST Protect Phases 77
Crus~· Lt/fJ.C1J<.-ftt Ac.:.fivf.tltt~·
2I
B1af.1u1!S Process Redesign
A Systems Oe,..,lopmcnr Process
88
Seque11.tlal vers1a Iterative
J)(!velopment 89
Alternative Routc-s and Srrarcgic-s 92
11,e Afodel-Drlveti Develop ,netJ.f
Strategy !)4
The Rapid Appllcatfo11 J)(!velop me11t
Strategy !)8
11,e Cotntnercial Applicat/011, Package
I,npletne11.tatio1i Strategy
H }&rf.rl Strategies 104
svste111- Jl/al11tenance 104
Automated Tools and Technology
JOO
I 07
Co111-p uter-Asslsted Systetns E11gl11eer111g 108
A.ppllcntf.o·n Deve.top 111.ent E11viro111ne11.ts 109
Process and Pro/ea Managers 111
Task 2.5- Update or Refine t/Je Protect
Plan 183
~ ~ ~ ~ -4~ _
PRO
~ J_Ec
_T_MAN
~ _A
_G
_E
_M_E_NT
~_
1_
1a
~~)
lnrrocluctio11
'Jtlsll Z.6-con1:n1-·1111.tcaie Ft1utt11g s and
120
What ls Project Ma11agc.me.nt?
Recotutuendatlons 183
120
The Requirements Analysis Phase
The causes of Failed Profects 121
The Project Ma11agement Body of
K11owledge 123
TI1e Proj«t Ma11agcmem Life Cycle
Task 3. I - Identify and F.xpress System
Requ.lrenumts 185
Task 3.2- Prlorlrize System Requirements I 88
Task 3.3- Update or Refine the Protect
Pla11 188
Task ,3.4- Cot11:»1:uttlcate the Requfre,ne11-ts
Statenumt 189
127
Activity I - Negotiate Scope 130
Activity 2 - Jde11tl{y Tasks 130
Activity 3 - Estlmate Task Du.ratlo11s 132
Activity 4-Sped{v Intertask
Depende11cies 134
Activity 5 - Asstg11 Resources I 36
Activity 6 - 1)(.rect rhe Team Effi;, rt 139
The logical Design Phase
Requlre111.e11ts
140
(alter11attve) 192
Task 4.2- Validate Ftmcrio11al
Requ.lrenumts 192
Task 4.3- Deflne Accepta11ce Jest cases
I 4!)
The Decision Analysis Phase
Systems Analysis Methods 157
SYSTEMS ANALYSIS
Introduction
19 I
Task 4. lb- Prototype Fu.11ctlo11al Requ.tre111enrs
PART TWO
5
189
Task 4. Ja- Struc11,re Fu11ctlo·1U1l
.A.ctlvltv 8 - Assess Project Results and
B..~ptwfotJC'O$
189
011go-t11g Requ.lrenients ,lfanage11w11t
Activity 7- Afonitor and Con.trot
Progress
185
192
Task 5. I - Identify candidate Solutlo11s 194
Task 5.2- Analyze candidate Solutlws 195
Task 5.J- Compare ca,utldate Solutions 197
Task 5.4- Update the Protect Plan 197
'Jask 5,5- Recon1r,1,end a Syst.e,n
Solutto11 I 97
_)
158
192
160
What ls Systems Analysis? 160
Systems Analysis Approad1cs 161
i.lfodetDrlven A11al1:rt.s Approaches 161
Accelerated Systems A11alyslsApproacbes 163
Requ.h'etnents Discovery Afetbods 165
B11Slness Process Redesig n Afetbods
Introduction 208
An Introduction to Requirements Discovery 208
167
The Process of Rcq ttlrcn1c.nts Dlsco,"'t'-ry
Task I. J- Jde11ttfv Basellt1e Problems a1ul
Opportu11ltles I 69
Task 1.2- Negoriate Base/111.eScope 172
Task !.)- Assess Base/111.e Pro/eel
Worthiness I 73
Task J.4- Devetop Baseline Scbe<lu/e a11d
Budget 173
Task 1.5- Cot1it1J.1Jt1-f.cate the
Project Plan I 73
The Problem Analysis Phase
FACT-FINDING TECHNIQUES FOR
REQUIREMENTS DISCOVERY 206
I 66
FAST svstemsA11atvs1s StrateJ!J.es 166
TI1e Scope Definition Phase
6
174
Problen1 Discovery a11d-A11alysis 210
Requ.lretnents Discovery 2 I2
Doa,11,enting a ,ul A 11alvzi1ig
Requ lrettients 2 I2
Requ.lrenwnts ,lfanagenwnt 2 I 4
Fact.FmdingTecbniq ucs
215
Satnplltig of Exisrf.11g Docu1ne1itatfor., FornJS,
a,ul Flies 215
Research a,uf Site Visits 217
Observation of the Work Envlro11nient 2 I8
Task 2. J- U11dersta11d t/Je Problem
Domain 175
Task 2.2- Atiatvze Probletns a,ul
Oppornmltles I 80
Task 2.3- An.atvze B·usfness Processes
210
Qu.esttontmlres 220
lntervle,vs 222
180
Task 2.4- /Jstabllsb Svste,n Jn,prove,ne,it
Objectives I82
Hotv to Co11dua an /11.tervleu.1 224
Dlscouery Prototyping 228
foltU Req11tre1ne11.ts Planttl1,g 22!)
A Fact-Finding SttategJ' 234
xi
7
MODELING SYSTEM REQUIREMENTS
wrrH USE CASES
242
(!
PROCESS MODELING 314
Introduction 316
An Introduction to Process Modeling 316
System Concepts for Process Modeling 319
Introduction 244
An Introduction to Usc-C..se Modeling 244
Systetn Concepts for Use-Case Modeling 246
External Age11.ts 31!)
Data Stores 319
Process Concepts 321
Data Flows 325
UseGaws 246
Actors 247
Refaiio11sbtps 248
The Process of logical Process
Modeling 334
The Process of Rcguirctncnts Use-Case
Modding 251
Strateg ic Systems Plmmi11g 334
Process il·lodellng fo r Business Process
Redesign 334
Process ,lfodeflttg du.rl11g svstetns
At1alysls 335
Looking Ahead to Systems /)(!sign 337
Fact-Ff.11dl1ig and /11/omJ.atr.011 Gatheringfor
Step I: Jde11tifv Busl11essActors 251
Step 2: Jdenttfv B·us/11ess Requ tretnents Use
Gases 252
Step 3: Construct Use-Case Model
Diflgram 254
Step 4: Docu.nient Business Requ.f.retnenrs
Use-Case Narratives 256
.ProC'O$$
Use C..scs and Project Management 260
Jl!odq/Jng
3 37
Co1np11ter-Alded Syste111s Engt11e.erl11g (CASE)
Process Modell11g 337
Ra11kt1Y{ and Evaluaring Use Gases 260
Jdentff l,i11g Use-Case Depe1ule11cies 261
How to Construct Process Models 338
The Context Data Flow Diag ram 338
8
DATA MODELING AND
)
~ ~ ~ ~ -ANA
~_LY_s_1s~ 2_68
~~~~~~~
Introduction 270
What ls Dara Modeling? 270
Svstetn Concepts for Data Modeling 271
E11tltfes 27 I
Attributes 272
Relolio11sbtps 274
The Eveu~Respo11se or Use-Case List 341
Even.t DecortlJ>Osltf.011 Diagrmns 342
Even.t Dlag ratns 34.5
The System Diag ram(s) 347
Primitive Diagrams .H9
Comp leting the Speciflcatfo11
349
Synchronizing of Systctn Models 359
The Process of logical Data Modeling 283
Strategic Data .ilfodel/11.u
rbe Fu.11ctio11al Decotnposition
Diagram 339
283
Data and Process Model
Syncbro11i.zation 359
Process Dlstrtb11t1011 360
Data iWodeltng du.rtng Systetns
Analysts 285
Looking Ahead to Syste,ns Desig n 286
Au.tomated Tools for Data Mode/Ing 286
How to Construct Data Models 288
10
OBJECT-ORIENTED ANALYSIS
AND MODELING USING
THE UML 368
E11tlty Dlscowry 289
The Cot1.text Data Model 290
The Ke1·./Jased Data Model 292
Generalized Hierarchies 295
The Fu.ly Attributed Data Model 295
Analvzing the Data Model 298
Wbat Is a Good Data Model? 298
Dato Analysis 299
Normallzalio1i Iixample 299
Mapping D1ta Requirements to
Locations 306
xii
An Introduction to Objccr.Qricnted
Modeling 370
History of Object Modeling 370
System Concepts for Object Modeling 371
Ob/ ects, Attrlb11tes, Methods, at1d
E11caps11/alio11 371
Cft,sses, Ge11.erafl:Zatlo1i, and
Specialtzat/011 373
Ob/ect/C1ass Relatio,isblps 376
,lfessages and Afessaci Sending 378
Pblymorpblsm 380
for
TI1e UML Diagr:uns 381
TI1e Process of Object Modeling 383
PART THREE
Jlfodell1Jg rbe Functf-011.a l Descrf.p t(on of the
Systems Desi9 n Methods
443
System 383
Co11structi11g the Analysts Use-Case
Model 383
Modeling rbe Use-Case Activf.tles 390
G11lde(t11esfor Co11Structt11g Actf.vlty
Dlt1grams 394
Dratvlng Syste,n Sequence
Diagrams 394
( 12
Introduction 446
What ls SysteblS Design? 446
Systems Design Approaches 446
Model-Drlve11 Approaches 447
Rapid App/icatlot1 Development 451
FAST Systetns Destgn Strategies 453
Gulde(/11.es fo r Co11Structt11g Systetn Sequ.ence
Diagrams 395
fl11ding and Identifvi11.g the B·ust1wss
Objecrs 396
Orgar,lz/.11g the Objects atul ldentifytng 'J'beir
Relat1011ships 400
11
SysteblS Design for In-House nc-'Clop m<nt- The
"Build• Soltnion 453
Task 5. 1- Destgn rhe Application
Arcbltectu,-,, 453
Task 5.2 - Destgn rhe System Database(s) 457
Task 5-3- Destw , rhe Sysrem Interface 457
Task 5 . 4- Package Destg n
Speci.ftcatlo11s 459
Task 5.5- Update the Protect Plan 460
FEASIBILITY ANALYSIS AND THE
SYSTEM PROPOSAL 412
Syst~,s ~ign for Integrating Conuncrcial
Software- The 'Buy• Soltnion 460
Introduction 414
Feasibility Analysis and the Svstcm
Propostl 414
Task 4. I- Research 'J'eclnJ.tcal Crf.terla a11d
Options 462
Task 4.2-Solfclt Proposals or Q11otes from
VendOrs 462
Task 5A. I - Validate Vendor Claims Mui
Perfarma,u:es 465
'Jask 5A2- Evaluate and Rank Venthr
Proposals 465
Task 5A.3- Award (or Lei) Contract and
Debrle/Vetulors 466
Feastbtlitv An.atvsts- A Creept11g Cotntnittn.ent
Approach 414
S1'ste111s A11alvsts- Scope Defl1,ttlo11
Checkpoltll 416
Systetns Analysls- Probletn Atialysts
Checkpolt1t 416
SystenJS Desig n- Decision At,alysis
Checkpoint 416
Six Tests for Feasibility 417
/n1,pact of B1,v Decision 011 Ren1ai11J;ng
Lrfe-Oyde Phases 466
Operational Feastbtlltv 417
c,,tiu.mt (or .PotfttcalJ ltlastbtfllV
417
Teclmtcal Feasthl/f. ty 418
Scbed11le Feaslbllitv 4 18
Economic Feasibtlitv 4 I 9
Legal FeaslblJlty 419
Tbe Bottom Line 419
Cost-Benefit AnalvsisTechnigu~s 419
How M11ch Will rbe Sysrem Cosr? 419
Wbat Bene{lrs Will the System Provide? 420
Is the Proposed System Cos<Effecttvel 422
Feasibility Analysis of Candidate Systems 426
Candi.date Systetns ,llatrf~'< 426
Feaslbtlitv Analysis Matrtx 429
TileSystcn1Proposal 431
Wrf.ffen Report 431
Fortna[ Presentation 433
SYSTEMS DESIGN _44
_ 4_ _ _ _ _ __
~
\.__
PPUCATION ARCHITECTURE AND
MODELING 474
Introduction 476
Application Architecture 476
Physical Data Aow Diagrams 477
Phvslcal Processes 477
Phvslcal Data Flows 481
Physical E.wernalA[l!mts 481
Physical Data Stores 481
Information Technology Architecture 483
Dlstrlbured Systems 484
Data Archltecturos- Distrlbuted Rela.tiot1al
Darahases 494
xiii
Interface Architectu.res- /11pu.ts, ou.pu.ts, and
,lfldtlleware 495
p,.,x:essArc:hltect141'f!s- Tbe So(t1mre
Develop,ne1it E1ivtro1,1nent 500
Application Architecture Strategics for Systc.ms
Design 502
The Enwrprfse APplfcatto·n Arcbltec.ture
Strategy 502
'The Tactical Applicaffo11 Arcbltecture
Strategy 503
C
504
'/lJe Neui'Ork Arcbltect,,re 505
Data [)(strlbut/011 and 'Jechtiotos v
Asslgntnents 506
Process Distrf.bution and Techtiofogv
Asslg11111ents 507
17.Je Person/Alacbi11e Bo·u11.darl.es 510
558
Au.to11Ulted Tools for OUt(!ut Desf.gn a11d
Prototypi11g 558
OU.tfmt l)(!sfg 11 G11irle//1u,s 559
The Ou.fput Desf.gn Process 562
Web-Based OUpu.ts a11d E-Bust11ess 570
(>
Modeling the Application Ardutccturc of an
lnfornution System 503
Drawt11g Physical Data Flow Diagrams
Prereq11fsUes 504
How to Design and Prototype Outputs
INPUT DESIGN AND
PROTOTYPING 580
Introduction 582
Input Design Conccpts and
Guidelines 582
Data captu.re, Data E11.trH atJ.d.Data
Processl11g 582
/11put Aletbods and /111ple111e11tatlon 585
Syste,n User /ss,1.es for Input Desf.g ti 587
/11ten1al Controls- Data Edltf11g for
luputs 589
GUI Controls for Inp ut Design 590
~ ~ ~1_4~ D_AT.
_ AB
~ A_S_
E_
DE_s_1G
_N~ s_1_6~ ~ ~ )
Introduction 518
Conve.ntional Fues ,'<'rsus the Database 518
'/lJe Pros and 0>11s of C.01,ventlont,I Piles 518
'/lJe Pros and 0>11s of Databases 520
Database Concep ts for the Systems Analyst 520
Fields
521
521
Record,
Ft'les a,;d 'Tables
Databases 523
522
Pn:n:qttisitc for Database Dcsign-
Normalization 528
Conventional Fde Design 529
Modem Database Design 529
Goals and Prerequ lsf.tes to Database Desig n 530
'The Database Schema 5 30
Data a,uf Re{ere11tlal hlteg rlf:V 535
Roles 538
Database Distribution and Replicaffo11 538
Database Protor:vpes 539
Database cap actr:v Plmml11g 539
Database Structu.re Ge1ieratio11. 539
1 5 OUTPUT DESIGN AND
PROTOTYPING 548
Introduction 550
Output Design Concepts and Guidelines 550
Distrlbut/011. a1id A1,dte11ce of Outputs 550
l»1plet11e11.tatfo1, ilfethotls for Oup uts 553
xiv
Co1n·1no1i GUI Controls for Inputs
Adva11ced hrp ut Controls 596
592
How to Design and Prototype Inputs 598
Auto11,ated Tools for lt1p ut Desf.gn and
Prototypi11g 598
'The Itip ut l)(!sf.gn Process 599
Web-Based Inputs a11d E-Bust11ess 605
(17
USER INTERFACE DESIGN 612
Introduction 614
l·scr Interface Design Concepts and
Guidelines 614
Types of COttipuier users 614
H11n,a11. Factors 615
H11t1UltJ. Englneerl11.g Gu.ldel/1,es 616
Dialogue 1'0·1,e atid Tenn/1,ofogy 617
l"ser lnterfaccTcdmology 618
operati1ig svste,ns and Web
Bro,1vsers 618
Display Mo111tor 618
Keyboards a11d Pof.nters 619
Graplucal User Interlace Styles and
Considerations 619
Wl11do1vs and Fra1nes 620
ilfetJ.tJ-Drlveti Interfaces 620
/1utructf.01~Drlven /11terfaces 627
Questlo·,~A·nstiier Df.alog·t1es 629
Specia l Co11sitleraffo11s fo r User l11terface
Design 629
How to Design and Prototype a Uset lntetfacc 633
Auto·,nared 'Jools for User /11terface Desig n a11d
Prototypt11g 634
The User Interface Design Process 635
18
OBJECT-ORIENTED DESIGN
AND MODELING USING
THE UML 646
lntroductio11 648
TI1e Ocsig11 of an Object-Oriented System 648
The Construction Phase 684
Task 6.1- Butld and 'Jest Networks
(I/Necessary) 684
Task 6.2- Bt#ld and 'Jest Databases 687
Task 6.~',J- Jnstafl atid Test ,,relv Softtl.We
Packages (I/ Necessary) 687
Task 6.4- Wrlte and Test Neu; Progratns 688
The In1plementation Phase 689
Task 7.1Task 7.2Task 7.3Task 7.4Task 7,5-
Conduct System 'Jest 689
Prepare Conversion Plan 689
lnstal/ Databases 692
1ra111 Users 693
Convert to Nezv Svstetn 694
Entltv Classes 648
interface Classes 648
Control Gasses 649
Persl.stence Classes 649
Syste111 Classes 649
Desig n Relationships 650
Attribute ar1d MetbodVlslbl/ity 650
20
Ob[«t Rqsponslblllth>s 651
TI1c Co11lcJll of Sy:,ctc1u:, O p ctatio1.1 atit.l
TI1e Process of Object Design 651
SYSTEMS OPERATIONS AND
SUPPORT 700
Introduction 702
Suppon 702
Systen1 Maintenance 706
Reft11ing the Use-case Model 651
Jlfodell1Jg aass Interact(o11s, Behaviors,
and States That Support the Use-case
Scenario 656
Updating the Object Model to Reflect the
Jn,_ple1net1-tatlo11 Envtron111e11-t 665
Object Reusability and Design J>.mcms 666
Design Pattetns 668
TheStrategyPattern 669
The Adapter Pattern 670
Ob[ect Fra111et1..'orks a,ul Co1npone11.ts 67 I
Task 8.1. I - Validate the Problem 706
Task 8. l.2- Be11c/Jmark Program 707
Task 8.1.3-Studv ar1d Debu.g the Program 708
Task 8.1.4- Test the Prog ram 709
Systen1 Rccoverv 709
Technical Support 7 IO
System Enhancement 7 JO
Task 8.4.J Request
Task 8.42Task 8.43System
A11alvze Enbance,nen.t
712
Make the Quick Fix 712
Recover Exlst/11g Phvsica/
713
Additional UML Design and In1plcmentation
Diagrams 671
Systen1 Obsolescence 7 I 4
PART FOUR
Photo Credits 720
Beyond Systems Analysis and Design 681
Glossarv/lr1dex 721
19
SYSTEMS CONSTRUCTION AND
IMPLEMENTATION 682
Introduction 684
What ls Systems Construction and
Implementation? 684
xv
Systems Analysis and Design Methods
Part One
The Context of Systems Development Projects
product we will teach you how to
build-information systems. Specifi-
customer or user of those systen1S or
as a developer of those systems. Systems analysis and design is about
business problem solving and computer applications. The methods you
will learn in this book can be applied
to a wide variety of problem de>
mains, not just those involving the
computer.
Before we begin, we assume
you'Ye completed an introductory
course in computer-based information systen1s. Many of you have also
completed one or more programming
courses (using technologies such as
Access, JaM., CIC++, or l.fo,al
Basic). That will prove helpful, since
systems analysis and design precedes
ancllor integrates with those activities.
But don't worry- we'll review all
the neoessary principles on which
book. Try to keep that in mind as you
explore tbe big picture.
Systems development isn•t
magic. There are no secrets for success, no perfect tools, techniques, or
methods. To be sure, there are skills
that can be mastered But the complete and consistent application of
those skills is .still an art
We start in Part One with fundamental concep5, philosophies, and
trends that proTide the context of systems analysis and design methods-in other words, the basics! ff you
understand these basics, you will be
better able to apply, with confidence,
tbe practical tools and techniques you
will learn in Pats Two through Four.
You will also be able to adapt to new
situations and methods.
Four chapters make up this part.
Chapter I, "fbe Context of Systems
Analysis and Design Methods," introduces you to the participants in systems analysis and design with special
emphasis on the. mcxiern systems analyst as tbe facilitator of systems work.
You'll also Jean, about the relation-
s:ys:tem.s: :m.:tly.si..s: :md de.sign i..s: b:ls:ed.
ships between .systems: :i.n:a.lysts:, end
dependent on the principles th:a.t :ue
Part One focuses on tbe big picture. Before you learn about specific
activities, tools, techniques, methcxls,
and technology, you need to understand this big picture. A, you explore
the context of systems analysis and
design, we will introduce many ideas,
tools. and techniques that are not explored in great detail until later in the
users, nunagers, and other information systems professionals. Finally,
you'll learn to prepare yourself for a
career as an an:llyst (if that is your
goal). Regardless, you will understand how you will interact with this
important professional ,
Cbapter 2, "Information System
Building Blocks," introduces the
surveyed. This chapter inlroduoes two
modeling techniques for project management: Gann and PEKl. These tools
help you schedule activities, evaluate
progress, and adjust schedules.
This is a practical book about information systems development methcxls. All businesses and organizations
de,-elop information systems. You can
be assured that you will play some
role in the systems analysis and design for those systems-either as a
cally, you will learn to examine information systems in terms of common
building blocks, KNOWlJIDGB,
PROCESSES, and COMMUNCATIONSeach from the perspecti,-e of different
participants or stakeholders. A visual
matrix framework will help you organize tbese bwlding blocks so that you
can see them applied in the subsequent chapters.
Chapter 3, "Information Systems
Development," introduces a highlevel (meaning general) process for
information systems development.
This is called a systems de1·elopment
life cycle. We will present tbe life cycle in a form in which most of you
will experience it- a sysienJs del·elopment methodology. This methodology will be the context in which you
will learn to use and apply the systems analysis and de.sign methods
taught in tbe remainder of tbe book.
Cbapter 4, "~ect Management,"
introduces project management
techniques. All systems projects are
THE "PU'tERS"
•cw
z
J
0
•a:
..
.."
..
•w
••>
•
THE ~PRODUCT"
z
~
•<.>
..
0
a:
~
•cw
!
•w
•f
•
v
c
•
••
•>
..
..
•
..•
~
z
•c
!
2
•w
0
•w
••>
•
INFORMATION
SYSTEMS
Transaction Processing Systems
Management Information Systems
Decision Support Systems
Executive lnformatlon Systems
Expert Syslems
Communications & Collaboration Systems
Office Automation Systems
~
•>
•
•cw
0
•"
••w
••
•>
TECHNOLOGY
C H A PT E R 1 H OM E PA G E Each chapter in this book begins with a "home page" similar to
the one above. The home page is something of a chapter map, a visual framework for systems thinking
applicable to that chapter. Chapter 1 focuses on (1) the players in the systems game, (2) business drivers
of interest to business players, (3) technology drivers ar,d enablers of interest to the technical players,
and (4) the process used to develop systems. We will also examine the critical role played by systems
analysts in facilitating an understanding of how all four perspectives must come together.
The Context of Systems
Analysis and Design Methods
Chapter Preview and Objectives
This is a book about systems analysis and design as applied to information systems and
computer applications. No matter what your chosen ocoJpation or position in any business, you will likely participate in systems analysis and :lesign. Some of you will become
systems analysts, the key players in systems analysis and design activities. The rest of you
will .,.,.ork with systems analysts as projects come and gc in your organizations. This
chapter introduces you to information systems from fow clifferent perspectives. You will
understand the context for systems analysis and design methods when you can:
I Define information systeni and name seven types of information systen1 applications.
I ld!ntify different types of stakeholders who use or dtvelop information systems, and
give examples of each.
I Define the unique role of systems analysts in the de,-e.Jopmeot of inforn1ation systems.
I ld!ntify those skills needed to successfully function as an information systems analyst.
I De.scribe current business drivers that influence infonnation systems development
I De.scribe current technology drivers that influence information systems development.
I Briefly describe a simple process for developing information systems.
6
Part One
1ho Context of Systems l>owlopmont ProjOffl
It is Bob tttartfnez•s first week at work as an ai1..1lyst/programmer. Fresh out of college
wlth a degree In computer lnfonnatlon systems technology, Bob is eager to work with
information $)'stems In the real world. His employer is SoundStage Entertainment
Club, one of the fastest.growing music and video dubs In America. SoundStage Is Just
beginning systems analysis and design wod< on a reenglneering of thelr member services Information system. Bob has been appointed to the p roject team.
Thls morning was the lickoff meeting for the projec~ a meeting that lnduded the
vice president of member sen-ices, director of the audio d ub, director of the game
dub, director of marketing, diroctor of customer sen-i ces, and director of warehouse
operations. With that Uneup Bob was glad to mainly keep sllent at the meeting and
rely on h.1s boss, Sandra Shepherd, a senior ~·stems analyst. He was amazed at how
well Sandra was able to speak the language of each of the participants and to explain
the plans for the new lnformation system in terms they c ould tmderstand and wJth
benefits they could appreciate. Bob had thought that being Just out of college he
would know more about cutting-edge tedu1ology than most of h.1s co-wotkers.
system a gcup of interrelated components that function together to achieve a
desired result.
But !iaodrn seemed to w1derstmd everytJ:ung about e<0mmerce and ltSJng moblle
tecbnologles plus many things of wh.lch Bob was only '\o-aguely aware. He m1de a
note to read up on ERP systems as that had come up in the discussion. By the end of
the meeting Bob had a new appredatlon for the Job of systems analyst and of all tl1e
things he had yet to leam.
A Framework for Systems Analysis and Design
iaformatioo system (IS)
an arrangeme,t of people,
data, processes, and iitormation technology that interact to collect, process, store,
and provide as output the information needed to support
an organization.
lufo, ...u.adou tttlu.tul~y
(IT) a comemporary term
that describes the combination of computer technology
(hardware anc software) 'Mth
telecommunications technology (data, imaJe, and voice
networks).
t:raasactioo processing
system (TPS) an informationsystem that captures and
processes dat i about business transaciions.
man.agemeot ioforma-
tioo system (!\OS) an information system that provides
for management-oriented reporting basedon transaciion
processing anj operations of
the organization.
As Its tltle sugJ!l'stll, thls ls a book about systems analysts and design methods. In thls
chaptei;. '\\"'e will introduce the subject using a simple bur comprehensive '\oisual framewod<. fach dupter In thls book begins with a home page (see ~
that qulcktJ' and
visually shows whlch aspects of tbe total framewod< we will be discussing In the dupter.
We'll build thls visual framework slowly over the first four chapters to avold overwbeJm.
lng you with too much detaU too early. Toereafte,; ead1 chapter will hlghllght those
aspects of the full framewod< tlut are being taught In greater detail In dut chapter.
Ultimately, tills ls a book about •analy7ing" business requirements for Information
systems and ..deslgili.ng" infort1u1tto11 S):Ste,ns that fulfill those business re<Jltlremenrs.
1n other words, the proaUcr of
syscems ai1.atys1S and <1es1gi11s an lnformauon syscem.
111at product Is visually represented lt1 the visual framewod< as the large rectangle In
the center of the picture.
A system is a group of interrelated components that fw1ctlon together to adtieve
a desired result For lnslance, yoo may own a ltome theater system made up of a DVD
pL1yer, rec eiver, speakers, and display monltor.
Information systems (JS) lt1 organizations capture and ma,,age data to produce
useful. information dur supports ai1 orgail.izatlon and irs employees, customers, s12ppUers, and partners. ,_lany organizations consider lnformation systems to be essential ro
their abillty ro compete or gain competJtt,--e advancage. ~fost org.ul.izations have come
to realize that ail workers need ro participate ln the development of infonnatlon systems. Therefore, Information ~ems development is a reJevanr subject to you rtgardless of whether or nor you are studying to become an lnfonnatlon systems professional.
Information systems come in all shapes and sJzes.111ey are so interwoven lnro the
fabric of the business S)'sterns they support that It is often dlfllcult to dlstingulsh berween business systems and thelr support Information systems. Suffice It to say mat lo.
formation ~ems can be dassUled according to d1e fw1ctlons they serve. Tra.osactioo
processing systems (TPSs) process business transactions such as orders, time
cards, payments, and reservations. Management lnformatloo systems (MIS.) use
the transaction data to produce lnfonnatlon needed by managers to run the business.
Tho Contoxt of Systoms Anolysls and l>osg, Mothods
d,optO< Ono
7
Ded<lou support systems (0555) help ,-arlous decision makers Identify and choose decisioo suppon system
between options or decisions. E.ucuth-e lnfonna tioo SJ,-Stems (E!Ss) are tailored to (DSS) an information system
the wlique information needs of executh,--es who pL1n for the business and asses., per- that either helps to identify
fornunce ag.1lnst those plans. Expert systems capture and reproduce d,e knowledge decision-maJ<inQopportunities
of an expert problem solver or declslon maker and then slmufate the• thlnklug" of that or provktes information to help
make decisions.
expert. Commuo.icatioo and collaboration S)'Steros enhance communlcatlo11 and
colfaboration betweet1 people, both internal and extemal to the organization. Finally,
office automatio11 systeins heJp employees create and share documents that support executiVe i.oformatioo
day-m-day office activities.
system (EIS) an information
As illustrated lo the chapter l1ome page, lnformadon systems can be '\oiewed from system that supe>orts the planni ng and assessment needs
various perspectives, lndudfng:
of executive managers.
Toe
The
Toe
The
players lo the lufonnation system (the "team").
busine.s., drivers influencing the lnformatlon system.
technology drivers used by the Information system.
process used ro develop the lnformatlon S'/stem.
Let's examine each of these perspectives in the remalnlng sections of the chapter.
( The Players-System Stakeholders
let's assume you are lo a position to help build an information system. Who are the
stakeholders lo this >)'Siem? Stakeholders for luformatlon systetns can be broadly cla.ssltled Into the five groups shown on the left~1.10d sire of Figure 1-l. Notice that each
stakeholder group has a dlfferei1t perspective of the s,me information system. The sy..
tems analyst is a unique stakel1older In Rgure 1-1. Toe >)'Siems analyst serves as a facilitator or coad1, bridging tJ,e communlcatlons gap that can naturally de.-elop bem-eeo the
11ontechnical ~tern owners and users and the tedmlcal system designers and builders.
All the above stakeholders have one thing In common- they are wt1..1t the U.S.
Department of Labor calls lnfonn.~tlou workers. Toe u,-.Uboods of Information
wod:ers depend 011 decisions made based on information. Today, more than 60 percent
of the U.S. labor force is involved h1 producing, dlstrlbuth1g, and ush1g Information.
Let's ex.amine the five groups of lnfonnation workers In greater detail.
let's briefly examloe the perspecth'es of each group. But before we do so, we
shotid point out tl1.1t these groups actually define "roles" pfayed lo systems de.-elopment In practice, any indJvJdual person may play more than one of these roles. For example, a system owner might also be a system user. SlmlLirly, a systems analyst may
expen S}'Stem an informa.
tion system that captures the
expertise of workers and then
simulates that e:cpertise to the
benefit of nonexperts.
commuoications aod
collabotatioo system an
information sysem that enables more etfec.tive communications between workers,
partners, customers, and suppliers to enhanc» their ability
to collaborate.
also be 2 system des:lgne,, 2nd a s:ys:tem designer might also be 2 system builder. 1\.ny
ufftl.t au1ouloldot1 ~y:,1eu1
combination may work.
an information system that
supports the wide range of
business office aciivities that
provide for improved work flow
between workers.
>
Systems Owners
For any lnformation $)'stem, large or small, there will be one or more system owners.
System owners usually come from the ranks of management For medJum to L1rge inforrmtlon systems, $)'stem owners are usually mklJJe or executh,--e managers. For
sm.1lier systems, system owners may be middle managers or supervisors. System owners tend to be Interested In the bottom line-how much will the system cost.? How
much '\o-a.lue or what benefits will the system return 10 the bush1ess?Value and benefits cin be measured In different ways, as noted h1 the margin checkllst.
>
Systems Users
System user,; make up the vast majority of the information worl<ers lo any h1formatioo
system. Unlike system owners, ~tern users tend to be Jes, concerned with costs and
bet1alts of the system. Instead, as Ulustrated lo Figure 1-1, they are concemed with
tl,e functionality tJ,e system pro,ides to their Jobs and the system's ease of leamlng
and ease of use. Although users l1..1ve become more tEdmolog)'-literate o,--er the years,
stakeholder any person
who has an inte·est in an existing or proposed information
system. Stakeholders may in.
elude both technical and nontechnical workers. They may
also include botil internal and
external workers.
i.aformatioo "'·orker any
person whose job involves
creating, collectng, processing, distributing, and using
information.
8
1ho Context of Systems l>owlopmont ProjOffl
Part One
••
"Pl A.YE.RS•
-
THE "PRODUCT• -
•
••
'HE PAUCEW'
AN IN~OAMA.110 N SYSTEM
-
~
~
ffi
•
z
•
) System owners pay for the aystem to bf built and o perated end eel
0
2
v
w
~
~
~
.."
>
~
-
"•z •
2
..,
~
...
0
"
~
~
•'
~
~
~
>
~
•z
•
~
..
2
~
~
>
~
SYSTEM OWNEAS' VIEW OF THE It-FORMATION SYSTEM
the vision and priorities forthe aystem. He,ce, they v iew an
information system in terms of ooeta and benefits to solve problems
and exploit opportunities,
'
~
~
"
Ill
~
•
I!!
~
>
~
•
SYSTEM USEAS' VlEW OFTHE INFORMATION SYSTEM
•
) S'f*tem user s define the business requi1ements and e,q>ectations
V
tortne s)ISlem. Hence, tneyv tgW an 1morrnat1on 8)1,!,t&m In ter~
or
•
the functionality provided to their jobs, e&Ee<>f.Jearning, or ease~·
use,
-
~
~
ffi
z
!2
~
w
Q
2
I!!
~
•
SYSTEM OESIGNEAS' VIEW OF THE N FORMATION SYSlEM
••
) S'f*tem d eeig n er s translate the business requirementa into a
•
>
~
z
fea.sible technical solution. Hence, they v iew an information ey.,.tem
in terms of a design blueprint to guide the construction of the final
eystem.
-
•
~
~
"l!I
...
~
m
2
w
--
•
SYSTEM BUILOEAS' VIEW OF THE INFORMATION SYSTEM
) System builder• oorutruct, deploy, end maintain the information
V eysf.em, Hence, they tend to view en information system in terms of
~
>
the actual working hardware and aoftwareto implement the evstem,
•
~
-
TE Ct
•
•• s
F I GU R E 1 • 1 Stakeho lders' Perspective of an Information System
system owoer an inforrna.
tion syswm's sponsor and
executive advocate, usually
responsible for funding the
project of developing, operat·
ing, and maintaining the
information sy31em.
their primary concent is to get the job don e. Consequently, discussions with most
users need to be kept at tl1e busloess requirements level as opposed to tl1e technical
requirements level. Much of tllls book Is dedicated to teaching you how to effectively
identify and communicate business requirements for an lnfonnatlon system.
There are many classes of SJ'stem users. Each class should be directly it1vol,--ed in
any Information system developmetll project that affects them. Let's briefly examine
these classes.
Tho Contoxt of Systoms Anolysls and l>osg, Mothods
lntetnal System Users Internal system users are employees of the businesses for
wtlich most information systems are built. Internal users make up the largest per-
cent1ge of information $)'stem users In most businesses. Examples lndude:
Clerical a1ul servf.ce toorkers- perfonn most of the day-to-day transaction
processfr1g lo the average business. They process orders, lnvoJces, payments,
and the like. They type and fife correspondence. They fill orders In the
warehouse. And they manufacture goods on the shop floor. ltfost of the
fundamental data In any business ls captured or created by these workers,
many of whom perform manual labor In addition to processing data. Information systems tl1at target these workers tend to focus on transactJon processing speed and accuracy.
Teclmtcal a11d professto11a/ staff- consists largely of business and lndustrL1I
specL1llsts who perform highly skilled and spedalized work. Examples
Include lawyers, accotllltants, engineers, scientists, market analysts, advertlsh1g
designers, and statistidans. Because thelr work ls based on well-defined bodies of knowledge, they are sometimes called knowledge workers. lnform.1tlon systems that target technlcal and professional staff focus on data analysis
as well as e:eneratine: timeJy Information for problem soJvine:.
s,,pervisors, tntMle ni.anagers, and e.wcu.tlve ,nan.agers- are the dedslon
makers. supervisors tend to focus on day40-0ay problem soMng and decision
mal'ing. '-'Odd.le managers are more concen1ed with tactical (sl1ort-tenn) operational problems and decision maklng. Exec,,1th·e managers are concerned
with strategic (long4erm) planning and decision making. Information systems
for managers tend to focus enti.reJy on h1fonnatlon acces.,. '-'tanagers need the
right Information at the right time to lde11tlfy and solve problems and make
good decisions.
External System Users The Internet has allowed t:rad1tio11al information system
boundaries to be extended to include other businesses or direct consumers as system users. These exten1al system users make up an increasingly L1rge percentage of
system users for modern lnfonnation systems. Examples lnclude:
C1-t.sto111ers-any org.ul.izatlons or h1dl:viduals tl1,1t purchase our products and
senices. Today, our nistomers can become direct users of our information
~·stems when they can cllrecdy exec,,ne orders and sales transactions that
u.sed to require Intervention by an internal user. For example, lf you
purchased a company·s product vta the lntemec, you became an excemaJ
u.ser of that business's sales Information ~tern. (01ere was no need for a
separate h1ternal user of the business to Input your order.)
Suppliers-any orpnlzatlons from wblcb our ccmpany may purchase supplies
and raw materials. Today, these suppUers can Interact directly with onr com.
pany•s lnfonnatlon ~ems to detennlne our supply needs and automatically
create orders to fill those needs.111ere ls 110 Jo~er always a need for an lntero.al user to lnltiate those orders to a supplier.
Partners-any organizations from which our company purchases senices or
with which It partners. ~tost modern businesses contract or outsource a number of basic services such as grow1ds maintenance, network m:uugement, and
many others. And businesses h.a,--e learned to partner with other businesses to
more qulckly le,-ernge strengths to build better products more 12pldly.
e»iploJiees- those employees who work on tl1e road or who work from
home. For example, sales representatives usualtl spend much of tl1eir time on
the road. Also, m:uiy bush1es.,es permit workers to telecommute (meail.i.ng
"work from home") to reduce costs and impro•1e productivity. As mobile or
remote users, t11e.se employees require access t,) the same information systems as those needed by Internal users.
d,optO< Ono
9
POSSIBLE VALUES
AND BENEFITS OF
INFORMATION
SYSTEMS
Increased Business Profil
Reduced Busness Cosls
Cosls and Benefits of lhe
System
Increased Ma'kel Share
Improved Customer
Relations
Increased Effi,: iency
Improved Decision Ml.king
Better Complence with
Regulations
FeYre1 Mi~lake:s
Improved Serurity
Greater Capacity
system user a "customer'
who will use or is affected by
an information system on a
regular basis--capturing, vali.
dating, entering. responding
to, storing, and exchanging
data and information.
knowledge '\\l>tker any
worker 'M'lose 11sponsibilities
are based on a specialized
body of knowlec·ge.
10
Part ono
remote user a user 'M"lO is
not physically bcatscl on the
premises but vh:, S1il IrequirElS
access to inbnnation systems.
1ho Contoxt of Systoms l>ovolopmont ProjOffl
External system users are Increasingly referred to as remote tisers and mobile
users. T hey connect to our Information systems through laptop computers, h.andheld
computers, and smart phooes- efther wired or wireless. Designing lnfonnatlon systems for these devices presents some of the most contemporary of challenges tlur we
wlU address In this book.
m obile user a user 'M'lose
location is constantly chang.
ing but who re=1uires access to
information sy31ems from any
location.
system designer a techni.
cal specialist Vlo translates
system users'business requirements an:t constraints
into technical solutions. She or
he designs the computer
>
System d esig n ers are technology specL1lists for Information systems. As Figwe t -1
shows, system designers are Interested In lnformatlon technology d10Jces and In tl1e
design of systems that use chosen technologies. Today's system designers tend to fo.
alS on tedulical special ties. Some of you may be educath1g yourselves ro speclalize in
one of these tedulical specL1ltJes, such as:
Database ad,n-11,~rrators- spedalists lo database tedu1ologjes who desJgn
and coordht.1re dt.1nges to corporate databases.
1\ retwork architects- spechlists it1 networking and telecommunlcatJons rechnologles who design, Install, configure, optlmlze, and support local and wide
databases, inputs, outputs,
screens. net\Wrks, and soft.
ware that will meet the system
users' requirements.
area netwo tks, lnclu dlng connectio ns to the lnten1et and other extern:U
networks.
Web arcbf.tects- spedalists wt10 desJgn compJex Web sJtes for organlz.atlons,
lndudlng public Web sites for the lntemet, Internal Web sites for organlzatlons
(called l11tranets), an d private business-to-business Web sites (called e.m-auets).
Grapbr.c artl<ts- relatlvely new In today's IT wod<er mbc, specialists In grap hics technology and methods used to design and construct compelling and
easy-to-tlSe interfaces to systems, including interfaces for PCs, the \X'eb, h.andheJds, and smart phones.
Secu.rf.ty <!Xj>erts- specialists In tl1e technology and methods used to ensure
data and network security (a nd pri>-:tcy).
'/llclmo/ogy specia/fsts- expe,:ts In the application of specific tedUlologles
that will be used In a system (e .g., a specUk commercial software package or
a specUk type of hardware).
>
system builder a technical
specialist whoconstructs information syst~ms and components based on the design
specifications ;1enerated by
the system de.signers.
Systems Designers
Systems Builders
Syst e m b uilders (ag.1ln, see Flgiire 1-1) are another category of tedmology sped allsts
for frlformatJon ~ems. Their role is ro constrlK.1 the ~em accordtn,a to the system
designers• spedflcarions. In sm.1ll orgailizatJoos or wlth small Information systems,
systems designers an d systems builders are often the same people. But In large org.1nlzations and Information systems tl,ey are often separate Jobs. Some of you may be educating yourseh·es to spedaUze in one of d1elr technical speclaltles, such as:
Appllcaff.01,s progratunien- speclallsts who convert busit1es., requ.lrements
and staremenrs of problems an d procedures Into computer langt.tages. They
develop and rest comp uter programs to capture and srore data and to locate
and retrieve dara for computer applications.
S):Sfetns progran1111ers- spedaUsts who develop, rest, an d implement operating
systems-level software, tttllit!es, and services. Increasingly, they also develop
reusable software "components• for use by appUcatlons prognmmers (above).
Database programmer.s- spedallsts in database languages and technology
wt10 build, modify, and test database structures and the programs th.at use
and maintain them.
1\tetwork adtnitJ:f.strators-speclallsts wt10 desJgn, Install, troubleshoot, aod
optimize computer networks.
Secu.rlty ad111.l11istmtors-spedalists who design, irupJemenr, troublesho«,
and manage security and prh--acy controls In a network.
Tho Contoxt of Systoms Anolysls and l>osg, Mothods
Choptw Ono
11
Webniasters- spedalists who code and maintain Web servers.
Software Integrators- specialists who Integrate software packages with hardware, networks, and other software packages.
Although thJs book Is not directly intended to e<l1cate the system b1ulder, it Is h,
tended ro teach ~tern designers how to better communicate design specl.tlcatlons to
systffll builders.
>
Systems Analysts
As you have seen, system owners, users, de.signers, and builders often have ,1-ef)' dJf.
ferent perspectives on any information ~·stem to be built and used. Some are interested lo generalities, wbUe others focus on details. Some are nontechnical, while
others are very technlcal.11lls presents a commwlications gap that h..,s always existed
bet\,,.een tl1ose who need computer-based business solutions and those wl10 understand lnformatio11 technology. The S)'Stems a.oalys1 bridges that gap. You can (and
probobly will) play a role as eltl1er a systems analyst or someone who works witl1 sys.
tem.s ai1.alysts.
.As IUu.sb'ared In Figure l t, their r o le lnrention..,lly overl'lJ)6 the roles of all the
other stakeholders. For the ~·stem owners and users, systems analysts ldentlfy and '\o-:tlidate busines., problems and needs. For the ~·stem desJgners and bu.llders, systems analysts ensure that the technical solution fulfllls the business needs and integrate the
tedll'Ucal solution Into the business. In other words, ~tem.s analystsfacfJttate the development of Information systems tlvough interactla.1 with the other stakeholders.
There are several Jegftlmate, but often confusing, variations on the Job tide we are
calliqi"systffllS :uulyst.• Aprogrammer/miaf)<t(or analyst/programmer) includes the
responsibilities of both the computer programmer and the systems analyst. A bust11ess
analyst focuses on only the nontechnlcal aspects of systems analysis and design. Other
synonyms for "~terns analyst• are systems consultant, business ai1..1lyst, systems architect,,,ystems engineer, information engineer, infonnatlo11 aiulyst:, and systems lncegrator.
Some of you will become ~·stems analysts. TI1e rest of you wUJ rotrtlnely work
with systems analysts wl10 wlll help you solve your business ai1d industrial problems
by cteatlng and improving your access to the data ai1d infonnation needed to do your
job. Let's take a closer look at systems a,1alysts as the key facilitators of information
systems development.
The ~ole of the Systems Analyst Systems anal)•Sls understand both business and
computing. They scudy bustnes., problems ai1d oppomul.ltles and men uansfonn busInes., and information requirements lnto sped.flcatioos for information systems t11..1t
will be Implemented by various tecbnlcal specialists including computer program.
mers. Computers and lnformatlon ~·stems are of value to a business only lf they help
solve problems or effect impro,--ements.
Systems analysts initiate change wlthiJ.1 an organJzatlo11. E,--ery new ~tern
dtanges the bush,ess. Increasingly, the very best systems a,1alysts literally change thelr
organlzatlons- pro"idfng information tl1..1t can be used for competitive advantage,
finding new markets and services, and even dramaticilly changing :u1d improving the
way the org.ul.izatlon does busine.s.,.
Toe systems analyst is basically a problem solver.1llroughout this book, the term
problem wUI be used to describe many situations, Including:
Problems, either real or anticipated, thac require corrective action.
Opportunltles to improve a situation desplte the absence of compL1ints.
Dlrectlves to d1..1nge a sltuatio11 regardless of whether anyone has compL1it1ed
about t11e current slcuatlo11.
Toe systems analyst's job presents a fusck1ath1g and exciting dtallenge to many
individuals. It offers high management vlsibillty and opportunlties for Important
systems ao.3-'!•st a special·
ist who studies he problems
and needs of an organization
to determine haN people,
aata, processes. ana 1morma.
tion technology :an best
accomplish improvements
for the business
12
Tho contoxt of Systoms Dovolopmont ProJo<ts
Part Ono
Executiw
Management
Finarcial
Management
0
.....
Finerce
A«<lurtilg
Human
REISC>urces
0
--
Errp¥*1t
..,,_,
eonpwae,
Empie,Bon.to
NOTE: TN, ,guna d,:,mohSfJllhO howvdl ( N)f~n;iki~nC$ n4*t in lhi;i
ti th;,
ligl,1'$. lhi;i n..rnbond b.11111, f'Rf toin.
rdlinanOM lhOI •pi.in llllil bJIIQt
O
Operations
0
"*'
"*'
Resear::h &
Dewlopnent
0
ln..n10,y
......
Contol
i:.oon:h
"°""""
Coftfol
'rodu<t
........
Oi•bJlicn
Information
Services
-· -·
-· -· -..
..1J.,,...
........
··,,_ ..j.,,...
,,_
..1A.,,...
i:;~
f)
E'9n,,ri119
f)
hclue:lriol
E'9n,,ri119
,,_
c,p..ion,
Pu~Oling
--
o,..""'9111a1
o~
.,....~
Dapsan,11111
Compulrl
o}S
..,.....
...,..
....,...
c....o-
&r\10$
""--"&
f)
ANNn:h&
Dapstm,11111
CompUfflg
-
",...,...
1J
o..11111..11a1
Qimp......
o~
.,...~
....,..
( F I GU R E l • 2 Systems Analysts in a Typical Organization
,,_
1A
...,,...
u - tignod
°""81ope,.
1A
O...opmert
f)
.,,...
0
)
decision making and creativity that may affect an entire orga11Ji.atlon. Furthermore,
this Job can offer these beneflls relatively early In your career (compared to other
enrry-le1i--el Jobs and careerS).
Where Do Systems Analysts Work? Every business organlzes itself wllquely. But
certain patterns of organlzatlou seem to reoccur. Figure 1-2 is a representative organJzatlon chart. The following Oltmbered bullets cross-reference and emphasize key
points In the figure:
O
0
O
System owners and system users are located lo d1e functional units and subun.l:ts of the business, as well as ln the executive management
System designers and builders are usually located in the Information systems
un.l:t of the buslness. l\ilost systems analysts work also for the h1fonnatlo11 services tmlt of ait organlzatio11.
As sbown In the figure, si.rerns analysts (along with systems designers and
b,tllders) may be permanently assigned to a team that supports a speclfl<:
business function (e.g., flnmdal systems).
Numbers 2 and 3 above represent a tradltlonal approach to organlzlog sy!tems
analysts and other developers. Numbers 4 and 5 below represent strategies Intended
to emphasize elther efficiency or business expertise. AU of the strategies can be
combin ed in a single organization.
The Next Generation:
Career Prospects for Systems Analysts
/1/v:Jny of you are considering or preparing for a career as
a ,ys...,,, analyst. The Iii,, of a ,y,tem, analyst i, both chcllenging and rewarding. But what are the pro,pem far the
fvturo? Do organization, need ,y,tem, analyst,? Will they
need them in the fare...able future? I• the job changirg
for tie future, and if so, how? These questions a re
add .....d in thi, box.
According ta the U.S. Department of Labor, compul<r·
related jab, account far 5 out of the 20 fa,test-growirg
occupations in the economy. What's more, the$9 faste!f·
growing computer-related occupation, pay better than
many other job,.
In 2002, <168,000 worker, were da.. ified a• ,ystem,
analyst,. 2012, that number will grow to 653,000, an
increo,e a 39%. Thi, mean• that at lea,t 185,000 new
,y,tem• analy,ts mu,t be educated and hired (not including those needed to replaai the ones who retire or move
sr
into managerial positions or other occupations). 1he need
is increasing because industry needs systems analysts 10
meet the ,eemingly endl.., demand far more information
systems and software applications. As some programmirg
job, are being out-,ourced to independent contractors ard
othercountri.., the need grow, 9""n greater for ,killed ,y,lem• analy,i., who can create ,olid de,ign ,pecification,
for rtmote development teams. Opportunities for suca»s
will be the greate,t for the most educated, qualified, ,killed,
and oxperienced analyst,.
\',1,at happen• to the ,ucces,ful ,ystem, analy,t?
a position as a systems analyst lead to any other career$J
Indeed, there are many career path,. Some analysb leave
the information systems field and join the user community.
Their experience with developing busine$S applications,
combined with their total sysh~m$ perspective, can make
expeienced analy$1$ unique bu$ines$ $pecialist$. A~ernativelr. analy$1$ oon becane project managers, information
$Y$h~m$ manager$, or technical $peciali$t$ (for databases,
telecanmunications, microcomputer$, and $0 forth). FinalV,
,killed ,y,tem,analysbareoften recruaed bytheconw~irg
o,,..
O
0
z
CD
x
G)
and oubourcing indu$lries. The career
path opportunitie$ are virtually limitle$S.
---+
A$ with any profe$sion, $Y5h~m$ analyst, can expect change. While it i• alway$ dangerou$ to predict changes,
we'll toke a ,hot at it. We believe that
organizations will become increasingly
dependent on external sources for their
:::J
$ysh~m$ analyst$---<:On$ultanb and out•ourcers. Thi, will be driven by ,uch fac--;
tors a, the complexity and rapid change
of 19chnology, the de,ire to accelerate
,y,tem• development, and the continued
difficulty in recruiting, retaining, and retraining ,killed ,ystern, analy,i. (and
other information technology profe$·
:::J
$ional$) . In many ca$9S, internally em(/)
ployed •Y•tem• analy,1, will manage
projects th rough consulting or oubourcing
agreements.
We believe that an increasing percentage of tomorrow'$ sy$tems analyst$
will not work in the information $Y$·
lem• department. ln,19ad, they will work
directly for a busine$S unit within an organization. This
will enable them to better ,erve their u,en. I will al,o
give user$ more power over what $y$lem$ arE-built and
,upported.
Finally, we also believe that a greater percentoge of
,ystem• analyst, will come from noncomputing background$. At one ti me mo$ t ana ly$t$ were can~uter s,peciali, b. Today, computer gradua'96 are beconing more
bu$inC:ll$$·1iterate. Similarly, todays bu$ineu and noncomputing graduate, are becoming more computer-li'9rale.
Their full-time help and in,ightwill be needed to meet demand and to provide the bu,in.., badcground nece..ary
far tomorrow'• more complex applications.
CD
CD
0
0
Systems analysts (along with system designers ,nd builders) may also be
pooled and cemporarlly assigned to specific projects for any business
ltmctlon as needed. (Some organlzatlons beUeve this approach yields greater
efficiency because analysts and other developers are always assigned to the
hlghest-priority projects regardless of business area expertise.)
Some systems analysts may work for smaller, departmental computing organizations that support and report to their own specific business functions.
(Some org.ul.izatlons believe this structure results in systems analysts that
deveJop greater expertise In their assigned business area ro complement their
1edmlcal expertise.)
All of the above strategies can, of course, be reflected within a single org.ul.ization.
13
14
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
Regaroless of where systems analysts are assigned within the orga11lzation, it ls Jm.
ponant to realize that they come together in project tea-,ns. Project teams are usually
created and disbanded as projects come and go. Project teams must also indude appropriate representation from the other stakeholders tl1at we previously discussed
(system owners, system users, system designers, a11d system builders). Accordingly,
we will emphasize team building and teamwork tbrougl1out this book.
Skills Needed by the Systems Analyst For those of you with asplntions of becoming a systems ai1..1lyst, this !ectlon describes the skills you will need to de,-etop.
11lls book introduces many systems analysis and design concepts, roots, and techniques. Bur you will also need !kills and experJences thar neither this book nor your
systems analysis and design course can fully pro,ide.
When all else falls, the systems analyst who remembers the basic concepts and
pri11clples of • systems thlnkln@• will still succeed. No tool, teclmlque, process, or
meti1odology ls perfect in all situations! But concepts and pri11dples of systems tlllnki11g will always help you adapt to new and dlfferetll situations. This book emph,sizes
systems thinking.
Not too long ago, it was tl1ought that the systems aiul)'st's only reaJ roots were paper, pend.I, and a flowchart template. Over the years, several tools and teduliques
ha>-. been developed to help the systems analyst. Unfortunately, mall)' books emphasize a speclflc class of tools that ls assoc.L1ted with one methodology or approach to
systems analysis and design. In this book, we propose a• roolbox' approach to systems
analysis and design. As you read this book, your toolbox will grow to include mmy
tools from different methodologies Md approaches to systems analysis and design.
Subsequently, you shot~d pick and use tools based on the mall)' different slmatlons
you wUl encowller as an analyst- the right tool for the right Job!
In addition to having fonnal systems analysis and design skills, a systems analyst
must develop or possess other skills, knowledge, and tnlts to complete the Job. These
include:
Workl11g knowledge of injor111atlon teclniologf.es- The analyst must be
aware of both exlstlng and emerging information technologies. Such knowl-
edge can be acquired ht college courses, prof~Jonal development seminars
and courses, and in-house corporate tralnlng programs. Practlclng analysts
also stay current through disciplined reading and participation in appropriate
profe~Jonal societies. (fo get started, see the Suggested Readings at the end
of this and subsequent chapters.)
co·,npurer progran11ntng fXpertence a,uf experttse- lt lS dlfficuJc to tmaglne
how systems analysts could adequately prepare bush,ess and technical speclfi.
cations for a programmer if they didn't have some programmh1g experience.
,_lost ~tem.s analysts need to be proficient in one or more high-level programming languages.
General Jn1-0t1J!edge of b ·u.st11ess processes and temttnology- Systems antlysts
must be able ro communicate wfth bush1ess experts ro gain an understanding
of their problems and needs. For the analyst, at least some of this knowledge
comes only by way of experience. At ti,e same tlme, aspiring analysts should
avail themselves of every opportunity to complete basic bush1ess Uteracy
courses a"-allable h1 colleges of business. ReJeYanr courses may include fin..10dal accow1ting, management or cosr accotmtlng, finance, marketing, man.
ufacrurh1g or operations nunagemenr, quality maiu.gement, economJcs, and
business law.
General problem-solving si,lll<- The systems analyst must be able to take a
large business problem, break down ti1at problem into its parts, determine
problem causes and effects, and then recommend a solution. A11..1lysts must
avoid the tendency to suggest the solution before analyzing the problem.
For aspiring analysts, many colleges offer philosophy courses that teach
Tho Contoxt of Systoms Anolysls and l>osg, Mothods
Choptor Ono
FIGURE l ·3
U., I
The Systems
Analyst as a
Facilitator
..,,,
• •
•
•
A.ppli~tioll.l
pro,t11m111.,.
U.wN
problem-solving skills, critical thhlklng, and reasoning. These •soft skills• will
serve an analyst well.
Good (;nterperso11.al co1u1nu.nicatio11. skills- An analyst must be able to communicate effectively, both orally and ln wrJting. Almost wjd1out exception,
your communJcatlons skills, not your technJcal skills, wlU pro,-e to be the.
single biggest factor Jtt your career success or failure. These skills are learnable, but most of us mllst force ourselves to seek help and work hard to
bnprove them. ~lost schools offer courses such as busfr1ess and techn1cal
wcitlng, business and technJcal speakh1g, lnteniewfr1g, and listening- all useful skills for the ,ystems analyst. These skills are taught In a,apter 6.
Good l11..terperso11.al tr1/atio1JS skills- As Illustrated in Figure 1-3, systems
analysts lnteract with all stakehoJders in a systems development project.
These interactions require effective interpersonal skills that enable the aiialysc to deal with group d)•nanucs, buslness pollttcs, conflJct, and change.
blai1y schools offer valuable lnterpersonal-skllls development courses on
subjects sud1 as teamwork, principles of persuasion, managing change and
confllct, and leadershlp.
flexlbi/1.ty and adaptabl/1.ty- No two projects are alike. Accordh1gly, there Is
oo single, magical approad1 or standard that is equally applicable to a ll pro}
ects. Successful systems analysts lean1 to be flexible and to adapt co unique
challenges and sltuatlons. Our aforen1entioned toolbox approad1 is lncended
10 encour.tge llexibillry In the use of systems analysis and design tools and
methods. But you must develop an attitude of adaptability to properly use
any box of tools.
Character a-nd ethics- The natltre of the systems analyst's job requires a
strong character and a sense of rlghc and wrong. Analysts often gain access
to sensitive or co1lfldeotlal facts and lnfonnatlon rhac are nor meant for
public disclosure. Also, the products of systems analysis and design are usu,Uy considered the Intellectual property of the employer. 1l1ere are several
standards for con1puter ethJcs. One sud1 standard, from the Compucer
Ethlcs hlStltute, ls called ..The Ten Commandments of Computer Etll.ics" and
Is shown In Figure 1-4.
IS
16
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
F IG U R E 1 • 4
Ethics for Systems Analysts
'
The Ten Commandments of Computer Ethics
1. Thou shalt nol use a oompulor lo harm other people.
2. Thou shalt nol interfure with other people's oompul<>r work.
3. Thou shalt nol snoop around in other people's oompul<>r files.
4. Thou shalt nol use a oompulor lo sl9al.
5. Thou shalt nol use a computar k> bear false witness.
6. Thou shalt nol copy or use proprierory software for which you hove not paid.
7. Thou shalt nol use other p«l)le's computer resources without authorization or proper
compensation.
8. Thou shalt nol appropriate other people's intellectual output.
9. Thou shalt think about the social consequence, of the program you are wri~ng or he
sys-tern yoo are designing.
10. Thou shalt alway, use a oompul<>r in ways that inwre consideration and , ..poet fer
your r..llow humans.
>
External Service Providers
exteroal service
provider (ESP) a syS1Sms
111ose of you with some computing experlence m.1)' be wondering where consultants
analyst, system designer, or
system builde1 who sells his
or her expertise and experi.
ence to other businesses to
help those businesses pur.
chase, develop, or integrate
their information syS1ems
solutions; may be affiliated
'Mth a consulting or services
organization.
framework. But they are there! Any of our stakeholder roles may be filled by Internal
flt ln our taxonomy of staL::el10Jders.1l1ey are not Immediately apparent in our Tt.sual
or extenul workers. Consultants are one example of an extenul service provider
(F.SP). tttost ESPs are systems analysts, desJgners, or builders who are contracted to
bring specL1I expertise or exp,rlence to a specific project. Examples lndude technol<>g)' engineers, sales engh1eers, systems consultants, contract programmers, and
systems integrators.
>
pf'Oject m .:io:iger an oxpo
rienced professional who
accepts respo1sibilityfor
planning, monitoring, and
cootrolling projac.ts with respect
to schedule, bJdget, deliver.
ables, customer satisfaction,
technical standards, and
system quality
The Project Manager
We">.. Introduced most of the key players In modem hlfonmtlon ")'stems developmentsystems owners, users, desJgi1ers, builders, and analysts. We should conclude by
emphasJzing the reality that these lndtvJduals must work together as a team to successfttlly build h1formatlon systems and applications that will benefit the bush1ess.
Teams require leadership. For this reason, usuall)• one or more of these stakeholders
takes on the role of project m.ao...'lger to ensure tl1at systems are deveJoped on time,
within budget, and with acceptable quality. As Figure 1-1 Indicates, most project
managers are experienced systems analysts. But in some organizations, project managers are seJected from tl1e railks of what we ha,-e called "system owners." Regard.Jes.,,
most orgartizatlons have learned that project management ls a specL1lized role that
requires distinctive skills and experJence.
Business Drivers for Today's Information Systems
Another way to look at our h1formatlon system product Is from the perspecth.. of busi-
ness drtvers. Using Rgure 1-5, let's now briefly examine the most lmportant business
tre11ds that are Impacting Information systems. Many tre11ds quickly become fads, but
here are some business trends we believe wUJ influence systems de,--elopment In the
Tho Contoxt of Systoms Anolysls and l>osg, Mothods
THE
TfC H
L
OAIVEAS
F I G U R E 1 • S Business Drivers for an Information System
comJng years. ,_lany of d1ese trends are reL1red and integrated such t11..1r they fonn a new
business philosophy that will Impact d,e way everyone works In the comlng years.
> Globalization of the Economy
Sh1ce tl,e 1990s, there has been a slgnJJlcant trend of economic globaUzatlon. Competltlon ls globa~ wlth emerging h1dustrial nations offering lower-cost or hlgher.quallry
Choptor Ono
17
18
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
alternatives to many products. American businesses find themselves wJth new inter11ational competitors. On the other hand, many American businesses have discovered new and expanded international mad.:ets for their own goods and ser,·Jces.
111e bonom Une is that most businesses were forced to reorganize to operate In tllis
global economy.
How does economic globaUzatlon affect the players In the systems game? first,
informatJon systems and computer applications must be Internationalized. They
must support multiple languages, currency exchange rates, lnten1atlonal trade regulations, and different business cultures and practices. Second, most informitJon
systems ultimately require lnformatJon consolidation for performance analysis and
declsJon making. The aforementioned langtiage barriers, currency exchange rates,
transborder Information regulatlo11s, and the UL::e, complicate such co11solidation.
Finally, there exists a demand for pL1yers who can commwlicate, orally and in writing, wlth management and users tl1.1t speak different languages, dialects, and slang.
Opportunities for International employment of systems analysts should continue to
expand.
>
electtooic rommerce
(e-commerce) the buying
and selling of goods and
seNice.s by using the Internet.
electtooic business
(e-busit1ess) the use of the
Internet to conduct and sup.
port day-to-da'j business
aciivities.
Ele<tronic Commerce and Business
In part due to the globaliz.atlon of the economy, and ln part beclltSe of the pervash"eness
of the lnteme~ businesses are clunglng or expanding their business model to lmplanent
eJectro11ic commerce (e«>mnerce) and electronic b,1sloe.ss (e-busiaess). 111e
Internet Is fundamentally dia~lng the rules by whlch business is conducted. We
U,-e in a world where consumers and bush1esses wUJ Increasingly expect to conduct
commerce (bush1ess transactions) using the Internet. But tl1e Impact ls even more
substantive. Because people who work h1 the business world have become so comfortable with •surfing the Web; organlzatlons are Increasingly embracing the Web Interface as a suitable arcllitecture for conducting day-to-day business zvltbl-n t11e
organizatio11.
There are tlvee basic type! of e-commerce- and e-business-enabled lnforrmtlon
systems applications:
Marketing of corporate lm,ge, products, and services ls the simplest form of
eJectronic commerce applkatlon. 111e \X'eb is used merely to .. lnform" customers about products, services, and policies. ,_lost busines.,es have adlieved
tllis JeveJ of eJectronic commerce.
Bus/1,ess-10-co1,su.111er (B2C) eJectronic commerce attempts to offer new.
Wel>based channels of distribution for traditional products and senices. You,
as a typlcal consumer, can researcl1, order, and pay for products directly ,·1a
tl1e Internet. Examples in d ude Amazon .com (for books and music) and
E-trade.com (for stocks and bonds). Both companies are businesses tl1.1t were
created on tl1e \X'eb. 111eir competltio11, however, lncludes tradftlonal busJ..
nesses that have added Web-based electronic commerce front ends as an
alternative consumer option (such as Barnes and Noble and ,_lerrill Lynch) .
Figure 1-6 illustrates a typical B2C Web storefront.
Bus/1,ess-10-b·ust,wss (B2Bj electro1lic commerce is the real future. This ls the
most complex form of electro1lic commerce and coldd tLltim.ateJy evolve into
electronlc buslness-d,e ccmplete, paperless, and digital processing of >irtually
all business transactions that occur witllin and between bush1esses.
One example of 828 electtonlc commerce ls eJectron.ic prOCltrement. All businesses purchase raw materlals, equlpment, and supplies- frequently tens or htmdreds
of millions of dollars worth per year. 828 procurement allows employees to browse
eJectro1lic storefronts and catalogs, inltL1te purchase reqt.tlsltions and work otders,
route requisitions and wort orders electronlcally for expenditure approvals, ord<r tl,e
goods and services, and pay for the de!l,-.red goods and completed services- a ll
Tho Contoxt of Systoms Anolysls and l>osg, Mothods
~
~
•• ......
...a,,,.;1 . ~
19
looll ...-
~ __.!l_~
4._,..
!:,~-...
i"".'· ii.
~ ,J_R__:
BA.RNES&NOBLEO
· -
Choptor Ono
c,-
• • ...(QoJ •
lilil.. ~-· ·- ]El
e .... ;,,- ... o- -
Slwqi s.,.,-. . . fl... lhtro Kr,
BOOK<>BROWSER
NewReleases
-~==--·
,,.......,. ,Ul'I ..
._,..--.o,,,,,,.
P~l,...W.,IO
, au.a .N11 K,a,U\'t ,wnuw1111>11>,~11" 9oidl»), w:11
S<~,r~. 0¥~1!1 H«.tl!Um, Ad. Mc>td/, 41'-"
H#f P\'IN,WtMS<"f...4 ~ ti£,
itdll li Ii
• mro lYMtf
PM
7>,,HntJ,(,~
• 1!!!!!s. A..,...t.o, ~.-11n,p\lJPt lJ11"1¢0'fb'fl
,..........,_h·•=
•feRetui•"••:
• Sh~ ..
·-
fatllet'l:O.,lt.,._ t6th:flnlUI• Perfec.t Gift Ntr.
•r11e,m f'i:f
• fllllki YHtf:I
• Tht ~ttttts I Ht
·~Rt•~>
·tt..u•"-"'o.•
~··
• We11,c,e A..
Hti•t
~m
·.....
• fhef•ih•
· ·· .._.,Ml>h•dh.-...1..•
se- 1jl, • t iy,.J. (O!t14'1Cl'8C .,,,mDwidft~
•
"''"""~J
-.,..mp1mt1. r>io,-..,~ tt-•
- . . - ~.., suM ..u 1. .thft )'Ht lGt,111. •• ....
~~ ~tdtr,,'1\111\.. ll'll MWltillO"
\rfu(l l- .
• «..l ,
Y!f!o eett
•
• MJ4fth't l,t b.
=:,iv
lbl!lW Ctt!l>f'lt)! •
· ~··~~ptl:~to\Mlrllt1»11:t
"l,'Mb':Hr\
tJ
~~.in
~
'
~
... 0 ¥'0&.,.. .
fi]tiii:J>oo-~(~~-"'--~.,.~~
Fu
RE 1 - 6
An Electronic Commerce Storefront
wjth)ut the tradJtlonal time-consumlng and costly ptper flow and bureaucracy. Ffg.
W'C 1-7 illust.mtcs a snmplc Web-based procurement sto.rcf.ront.
largeJy due to the trend toward these e-buslness and e-commerce applicatlons,
most ne\\' information systems applications are being deslgned for an Internet
ardlitecture. Not that long ago, we. were redesigning most: applkatlons to operate
within a Wln.dot'1S user lnterface. Today, we lncreash~· see applications designed to
rtm witllin an Internet browser sud1 as Internet E:'(p!orer or 1\fetscape. The cholce of
a desktop operating system, such as Wtndotvs, il.fact11tosb, or IJ11ux, ls becoming less
Important d1an the availability of the browser Itself.
>
Security and Privacy
As t11e dlgitaJ economy continues to e,--olve, citizens and orgai1izatlons allke have developed a heightened awareness of the securfty .u1d prtvacy Issues Ul\--olved in today's
economy. SecurJty issues tend to revolve arow1d business continuity~ that is, "How will
the business continue ln the event of a breach or disaster- any event that causes a disruption of business actlvity?• Additionally, busine~es must ask themselves, .. How can
t11e business protect its d.Jgital assets from outslde threats?" It is true that these questions ulUmateJy come down to technology; howe,,-er, the concerns l1ave become
funcbmental busJness concerns.
)
20
Part Ono
Tho contoxt of Systoms Dovolopmont ProJo<ts
Hold )IOUff'l"IOUM ~ •
button foi • fflOff
det.a,led apa....ion
r r o """"" ....
F I GU RE 1 • 7
An Electronic Commerce Procurement Storefront
Re.lated ro security is the Issue of pri"-acy. Consumers are increasingly demaodJng
prjvacy in the dJgltal eco11omy. Governments are regulating privacy Issues, and the.
regulations will Uke.ly become more strlogent as the digital e.c onomy conrinues to
evolve. Go to your favorJte commercial \X'eb sites. Almost every business now has a
privacy policy. Consumer groups are beginning to analyze and monltor such privacy
polldes, holdlog companles accountable and lobbying governments for stricter
regulations and cnf01'ccmcnt.
As Information >)'Stems are developed and changed, you will Increasingly 1,e expected to incorporate more strlnge11t securJty and prtvacy controls. In the global
economy, you wlll need to become sensitive to a wjde array of reguL1tlons that "-at)'
cooslderably from one cow1try 10 another. Certalnly,security and privacy mechaalsms
will be subject to the same internal audJts that have become routine ln systems that
support or lnteract with financial systems.
>
Collaboration and Partnership
Collaboration and partnership a.re sJgnJflcant busine.s., t.re11ds that are influend.ag information systems applications. Within organizations, management Is emphasl~ the
need to break down the walls that separate organJzatlon departments and fw1ctJons.
1'ilanagement speaks of"cross-functloual,. teams that collaborate to address common
business goals from lnterdlsclpllnary perspectives. For example,new product design
used to be the exduslve domaln of engineers. Today, new product design typically ln""'Olves a cross-fw1ctional ream or' representatives from many organizational unlts,sud1
as e1lgi.neerlng, marketing, sales, manufacturing, ln,,..entory control, dlstrlbutlon, and,
yes, information $)'stems.
Tho Contoxt of Systoms Anolysls and l>osg, Mothods
Similarly, the trend toward colL1borntlon extet1ds beyond the organization to lo.
dude other organizations- sometlmes even competitors. OrganJz.atlons choose to dJ.
rectly collaborate as partners in business ve11tures that make good business sense.
,_Ucrosoft and Orade sell competitive database management systems. But ,_Ucrosoft
and Oracle also partner to ensure that Ora.de appUcatloos wUJ operate on a t.Ucrosoft
database. Both comparties benefit fuundally from sucl1 cooperation.
In a similar vein, businesses have learned that It can be beneflclaJ for their information ~tem.s to Interoperate with one another. For example, wbUe Wal-?ttart could
generate lts own restocking orders for merd1andJse and send them to Its suppliers,
it makes more sense to Integrate their respectl,. e. fnventory control ~·stems. Suppliers can monitor Wal-f\fart's lnventory levels directly and can automatically inltlate
busluess-to-busfness transactions to keep the sheJves stocked with thelr merdiaodlse. Both companles benefit.. (Of course, this also raises the aforementioned
issue of requirements for good security.)
>
Knowledge Asset Management
What is knowledge? KtJ.OtlJledge is the result of a continuum of how we process raw
data lnto useful lntOrmatlon. lntOrmatio11 systems collect raw data by captu.rlng business facts (about products, employees, customers, aod the like) and processing buslne55 transactions. Data gets combined, tlltered, org,10lzed, and analyzed to produce
Information to help managers plan and operate tl,e business. Ultimately, infonnatlon
is refined by people to create knowledge and expertise. Increasingly, organlzatlons
are asking themseJves, ..How can the company m.1nage and share knowledge for competitive advantage? And as workers come and go, how can the workers• knowledge
and expertise be preserved wlthiJ.1 the organizatio11?"
Thirty years of data proce~lng and infonnation ~stems have resulted in an enormous volume of data, Information, and knowledge. .'\JJ three are considered critical
b·ustness resources, equal In importance to the classic economic resources of land,
labo~ and capital.
The need for knowledge asset management Impacts informatio11 systems on a '\o-:triety of fronts. Although we have captured (and continue to capture) a great amount
of data and information in information systems, they are loosely Integrated In most
organizations- indeed, redw1dant and contradictory data and information are common in informatio11 systems. As new information ~·stems are bulh, we wUJ increasingly be expected to focus on integration of the data and Information that can create
and preserve knowledge In the organizatio11s for whldt we work. Tills will greatly
complicate systems analysis and de.sJgn. ln this book, we plan to Introduce you to
man~· tools and tedtnlques that can heJp you Integrate systems for improved
knowledge m.u1..1gemenr.
> Continuous Improvement and
Total Quality Management
lnfonnation systems automate and support: business processes. In an effort to continuously lmprove a business process, co11tin11011s process impro""etlleut (CPI)
examines a business process to implement a series of small changes for lmprovement
These changes can resltlt In cost: reductions, impro,--ed efficiencies, or increased value
and profit.. Systems analysts are both affected by continuous process improvements
and expected to hlitlate or suggest sud1 lmproveme11ts wltlle designlng and Implementing informatio11 ~tem.s.
Anotl1er ongoing business driver is total quality management (TQM). Businesses
have learned that quality has become a critical sucre55 factor in competition. They
have also learned that quality management does not begin and end with the products
and services sold by the business. Instead, lt begins with a culrure that recognlzes that
Chapter Ono
21
data raw facts about people,
places, events, and things that
are of importance in an organization. Each fact is, by itself,
relatively meaningless.
i..aformatioo :tata that has
been processed or reorganized into a more meani ngtul
form for someore. lnbrmation
is formed from combinations
of data that hop~fulty have
meaning to the recipient.
knowledge data and infor.
mation that are further refined
based on the facts, truths, beliefs, judgments experiences,
and expertise o1 the recipient.
Ideally informati, n leads to
wisdcm.
business pt()('esses tasks
that respond to Ousiness
events (e.g., an order). Busi.
ness processesare the work,
procoduroe, anC: ruloe ro
quired to complete the busi.
ness tasks, independent of
any information technology
used to automa1e or support
them.
contiouous process
impro,•emeot ( CPI) the
continuous monitoring of
business processes to effect
small but measurable
improvements in cost
reduction and value added.
t0t3.l quality -maoagemeot
(TQ.\l) a comi,ehensi\19 approach to facilitating quality
improvements ard management 'Mthin a b~siness.
22
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
everyone In the business Is responsible for quality. TQM commltmet1ts require that
every business function, lnclucllng Information services, Identify quality lndlettors,
measure quality, and make appropriate cha!ll!l'S to Improve quality.
Information systems, and hence systems analysts, are part of the TQM requlremet1t.. OUr discussions wtth college graduate recruiters suggest tl1at an .. obsessh,--e" attitude toward quality m.u1..1gement will become an essential d1..1racterlstic of
successf,d systems analysts (and all Information tedmology professionals). Tivough,
our tllis book, continuotis process Improvement and total quality m:u1..1gemet1t will be
an underlying theme.
>
business process
redesign (BPR) the study,
analysis, and redesign of
fundamental bJsiness
processes to r;duce costs
ancVor improw value added
to the business.
Business Process Redesign
As scared earlier, many infonnation systems support or automate busines., pro«s.,es.
,_lany businesses are learning that tl1ose business processes have not d1..1nged subscantially in decades and tl1..1r those business processes are grossly lneffident ancVor
costly. ~L1ny business processes are overly bureaucratic, and all their steps do not tndy
contrlbute value to the busfr1ess. Unfortw1ately, lnformatlon systems have merely automated many of these lnefficiendes. Enter business process redesign!
Bushiess process redesign (BPR) Involves malting substantive cha!1ges to bus•
ne.s., processes across a larger system. In effect, BPR seeks to Implement more subsuntial
changes and lmpro,--emenrs rl1an does CPL In a BPR, business processes are carefully
documented and analyzed for timeliness, bottlenecks, costs, and whether or not each
step or task truly adds '\o-:tlue to the org.'tnfzacion ( or, conversely, adds only boceaucracy). Business processes are men redesigned for maximum efficiency and lowest
posslble costs.
So how does BPR affect infonnation systems?111ere are two basic ways to lmplemet1t any Information system- build it or buy Jr. In other words, you can wrlte the
software yourself, or you can purchase and lmplemet1t a commercial software package. In both cases, BPR figures promltm1tly. ln writing your own software, It Is useful
to redesign bush1es., proces.,es before wrfth1g the software to automate them. Tills
way, you avoid automating w1derlylng lnefflclet1des. Alternatively, In purchasln@ software packages, most businesses ha,--e disco,-ered it is easier to redesJgn the business
processes to work with the software package than to attempt to force (and even
cripple) the software package to work with existing buslt,ess processes.
Technology Drivers for Today's Information Systems
Ach--ances h1 h1formatlon technology can also be drtvers for information systems (as
suggested In Figure 1-8). In some cases, outdated technologies can preset1t sJgnlfica.nt
problems that drive Information S)'stero developmet1t projects. In other cases, newer
technologies present business opportunities. Let's ex.amine several tedu1ologies that
are influencing today's Information systems.
>
Networks and the Internet
Scott ~tcNealy, Stm Computer's charismatic CEO, is oftet1 clred as stating, '111e network has become the computer;" Few woldd argue tl1at today's Information ~tem.s
are instaUed 011 a network architecture conslsth1g of local and wide area nef\\'Orks.
111ese networks lndude mainframe computers, network servers, and a variety of desktop, L1ptop, and handhekl client computers. But today, the most pervast,--e networking
technologies are based on the Internet. Some of the more relevant Internet technologies that you need to become aware of, lf not develop some basic skill with, are
described In the following list. (For now, don't be lntlmldated by these terms- we
Tho Contoxt of Systoms Anolysls and l>osg, Mothods
THE
8
1E PLAYER:
••
R
ER 8
THE ' PRODUCT'
..•
•..
HE P~
"
'
•
••
'
•
•
•
•
•
••
;f
•
•
•
•
0
23
Choptor Ono
•
•..
..
"
'
INFORMATION
SYST EMS
..••
..
..•
•
,f
,f
,f
,f
,f
Networks 3nd the Internet
Mobile and wireless techndogies
Object tecnnologies
Collaboralive technologies
Enterprise applications
ii,
•..
F IG U R E 1 • 8
..
..
,:
0
..•9
•
Technology Drivers for an Information System
will be teaching you more about these tedu10Jogies and how ro desJgi1 ~·stems t11..1r
use them througl1out this textbook.)
:,f ftML and XML are the fundamental Lwguages of Web page authoring and
Internet appUcatlon developmet1t. Extensible Hypertext Marl-tip Lsnguage
<xlffML) is the emerging secondi!et1eratlon venlon of lffML, the language
used to construct Web pages. Extensible Madrnp Language (XML) Is the
language used to etfectl\'e!)• transport data content along with its proper Inter-
z
•
•
24
Part Ono
Tho contoxt of Systoms Dovolopmont ProJo<ts
pretation over the Internet. Introductory xtf1'1'{l and Xl\fl courses ha,-e become
core requirements ln most information systems and Information technology
college curricula.
Scripting languages are simple programming languages designed specifically
for Internet applications. Examples Include Per4 VBScrlp~ and JavaScript.
These languages are Increasingly taught In college Web development and
programming courses.
\X'eb-spedflc programming languages sudl as Java and Cold Fusto·n have
emerged to speclflcally address construction of complex, Web-based apptications that fn,lolve multiple servers and \X'eb browsers. These languages are
also becoming prevalent In college programming curricula.
Intranets are essentL1lly pdvate lnternets desJgned for use by employees of
an organli.atlon. Tiley offer the look and feel of the lnten1et; however, se..."ttrity and firewalls restrict their use to employees.
E.xtmnets, ll.L::e lntranets, ate pci"-ate Inteme.ts. Bln extranets are for use
betweet1 specific organlzadons. Only the employees of those identllled businesses can access and use the extranet. For example, an automotive manufacturer sud1 as Chevrolet ~ht set up an enranet for the sole use of irs realers. Tb.rough th.ls extr.tnet, the nunufacture.r c:ut communJcnre lnform:itlon
about parts, problems, sales Incentives, and the like.
Portals (ht corporations) are ..home pages" that can be customized to the
speclflc needs of dlfferetll lndlviduals who use them. For example, portal
ted1nology can define Web pages that provide approprL1te lnformatlon and
applications for dJfferent roles in the same company. Ead1 lndtvJduat•s role
determines whJch In.formation and appUcations that person can use from her
or his \X'eb page. Example! of roles lndude "customer;' "suppUer; and dlfferetll types of •employee.• Portals can also effectlvely Integrate public lntemet,
pri'\o-ate Intranet, and extrauet content into each indJvJdual user's home page.
Web services are the latest rage. Web services are reusable, Web-based programs that can be called 6om any other lntemet program. For example, let's
say you need to wrlte a program to accept credit card paymenrs over the
'>"'eb. Sure, you could write, debug, and test tl,e credit card validation program yourself. But an alternative approad1 would be to purchase the right to
use a credJt card '\o-:tUdatlon program over the Web. By dolng so, you need not
maintain responsibility for the credit card valldatlon code. You need only
•cau• the Web service from your program, mud, as you would call an Internal subroutine. Of course, you wtU pay for the pri"ilege of using Web setvJces since somebody had co wrJce the orJgtnal Web sen-1Ce program.
...
........
1:i2.!~
,.....
These are but a few of the network and Internet ted111ologles tl1at you should
seek out du.ring your e.d ucatlon. But you must recognize the voJatlUty of the Internet
and accept that these and otherteclmologies wUl emerge and disappear frequently In
the near future.
>
( Wireless Handheld )
Mobile and Wireless Technologies
Moblle and wireless tedlllologle< are poised to slgolllcantly d,ange the next geneiatlon
of lnfonnatlon systems. Handheld computers, or perso1U1l data assfsta11.ts (PDAs, such
as tl,e HP IPaq, Palm, and RIM BlackBerry"), have become common in the ranks of
information workers. These de;ices are lncreasinglj• Including wireless capabilltles
(see margin photo) that pro,ide Web access and e-ruall. CeU phones are also Increasingly
featuring lnten.1et and e-mail capabllities. And now, integrated devJces such as s111art
phones are eme,glng that lntegr.,te the capab!Ut!es of POAs and cell phones Into a single
de>ice (see margin photo). For those who prefer separate devices, technologie< like
Bluetooth are emerging to allow the separate de'\oices to interoperate as one logical
de'\oice whlle presening each one's form factors and advantages.
Tho Contoxt of Systoms Anolysls and l>osg, Mothods
Choptor Ono
2S
Addltlo1ully, laptop computers are Increasingly equlpped with wireless and mobUe
capabilities to allow lnfonnatlon workers ro more easily move between locations while
preserving connectMty to Information systems. All of these tedmlcal trends will sigruj:
icandy Impact the analysis and design of new lnfonnatbn systems. Increasingly, wireless
acce.s., must be assumed. And d1e limitations of mobile del-ices and screen sizes must be
accommodated In an information system's design.Thls textbook wUI teach and demo,~
stmte tools and technlques to deal wid1 dte design of emerging mobUe applications.
>
Object Technologies
Today, most contemporary information systems are built using object technologies.
Today's pervasive programmlng languages are object-oriented. Tuey lndude C+ +,Java,
Smailtalk, and Visual Baste .NE/'. Object tedlnologlesallow programmers to build software from software parts called objects. (We will l!l't into more specifics about objects
later In this book.) Object-oriented software offers two fundamental ad,,inta&l'S over
nonobject software. First, objects are reusable. Once they are designed and built, objects
can be reused In multiple Information systems and appkations.Thls reduces the time required to de,'dop future software applications. Second, objects are extensible. Tuey can
be ch.'tnged o r expanded easily wtthout adversely lmp.cting any pt'e"ious applic:iti01u;
that used them.11lls reduces the lifetime costs of malmalnlng and Improving software.
The lrupact of object tedmology Is slgnllkant in the world of systems analysis
and design. Prior to object technologies, most programming languages were based on
so.called structu.red methods. Examples !ndude <XIBOL (the dominant language), c;
FORrRAJ\; Pascal, and Pl/I. It ls not Important at this time for you to be able to differentiate betweet1 structured and object technoJogfes and methods. Suffice to say,
structured methods are Inadequate to the task of analyiing and designlng systems that
will be built uslng object tedmologles. Accordlngly, object-orlented analysis and
design methods ha,--e emerged as the preferred approach for building ,no.st contemporary information systems. For this reason, we will integrate object-oriented ai1..1lysls
and desJg1.1 tools and techniques tlvoughout this l:ook to gtve you a competitive
ach--antage in tomorrow's job mad.:et.
At the same time, structured tools and techniques are still lmportai1t. Databases,
for example, are still commonly designed using structured tools. And structured tools
are still preferred by many systems analysts for analyzing and deslgnlng work flows
and business processes. Thus, we will also teadt you several popular structured tools
and technlques for systems analysis and design.
It ls easy to become a devout dtsclple of one ai1..1lysls and design strategy, sud1 as
strucrured ai1..1lys1S and destgn or obJecr-0rJenced a1..1lys1S and desJgn. You should
a'\o-old doing sol We will advocate both and tead1 you when and how to comblne
structured and object-oriented tools and techniques for systems analysis and design.
As we write this chapter, this approach- called aglledevelopment- ls galnlng favor
among experienced analysts who h.ave become weary of overly prescriptive methods that usually insist that you use only o,ie methodology's tools and processes. At
the risk of oversimplifying agile methods, tlllnk of it as assembling a toolbox of dlf.
ferent tools and technlques- structu.red, object-oriented, and others- and then selecting the best tool or technique for whatever problems or need you encotmter as
a systems at1..1lyst..
>
Collaborative Technologies
Another slgnlJlcant tedlnology trend ls the use of collaborative tedmologles. Collaboratl,--e teclutologies are those that ertbance interpersonal communications ai1d teamwork.
Fottr important classes of collaborative technologies are e-mal~ instant messaging,
groupware, and work flow.
Everybody knows what e-mail is. But e-mail's importai1ce in information systems
developmetll ls changing. Increasing!)', modern lnfornution systems are e-maf/.enabled;
( Smart Phone
)
object tecbnology a softw&ira tactinn lom1 th&i t dafinA.<:
a system in terms of objects
that consolidate data and behavior (into objects). Objects
become reusable and extensi.
ble components for the soft.
ware developers.
object-orieoted anal}'Sis
aod design acollection o f
tools and techni~ues for
systems development that 'Mii
utilize object technologies to
construct a syst~m and its
software.
agile development a
systems development strategy
wherein the sysl9m developers
are given the fla:ibility to select
from a variety of appropriate
tools and technques to best
accomplish the asks at hand.
Agile devebpment is believed
to strike an optimal balance
between produc:ivity and quality for systems d1\lelopment
26
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
that is, e-mail capabilities are built right into the application software.There ls no need
to switch to a dedlcated e-mail program such as Outlook. The application merely
invokes the user's or organfz.atlon's default e-mail program to enable reJe"'ant messages
to be sent or received.
Related to e-maU technology ls lnstant messaging (e .g., AOL's /11.stant ,llesse1iger
and Microsoft's MSN Messe11ger Servf.ce). Instant messaging was popularized in public and pri'\o-ate "chat rooms" on the Internet. Bur itutant messaging ls slowly being Incorporated into ent erprise information ~·stems applications as weU . For example,
it1Stant messaging can implement Immediate response capabilities Into a help ~"'Stem
for a business appUcatio11. lm.agl..ne beh1g able to h1Stantly send and recei,-e messages
with the corporate help desk when using a business application.The productlvi~· and
sen-ice-level Implications are sJgnlficant.
Flnally, groupware technolcgy allows teams of indtviduals to collaborate on pro~
ects and tasks regardless of their physical location. Examples of groupware tecbnolo.
gies lndude Lotus's Sa111eTl1ne and ,_Ucrosoft•s Net,lleeff.11g. Using sud1 groupware
allows multip le it1dJvJduals to partldpate in meetings and share software tools across
a network. As with e.mall an d Instant messaging, groupware capabilities can be built
into appropriate busine55 applications.
aearty, ..ystems analysts and system designers mu.st buUd these innovnclve col
L,borative technologies lnto their applications.
>
systems iotegtatioo the
process of buiding a unified
information sy31em out of diverse compon~nts of purchased softwa'e, custom-built
software, hal'CWare, and
networking.
eoter·prise resource
planning (ERP) a software
application tha fuUy integates
information sy31ems that span
most or all of t'le basic, core
business func1ons (including
transaciion processing and
management ilformation for
those business funciions).
Enterprise Applications
Virtually all organlzations, large tnd smal~ require a core set of etllerprlse applications
to conduct: bush1ess. As shown In Agure 1-9, for most busines.,es the core appliettlons
it1dude tlnancL1l management, human resource management, marketing and sales,
and operations management (in,-entory an cVor manufacturh1g control). At one time,
most organizations custom-bulll most or all of these core enterprise applications. But
today, these etllerprlse applications are frequet1tly purchased, Installed, and contlgured for the business and it1tegrated lnto the orgartization's business processes. Why?
Because these core enterprise applications ln different organizations or industries
tend to be more alike than they are different
Today, ti1ese "Internal' core applications are beh1g supplemented wltb oti,er eo.
terprlse applications that integnte an organization's business processes with those of
its suppliers and ctlstoruers. 111ese applications, called a,stonier relatto·n ship nui,iage,nent and supply cba.t11 nuinagetnent, are also illustrated In FJgure 1-9.
The tret1d toward the use of purchased enterprise applications slgnlflcantlj• Jm.
paccs syscem.s ai1..1tySls and desJgn. Ptll'Cbased and iJ.1ScaJJed encerprtse appUcatlous are
ne,--er sufficient to meet all of the needs for Information systems ln any organizatlo11..
111us, systems analysts and other developers are asked to develop value-.'ldded applications to meet addJtional needs of the busines.,. But the purchased and installed e11ter·
prise applications become a tedmology constraint. Any custom application must
properly hllegrate with and intaface to ti,e purchased entetprise applications. This is
often called S)'Stems integration, and this is the business and systems environment
into which most of you wUJgraduate . Let's brlefly explore some of the more common
enterprise applications an d describe their implications for systems analysis and design.
As previously noted, the core business infonnation system applications in most businesses were developed In-house incremet1tally over many years. Ead1 system had Its own Bies and databases with loose and
awkward Integration of a ll appUcations. During the 1990s, businesses tried very llard
to integrate these leg,1cy lnform1tion systems, usually with poor rest~ts. Organlzatlons
would have probably preferred to redevelop these core bush,ess applications (see
Figure 1-9 ag,1ln) from scratd1 asa single lntegmtedinfonnation system. Unfortumtel)',
few if any businesses had enough resources to attempt this. RecognJzlng that the
basic applications needed by most businesses were more similar than different, the
software industry developed a solution - ente rprise resource planning (ERP)
Enterprise Resource Planning (£RP)
REPRESEMATIVI:
ERP VENDORS
SSA
Oracle/PeopleSoft
SAPPG (the Market Leader)
Tho Contoxt of Systoms Anolysls and l>osg, Mothods
CLSTOMEAS
CORE BUSINESS
FUNCTIONS
Choptor Ono
27
SUPPLIERS
HUMAN
FINANCIAL
RESOURCE
MANAGEMENT
MANAGEMENT
(an enterpri&e
application)
(an enterprise
application)
CUSTOMER
RELATIONSHIP
.SUFPLY CHAIN
MAHAGEMENT
MANAGEMENT i.---1---1-l
( SC M )
(CR M)
OPERATIONS
MARKETING
& SALES
(1:111 ,,11h:11 ... ,1~...
application)
MANAGEMENT
(eoi' ,,....... "'' h:i,:,
application)
ENTERPRISE ·=ieso uACE PLANNING
( E R P)
DIS1A18UTOAS
~G U R E
l •9
Enterprise Applications
_ _ _ _ _)
appUcatlons. An ERP solutio11 is built arotmd a common database shared by common
business functions. Examples of ERP software vendors are listed in the margin.
REPRESENTATIVE
Alt F.RP solution pro\oides the core lnformation system functions for tl1e entire
SCM VENDORS
business. But usually an organJzatlon must redestgn its busine.s., processes to fully exp loit and use a n ERP solution. !\ilost ocgai1lzatlons must still supp lement the F.RP soJu.
i2 Technologiis
tlon with cuscom software appucauons to fulfill bustn ess requtrements chac are
Manug istics
wlique to the industry or b usiness. For most organlzatlons, an ERP implementation
SAP
and integration represenrs dle single largest information system p roject ever underSGT
ta ken by dle organization. It can cost tens of mJllions of dollars an d require a small
army of managers, users, ait.1lysts, technlcal speclallsts, programmers, ai1d consultanrs.
ERP appUcations are signlflcant to systems analysts for several reasons. First, systems analysts may be lnvol,--ed In the dedsJon to seJect a nd purchase an ERP solution.
Second, and more common, systems aii.1Jysts are frequently lnvol,--ed ln tile custom.J.zatlon of t11e ERP solution, as well as the redesign of business processes to use
t11e mP soJutio11.Tiilid, if custom-built applications are to be developed within an organilation that uses an ERP core solution, d1e ERP system's archJtecnire slgnJflcantly
Impacts the analysis and design of the custom application that must coexist and InsupJ>ly chain manageteroperate wjth the ERP system.
meot (SC~l) a software
Supply Chain Management Today,many orpnlzations are expending effort on et~
terpdse appllcatlons that extet1d support beyond their core business ftu1ctlons. Comp anies are extend.Jog their core business appUcatlons to interoperate with their
suppliers ai1d dlstrlblnors to more efficiently manage t11e flow of raw materials ai1d
p roducts between their respective orgart.izatlons. These Sl1pply c liaio m..1.nagemeut
(SCM) appUcations utUize the Internet as a means for Integration and communications.
applica1ion that :,ptimizes
business processes for raw
material procurement through
finished product distribution b'f
directly integrathg the logist~
cal information systems of organizations with those of their
suppliers and distributors.
Part ono
28
1ho Contoxt of Systoms l>ovolopmont ProjOffl
The Farms
i
---·---... __
__ _
_
·---..... ·----
"
:............
Food Processing Plants
Distribution Centers
i
•
The Restauiants
U RE 1 · 1 0 Supply
CF I G---------Chain
)
.____.
REPRESEMATtVI:
CRM VENDORS
BroadVision
E.piphany
Kana
Amdocs
Oracle/PeopleSoft
Siebel (the M.rket Leader)
SAP
customer relatioosbip
managemeot (CRM) a
software application that pro.
vides customers with access
to a business's processes
from initial inquiry through
postsale service and support
For example, Figure 1-10 demonstrates a logical supp~· chain eodlng at rest:urants
belonging to a franchlse (e.g., o utback, Red LObster, Weod)'<J. Notlae that this supply
chain lndudes many businesses and carriers to adlleve Its final result-ensuring tlut the
restaurants have adequate food mpplies to do business. Any deL1ys or problems in any
single link of this supply chain will adverse~· affect one and all. For dut reason, several of
these businesses wlll implemern supply duln managemetll using SCM sofrware tech.
nology to plan, implemen~ and manage the chain. Examples of supply chaln manage.
meet vendors are listed In the margin. (It should be noted that several ERP application
vendors are extending ERP software applications to indude SO.I capabilities. Toe SCM
market ls due for a slukeour because there are too many ,--endors for all to succeed.)
sat applications are significant to systems analysts for the same reasons as stated
for ERP applications. As an analy,t, you may be Involved In the evaluation and selection
of an SCM package. Or you may be expected to implement and perl1aps custonllzesuch
pack.ages to meet the organization's needs. And agaln, you may expect to partldptte ln
redesigning exlstlng business processes to work appropriately with the SOI solution.
Customer Relationship Management t.tany companies have discovered that
highly focused customer relatlonsh.ip management can create loyalty tl1at resu1ts in
increased sales. Thus, many businesses are lmplementlng C\1stomer relatio11Sltlp
ma.oagemeut (CRM) soJutions tl1..1t enabJe customer self-sen-ice '\oia the Internet.
Tho Contoxt of Systoms Anolysls and l>osg, Mothods
The theme of all cro.t s0Jutlo11s is a focus on the •customer." <:mt is concerned
wlth not only provJdfng effective nistomer lnqulr,' re.spo11ses and assistance but
also helping the business better profile its customer base for the purpose of improving customer relations and marketing. Examples of cro.1 vendors are listed In
the margin. As was the case with SC,_I technoJogles, many ERP vendors are developing or acquiring CR.l\t capabilities to compleme11t and extend their ERP solutions. And as with SCM, tl1e larger number of players will likely be reduced through
acqti.sltlon and attrition.
CRM technology Impacts systems :uulysts In predsely tl1e same ways as tl1ose we
descrlbed for ERP and scr.t technology. In many businesses, new applications must interface with a core, <:mt enterprise application.
Choptor Ono
29
REPRESENTATIVI:
EAi VENDORS
BEASyslems
IBM (MQSeries)
Mercalor SoftNare
TIBCO Softwae
Enterprise Application Integration ,_lany companies face the slgnlflcant challenge
of ln1egratlng tl1elr exlstlng legacy systems wltl1 new applications such as ERP, SOI, :u1d
CR.lit solutions. Any company tl1..1t wants to do busi..nes., across the lnten1et will also
l1..1ve to meet the challenge of integrating its systems with those of other organizations
and their dlfferent systems :u1d technologies.To meet tills challenge, many organizations
are looking at enterprise application Integration software. Enterprise appllcatlou
lntegratlon (RAJ) involves litlklng appUc:itlons, whether pu.rcb:ise-d
Ot'
de.,--eloped ht
house, so tl1..1t they can transparently Interoperate wJd1 one another. This Is illustrated
conceptually ln Figure 1-11. Some vendors offering E~ tools are listed In the margin.
C USTOMERS
enterprise applicatioo
mtegratioo (EAi) the
process and technobgies
used to link app'ications to
support the flow of data and
information between those
app11cat1ons. EAi so1ut1ons
are usually based on
mkkleware.
SUPPLIERS
CO RE BU S INE SS
FUN C TI O N S
ENTERPRISE RESOURC E PLANNING
APPLICATIONS
( ERP:
See Figure 1.9)
CJ STOMER
AE_ATIONSHIP
ENTERPRISE A PPLICATIO N
M AN Nl EMENT
(C R M )
r
,...
INTEGRATION
( E AI )
~
Other
Purchaaed
Application
Other
Purchaaed
Application
Other
C ueto~
Built
Application
Other
C ustomBuilt
Application
F I G U R E 1 • 1 1 Enterprise Application Inregration
SUFPLY CH AIN
MANAGEM ENT
(SC M )
30
Part ono
micldleware software
(usually purchi.Sed) used to
translate and route data
between ditfe~nt applications.
1ho Contoxt of Systoms l>ovolopmont ProjOffl
Again, this market Is rapidly expanding and contracting. The tools are used to deJloe and
construct communication plpeUnes between dilferlng applications and technologies.
Today, as any new information system ls developed, it must be Integrated with
all the Information systems that preceded lt.11,ese •legacy• tnfonnation systems may
have been purchased or built ln·house. Regardless, systems analysts and other developers must consider appllettlon Integration for any new information system to
be developed. And l!AI technologies are at the core of the Integration requirements.
~~~A
~ S_i_
m_p_l_
e _S_y_s_te_m
~_
D_e_v_e_lo_p_m
~e_n_t_P_ro
~ ce_s_s~~~~~~~~~~~)
system devtlop-meot
process a set of activities,
methods, best practices,
deliverables, a-id automated
tools that stakeholders use to
develop and rraintain
information sy31ems and
software.
111us far you have learned about different types of Information systems, the pL1yers
involved lo de,--eJoplng tl1ose S,'stems, and severaJ business and technology drivers
that Influence the deveJopment of infonnatlon systems. In this section you will learn
about another Information system perspective, the "process" for developing an information system.
,_lost organ.izatlons h.a,--e a formal S)'Stem de"-elopmeut process conslstlng of a
r.r:1nrl.arrl r-Pt nf prnrP."-'-"'~"' or stP.pr- thpy PT(lPrt will hP. fnllnwM n n :iny r.yr-tP.m MvP.l-
opmet1t project. Wlille these proces.,es may '\o-:try greatly for dJfferent organizations, a
common characteristic can be found: ,_lost organJz.atlons' system development
process follows a prohlem-sol,ing approach. Th.at approach typically Incorporates the
following gei1eral problem-solving steps:
I. Identify the problem.
2.
3.
4.
5.
6.
7.
Analyze and w1derstand the problem.
Identify solution requlremetlls and expectations.
Identify altematlve solutions and choose the best course of action.
Design the chosen solution.
Implement the chosett solutio11.
£\.-aluate the results. (If the problem is not solved, return to step l or 2 as
appropriate.)
Figure 1-12 adds a system deveJopment process perspective that we wtD use
(with appropriate refinements) throughout tills book as we study the development
process, tools, and tedmlques. For the sake of simplicity our lnltlal problem-solving
approach establishes four stages or phases tl1.1t must be completed for any system
development project- system Initiation, system analysis, system design, and system
Our Sintpli6ed System
General Problem-Solving Steps
Development Process
System iiitiation
,. Identify the problem, (Also plan for lhe solutbn
ol lhe problem,)
System analysis
2. Analyze and understand the problem.
3. Identify solution reqUrernents and expectab,ns,
System design
System i'nplementation
•.
Identify alternative soiu,oos and choose lhe
beS1 oourse of action,
••
Oesig, the chosen solution,
••
Implement the cha.sen soiu,oo•
7. Evaluate the result& ( If the problem is not
solwid, return n Slep 1 or 2 es appropriate.)
Tho Contoxt of Systoms Anolysls and l>osg, Mothods
•
OU
IE
-
-
TME "PROOu c r· -
L
•
"
2
w
u
z
•
u
u
0
a
•
•
••
•
•
•>
'
z
•
u
>
•
A N I.NFORM ATION SYSTEM
~
SYSlEM INITl#JIO N DELIVERA BLES
A
Syetem initiation produces a busne.98 problem 8t8tement project
p lan that eWlblishes scope,, gclf..le, echedule, end budget br solving
the problem with a technical eol.rtion,
=>
(
.
•
'
'
-
'
•w
!
SYSTEM ANALYSIS DELIVERABLES
Syetem a naty,i• plOducee a "8lement of the system users'
for a solution
=>
-
buelneu requirements, expec:talions, and prioritiM
to
(
the buslneee problem.
•
"
z
•
•w
A
Syetem d esign prodU08.$8 technical blueprint end epecfficatione br
a solution 1h8I fu lfille the buelne$$ requirem ents,
2
-
'
.
I
(
•
'
'
'
SYSTEM IMPLEMENTATION DELIVERABLES
0
..'
'
'
SYSTEM DESIGN DELIVERABLES
=>
'
'
w
2
I
A
w
0
'
.
~
•
-
••
'
w
•
OR
31
Choptor Ono
Sy.t em i.m.plementation proc'u cM the technical hardware and
=>
software solution for the buelneu problem accon::tl"IQ to the technical
an::hitecture and epecfficatlons.
A
'
•
.
(
"
'
TE C
N
OH
E
-
S
F I GU R E 1 • 1 2 Systems Development and Problem Solving
implemenratlon. TI1e table on the pre"iotis page shows the correlation between the
abo,-e general problem-60l"ing steps and our process.
It is important to 11ote that any system development process must: be managed
on a project-by-project basis. You learned earUer that at Jeast one stakeholder accepts responslblUty as the project manager for ettsu.rlng that the system is developed on cime, within budget, and with acceptable quality, The actlvlty of managing
a project is referred to as project management. Accordingly, in Figure 1-12 we
l1ave added a process for project management. Also, to ensure that all projects are
project managemeot the
ac.ti\'ity of defining, planning,
di reciing. monitoring. and
oontrolling a project to develop
an acceptable S'/stem 'Mthin
the allotted time and budget
32
Part ono
process man.agemeot
the ongoing ac.tivity that
defines, imprcues, and
coordinates th; use of an
organization's chosen
methodology ~he "process")
and standards for al I system
development projects.
1ho Contoxt of Systoms l>ovolopmont ProjOffl
managed according ro the same development process, we have included process
man..1.geruent as an ongoing actl'\oity. Notice that project and process management
overlap all of the process pl1ases.
Let's briefly examine our system development process In Figure 1-12 to expand
your understanding of ead1 phase and actMty In the process. Given a problem to be
solved or a need to be fulfllled, what will we do during system lnltlation, analysis, design, and Implementation? Also, who will be lnvoh-.d In each phase?
>
System Initiation
Information system projects are usually complicated. They require a slgnlllcant time,
effort, and economic investment The problems to be soJ,-ed are frequently stated
vaguely, which means that the Initial envisioned solution may be premature. For these
reasons, system projects shotdd be carefully pfanned. System lnltlation establishes pro~
system iftitiatioo the initial
planning for a project to define
initial business scope, goals,
schedule, and budget.
ect scope and the proble=hing plan. Thus, as shown In Figure 1-12, we see that
system Initiation establishes the project scope, goals, sd1edtde, and budget requlred
to solve the problem or opporttlnlty represented by the project. Project scope defines
the area of the business to be addre55ed by the project and the goals to be achle>-.d.
Scope and gonls uhJm.'ltely Impact the resource commirruenu, n:unely, sdledule :md
budget, tl1at must be made to successftdly complete the project. By establishing a pro~
ect schedtde and budget agalns1 the t11ittal scope and goals, you also establish a base11,w ag.,inst whid1 all stakeholders can accept the reality that any futtu-. changes In
scope or goals wiU impact the schedtde and budget.
Ffgure 1-12 also shows thal project managers, ~·stem analysts, and system owners are ti1e primary stakeholders In a system analysis. This book will teach you
many tools and techniques for Initiating a system project and establishing a suitable
project pL1n.
>
system analysis the study
of a business problem domain
to recommenc improvements
and specify the business
requirements and priorities
for the solution.
System Analysis
The next step In our system development process ls system ao...1.lysJs. System
analysis ls Intended to provide the project team with a more ti1orough understanding of the problems and needs that triggered ti1e project. As sud,, the business area (scope of the project- as defined during system lnitlatlon) may be
studied and analyzed to gain a more detailed w1derstanding of wl1at works, what
doesn't, and wl,at's needed. As depicted In Figure 1-12, the system analysis requires
working wlth system users to clearly define business requirements and expectations for any new ~·seem thac IS co be purchased or developed. Also, business prJorJtles may need to be established In the event tl1at schedule and budget are
insufficient to accomplish all that ls desired.
Recall the business drh-.rs discussed earlier In the chapter. These (and future)
business drivers most closely affect system analysis, which often defines business requirements it1 response to the busit1ess drlvers. For ex.ample, we discussed a c\.l'rent
tret1d toward e-busi.ness and e-commerce. Th.ls busit1ess driver may lnfluence the business reqttlrement for any lnformatlon system, leading us to establish project go1ls to
conduct all business tr.tosactlous on the \X'eb.
The completion of a system analysis often results In the need to update many of
the deliverables produced earlier, during system initiation. Toe analysis may reveal the
need to re,ise the business scope or project goals- perhaps we now feel the scope
of ti1e project Is too large or too small. Accordingly, ti1e scbedtde and budget for ti1e
project may need to be revised. Finally, the feasiblllty of the project itself becomes
questionable .111e project coldd be canceled or coldd proceed to the next phase.
As shown In Ffgure 1- 12, project managers, ~·stem analysts, and system users
are the primary stakeholders In a system analysis. Typically, results must be swnmarlzed and defended to the system owners, who will pay to desJgn and Implement an
information system to fulflll the business requirements. Tilis book will teach you
Tho Contoxt of Systoms Anolysls and l>osg, Mothods
Chapter Ono
33
man~· rools and redullques for performing a system analysis and documenting user
requirements.
>
System Design
Given an understanding of the business reqttlrements for an infonnatlon system, we
can oow proceed ro system design. During system desJgn we wUJ itlitlally need to system design the
explore altemati,-e technical solutions. Rarely is there only one solution ro any prob. specification or oonstruciion of
lem. for example, today most compan.ies need to choose between purd1..1slng a solu- a technical, oorrputer-Oased
solution for the business
tion that is good enough and building a custom solu tion in-house. (We'll explore requirements identified in a
options such as this tlvoughout this book.)
system analysis. (Note: InOnce a technical altesnative is choset1 and appro"ed, the system design phase de- creasingly, the c'esign takes
velops the tedmical blueprints and spedJkations requlred to Implement the final solu- the form of a wcrl<ing
tion. These blueprints and speclflcations wlll be used IO Implement required databases, prototype.)
programs, user interfaces, and networks for the information system. In the case where
we choose to purduse software instead of build I~ the blueprints specify how the purchased software wlll be Integrated Into the business and with othes information systems.
Recall the tedmology drivers discussed 111 the l,.st section of the diapter. These
(and future) technology drfvers most closely Impact the system design prooess and
dedslons. ,_tany organfz.ations define a common lnformatlon technology architecture
based on these technology drh,--ers. Accordingly, all eystem designs for new lnfonnation ")'Stem.s must conform to the standard IT archlt:ecture.
As depicted 111 Figure 1-12, project managers, system analysts, and system deslgners are the primary stakel1olders 111 a system deslgn.1bls book will tead1 you many
tools and teclmlques for performing a system deslgn.
>
System Implementation
The Onal step ln ottr simple ~·st:em deveJopment process is system lmplement..1- system impl001eotatioo
tioo. .As shown lo Figure 1-12, system impJementatlon constructs the new lnfonna- the construction, installation,
tion system and puts It into operation. It is during ,ystem Implementation that any testing, and deti119ry of a
system into production
new hardware and system software are installed and tested. Any purchased applica- (meaning day-tc-day
tion software and databases are Installed and configured. And any custom software operation).
and databases are constructed using the technical blueprints and spedflcatloos
developed during system deslgn.
As system components are constructed or inst:1Ued, they must be indhidually
tested. And d1e complete ~·stem must also be tested to etlSure that It works properly
and meets user requJ..remet1ts and expecratlons. once me system h.as been fully tested,
it must: be placed into operatio11. Data from the previous ~tern may ha,-e to be converh:d or entered into start-up databases, and system users must: be trained to properly nse the system. Fitllllly, some sort of transition plan from older business processes
and Information systems may have to be implemented.
And once again, as depicted in Figure 1-12, project managers, system analysts, and
systesn builders are the primary stakeholders in a sy,tem lmplemetllation. While this
book will teach you some of the tools and tedmlques for perfonnlng a system Implementation, most of these methods are taught in programming, database, and netwoddng courses. 111.ls book emphasizes system lnitittion, analysis, and design skills,
but It will also tead1 you the wlique system Implementation tools and techniques tl1.1t
are most commonly perfonned by systems analysts and, therefore, are not typically
covered In tl1ese other information technology courses.
>
System Support and Continuous Improvement
We would be remiss not to briefly acknowledge that Implemented infonnation sys,
temsface a lifetime of support and conth1uot1S impro,-ement. But where is tlut shown
in Figure 1-12? It is there! But It is subtle.
34
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
Implemented lnformarJon systems are rarely perfect. Your users will find errors
(bugs) and you wUJ discover, on occasion, design and Implementation flaws thar
require attention and fixes. Also, business and user reqttfrements constantly change.
111us, there will be a need to continuously improve any lnformatlon system until the
time ft becomes obsolete. So where does system support and change flt into our
development process?
A change made for system support or Improvement ls merely another project,
sometimes called a 1nal11te11a11ce or e1Wa11ce,ne1J.t project. Such a project should fol-
low the exact same prohle=lvlng approach defined for any other project.The only
difference Is the effort and budget required to complete the project. Many of the
phases wUJ be completed much more quickly, especially If the original stakeholders
properly documented the system as Initially developed. Of course, If they dld not, a
system improvement project an quickly consume much greater time, effort, and
money. Much of what we will teach you In this book Is lnte11ded to help you approprL1tely document lnformatlou systems to slgnlflcantly reduce lifetime co.ts of
supporting and lmpro"iog your Information systems.
Q_
0
E
v
0
0
0:::::
0)
c
c
I....
0
(])
.-l
Each chapter will pro>ide g,udance for self-paced i11struction under the hetdi11g
.. Learnh1g Roadmap." Recogilizlng that different students and readers have different
backgrounds and interests, we will propose appropriate teaming paths- most wlthln
this book, but some beyond the scope of dlls book.
Most readers should proceed dlrectl)• to Chapter 2 because the first four chapters
provide mud1 of the context fot the remah1der of the book. Several recurring themes,
frameworks, and terms are lntroduced in those chapters to allow you to define your
own learning patl1 from tl1at pdnt forward.1ltls d1apter focused on Information systems from four different perspectives:
•
•
•
•
The pklyers--both developers ard users of information symems.
The busiless ctive,s that currenly influence infOITilation ~ terns.
The tecmology d'we,s that currently influence inf01TI1ation ~ s .
The process of deVeloping infonmtion symems.
a,apter 2 wUJ take a doSE-r look at tl,e product ltself- lnfonnatlon systemsfrom :m :udlltectural perspective :1.pproprbte for systems development. We will de
floe how different players and deve.lopment stages view an lnformation system.
Looking further ahead, Chapter 3 more dose!)• examines the process of si,tems
development. a,apter 4 completes the Introduction to systems analj•sls and design
methods by ex.amlnlng the nuiriage111e11.t of systems deve.lopment.
Summary @
l. Informztlon systems in organizations capture and
manage data to produce useful lnformation that
supports an organization and lts employees, customers, suppliers, and partners.
2. Informztlon systems can be dassllled accordh1g
to the functions tl,ey serve, lndudlng:
a. Transaction processing systems tl1..1t process
busine.s., transactions such as orders, time
cards, payments, and reservations.
b. ~tanagement lnformation ~·stems that use
transaction data to produce infonnation
needed by managers to run tl1e busines.,.
Tho Contoxt of Systoms Anolysls and Dosg, Mothods
c. Decision support systems that help various dedsJ011 makers ldentlfy and choose between
options or decisions.
d. Executive information systems tl1at are
systems taUored to the unlque lnformatlon
needs of executives who plan for the business and assess performance against the
plans.
e. Expert systems that are ~·stem.s that
capture and reproduce the knowledge of
an expert problem solver or dedsJon maker
and then simulate the "thlnklng• of that
expert.
f. CommunJcatlon and collaboration systems
that enhance communJcatlon and collaboration between people, both internal and external to the organlzation.
g. Office automation systems that help employees cre:ite :ind d1..'lre documents th.at SUpp<>t't
day-to-day office actlvtties.
3, hlformation systems can be viewed from vari-
ous perspectlves, lndudlng from the perspec11ve of the "players," the .. business drfvers"
Jnfluenc-lng the information system, the .. ted1n0Jogy drfvers" used by the information system,
and the ..process" used to develop the lnformaHon system.
4. h1fonnatlon workers are the stakel10Jders ht lnformatlon systems. Information workers lnclude
1l1ose people whose jobs involve the creation,
collection, processit1g, dlstrlbution, and use of
Information. They h1dude:
1.
b.
c.
d.
e.
System owners, the sponsors and chlef advocates of lnformation systems.
System users, the people who use or are lmpacted by ti,e Information system on a regular
basis. Geographically, system users may be
internal or external.
System designers, technology specialists
who translate system users• business
reqttlrements and co11straints into techn.ical
soJutions.
System bttllders, technology specialists who
construct the it1fonnatlon system based on the
design speclftcations.
Systems analysts, who facilitate the development of information $)'stems and computer
applications. They coordinate the efforts of
the owners, users, designers, and builders.
Frequently, they rnay play one of those roles
as well. systems analysts perform systems
analysis and design.
5. h1 addition to having formal systems analysis and
design skills, a systems analyst must develop or
Choptor Ono
35
possess the following skills, knowledl!f', and
traits:
a. Working knowledge of it1fonnation
technologies.
b. Computer programrolng experience and
expertise.
c . General knowledge of busines., processes and
terminology.
d. General problem-solvtng skills.
e. Good interpersonal communication skills.
f. Good interpersonal relations skills.
g. Flexlblllry and adaptahlllry.
11. Character and eth.ics.
6. Any stakeholder role rnay be tllied by an hllernal
or external worker referred to as an external service provider (ESP). Most ESPs are systems analysts, designers, or builders who are contracted to
brlng specl:U expertise or experience to a spe
clfic project.
7. Most h1fonnation systems projects lnvoh.. workit1g as a team. Usually one or more of the stakeholders (team members) takes on the role of
project manager to ensure that the system ls developed on tlme, wlthh1 budget, and with acceptable quality. Most project managers are
experienced systems analysts.
8. Busit1ess delvers it1fluence information $)'5tem.s.
Current busit1ess delvers that wlll continue to it1fluence the development of it1fonnation systems
h1dude:
a.
b.
c.
d.
Globalization of the economy.
FJectron.ic commerce and busit1es.,.
Security and privacr
Collaboration and partnership.
e. KnowJedge asset management.
f. Continuous improvement and total ([ltal.icy•
management.
g. Business process redesJgn.
9. Information t echnoJogy can be a delrer of lnformatlon $)'stems. Outdated technologies can present p roblems that drlve the need to develop
new systems. Newer tec hnologies Slr.h as the
folJowlng are influenclng today's information
systems:
a. Networks and the lnten1et:
I) :<flTML and XML are the fundamental langltages of Web page authoring and Internet appllcation development. Extensible
Hypertext Marl<up Language (xHTML) Is
the emerging second-generaticn versJon
of HTltfL, the langttage used to construct
Web pages. Extei,slble Marl-up Language
(XML) Is ti,e language used to effective~·
36
Part ono
Tho Contoxt of Systems l>ovolopmont ProjOffl
transport data content along wfth its
proper interpretatio11 over the lnten1et.
II) Scripting languages are simple program-
ming langual!l's designed specUlcally for
lnten1et applications.
ill) Web-speclflc programming languages
such as Java and Cold Fusio1i have
emerged to speclflcally address construction of complex, Web-based applications
that involve multiple servers and Web
browsers.
fv) !11tranets are essentially prfvate lnternets
designed for use by employees of an org,1lllzation. They offer the look and feel of
the Internet~ however, security and firewalls restrict thelr use to employees.
v) E..'!(tranets, like intranets, are private lnternets. But extranets are for use between
speclftc org:m.l7!itlons. Only the employ
ees of those ldentlfled buslnesses can
access and use the extranet.
vi) Portals (in corporations) are "home
pages" that can be customized to the
specific needs of dlfferetll individuals
who use them. For example, portal technology can define Web pages that provide appropriate Information and
applications for different roles in the
same company. Each indtvldual's roJe determines which information and applications that person can use from her or hls
Web page.
vii) Web services are reusable, Web-based programs that can be called from any other
lnten1et program.
b. ltfoblle and wireless technologies-lncreaslnW.y. wireless access must be assumed. And
the ll.mltations of mobile devices and screet1
slze.s must be accommodated in an lnformation system's design. All of the following rechnlcal trends will significantly Impact the
ai1..1lysls and design of new h1fonnatlon
systems:
i) Handheld computers, or personal data
assistants (sud, as ti,e HP IPaq, Palm, and
RIM BlackBerry)
become common
in the rar1ks of lnformation workers.111ese
devices are increasingly including wireless
capablUties that provide \X'eb access and
e-mail
II) Cell phones are also Increasing))• featuring
lnten1et and e-mail capablUtles.
Ui) Integrated devices such as s,nart phones
are einerging dur integrate the capabilities
ha,.,
of POAs and cell phones Into a single
device.
Iv) Technologies like Bluetootb are etnerglng
to allow separate devices to h1teropemte
as one logical device while preserving
each one's form factors and advantagts.
c. Object technologies-Most contemporary information systems are built using object technologies. Object technologies allow programmers to
build software from software parts called objects. Object-oriented software offers tl,e ad,'311tal!I' of reusablltty and extetlSlblltty.
d. Collaborative rechnologles- Collaborati\"e
technoJogles are those that enl1..1nce interperso11..1l commwlicatlons and teamwork. Four important classes of collaborative technologies
are e-mail, lnscant messaging, groupware, tnd
work flow.
e. Enterprise applications-Vlrtually all organizations, large and small, require a core set of enterprise applications to conduct business. For
most businesses the core applications indude
B.nandaJ m:u1..1gemet1t, human resource mtnagement, marketh1g ai1d sales, and operations
management (h1vet1tory and/or m:u1ufacturlng
control). At one time, most organl1.ations
Cl1stom-bu.Ut most or all of these core enterprise applications. Blll today, ti,ese enterprise
applications are frequei1tiy putchased, Installed, and configured for ti,e business and
lntegrated into the organlzatio11's business
processes.111ese ..h1ternal .. core applications
are being supplemented with other enterprise
applications that lntegrate an org.ulization•s
busine.s., processes with those of lts suppliers
and customers. These applications are caUed
Cl1stomer relationshlp mana.e:ement (QU\i() and
supply chain management (SC~O. Enterprise
application integration (EAi) lnvo(,-es linking
applications, vvi,etl,er purchased or developed
In-house, so that they can transparently interoperate with one another.
10. Many organizations have a formal systems de,..topment process conslstlng of a standard set of
processes or steps they expect will be follow,d on
any systems developmet1t project. S)'S!ems deveJ.
opment proce.s.,es tend to mirror genera) problemsolving approad,es. This chapter presei1ted a
simpllfted system development process that Is
composed of the following phases:
a. Sysrein lnltlation-d,e lnltlal planning fora
project to define inltlal business scope, grols,
schedule, and budget.
Tho Contoxt of Systoms Anolysls and Dosg, Mothods
b. System analysis-the study of a business
process domaht to recommend improvements
and specify the bush,ess requirements and priorities for the solution.
c. System design-the speciflcatlon or construc-
tion of a technical, computer-based solutio11
for the business reqttlrements ldentlfled in ~·stem analysis.
d. System implementation-the construction, lnstallatlon, testh1g, and delivery of a system lnro
operation.
11. h1fonnation systems face a llfethne of support
and continuous improvement. A change made for
system support or impro,--ement ls merely another project, sometimes called a mah1tei1..1nce
or enhancement project. These projects follow
1he exact same proble=lvlng approach defined
Choptor Ono
37
for any other project, but they req,tlre less effort
and budget.
12. Sequentlal developmetll req,tlres that each development process (phase) be completed- one after
the other. This approad1 Is referred to as the
waterfall approach. An alternative de,-etopment
approach Is lterath.. ( or Incremental) d?velopment.
This approach reqttlres completing enough anal)•-
sis, design, and implementation as is necessary to
f,tlly develop a part of the new S)'Stern. Once that
version of the system ls implemented, the strategy ls to then perform some addJtlonal analysis,
deslgi1, and lmplementatio11 ln order to release
the next version of the system. These Iterations
continue until all parts of the entire infonnation
system have beet1 developed.
\;~::S Review Questions
I. Why are Information si-stems (IS) essential In
org;ulizatlons?
2 . Why do S)'sterus analysts need to know who the
stakel10Jders are ln the organJzation?
3. Who are the typical stakel10Jders h1 an lnforrua-
tJon system? What are their roles?
4. Please expL1in wt1at the consequences are lf an
jnformatio11 ~'Stem lacks a system owner.
5, What are the differences between internal users
and extenul users? Give examples.
6. What are the differences between the role of
,ystem anal)•sts and the role of the rest of the
,takel10Jders?
7. What klnd of knowledge and skills shot~d a
,ystem anal)•st possess?
8. ht addition to the business and computing knowledge that S)'Stem analysts should possess, what
are the other essential skills that they need to
effectively complete their Jobs?
9. Why are good Interpersonal communlcation skills
essentL1l for ~'Stem ai1atysts?
10. What are some of the business delvers for today's
infonnatlo11 S)'Stems?
11. What are the dlfferei1ces between electronic
commerce (e-commerce) and electronic business
( e-bush,ess)?
12. What are the differences between Information
and knowledge?
13. What are the most important tedutology drivers
for today's infonnatlon systems?
14. What are the four steps ln a system development
process? What happens ln ead1 step?
15. Why Is system Initiation essential ln the system
de1i--elopment proces.,?
@:
l. .\ssume you are a systems analyst wt10 will be
conducting a reqttlremenrs analysis for an lndtvld-
ually owned brick-and-mortar retaU store with a
point-of-sale S)'Stem. Jdet1tlfy who the typical
intental and exten1..1l users mlght indude.
2 . .\ssume you are a systems analyst for a consultl11g
company and have been asked to assist the chlel
executive officer (CEO) of a regional bank. Toe
bank recently lruplemented a plan to reduce tl,e
Problems and Exercises
number of staff, including loan officers, as a strategy to maintain profitability. Suhsequtntly, the
bank has experienced chronlc problems with
backlogged Joan requests because of the limited
number of loai1 officers who are able to review
and approve or disapprove Joans. The CEO of the
bank is lnterested ln solutions that would allow
the appro'\o-al process to move faster '\\·lthout lncreaslng the munber of loan officers, and has
38
Part Ono
Tho Contoxt of Sy,toms Dovolopmont ProjOffl
engaged yolU' company to come up with suggestions. What is one type of system tllat you mlght
recommend to the bank?
3. How do communication and collaboration sys-
tems lmpro,-e efficiettcy and effectlvet1ess? What
are some of the communication and collaboratio11
system! tl1at are being used by an increasing
number of organizations?
4. Identify tile type of Information system ti1at derical workers ln an organization would typically
use and why.
5. As Information systems increase h1 complexity
and comprehensiveness, ethical issues regarding
accessing and using data from these systems are
also lnaeasing. W11at are some of these ethical
issues?
6. What are business to consumer (B2C) and business to business (B28) Web appllcations, and
wh:it are some ex:unples of each type?
7. Wh.lle ~'Stem developmet1t processes and
meti1odologles can vary greatly, Identify and
briefly explain the •generic" phases of the system
de1i--elopment process tl1at are de.scribed ln the
textbook and whlch must be completed for any
project. You are a contractor with a systems lntegration company.
8. Your company h.as a contract wJth a local firm
to link all of their ~·stems so they can transparet1tly work together.Their applications lndude
a number of existing legacy systems, whlch
were b ,tllt at dlfferent times by dlfferent developers using a variety of languages and pfatforms, as well as several newer contemporary
appllcations. What is ti1e term for thls type of
linking! What type of t ool would you most
likely use, and what are some examples of these
tools?
Projects and Research
9. YOlU' company ltas asked you to develop a new
Web-based system to replace lts existing legacy
system. There will be very little change in
business requirements and functJonaUty from
the existing legacy system. Suggest whlch
system development process you ruJght use
and why.
IO. You recet1tly Joined a retail sales company whld1
has recently bought out and a~imlL1ted a commercial h1dustrlal supply house. You have bem
asked to lead a project to develop a consolidited
Inventory-tracking ~'Stem. Suggest wllidt ~·stem
development process you ruJght use and why.
II. Your company president sits down beside you
Just before a meeting ls to begin and tells you that
people keep sayh1g the customer needs to hl5tali
a QU\il, but doesn't reaUy know what ft is. Th.e
company president tllen asks you to explain it in
nontech.nlcal terms ht the next 30 seconds.
IZ. Industry studies indicate tllat mobile and wireless
technology h.as become one of the major tedu10Jogy drivers for designing new information systems. Why ls tills tile case and what is the hnpact?
13. Briefly explaln the hnpact of Web services on 'X'eb
development. GJ,--e some examples of\X'eb services.
14. Identify h1 whlch phase of the development
process tile following activities belong:
a. Development of the technlcal blueprint or desJgn dOCltment.
h. Project schedttlh1g.
c. Integration testing.
d. Interviewing ~'Stem users to define business
requirements.
15. What are the two most important advantages of
obJect-orJented software tedu10Jogies over structured software technologies?
11§
1. Re.seard1 the average and/or ruedt.ut saL1rles for 11'
professionals. You can use a '\o-atJety of methods to
find this information, such as searching tile Web
for onlh,e sites that publish tile resttlts of salary
surveys for rr professionals. You can also look at
classlfled ads In newspapers, trade rnag.11lnes,
and/or 0tillne.
a. Is there a slgnf.flcant difference between
typlc,I salaries for system analysts, designers
and developers?
b. Roughly, what is tile diffete11ce In the typlcll
saL1rles for tl1ese different groups?
c. What do you thitlk are the reasons for the
difference?
d. Is there a gender g.1p In the salaries of rr professJonals? Discuss any trends that you found,
and the Implications.
2 Contact d1e cWef information officers (OOs) or
top rr managers of several local or regional
organizations. Ask them aboltt the process or
Tho Contoxt of Systoms Anolysls and Dosg, Mothods
methodology they use for system deveJopment
in their organizations, and why they utUize tl1..1t
partlct~ar approach.
a. Describe and compare the different approaches
that you have fow1d.
h. Which approach do you believe to be the most
effectlve approach?
c. Why?
3. Cueer choices and personal skills:
a. At this point In your education, if you had to
choose between becoming a $)'Stem.s analyst,
systems designer, or systems builder, which one
would you choose?
h. Why?
c. Now dtvlde a piece of paper into two columns.
On one side,llst the personal skills and tralts
you th.ink are most Important for each of these
three groups of systems analysts, designers, and
builders. ln the second column, list at )east flve
skills and traits that you feel to be your
strongest ones, then map them to the skills and
traits you listed for each of ti,e three groups.
With wh.lch group do you have the most skills
and traits In commo11?
d. ls this group the same one as the one you
would d1oose in Question 3a? Why do you
think this is (or Is not) the case?
4. Your school library should have journals and peri·
odlcals dating back at least several decades, or lll.1)'
subscribe to onUne research services which do.
Look at severaJ recent artldes In information tech·
nology joumals regarding systems analysis, as wen
as several articles from at least 25 years ago.
a. Compare d1e recent artides to the older ones.
Do there appear to be slaniJkant differences in
the typical knowledge, skills, ab!Utles, and/or
experience tl1..1t systems analysts needed
25 years ago compared to now?
b. If you found some differences, what are the
ones that you consJder most important?
c. Wh.at do you think are some of the reasons for
these changes?
Choptor Ono
d. Now get out your crystal baU and look into ti,e
future 25 years from 11ow. W11..1t dJfferences do
you predict betweei, the systems analysts of
today and tl1ose in 25 years?
5. Search the Web for se,-.ral articles and Information
on ethical Issues reL1ted to h1fonnatlon tedu1ology
professionals.
a. What articles did you find?
b. Based on your research, which etll.ical Issues do
you tlllnk systems analysts might face during
their careers?
c . Pick a partlcufar ethical issue and explain the
steps you would take If you were confronted
with tllis Issue.
d. What would you do if you fow1d your best
friend and co-worker had committed a serious
ethical vJolatio11? Facts to consider:The violation m.-1y never be discovered, but ft will cost
your company many thousands of dolbrs In
higher costs over the next several years. Your
company has a strlng,,nt policy of firing employees who comm.it serious ethical violations.
~take sure to explain your reasons for the
actlon(s) you would take, if any.
6. Search the Web or business periodicals In your
library such as Fotbes ~tagazlne for information
on three or four dlief Information officers of large
companies or organizations.
a. Whlch Industry sector, comp~es, and aOs did
you find?
b. For each CIO that you researched, what was
their predominant experJet1ce prior to becoming a CIO; tl1at Is, did they have an infonnation
technology background, a business backgrow1d,
or both?
c. f<>r each CJO, what ts their Je,-et of educatlon?
d. How many years h.as each been a CID, and for
approxlm.1tely how many differe11t companles
has each one worked?
e. Based upon your research, what knowledge and
skills does a CIO need in order to be successful?
Why?
O
I. What do you think will be possible technologlcallj•
l Oyears from now? How abottt 20 or 30 years
from now? Re.seard1 a new and interesting technology tl1at is lo the research and development
stage. Prepare a presentation using a movie clip
aad PowerPoint on this tedu1ology and pre.sent Jt
39
Minicases
to the class. Submit a short paper on the Impacts
this new technology mJght have 011 sodety and/or
businesses.
2. Consider outsou.rch1g: It ls many times the case
that at least part of tl1e development ptocess ls
outsourced. In fact, project leaders tod,y must be
40
Part ono
Tho Contoxt of Systoms l>ovolopmont ProjOffl
capable of handlh1g geographically diverse teams
as well as tlmeUne and resource constraints. Outsourcing brings 10 the table h1creased efficietlC)'
and economic galns to the societies tl1..1t are interacting. However, these gains are not quickly realized, and the neg,1t!ve Impacts on a society that is
outsourcing can be sign!fkant from a jobs perspective. Dr. btanklw, as an economic advisor to
President Bush, publiciy touted the benefits of outsourcing and was deeply criticized for his stance.
Do you think that ll is good or bad for a business
to outsource work? Do you tllin.k there are ethlcal
dilemmas for comp:ulies who outsotirce? Find at
least two artides on the impacts of outsou.rch1g,
and brin.g them to share with the class.
3, You are a network administrator, and as part of
your job, you monJtor employee e-mails. You discover thlt your boss is cutting comers on a $)'stem
Team and Individual Exercises
l. Get toged1er Into small groups of two.The first perso11 will decide on a task tl1at he/she wishes to be
completed-for itmance, sharpen a pencil or write
down the name of the professor. It st1oti.ld be simple and stralghtforward. That person is to comm,,
nlcate 011 paper using only diagrams and no words
(vernal or writtet1) what he/she wishes 10 be done,
and gi,-e ft to person number two. Person number
two sl1ould then complete the requested task.
2 . W11at dJd you discover from this exercise? How
long dld it take untll the second person tmderstood what the first person was askh,g for? Was
Suggested Readings
Amblea; Scott.
Agtle Alodeltng: B/fecttve.
that your company is developh1g In order to finish
the project more q<tlcldy and to stay w1der budget.
There is a flaw in the system as a result, and this
flaw wlll cause a nerwotk crash if more than
20 people are on the network at a time. The client
expects approximately 12 people on the networt
at any given time. You are sure, as apparently your
boss is, tl1at the customer will not find ottt tmtll
well after the project is accepted (lf ever). What
do you do?
4. A S)'stems analyst must be both tecimlcally proft.
dent and capable of successful customer communlcatlon. Developing a good S)'stem requhes a
complete understanding of user requirements
r.tany times, users don't know wh.at is avalL1ble
(technologically) or even what they wo,tld llke
from a system. What are characteristics of good
comruunlcatlon?
~
there mlscommunicatlon? Write down your
thoughts and observations, and share them with
the class.
3. lndlvtdual exercise: Imagine a really cool technology. The sl1· is the limit, and anything is possible.
How does tills technology Impact your life? Does
It impact business?
4. lndlvtdual exercise:11llnlc back on tl,e last time
someone told you sometlling cou.ld1i 't be done.
W11at was ft? Did you listen to them? Why or
why not?
~
Practfc.es
Jor ex-
trenie Progm1n111fng and the Un{fted Pt'Ocess, New Yolk:
John Wik)• & Sons, 2002. This book has signifteantly
shaped our thinking about the solt\\,are ck,-clopmcnt
procc55. Those of you v1tho arc critical of the •extremeprog:r.unmi.ng" mo,tmcnt nc:,c,d not fear that our c:nthusi·
asm fur this suggested reading indicates an endorsement
of extreme programming. We simply like the sanity that
Scott brings to the process of systems and software ck\-cl·
oprnc:nt through the use of flexible rnct.hods within the
context of an itentive process. We will reference this
book in sn•eral chapters.
Emest, Kalltran;John Grillo; and James Linderman. Btbfcal
Dectston .Waktng and Itifonnatton Technotog:t: An It~
troductto:1. UJab cases, 2nd ed. Burr Ridge,
ll.: 1\otcGnv.•Hi.U/ltwin, 1995. This is an excellent textbook for teaching
ethics in an 1\otts curriculum. It is a collection of case studies that can comple.ment a syste.ms analysis and design
course.
Gartner Group IT Syrnposiurn and Expo (annual). Our tUliversity's manage.rncnt infonnation tUlit has Ion@ sut>scribcd to the Gartner Gtoup•s sendce that reports on
industry trc:nds, the proOObilitics for success of trends
and technologies, and suggested strategics for inhrma·
tion technolog}' transfe.r. Garme.r rescaN:h has pla,-cd a
significant, ongoing role in helping us to chart business
and technology drivers as described in this chapter. We
ha,-c also bcdl fortunate to be able to attend Gartncr•s
annual IT S)'ttlposium. Garme.r Group rc:port! and
symposiums ha,-c influc.nced each edition of the book.
Fo r rnore information about the Gartnc.r Group, scc
www.gartncr.com.
Tho Contoxt of Systoms Anolysls and Dosg, Mothods
Gause, Donald and Gerald Weinberg. Aro Jtiur Ugbts Ou?
HOUJ to Ftgure Out
Wbat tbe Proble111 REALLY JS, New
Ycrk: OorSC't House Publishjng, 1990. Yes, this is not a rt'·
cent book, but neithe r arc the fundamentals of problC!U
solving. He rc's a short and casy-t~rcad book abo ut gen·
chi prob k .rn sol·l'i.ng. You can p robably read the e ntire
bcok i.n one night, and it could p rofoundly i.blpro,t your
proble m-solving potential as a systc.ms analyst (ot; fo r that
nu.ttct; any othe r profession) .
Levine, Martin. Bffectfve Proble111 sotvtng, 2nd ed. Engle·
'\\'OOd Cliffs, NJ: Prc ntkc Hall, 1994. This is ano the r o lder
book, but as we stated before, p roble m-solving blC'thods
arc time less. At only t 46 pages. this title can scr,t as m
excelle nt p rofessional rc fclt'J\Cc.
Choptor Ono
41
Weinberg, Gerald. Ret!Jtnt!tng S)1ste11JS AnatySf; and Destgn.
Ne\\• York: Dorsct Hou se Publishing, 1988. Don 't let the
date fool you. This is o ne o f the best and rn:,st important
books on this subject c,.•er written. This book may not
teach any of the popular systems analysis and design lllC'th·
ods o f our day, but it chalkn.gcs the lt'adc.r to leap beyond
t.hose methods to consider soructh.ing fu.r mote importantthc people side o f systems work. Dr. Weinbc-rg's theories
and concepts arc presente d i.n the co ntext o f do:zcns of
de lightful mblcs a nd sho rt expe riential st·:>rics. We arc
grateful to him fo r our Jitl'o rite syste.ms analJsis h blc of all
time, "TheThttc Ostriches.•
Business
cr1vers
Goel,
G 081;
IMPROVE
B USINESS
PROCESS&:$
IMPROVE
BUSINESS
COMMUNICATIO NS
~
;t\j-
"<
~
'
,
,
j\...
"""
j\...
"<
·~
j\...
~
'
,,
";;!
">z
"
>
;;I
"""
•,
....
<
;;I
"""
"
~
SOl'TWAAE
le:CHNOLOG E:$
NETWORK TECHNCLOGIES
Tecrino1ogy
Drivers
Information System
Bui Id i ng Blocks
Chapter Preview and Objectives
Syste-ms analysis and design methods are used to develop information systems for organization.s. Before learning the process of building systems. you need a clear understanding
of the product you are trying to build. This chapter takes an architectural look at information systen1s and applications. We will build a framework for information systems architecture that will subsequently be used to organize and relate all of the chapters in this
book The chapter will address the following areas:
I atferentiate between.front- and back-office information systems.
I De.scribe the different classes of information system applications (tmnsaction
p1ocessin.g, n1a.11Dgen1ent information., decision support, expert, co,nnumication and
ccl/aboration, and office automation systems) and ha.v they interoperate to supplement
one another.
I De.scribe the role of information systems architecture in systems development.
I Identify three high-level goals thac provide syscem owners and syscem users wJcb a
perspective of an information system.
I Na.me three goal-oriented perspectives for any information systems.
I ld!ntify three technologies that provide system designers and builders with a
perspective of an information system.
I Describe four building blocks of the KNOWLEDGE goal for an information system.
I Describe four building blocks of the PROCESS goal fo, an information system.
I Describe four building blocks of the COMMUNICATION, goal for an information system.
I De.scribe the role of network technologies as it relates to KNOWLEDGE, PROCESSES, and
COMMUNJCfflONS building blocks.
44
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
111e SoundStage member services system project is getting underway. Bob Martinez
has been assigned the task of conducting lnltial meetings wld1 groups of system users
to g.1lt1 their perspective on the system and what It must accomplish. He quicldj• cllscovered that everyone had a cllJferent perspective and expressed that perspective in
a different language. ltt college, majoring in computer information ~terns technology, Bob tended ro think aboln information systems In rerms of programming languages, nerworldng tedUlologies, and databases. He found d1at the others didn't think
in tl1ose tenns. The system users talked about manual forms and how they were
routed.111ey talked about policies and procedures and reports they needed. As he
met with managers he heard them talk abour strategic plans and how the system
coldd gi,-e the org;ulizatlon a competltl,. e. edge.
It reminded Bob of the old story he h.ad heard abom three bllt1d men who came
upon an elephant. One felt the trunk and concluded that an elephant was like a snake.
Another fel t a leg and concluded tl1..1t an elephant was like a tree. The third felt aJl ear
and concluded that an elephant was like a fan. It didn't take Bob Jong to realize that
the owners· and users· perspect!Ves were Jusc as valid as h.Js. An infonnatlon syscem is
more than tedmology. It is mainly a tool that serves the goals of the organlzation.
~~~T_h_e~P_ro_d_u_c_t~ l_n_f_
o_rm
~ a_t_
io_n~S_y_ste
~m
~s ~~~~~~~~~~~~)
£root-office i.o..formatioo
system an inbrmation sys.
tern thatsupports business
functions that roend out to
the organization's customers.
In 01apter 1 you were lntroduced to lnfonnatlon systems from four dtfferen1 perspectives, including stakeholders, business drivers, tedUlology drivers, and ti1e
process of systems development . As suggested by the home page (see p. 42), tills
diapter wUI more dosely examine the information system "product.•
Organizations are served not by a single information system but, Instead, by a
federation of Information systems that support '\o":lrious business ftmct:ions. Th~ idea
is Illustrated in Figure 2·1. Notice that most businesses have both front-office
, FIGURE 2 - 1 '
A Federation
o f InforJriation
'-Systems
cusro.AI
....... ·-·~
I
t
·-
"'"'
......
En1ttpri• • R,,ourc• Pl,nnil'l9 (ERP)
Olli,o
11"3.cw.,lic..,
11"3.cw.,lic..,
~
11, n, 9,111,1.t lnforrn, tiol'I , .nd O,oi,iol'I lvppon ly,i.n1t
•i •
;
;
l
"""'
......
Olli,o
-.,_-
"*"'"•'°'•
Eni.rprit• R,,ovrc• Pl• l'll'ling (ERP)
.......
.........
.,_
~
........
.....
-
..........
SUPPL.IERI
....._
....
IIAwa...,.;..,,
~
•
Information Systom auildlng Blo,ks
4S
Chaptorlwo
informatl.011 systems tltat support business functions that reach out to back-Office ioformatio-o
customers (or constituents) and back-office btfonn..1tlon systems t11at support system an information
internal business operations as well as interact with suppliers. These front- and system that supe>orts internal
back-0ftlce information systen1s feed data to management information systems and business operations of an
organization, aswell as
decision support systems that support management needs of the business. Con- reaches
out to suppliers.
temporary information $)'stem.s are Interfacing with customers and suppliers using
electronic commerce technology, cttStomer relations management (CR}.I), and
supply chain management (SC~I) appllcatlons (see descriptions In Chapter I) over
the Internet. Finally, most companies have some sort of Intranet (Jnternal to the
business) to support commlmications betweett employees and the information
systems.
In Chapter l you learned that there are several dasses of information system ap.
pllcatlons (see opposite page). Each class serves the needs of different types of users.
In practice, these cbsses overlap such that it lsn 't always easy to dtffere11tiate. one
from another. The "-arlous applications should ideally interoperate to complement and
supplement one another. Take a few mome11ts to study Agure 2-2, which Illustrates
typical roles of lnformatio11 systems lo an organl.ation. The rounded rectangles
represent various informatio11 systems. Notice that aa org.'lnlzatlon can and will have
multiple t:ransaction-proccssing systems, office automation systems, and the like.
The "drum,. shapes represent stored data. Notice tl--gt an organlzatio11 has multiple
"""'g,;,rn• nt
"'"""'""
0
.,,_o:rllon
1nr«mellon
..
.,,_o:rllon
__sotiu.inou
modo..
~
0
_..
-- ---
.. .
•••
I ll
-
FHWod •
_... -- ..
.. -·
-
,.,rpralrodl
0
-
Tm
_..
--- - ---
... .
Int
0
,--1
I
,._ ..
-·
-
1nt.irm, 11on
••
II
...
"
I""' 0
AIWOCII•
0
1nl'clrmdGn
-- .. ....
o:
.....
-M
·--M..... t~J
I;::, ·"",::" ~= ~
-
I
I
1
,._9on1111d I
-
•••
I
G
-!!!!!
ond doi.
(•NI 9ff'IIP)
CD
e,_,.,
a... a 1nror111011on
( F IG U R E 2 • 2
:FIIIJlrOd .
1,.orgonll:OCII
~
---- -·-- --- - i
_Jo
.,._
I •••
T
0
a.n.o:rllOn
t.-~
_._.; - - •
, ~.? '
Information Systems Applications
-)
46
Part ono
CLASSES Of
INFORMATION
SYSTEM
AP PU CATIONS
Transaction Pr,icessing
System (TPS)
Management Information
System (MIS)
Decision Sup!X)rt System
(DSS)
Executive lnfo,mation
System (EIS)
Expert System
Communicationand
Collaboration System
Office Autoll\llion System
1ho Contoxt of Systoms l>ovolopmont ProjOffl
sets of stored data, and only some of them work together. We call your attet1tlon ro the
following number arutotatlons on the diagram:
O TI1e first transaction processing ~·stem responds to an input transaction's
data (e.g., an order). It prcduces tr.u1Sactlon lnformatlon to verJfy the correct
processing of the inpur transaction.
0 TI1e second transaction processing system merely produces an output trdnsactlon (e.g., an Invoice). Such a system may respond to something as simple
as the passage of time (e.@., Jr is the end of the month~ therefore, get1erate all
Invoices).
O TI1e first management lnformatlon system simply produces reports or
Information (e.g., sales analysis reports) using data stored In transactional
databases (maintained by the aforementioned transaction processing
systems).
O The second management information system uses business models (e.g., MRP)
ro produce operational management Information (e.g., a production sd1edu.le).
0 Notice that an ~fIS may use data from more than one transactional databise.
() Notice that snapshots of data from the transactional databases popufate a data
warehouse. 111e snapshors may be taken at various time intervals, and dtfferent
subsets of data may be Included ln various snapshots. 111e cbta In d1e watehouse wUI be organized to ensure e~· access and lnqulry by managers.
O Decision support and executive Information systems applications wlU typically provide read-only access to the data warel1ouses to produce decision
support and executive managemet1t Information.
O An expert system requlres a special database tl1at stores the expertise In the
form of rldes and heuristics.
(:) An expert system elther accepts problems as Inputs (e.g., Should we grant
credit to a spedflc ctlStomer?), or senses problems in the environment
(e.g., Is tl1e lathe producing parts wlthln acceptable specifications?), anrl
thetl responds to a problem with ai1 appropriate solution based on the
system's expertise.
~ Persona) office automation systems tend to revol,--e arow1d the data and busJness processing needs of an lndhidual. Such systems are typically developed
by the users themselves (ai1d run 011 personal computers) .
'1) Work group office automation systems are frequently message-based (e.g.,
e-mall-based) and are smal.Jer-scale solutions ro departmental needs. As sbow11
In tl1e figure, they can access or Import data from Lieger, transaction processing
systems.
In the average business, there will be many Instances of ead1 of these different
applications.
A Framework for Information Systems Architecture
iaformatioo systems
arcb.itectt1re a unifying
framework into which various
stakeholders with different
perspectives can organ iz:e
and view the fundamental
building blocks of information
systems.
It has become fashlonable to deal with the complexlty of modem Information systems
by using the term archltectu.re. Information technology professJonals speak of data
archltectures, application architectures, network architectures, software architectures,
and so forth. An iafonnatioo systems architecture serves as a h.lgher-level f.ramework for understanding different views of t11e fundamental b,uldlng blocks of an
information system. Es.,entially,fnfonnatlon systems architecture provides a foundation for organizing the "-arlous components of any lnformatio11 ~tern you care to
develop.
Different stakeholders have different perspectives on or views of an lnformatlon
system. System owners and sysrem users tet1d to focus on three common business
goals of any Information system. These goals are typlcaUy estahllsbed In response to
Information System aulldlng Blo,ks
one or more of the business drtvers you read about ln Chapter l .T hese goal-orlented
perspecth,--es of an Information system include:
The goal to improve b·ust1,ess k11owled!fJ, KJ.1owledge ls a product of information and data.
The goal to improve b·ust1,ess processes and senices.
The goal to improve b ·ust1,ess cott1:111.·u1J.f.catlons and peopJe collaboratlo11.
Toe role of the system designers and b,ulders Is more technical. As such, their
focus tet1ds to be pfaced more on the tedu,oiogles that may be used by the Infor-
mation system in order to achieve the business goal.The system desfgners•aod builders•
perspecth,--es of an Information system tend to foctis more 011:
The database teclniologf.es that support business accttmulatlon an d use of
business knowledge.
The softuVlre teclnJ.ologtes that automate and support business processes an d
senices.
The in.terface technologies thar support busine.g commun.lcatlons and
collaboratlo11.
.As
sho wn ht Figu re 2 3, the inten;e-Ctlo n of these perspectives (rows and
columns) defin es building blocks for an lnformation system. ln the next section, we
will describe all these information system building bbcks.
NOTE: Throughout tllis book, we use a consistent color sd1eme for both the
Cramework and the "-arJous tools thar relate to, or docttment, the bulldfng blocks.
Toe color scheme Is based on d,e building blocks as follows:
•
•
•
represetlls something to do with
represetlls something to do with
represetlls something to do with
!ll~iiii:iil
PROCESSES
iiiill•••
Toe information system b,uldlng blocks do not exist In Isolation. T hey must be
carefully synchronlzed to avoid Inconsistencies and Incompatibilities within the
system. For example, a database designer (a system designer) and a program.mer
(a systetn bu.rider) have tl1eir own architectural views of tl1e system; however, these
views m ust be compatible an d conslst:ent lf tl1e system Is golog ro work properly.
Synchronization occurs both horizontally (across anygivet1 row) and vertlcally (down
any givei1 column) .
h1 the remainder of this dupter, we'll briefly examine each focus and perspect!vethe bulldlne blocks of information systems.
> KNoWlEDGE
Building Blocks
lmpro,ing business knowledge ls a funda metllal goal of an Information system. As you
learned lo 01apter 1, business knowledge Is deriwd from data and information.
Through processh1g, data Is rellned to produce information that res,tlts In knowledge.
Knowledge is wt1at ei1..1bles a company ro adlieve Its mission an d vision.
The KNOWLEDGE column of your fra mework Is Illustrated lo Figure 2-4. Notice ar
t11e bottom of the KNOWLIDGE column that our goal is to capture and store busloess
dara using DATABASE TOCHNOLOGCES. Database tedinology (such as Access, SQL Server,
DB2, or Oracle) will be used ro organize and store dara for all lnfonnation systems.
Also.as you look down the KNOWLEDGE column, each of our different stakeholders h.as
different perspectives of the Information system. Let's ex.amJne those '\oiews and
discuss tl1eir relevance to tl1e KNOWLEDGE column.
System Owners' View of KNOWLIOCI T he average system own er Is nor interested In raw data . The system owner is Interested In information tl1..1t adds new
buslness kt1owledge. Business knowledge and information help mat1..1gers make
Chaptwlwo
47
48
Part Ono
Tho contoxt of Systoms Dovolopmont ProJo<ts
Business
Drivers
Goel:
IMPROVE
BUSINESS
PROCESSES
R M AT
••wz
..
"..
.."
..
....
3
0
•w
<
BUILDING BLOCK
BUILDING BLOCK
BUILDING BLOCK
;;I
"
••
>
•
z
~
•<.>
..
0
"
••w
•••
w
BUILDING BLOCK
BUILDING BLOCK
BUILDING BLOCK
~
....
<
••
t
•
~
~
v
c
..•
..
>
..
..
..
..•
~
z
••wz
0
.... ..""
~
"
0
•w
BUILDING BLOCK
BUILDING BLOCK
<
BUILDING BLOCK
•>
•
..
~
..
..
>
••~
•"
••~
~
BUILDING BLOCK
BUILDING BLOCK
BUILDING BLOCK
<
•>
•
NETWORK TECHNOLOGIES
Tecnno1ogy
Drivers
( F I GU R E 2 • 3 Infom,ation System Perspectives and Focuses
)
Information System aulldlng Blo,ks
8
-
.....
-..
..
..•
-
~
z
~
0
•
••
•<
z
<
•
•
•
•
0
0
••
•
•'
••
•>
<"
z
<
•
••
•
•>
•
..
t;;
•
v
Driver,
Goel,
IMPROVE
BUSINESS
COMMUNICATIONS
1NFORMATION
7
F'.lNCTIONAL
SCOPe
&
SOOPE
VISION
VISION
SYST EM
0
~
rot.MUNICATIONS
SOOPE
•
-
•
\r
VISION
~
~
>
--
....
..•
~
~
t;;
'
~
•
J,.
0
EUSINESS
BUUE88
°"'A
FEiJil ll=IB ElfTS
v
PROCESS
BUSINESS
INTEAi;t.CE
REQJIAEMENTS
RECUIAEMENTS
-
'
1;1~
i:i
•
~
~
~
'
0
....
.."
ill
..
....
.."'
..•
..
'
~
z
;;
EUSINESS
•
1;1-
PROCESS
v
INTEAi;t.CE
DESIGN
DESIGN
DAlM\SE
llEmN
Q
"z•
~
~
SOl=TWARE
t;;
•
DESIGN
>
i
i'"
COM,ilERC IAL
SOl=TWARE
~
Q
~
t;;
....,,.,
DAlM\SE
SOI.UllON
v
INTEA~CE
SOLLITION
~
CUSTOM-BUILT
APPLICATION
PROGRAMS
,
DAlM\SE
TEa1NOl.OOIEII
I
~
~
-
.....
~
F IG U R E 2 • 4
;1- '
A\CKAGES
•
>
-
•••
Goel,
BUUE88
......
n
MPROVE
EUSINESS
PROCESSES
IN>MSlQE
-
U 8 I
49
Chaptwlwo
~
SOl=TWARE
TECHNOLOGIES
INTEAi;t.CE
TECHNOLOGIES
NETWORK. TEC HNOLOGIES
Tecnno1ogy
O
r I V
..
'
A BUSINESS l<NOWLEOGE Perspective of Information Systems
I
so
Part One
1ho Context of Systems l>owlopmont ProjOffl
intelligent decisions that support the organ.izatlon•s miss.ion, goals, obJectlve.s, and
competitive edge.
Bush,ess knowledge may Initially take tl,e fonn of a simple list of business entitles
and business rules. Examples of business entitles might indude cusroMERS,PRooocrs,
J3;2UIPMENT, BUDDINGS, ORDflt5, and PAYME'tf'S. Wh.at do business entitles have to do wJth
knowledge? Information ls produced from raw data tl1at describe these business
entitles. Therefore, lt makes sense that we should quickly Identify relevant business
entitles about wbid1 we need to capture and store data.
It ls also useful to understand simple business associations or rules that de.scribe
how the business entitles Interact. Examples of useful business rules for a sales system
mlght h1dude tl,e followh1g:
• A CUSTOMER can place oaoms- an oRDm must be placed by a cusro~.
• An ORDEll sells PRODUCTS-a ?Ro oucr mav be sold on an oRDm.
lntulttvely, a system's database needs to track these business entities and rules in order
to produce useful h1fom1atlon (for example, "Has cusroMEt 2846 placed any unfilled
ORO~S?").
System owners are concerned with the bJg picture. 111ey are generally not Interested ln details (such as what fields describe a
CUS'l'OMm or
an on.om),The prim:l.ry role
of system owners h1 a systems development project should be to deJlne the scope and
vision for the project. For KNO"KLEDGE, scope can be defined In simple terms sud1 as
the aforementioned business entitles and rules. System owners define project ,islon
and expectations In terms of 1helr Insight Into problems, opportunities, and constraints as they relate to the business entitles and rules.
data requiremeot a
representation of users' data
in terms of en1ties, attributes,
relationships, and rules.
System Users' View of KNOWl.!OCI! Information system users are knowledgeable
about the data tl1at describe the business. As Information workers, tl1ey capture,
store, process, edJt, and use that data every day. They frequently see the data only
in terms of how data are currently stored or how tl1ey tll.iok data should be stored.
To them, the data are recorded on forms, stored in file cabinets, recorded h1 books
and binders, organized Into spreadsheets, or stored in computer fl ies and databases. The challenge In systems development ls to correctly Identify and ,·erJfy
users• business data requJrements. Data requ1remeuts are an extension of the
business entitles and rules that were inltially Jdentlfled by the ~·stem owners. System users may ldetlllfy additional entitles and ntles because of thelr greater lamiliarJty wlth the data. t.tore importantly, system users must specify the exact data
attributes to be stored and the precise business rules for maJntaJoing t11at data.
consJder d1e followtng example:
A system owner may Jdentlly the need to store data about a business entity called
cusTO~. System users might tell us tl1.1t we need to differentiate between
PROSPEC'llVE CUSTOMERS, ...cnvt CUSTOMEt5, and INACl1VE CUSTOMERS becatlse they lmow
tl1at slightly different types of data describe each type of customer. system users
can also tell us precisely what data must be stored about ead1 type of ctlstomer.
For example, an AC'nVE cusroMER mJght require such data attributes as CUSTOMER
NUMBER, NA..\ffi, BIUJNG ADDRE!S, CREDIT R.ATCNG, and CURRENT BALANCE. Finally, system
users are also knowledgeable about the precise rules that go,-en1 entitles and relationsh.ips. For example, they might tell us that the credJt rating for an ACTIVE
cusro.\.UR must be PREff.RR.fD,NOR..\tAL, or PROBAnONARY and that the default for a new
custom er is NOR.-\tAL. TI1ey mfght also specify tl1.1t only an ACTIVE cusroMEJ. can
place an ORDEJt., but an ACliVE CUSTOMER m.Jght not necessarily l1.1ve any current
ORDERS at any gj,-en time.
Notice from the abo,,..e example that the system user's data reqttlrements can be
identified Independently oft11e DATABASET&:HNOLOGY that can or will be used to store
the data. System users tend to focus on tl1e .. business• i~ues as they pertain to
Information System aulldlng Blo,ks
d,optorlwo
SI
the data. It ls Important that the system users pron.de data requirements tl1at are
consistent with and complementary to the lnformatlon scope and vision provided by
the ~·stem owners.
System Designers' View of KNoWllDC! The system designer's KNOWLEDGE perspective differs significantly from the perspectives of ~·stem owners and system
users. TI1e system de.signer is more concerned with the DATABASE TECHNOLOGY that
wlU be used by the Information system to support business knowledge. System designers translate the system users' business data requirements into database designs
that wUl subsequently be used by system bullders 10 develop compu1er databases
that will be made available via the information ~·stem. TI1e system designers• view
of data ls constrained by the limltatlons of whatever database management system
(DBMS) ls cbosen. Often, the d1olce has already been made and the developers
mltSl use tl1at technology. For example, many businesses have standardJzed on an
enterprise DBMS (such as Orade, DB2, or SQL Se•ver) and a work group DBMS
(such as Access).
In any case, the system designer's '\oiew of KNOWIEDGE consists of data structures,
database scbemas,flelds, indexes, and other technology-dependent components. ,_lost
of these tecboicnl speclflcatlons are too complex: to be reasonably understood by &)'S
tem users. The systems analyst and/or database specialists design and document these
tedmlcal views of the data. Thls book will teacb tools and techniques for transforming business data requirements into database schemas.
System Builders' View of KNOWU!OCI The final ,·Jew of KNOWLEDGE is releYant to
the ~·stem builders. lo the KNOWLEDGE column of Figure 2-4, system builders are dos.
est to the actual database management system technology. They must: represent data
in ,-.ry precise and unforgiving languages. The most commonly encountered database
language ls SQL (Strr,aured Qr,ery Language). Altematlvely, many database management ~tems, such as Access and Visual fu"<.Pro include proprietary languages or
facUIUes for constructing a new database.
Not all information systems use database technology to store their business
data.Many older legacy systems were built withflatfile tecbnologles sud1 asVSAM.
These flat-file data structures were constructed directly wlthJn the programming
language used to wrJte the programs that use those files. For ex.ample, In a COBOL
program the flat.file data structures are expressed as PICTURE clauses in a DATA orvistoN.
It is not the latent of this book to teach either database or flat-file construction
languages, but only to place them In the context of tl,e KNOWLEDGE bldldlng block of
infonnatlon syscems.
>
PRocess Building Blocks
Improvlng business and services processes Is another fundamental goal of an lnformatlo11 system. Processes deliYer the desired functionality of an lnformation system.
Proc.es.,es represent the tiork In a ~tern.. People may perform some processes, wltlle
computers and machines perform others.
Toe PROCESS building blocks of information systems are illustr.tted In Figure 2-5.
Notice at the bonom of the PROCESS colwrut tl1..1t soPTWAR.ETECHNOLOGCEs will be used to
automate seJected processes. As you look down the PROCESS column, each of our dJf.
ferent stakeholders has different perspectives of the information system. Let's
examine tltose views and discuss their relevance to the PROCESS column.
System Owners' View of PROCESSES As usual, system owners are generally interested In the big picture.They tend to foalS not so mud1 on work flow and procech.tres
as 011 hlgh~evel business functions, sucb as those listed In the margin of page 53.
Organlzacions are often org.ut.ized arottnd these business fuctions wtth a "ice presJdent
business functioo a group
of related processes that support the business. Funciions
can be decomposed into other
subfunctions and eventually
into processes t'lat do specific
1aSks.
52
1ho Context of Systems l>owlopmont ProjOffl
Part One
Bue1ne
- -
••
Drivers
Goel:
Goel:
Goel:
IMP ROVE
IMP ROVE
IMP ROVE
BUSINESS
KNOWLEDGE
BUSINESS
PROCESSES
BUSINESS
OOMMUNICATIONS
INF OR MATI ON SYSTE M"',~,,.
•z
u
RJNCTIONAL
~
..•
..
•
~
•<.>
..
~
0
•
~
a
c
••
>
•
•
•
••
/"
u
••
>
•
z
..
..
>
P ROCESS
REQUIREMENTS
BUSINESS
"
,/
~
.. ••
.. •
..
..• - •
~
"<
"
BUSINESS
•
-
~
z
J.
u
u
~
•
VISION
~
..•• - •
.. •
>
SCOPE
/
u
.."
.. z
"
0
~
P ROCESS
DESIGN
"<
"
..
SOnwAAE
DESIGN
>
-
"f i"
COMMERCIAL
SOnwAAE
u
0
~KAGES
"5
''\
0
a
•
/
ana/ or
CUSTOM-BUI.T
APPLICATION
PROGRAMS
•>
•
- -
,''
~
I
F I GU R E 2 • S
~
DATABASE
SOn'WAAi
TECHNOLOGI ES
TECHNOLOGIES
INTERl;\CE
TECHNOLOGI ES
NETWORK TECHNOLOGIES
Te c nno1ogy
D r I v e
'
.
A BUSINESS PROCESS Perspective of Information Systems
I
..
>
z
>
Information System Building Blo,ks
d,cptor lwo
overseeing each fw1ctlon. Unlike business e,-ents (rud1 as CUSTOMER sua,urs ORDER)
tl1at have a defl.nlte beghuling and end, a business function has no starting time or
stopping time.
Hlstorlcally, most informatio11 systems were (or are) fi,11ctto11.<entered. Thar
meaa.s the ~·stem supported one business function. An ex.ampJe would be a SALES
Sales
JNFOF.MATION SYSTEM that supports only the ln.itlal processing of customer orders.
Service
53
TYPICAL BUSINESS
FUNCTIONS
Today, many of these single-function Information systems are being redesigned as
Manufacturing
cross-functio1uJ information systems that support several business functions.
Shipping
As a contemporary altematfve to the tradJtlonal SALES tNPOR.-\IIATION SYSTEM, a crossR
ecei~ng
functional ORDER fUlFCLI.MENT INFOR."1ATION SYSTE.\t would also support all relevant
Accounting
processes subsequetll to the processing of the customer order.1bls would lndude Ill~
Ing the order In the warehouse, shipping the produm to the customer, billing the cus.
tomer, and pro'\oidfng any necessary follow-up ser,ice to the customer- lo other
words, all business processes required to ensure a complete and satisfactory response cross-functional
to tlie nistomer order, regardless of wll.ich departments are it1vol,--ed.
i.o.formatioo system a
As sl1own In Figure 2-5, the system owners view a $)'stem's business PROCESSES system that supe>orts relevant
with respect to the functional scope being supported by the systems and to a vi- business processes from
sion or expect.a tlon for improvements. The system's business functions are fre- several business funciions
without regard to traditional
quently documented by ..ysrems analysts in terms o f simple lists of business events
and responses ro tltose events. Some examples of business events and responses
are as follows:
orgamzauonai counaanes
such as divisions, depart·
ments, centers, and offices.
Event: CUSTOMER SUBMJTS O RDER
Response: CUSTOMER RECEJVES ORDER.ED PRO DUC'fS
Event E.\.U'L.OYEE Slm.\U'fS PURCHASE R.EQUISITION fOR SUPPUES
Response: E.\IIPLOYEE R.OCflVES REQUES'fED SUPPUES
Event END Of MONTH
Response: CN\OICE CUSTOMm'> AGAINST ACCOUNTS
With respect ro each evenr and response identified, system owners would identify perceived probletns, oppormnlties, goals, objectives, and constraints. The costs
and benefits of developing infonnatlon systems ro support business fw1ctlo11s would
also be cllsc1.issed. As wa.s the case with KNOWLEDGE, system owners are not concerned
with PROCESS details. That level of detail ls ldet1tlfled and documet1ted as part of the
system users' view of processes.
System owners also frequently ldet1tlfy senice.s and levels of service that they
seek to pro"ide to customers, suppliers, and employees. A popuL1r example is customer, supplier, or employee self-service. Human re.source syscems, for example,
incrtaslngly provide employees with tlte ability ro enrer their own transactions such
as d,ange of address, medical dalms, and training requests. S)'stetn owners also Identify
needs for lnformation systems ro impro,--e sen-ice by reducing errors and lmpro"ing
service.
This book will teach you how to ldet1tlfy and document project scope In terms of
rele"'aflr blislness functions, business events, and responses.
System Users' View of PROCISSIS Retunling again to Figure 2-5, we are ready to
examine the system users' view of processes. Users are concerned with the business
processes, or-Work;' tl1..1r must be perfonned In orckr ro pro"ide tlte appropriate respo11Ses to business evet1ts. System users specify the business process In rerms of
proceM req,1lremei1ts for a new system. Process requirements are oftett documented In terms of actfvitles, dara flows, or work flow.
These process requirements must be precisely specified, especially If they are to
be auromared or supported by software rechnology. Business process requirements
are frequently defined In terms of policies and procedures. Policies are explicit
r ules t11..1r must be adhered ro whett completing a business process. Procedures are
tl1e precise steps to be followed In completing tl1e business process. Consider the
following example:
process requ.iremeots a
user's expectation of the
processing reqlirements for
a b.Jsiness proc.iss and its
information sy"S'ems.
policy asetolrules that
govern a b.JsinEllSs process.
procedure SWp.by-step set
of instructions and logic for
accomplishing a business
process.
54
Part One
1ho Context of Systems l>owlopmont ProjOffl
CllEO JT APPROVAL is a policy. It establishes a set of rules for detennlnfng whether or
11ot to extend credJt to a customer. That credJt appro'\<-:tl policy ls usually applied
within the context of a speclflc CR.fDJT CHB:K procedure that established the cor.
rect steps for checklng credlt agalnst the credlt policy.
work Oow tie flow of trans.
aciions th rough business
processes to ensure approprj.
ate checks and approvals are
implemented.
Process requirements are also frequently specified In tenns of work flow. ~tost
businesses are very dependent on checks and balances to irupJement work flow. For
example, a purd1ase requisition may be lnlthlted by any employee. But tlut requisition
follows a speciJlc work flow of approvals and checks before It becomes a purchase
order transaction that ls entered lnto an information processing system. Of crurse,
these checks and balances can become cumbersome and bureaucratic. Systems analysts and users seek an approprorlate balance between checks and balances and
sen-ice and performance.
Once again, the challenge in systems de,-elopment is to identify, express, and analyze business process requirements exdusJvely In business terms that can be understood by system users. Tools and techniques for process modeling and documet1t1tlon
of policies and procedures are taught extetlSlvely In this book.
PRocesses As was the case with the KNOWt.EDGE building block, the system designer's view of business processes is co11Stralned bj' t11e
llmltatlons of speciflc application development technologjes such as Java, Vls1-tal
Baste.Nm; C+ +, and C#. Sometimes the analyst Is able to choose the software technology~ l1owever, often the chokes are limited by software ardlitecture standards that
specify wbid1 software and hardware tedu10Jogies must be used. In either case, the
designer's ,iew of processes Is 1edulical.
GJvet1 the busines., processes from the ~tern users' view, the designer must first
determine which processes to automate and how to best automate those pro«s.,es.
,_lodels are d.raw11 to document and communicate how selected business processes
are, or will be, implemet1ted using the software and hardware.
Today, many businesses purchase commercL1I off-the.shelf (COTS) software to.
stead of b,uldlng that software in-house. In fact, many businesses prescribe t11.11 software that can be purd1ased sl1ouJd never be built-or that only software that
pro,ides true competitive ach:antage should be built. In the case of purd1ash1g software, business processes must usually be changed or adapted to work with the software. Hence, in this scei1..1rlo the business process desJgn specifications must
document how the sofrware package will be Integrated into the enterprise.
Alternatively, in the case of building software In-house, business processes are
System Designers' View of
usually designed first. And the business process spe.clflcatlons must then be sup
softl\'3.te specifications
the technical c'esign of
business processes to be
automated or supported by
computer pnJGrams to be
¥Kitten by system builders.
plemented with software spedficatio11S tl1at document the tecbn.ical design of
computer programs to be written. You may have encountered some of these software specifications In a programmJng course. As was the case wJth KNOWLEDGE,
some of tl1ese tedmlcal views of PROCES.5ES can be understood by users but most
caonot.1l1e designers· intent is to prepare software speciJlcatlons that (I) fu!Jlll tl1e
bush1ess process requirements of system users and (2) pro,ide sufficient detail and
co11slstency for commwllcatJng tl1e software design to system builders. TI1e systems design chapters In thls book teach tools and techniques for transformlng business process requirements Into both business process design and software design
specifications.
System Builders' View of PROCESSES System builders represent PROCESSES ush1gprecise compu ter programming languages or application development et1vlronments
(ADEs) that describe inputs, outputs, logic, and control. Examples lnclude C++,
Visual Basic .NE'J', C# (part of the Mlcrosoft Vfsr,a/ Stu.tfto .NET ADE), and Java
(avalL1ble In ADEs such as IBM WebSpbere and BEA WebLogfc). Addltlonally, some
applications and database management systems provide their own inten.1..1[ L1nguages
for programming. Examples Include Vfsr,a/ Basic for Applications (in Access) and
Information System Building Blo,ks
PLSQL (in Orade). All these languages are used to write custom.bullt appllcatlou
progra.1llS that automate business processes.
This book does not teach application programmlng. \X'e will, however, demon-
d,cptor lwo
SS
application program a
language-basec, machine.
readable repres;ntation of
strate how some of these languages pro'\oide an excellent en'\oironment for rapJdly de- what a software process is
veloping a system using prototyping software. Prototyping has become the design
technique of d1olce for many system designers and builders. Prototypes typically
e,-oh·e lnro the fh1..1l version of the ~tern or application.
As mentioned earlier, sometimes decisions may ln\--olve purchasing a commercial
software package as a system solution. In this sceiurio, the system builder may need to
focus on customization that must be done to the software package. 111e system builder
may also be expected to develop application programs that must be Integrated with
tite commercial package to extend the package's functional capabllltles. Finally, the sys,
tern builder must also focus on program u tilities that must be written to h elp with the
con,-ersion and lnregratlon of the commercial program and existh1g ~terns.
> COMMUNICATIONS
Building Blocks
Let's examine our final building block- COMMUNICAJ'IONS. A common goal of most
organlzatl0tlS ls to improve business commttnlcntlons and collaboration between
employees and other constituents. Communlcatlon improvements In information
systems are typically directed toward two critical interface goals for an lnformation
system:
lnformatio11 ~tem.s must: provide effective and efficient communlcatlon lnterbces to the ~tern's users.These lntetfaces should promote teamwork and
coordtnation of activities.
Information systems must Interface effectively aod efficiently with other Information ~·stems- both wlth those within the budness and increasingly wlth
other businesses' infonnation systems.
The OO><l\llJNICATJONs building blocks of lnfonnatlon systems are Illustrated 111 our
framework in Figure 2-6. Notice at the bottom of the COM."1\INICATION column that it utilizes INTf.RW..CE r&:HNOLOGI ES to Implement the communication lnterfaces. And once
agalo, as you look down the COM.\.1.UNICATION coh1nu1, each of our different stakeholders has different views of the system. Let's ex.amJne those views and discuss their
rele\'aflCe to systems development.
System Owners' View of COIM\l.lNCATION The system owners• view of COM.\.1.UNIIS relartvety simple . Barty in a syscems developmenc project, syscem owners
need to specify:
CATJCN
With wtlich business units, employees, customers, and external busin~es must:
the new system lntetface?
Where are these business units, employees, customers, and external businesses
bcated?
WIUthe system h.ave to interface wlth any other lnformatlon, computer, or
au tomated ~·stems?
Answers to these questions help to define the communlcatlons scope of an information systems development project. ,_Unlmally, a sultable system owners• '\iew of
infonnatlon ~·stem communication scope and "ision m.Jght be expressed as a simple list of bush1ess locations or systems with whld1 the htformation system m ust Int erface. Again, relevant problems, opportunities, or constraints may be Identified
and analyzed.
System u,e,,' View of Co#M&JNCATION ~·st:em users' view of COMMUNICAn oN ls
more in terms of the lnfonnation system's inputs an d outputs. Those Inputs and
outputs can take many forms~ however, the busines., interface requirements are more
supposed to door how a
software process is supposed
to accomplish its task.
prot0typing a technique
for quickty building a funciioning but incomplEte model of
the information system using
rapid application development
tools.
56
Part One
1ho Context of Systems l>owlopmont ProjOffl
Business
Goal:
IMPROVE
BUSINESS
l<NOWLEOGE
talr.et'IOIJHI
Drivers
Goel:
IMPROVE
BUSINESS
PROCESSES
o,
I N FORMATION
~
•u
z
..•
..
.."
..
••
;t-
0
~
\r-
u
••>
•
~
'
z
0
,
~
•<.>
..
0
•
~
•
~
;L
•
••>
•
u
\f"
<
0
'
,
0
a
c
..••
..
>
..
....
..•
~
z
•
•
<
..
•u
z
~
u
;L
u
\f"
•
•
••>
•
<
0
£
>
z
>
~
..
..
>
•u
;L '
0
"•,
a
•
<
\[""
•>
•
"
~
DATABASE
TECHNOLOGIES
SOn'WARi
TECHNOLOOE S
N£TWORK TECtfllOLOGI ES
Tecrino1ogy
F I GU R E 2 - 6
Drivers
A BUSINESS COMMUN1CA110NS Perapective of Information Systems
Information System aulldlng Blo,ks
d,cptorlwo
57
Important than the technlcal fonnat. The Inputs and outputs represent how the pro,
posed system wouJd interact with users, employees, business wlits, customers, and
other businesses.
The details of tl1ose Inputs and outputs are important System users might specify the details In the form of a list of fields (and their values) that make up the Inputs
or outputs. Alten1atlvely, and because system users have become comfort.abJe with
the graphical user Interface (e.g., Wt11.do1vs or Web browsers) for the system, the
details might be specified in the form of prototypes. System users are increash1gly
demtnding that their custom-built Information system applications have the same
.. look: and feel,. as their fa\--orfte PC tools such as word processors and spreadsheets.
This common graphical user Interface makes each new application easier to learn
and use.
Both list and prototype approaches to documenting the ~·stem users' "iew of
00M.0UN1CA110N wlU be addressed In various dtapters of this book.
System Designers' View of COMMUNtcAJIION ~tttn designers must be concen1ed
with the technlcal design of both the user and the system4o..ystem commwllcat!on h,
terfaces. We caU these Interface speclflcatlons. Let's begin with the user Interface.
Users nod designers can be ln,--olvcd Ut Uttcdncc de.sign. Bur whcrcas system users
are lnterested in requirements and format, system designers have other interests such
as consistency, compatibUity, completeness, and user dialogues. The user d.L.'l.logue
(sometimes called l11terface 11avtgat1011) specifies how t!,e user wlU na>ig,11e through
an application to perform useful work.
The trend towatd graphical user interfaces (GUls) such as Wl11do1vs and \X'eb
bro"U•sers has slmputled life for system users but compUcated the design process for
system designers. In a typical Windows application, there are many different things
users can do at any gtven time- type something, cllc:k the left mouse button on a menu
item or toolbar icon, press the Fl key for help, maximize the atrrent window, mlnlmlze the current window, swltd1 to a different program, and many others. Accordingly,
the system designer '\oiews the lntetface in terms of \'arlous system states, events tl1..1t
d1..1nge the system from one state to another, and responses to tl1ose events. Today,
tl1ere are many more design decisions and considerations tl1e system designer mltSt address to docttment the dialogue of a graph.ical user interface solu tion. Tools used to
document user dialogues wlU be discussed h1 tl,e design wllt of tills book.
Web lnterfaces 11..1\-e further complicated the designer's activities. Society has come
to expect more gUtz ln Web Interfaces. For that reason, it is not at all uncommon for the
desf1!n team to lndude graplllcal design spedallsts and human-computer Interface spe,
ctalt5t5 to ensure that the mterface for a \\'eb server ts both compelling and easy to use.
Althougb not depicted In Figure 2-0, modern system designers may also design
keykss in.terfaces such as bar cod.fog, optical character recognition, pen, and voice or
l1..1ndwrlting recognltion. These alten1..1tlves reduce errors by eUmloating the keyboard as a source of hum..10 error. However, these interfaces, like graphical user interface,, must be carefldly designed to bot!1 exploit the under~·log technology and
maxinlze the return on wl1..1t can be a sizable lnvestment.
Flnally, and as suggested earUer, system designers are also concerned with systemto-system lnterfaces. Increasingly, ~·stem interfaces are the most diffintlt to design
and fmplement. For lnstance, consider a proairement Information ~·stem that is used
to initiate and purchase everything from supplies to equlpment . A procurement system must interface with other information systems such as human resources (to
detetmlne authority to purchase and approve ordets), accounting (to determine ff
funds are avallable against an accowll), receMng (to determine If ordered goods were
received, and accounts payable (to initiate payment). These hllerfacing systems may
use "'ry dlffere11t software and datahases. Tilis can greatly complicate system hllerfuce
design. System interfaces become e\-en more complex: wt1en t11e lntetface Is between
information systems ln dJfferent businesses. For example, In the aforementioned system, we might want to enable our procttrement system to directly interface wlth a
suppler•s order fulfillment system.
interface SJ>eci.6catioos
tochnical dosigns that docu.
ment how syste11 users are to
interact 'Mth a sjStem and
how a syS1em interacts 'Mth
other systems.
user dialogue a specification of how the user moves
from window to Mndow or
page to page, interacting with
the application programs to
perform useful work.
58
Part One
1ho Context of Systems l>owlopmont ProjOffl
Legacy information systems In most businesses were each built with the rech-
nologies and teduliques that represented the best practices at the time when they
were developed. Some systems were built lo-house. Others were purchased from
software ,--endors or de,-eloped witl1 consultants. As a result, the integration of d1e.se
heterogeneous systems can be difBntlr. Consequently, the need for dtfferet1t ~·51:ems
to Interoperate is pervasive. Accordlngly, the time system designers spend on ~·stemt~·stem Integration is frequently as much as or more than the time they spend on
system development The system designer's mission ls to find or build Interfaces
between these systems that (I) do 11ot create maintenance projects for the JegaC)'
systems, (2) do not compromise the superior tedinoJogles and design of the new
systems, and (3) are ideally transpare11t to the system users.
System Builders' View of COMMUNICATION System builders construct, install test,
and implement both user and system-to-system interface solutions uslng tNTEII.W..CE
TECHNOLOGY (see Figure 2.6). For user Interfaces, the Interface technology Is frequently
embedded into the appllcntr.0·11 developnie11t e1J.vtro·111nent (ADE) used to conru-uct
software for the system. For ex.ample, ADEs such as those for Vfsual sn,dio .,Vl!f, and
Pou:erb·u tlder indude all the lnterface technology required to construct a Wt11,iot1Js
graph.ic:il user lnrer&oe (GUI). AD& ruch as t11ose fOt' Java and Cold Fusion provide
middleware utility software
that allows application soft.
ware and systems software
that utilize differing technolo-
gies to interop;rate.
similar funcrlonallty for \X'eb interfaces. Alternatively, the user interface could be
constructed with a stand-alone interface technology tl1at supports :d1TJlfL (e.g.,
,_lacromed.L1's Dreat1'U)Qaver).
System-t~·stem interfaces are consJderably more complex than user interfaces
to construct or Implement One ~·stem-to-system interfacing technology that is currently popular ls mlddleware. Mlddleware is a layer of utility software that sits In between application software and systems software to transparently lntegrate differing
technologies so t11at they can lnteroperate.
One common example of mlddleware is the open database connectMty (ODBC)
tools that a llow application programs to work with d.Jfferent database management
systems wJd1out having to be rewritten to take Into consJderatlon the nuances and dlf.
ferences of those database management systems. Programs written with OOBC commands can, for tl,e most part work with any ODBC<ompllant database (which
indudes dozens of dilferetll database management systems). Slmllar mlddleware products ex.1st for each of the columns In our lnfonnatlon ~·stem framework. System
designers help to select and apply these products to integrate systems.
At tl,e time of this writlng,X,l!L (eXtenslble Markup Language) bas eme,w,d as
an evolving standard for system~o-system commwllcatlon.Xil!L ls wllque in its :blUty
to st1are daca between ~cems tlu'Ougb. data screams d1..1c not only lndude d1e daa buc
also lnclude the meaning and structural detlnltions for t11..1t data. JGlfL capabilltles are
the new frontier for software tlut implements electronic data exd1..1nge over the Web.
Once again, tills book ls not abottt system construction; howe,-er, we present tl1e
system builder's ,iew because the other COMMUNICATION views lead to the construction of the actual communication interfaces.
Network Technologies and the IS Building Blocks
In this chapter, we unveiled a framework for lnformatJon systems archltecture that
was initially Inspired by the work ofJohn Zadunan. 1 The Zachman "Framework for
lnformatJon Systems Arch.ltectnre,. achieved h1tematio11..1I recogn.irion and use. TI1e
Z.,cbman framework ls a matrix (similar to the chapter map at tl1e beginning ci this
chapter). The rows correspond to what Zachman calls perspectives of dlffere111
1loht1 A. behtnul. "A Fh:tnewotk for ln.fottnaliob S ~ Arc:biteetu~· /&.\! Svs1P:nu./ot1n,1tl26, tio. 3 (1987).
pp. 276-m.
Information System Building Blo,k s
59
d,optor lwo
, FIGURE 2 - 7 '
PROCESS
Buik:ting
Blocks
The Role of the
Ne h vorkin
Informatic-n
, Systems
NETWORK TECHNOLOGIES
people ln\--olved in systems development and use. TI1e columns correspond ro
foc-1,;es on different aspects of the informarJon 5'/Stem. Zac hman's architecture
includes a separate c oh1nu1 thar dosely equates to whar our framework recognJzes
as NITWOR..K TECHNOLOGI ES. (We have c hosen to omlt thar column because network
frameworks are more typically covered in dara communlcatlons and networking
textbooks- and those textbooks tend to focus on the Open Systems lnrerconnect
(OSf) framework as opposed to Zachman's.)
Btn unquestionably, roday's infonnatlon systems tre builr on networks. Figure 2-7
shows a modern high-level information systems framework thar demonstrates the
contemporary layering of an Information system's KN:>WLEDGE, PROCESSES, and COM."1\INICATICNS bttlldlng blocks 011 NlrrWORK TOCKNO I.DGCES. Today's best-designed lnformatlon
systems tend to separate these layers and force them to communicate across the networt. This c/ea1~/ayerl11g approach allows any one bulldlng block to be replaced with
another while ha>ing little or no lmpact 0 11 the other bttlldlng blocks. For example,
the DATABASE T&:HNO LOGY, SOFTWARE TECHNO LOGY, or INTERFACE TECHNOLOGY could be
dia~ed without lmpactlng the other bttlldlng blocks.
It ls not the latent of this book to tead1 network tecbnolog)'. ~fost information
systems and tedu1olog)' programs offer courses that can expand )'OUr understanding
of n<twort technology.
,
So where are we 11ow? If you have already read Chapter 1, you learned about lnformatlo11 systems deve.lopment projects with a focus on the stakeholders, the process,
and the bush1ess and technical drivers that lnfluet1ce the need for new $)'Siems. If you
ha,--en't already done so, you should at least skim Chapter 1 to learn about the co1,te:~t
ofsyrtems analysts a11d design methods.
In Chapter 2, you learned about the product itself- h1formatlon systems- In
tentlS of baslc bulldlng blocks.This architectural perspective focused on the different
lnfotn1ation system views of the various stakeholders. )'ou learned that $)'stem owners and users view lnformatlon systems from the standpoint of achleving goalslmpro"ing business knowledge, processes, and communications- whereas $)'stem
designers and bttllders view Information systems In terms of teclmology that supports
the achlevement of goals.
Most readers should proceed dlrectly to Chapter 3, wblch h1troduces you to the
process of lnformation system development. You'll learn about information systems
problem solvh1g, methodologies, and development technology as you expand your
educitlon h1 the fundamentals for systems analysis and design methods.
:::::0
0
0
Q_
3
0
-0
60
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
Summary @
I. Organlzatloos are served by a feder.ltlon of Infor-
mation systems that support "-arJous business functions. Busine.s.,es h.ave front-office information
systems that support business functions tl1..1t extend out to their customers and back-0ffice information systems that support Internal business
operations and lnteract wJd1 suppUers.
2. The many classes of Information system applications overlap and interoperate to complement and
supplement one another.
3. lnformadon systems archltecture provides a wllfylng framework into whlch various stakeholders
wlth dJfferent perspectl\o-es can organlze and view
the fttndimental building blocks of information
systems:
a. System owners and $)'Stem users tend to focus
on three common business goals of any information system- lmpro,-ements ln business
kno'\\iedge, business processes, and busine.s.,
commwlications.
b. System designers and bttllders tend to focus
on technologies used by the infonnation system
in order to achieve the business goals. They
focus on the database technologies that
support business kt1owledge, software technologies that support buslness processes, and
internee technologies that support business
commwlicatlons.
4. The three views represented in the model are:
a. KNOWLEDGE- the business knowledge d1at helps
managers make intelligent decisions.
b. PRcx:i:ssES- the actlvJtles (indudlng manageui~••t) lh.tl c..~.u·1·y uul tlut tui:,sio u of lit~
business.
c. CoM.\.llNICATIONS- how the system lnterfaces
witl1 Its users and other infonnatlon systems.
5. Improving business knowledge Is a fundamental
goal of an information system:
a. The S'/stem owner ls interested in lnformatlon
that adds new business knowledge.
b. lnfonnatlon system users are knowledgeable
about the data that describes the business. This
data is used to create fr1fonnatlon and subsequent business kt1owledge.
c. System designers are concerned wltl1 the
database technology that will be used by the
information system to support business
knowledge.
d. System bttllders focus on the actual database
management system tedu10Jogy used to store
the business data tl1at will support business
knowledge.
6. lmprovlng buslness processes ls a fundamental
goal of an information system:
a. System owners are interested h1 the business
functions the groups of reL1ted processes, that
support a business.
b. System users specify the business process in
tenns of process reqttlrements for a new system. Business process requJrements are frequently defined In terms of policies and
procedures. Policies are explicit rules that
must be adhered to when completing business processes. Procedures are the
precise steps to be followed ln completing
business processes.
c . System designers vtew business processes
in terms of the application development environment and the software technology used
to develop the S)'stern. Many businesses purchase com.merclaJ off-the-shelf software solutions instead of buildlng tl1e software
in-house.
d. System bttllders focus on custom-0,tllt applications programs that automate business
processes.
7. A common goal of most organizations is to fm.
prove bush1ess commwlications:
a. System owners define the communJcations
scope of an h1fonnatlon system development
project.
b. System users view communications in terms of
the information $)'stem's inputs and outputs.
c.. System designers are concerned wlth the technical design of botl1 user and S)'stem-to..ysiem
communication interfaces.
d. System builders are concerned with the lnterface tedinology tl1ey use to implement
user and system-t<>.system communlcatlon
interfaces.
8. Today's informatlo11 systems are built on networks. Network technology allows properly de-
signed lnformation systems to separate the
KNOWLEDGE, PROCESS, and COMMUNICATIO N building
blocks and force them to communicate across
the network.
Information System Building Blo,ks
Chaptw lwo
61
\';::::;s Review Questions
l.>
l. What is the difference between front-office
jnformatlon systems and back-0fflce lnfonnatlon
systems?
2. How do trnnsactlon processh,g systems (TPSs),
management information $)'Stem.s Q.fISs), and
decision support systems (DSSs) hlleract with
each other?
3. Why do we need to idet1tify tl,e Information
system archltecrure?
4. What are the three busfr1ess goal-oriented perspectives or views of an informatlo11 system
1hat systems owners and system users tend to
locus on? What are the three tedinologlcal
perspectives that system desJgners and builders
1end t o focus on?
5, How are the business perspectives and the ted1nology perspectives of an infonnation system
related?
6. h1 any gh.. n building blocks of an information
,ystem, the views of four groups of stakeholders
need to be taken into aCCOl lllt du.ring the deveJopment of the system. What are these four stakeholder groups?
7. Briefly describe how system designers and
S)'Stem builders t end t o view KNOWLEDGE In a
S)'Stem.
8. Understanding business functions ls essentL1l in
the process building block of an h1formation system. What are six hlgh-leveJ business functions
typical of many companles?
9. lfyou were the ~·stem owner of an onllne CO
store, list two bush1ess functions of your online
store ln terms of business events and responses
to those events.
10. Give an example of a policy and ti,e procedures
needed to !mpletnent the policy.
11. What ls prototyping? Why do we need sud1 a
technique?
12. What are the two most critical goals ln the communication building blocks?
13. What ls user dialogue?
14. Why has the lncreash1g use of graph ical user h1terfuces (GUI) complicated the design process for
system designers?
15. What role does network technology pay in deve~
oph1g an lnformatlon system?
(f!;/;
l . Companies generally need rouse more tl1an one
informatlo11 system t o support all their different
business flutctlons.These functions are fre.quently referred to as either front-office lnformarJon ~·seems or back-office ~·seems. Define
ead1 of these two types of systems and identify
some of the typlcal business functions supported by ti,em.
2 . As a systems analyst, designer, or builder, you wil
lrequet1tiy be Involved with your organization's
Jnformatio11 ~'Stem.s archltectu.re. What ls an h11onnation S)'Stems ardlitecture, and wltat is Its
purpose?
3, ,\.lthougt1 system owners and system users generally have differet1t perspectives of thelr organization's information system, both groups tend
10 focus on three business goats that are common to any information ~·stem . What are these
goal-oriented perspectives, and wltat is their
importance?
4. h1 a n lnformatio11 ~'Stem, the process building
blocks represent the work that occtU'S ln a sys-
Problems and Exercises
tetn, whid1 may be performed by people or by
computers and machinery. Stakeholders tend to
have different vJews or perspectt,--es of these
bttlldh1g blocks. What are these different stakeholder perspeal,¥!s regard.Ing processes, and
how they differ from ead1 oti,er?
5. Assume you are a systems designer and your organization ls bulJding a new h1ventory manage.ment ~·stem . In reviewing the requlremet1ts
documentation, ft appears that an error was
made and some addJtlonal data elements were
left out tl1at are needed to meet the business or
technJcal objectives of tl1e lnvet1tory management ~·stem. What should you 11o t do at this
point.?
6. Assume you are desJgnJng a retaU point-of-sale
(POS) system for your company. What are the
typical system hllerfaces of a poh11-0f~ale system
that need to be taken lnto accow1t ln desJgiling
the POS S)'Stetn?
7. As business technology becomes more powerful
and sophlstlcated, many bush,esses are redeslgnlng
1
62
Part Ono
Tho Contoxt of Sy,toms Dovolopmont ProjOffl
thelr slngle-functlon Information systems,
such as sales, into cross-flUlCtlonaJ lnformatlon
system! tl1at provide h1tegrated support for
separate, but reL1ted, business ftmctlons. Assume
that you are deslgnh1g an order managemet1t system that will lntegrate all busfr1ess functions triggered by the submission of a sales order. What
typical business functions wo,tld be induded in a
cros.,-functlonal lnformatlon system?
8. ~Uddleware is frequently used In systems Integration projects when different infonnation systems
are tied together to exchange data via system-tosystem lntetfaces. Briefly define mlddleware, explain Its benefits, and provide an example.
9. In idei1tifying and documei1tlng business requlrements, systems analysts need to be able to distlogulsh between Jaws, policies, and procedures.
Why Is this Important.?
10. It ls common for system owners :ind system
users to l1ave very different vJews of the same
business processes used in an information $)'Stein. Why do you think this Is? Consider an airline tl1at is de,-etoping a customer self.check-in
systein at altports. What do you think the perspectfve of the system owners is? What about the
system users? Give examples of how the business
proces!es for an alrllne check·ht system will be
vJewed by the system owners and ~'Stem users.
Projects and Research
11. System designers and system builders also
tend to have very different views of ~·stem
building blocks. Explain the different ways
that designers and builders might view the
communication bulldlng bloc.ks using the Cl.tstomer self dtecl:·in ~·stem scenario de.scribed
ln the last quest.loo.
IZ. System designers frequei1tly hm, a number of
technlcal design options to choose from what
designing lnt..C.ces between different systems
and applications. What should designers alw,ys
keep h1 mlnd when designing tl,ese Interfaces?
13. 11te framework for lnformation S)'Stems ardutecture used ht this textbook ls derived from
the pioneering framework developed by John
Zachman. What ls one of the advantages of de.
signing ~·stems based upon this or similar
frameworks?
l .f. At times, :ltl org.'lfUZ3.tion may dtoose to purchu:e :t
commercial ofl:the-•helf (COTS) software package.
What do you thlnk are the pros and cons of using
off-the-shelf applications compared to custombullt appllcatlons?
15. If an org.,nization d1ose a COTS package as their
solution, wo,tld the view of the system builder he
the same as for a custom-built application? If not,
how would It be different?
1?
l. Select a medJum to large organlzatlo11.The organJ..
i.atlon can be in the public or prtvate sector. and it
can be one wltl1 whJch you are personally fantltlar
or one for wlllch information is readily available.
a. Desctlbe the org..'lnlzatlon you ha,-e selected
(type of organization, mission, products or services.size, aiutual sales or revenues, etc.).
b. Select one of the major lnformation ~·stems the
organization uses aitd/or is developing, and
describe it.
c. In the organization you selected, wlto would
typically be the owner of this system?
d. Desctlbe, from the viewpoint of the owner, the
information produced by this systein.
e. If the organization Initiated a project to replace
or mocllfy this system, how might the systein
owner define tl,e scope and vision of d,e project
wlthln dte context of the organization you
se!ecn,d
f. Who are the typical users of tills system?
g. Describe, from tJ,e perspective of tl,e ,rser,, the
h1formation produced by this system.
11. What ls an essential differettce In l1ow system
owners and users view the Information produced by the systein?
2 Contact and Interview two or three systems aa.a.
lysts, h1 different organizations If possible, regarding th.ls chapter's subtoplc on commwlicatlon
building blocks.
a. Describe tl,e nature of each analyst's company
or org.'lnlzatlon, lts mission, and cutTent blliiness issues or needs.
b. How Important does each of the ~'Stem ai1,1.
lysts consider communications wlth system
users versus S)'Stem builders; that ls, which is
more Important aitd wlty?
c. Do they find it more cllfllCltlt to commwllcite
with the system users or wfth the S)'Stem
b,dlders? Why?
Information System aulldlng Blo,ks
d. If they were CIOs for a day, what wo,tld
each of them d1ange about the way their de.sJgners commwllcate with system users and
builders?
e. Whlch viewpoints do you agree with, or do you
have a totally different one tl1..1n the people you
interviewed? Justify your answer.
3, Se.led an informatio11 system used by a medium to
L'rge organlzatio11. It can be one with whid1 you
Chaptwlwo
63
goods or services from one than the other(s),
solely because of differences in thelr Web sites?
Why or why not?
d. From the viewpoint of a business customer, do
you think design or usability is more important
for a Web site? Explain your answer.
e. From the viewpoint of a consumer, would
yolU' answer be the same as ln the precedfrlg
question? ExpL11n.
are person.ally famUL1r or one wl1ose organli.atlom.l
structure and Information system you ha,-e
researched.
5. Researd1 several articles published in the last few
years in your library and/or on the Web that discuss ethical issues reL1ted to systems dtslgJ.1.
a. W11at is the nature of the org;ulizatlon you h.ave
a. W11at articles were you able to find?
b. Describe some of the situations and ethicaJ
issues tl1.1t mlght arise from tlrue to time in
systems design.
c. Pick one of the siruations described In (b) and
selected, its mission, and tl,e hlgl>-level purpose
of tl1elr information system?
b, W110 is the owner of the system?
c. If you were the owner of the system, descrlbe
l1ow you would see the system processes from
d.
e.
f.
g.
tl1.1t viewpoint.
W110 are the users of the system?
If you were one of the system users, de.scribe
l1ow you would see the system processes from
tl1.1t viewpoint.
If you were the system designer, describe tl,e
system processes from that viewpoint.
Wlut are the essential dUferences in viewpoints?
4. Imagine that you are the owner of a small business
aad are seateh.lng on the '\X'eb for a company that
can supply the products or services needed by
your business. Flnd several business-to-business
(B28) Web sites that offer the products or services
fer whid1 your business is looking. Famlllarize
yourself with thelr Web sites from tl,e viewpoint
of a typical business customer who is visiting the.se
sJtes for the first time.
a. Wh.ac is the narure of your organization, and
for wl1at type of goods or services are you
looklng?
b. Whlch 828 sites did you find on the Web?
c. Compare the different sites. If all other things
were equal (price, avallabillty, brands offered,
etc.), would you be more likely to purchase
descrlbe wfl..'lt you believe to be the system
designer's ethical obligation, if any.
d. (Extnt credit) Do you think tl1.1t requiring rr
professionals, that Is, S)'Sterns analysts, designers,
and builders, to be lict'llSed or cert!Jled wo,~d
increase professionalism and/or reduce unethical beJ1avior? Wllf or why not?
6. TI,e textbook uses a framework for describing information systems architecture that ls based upon
John Zad,man·s• ftaruework for Information S)'Stems Ardlltecture• model. Uslllg the Web or your
school library, research other fnruewotks for descrlblng IS archltectures, and select one, sud1 as
Open S)'Sterns Interconnect (OSI).
a. Wllld1 frameworks dld you find, and whlch did
you select?
b. Describe Its approach to comru,ullcating systems
archltecture. Include a diagram if appllcable.
c. WlL1c are tcs sJmilarJtles co the framewort.: used
in the textbook?
d. W11at are ics differences?
e. If you were a systems owner, which one wou.ld
you find easier to w1derstand?
f. If you were a $)'stems ai1..1lyst, wllich one would
you find easier to w1derstai1d?
{jJ Minicases
1. An rr manager requests ai1 amow1t of funds to
upgrade the e-mail server. Without the necessary
upgrade, the ser,--er will be burdened by the sheer
aoiollllt of e-mail and wUJ run the risk of crashing.
The business m:u1..1ger detlies the request, citing
the past rellablllty of the server, and expresses
concern at the recent large IT expenditures. The
business ma11..1ger )eaves the conversation wondering what rr h1vestruents are really necrssary, and
If the rr n>.1nager is Just creating "Job security.•
64
Part ono
Tho Contoxt of Systoms l>ovolopmont ProjOffl
TI1e IT manager, likewise, leaves the meeting frustrated at 11ot h.aving the tools he/she needs to do
the Job properly. The IT manager knows that
when the server crashes, it will be his/her re.sponslbillty to fix.
a. Do you thlnk th.ls happens often h1 bush1ess?
b. What perspectives do you think each are taklng
on the problem?
c. How could ead1 have communicated those perspectives and busfr1ess needs better?
2. Interview at least one person in marketing, customer service, and accotmtlng/payroll in the same
company. What types of h1fonnatlon do they handle? Do they share information aero:;,, departments? Do you notice overlap in lnformatlon or lo
data entry?
3, Government servJce departments are deeply bur-
crime. You should lnclude, but are not limJtOO to,
topics such as:
What Is the department's (or person's) Job?
What kh1d of data do they collect and analyze?
What kh1d of analyses do they do on tJ,e data?
How much fr1fonnatlon do they collect, from
whom, and wl1at programs do they use?
4. Your neighborhood grocery store, Wow Groctry,
always seems to be numfr1g out of your favorite lee
cream. In frustration, you ask the store manager
why they always seem to be out The store manager, Bob, tells you that d1e small store cuu1ot
afford an ln,--entory management system, so lnventory ls updated manually. 1bls means that oftentimes the store must either stock extra quantities
of well-liked ltems or rlsk running out.. Unfortunately, Wow Grocery does not have a large e1.1ough
dene-d by the amount of d:it:i th.at rhey hold and
freezer to store :iddJtion.'ll stocks of lee Cf'eam. As
process. IntervJew someone from a service department and draft a short essay. Service departments that must sift through '\o-ast amounts of
data are tl1ose tl1at deal wlth, for example, mlsslng persons, dllJd protective services, D,_(Y, and
tracking of persons on probation followlng a
a result, the store runs out of the ice cream quite
Team and Individual Exercises
I. How do you solve a seemlngly h,solvable problem?
As a ream, develop a methodology for solving t!,e
following question: How m..my homes are there in
the Unlred States that are palnred yellow?
2. Try somethlng you have nor done before (legal,
nor dangerous, and rated G). Share with the class
Suggested Readings
frequently.
5, W11at can \X'ow Grocery do to automate or m..nage
lts it1ventory system without spending much
money? Draft your solution lnto a short paper.
foj
what you did, and why you did It. Why Is It lmporrant to try and experlet1ce new thin~?
3. Share (with your ream) an unethical Incident that
you have observed. How did that Incident affect
you dhectly? What indirect Impact did It have on
others?
r]I
o. The Essenrfaf Gutde to user Interface
Destgn; An /ntroductfon to GUI Destgn Prtnctples
and nchntques, 2nd ed. New York: John Wilq· &
Galin, Wilbert
Sons, 200?.
Goldman, Jarncs E.; Phillip 'I'. Ra'\\'les; and Julie R. Marigt.
Cltent;.se,ver 111/onnatton S)1ste1ns: A Bustness-Orte11-te<1
New York: John Wiley & Sons, 1999. For
AJ)proacJJ.
studc,nts who att looking fo r a studcnt-oric,ntcd introduction to informatio n technology architecture and
data communications, '"'c rc-comme,nd our colleagues'
book because it was '"'rittdl for business and information systC!Us majors to provide a comprc-hensh'C' sun.•q•
of the technology that supports today's info rmat ion
systems.
Inmon, w. H. Butldtng tbe Data Wtlrebouse, 3rd ed. Ne\\•
Yotk:John Wiley & Sons, 2002.
Seth~ Vilo::rarn, and William R. King. orga11tzatto11al 1'm11Sfor111arfo11 tbrougb Busf1wss Process Reengtneertng. Upper
Saddle Rht,; NJ: Pttn.ticc Hall, 1998.
Taylor, 0.'l.vid, and Alyse 0. TerhtUlc'. Dotng E-Busfness: Strategtes for Tbrtvtng t11 an Ekctrontc ,Warlletplace. Ne\\•
Yotk: John Wiley & Sons, 2000.
bchtnan, John A •A Framework fur Information System
Architcctutt.• /BJW S)1ste1nsJ011r11al 26, no. 3 (1987). We
adapted the matrix model for infonnation system blilding
blocks from Mr. Zachman 's conceptual &.unC\\•otk. \le flt5t
encounte,rc-d John Zachman on the kcture circuit, ,vhctt
he dclh'C',rs a tt,rnarkably informati,t and C'Jltcrtaini.ng talk
Jnformatton System aulldlng Blo,ks
on the Sl.MC' subject as this artick-.1\otr. Zachman•s frame.
vi.t0tk has drawn professional acclaim and inspired at least
ot..c conference on his mock:I. His Et-.uncwork is based ct\
the concC'pt that architecture means dJffcrcnt things to
cUUC'.1t:nt people. His fr.uncwork s u.ggcsts that info rrnatktl
S)'stc.rns consist of thtcc distinct •product-oriented"
vi.rws-data, procc$SC'S, and technology (v1.rhich vi.•c rt'·
1Umed co1111111111-fcatto11S)- to whkh vi.•c added a fourlh
d,oporlwo
65
view,• intc.rfacc ." The Zachman ftame"'Ork offc,rs si.x dif·
fcrcnt a udiC':ncc'6peciftc ,tic\\,s- for each of thosc product
views-the ballpad,: and 0\\'1lcr•s vte\\,s (which vi.~ re·
nattlc'd as otvner~ and user's vfetvs, ttspcctivcl)•), the de·
signc.r•s and buildc.r•s views ("' hich we combined into our
deSfgner's vtetd), and an out-of-context ,'lcw (v.,hkh " 'c
called the butlder's vteuf).
Strategic 1nrormat1on Systems Plan
Sltateglc Enterprise Plan
Goll:
·~81..111nMt
l!NC'HLEOGE
~
~
!
-
S T A TEMENT OF W O A I(
PA 0 8LEM S TA TEMENT ( u • 1n9 tl'I O PIE C E S t r , m o worlt)
INFORMATION
FUNCTIOIIA.L
oco..
oco..
VISION
VISION
•
..
...,
•
CO-UNICATION8
•
V l 81)N
SYS TEM IMPRO V E•ENT 0 8JE C TI V E& ( u t lng tll o PIE C E& l r • m•w o rk )
OU O INC OO nc o u,nc11CNTO O TA TC•CNT
~
~
~
I•
r
•~
)
~
.
B
t
w
•,
•ffi
~
i
ij
.
11
8 U81Nl'.U
PSOCUO
,NTER,...
AEOUIAEMENT&
AECIJIA EM9fT8
LOOICAL
LOGICAi.
PSOCUO
,NLOGICAL
TER,...
DATA
DATA
........
M00EL8
;
[;
!
'~
•
SYS TEM PROP OSA L
•m
8 U91N£.8$ PFOCE88
0
~
.•
PHYSICAL
0 £.81011
8 PECIFICATION9
80F'T'llkAE OE81GN
8 PECIFICATON8
DAOe&IGN
......
•
'>
~
--
PHYSICAL
,NTER,...
TR A INING M A TERI A L S
-
r
COM• EACAL
••
0
,NTER,...
80F'T'llkRE
!•
,
DA80L""10N
......
0£.81GN
.9PECIFICATION8
........ !• ....
FUN C TION A L 8Y& TE•
~
•
.!....B
u&eR ,& 8Y8TEII
PHY&IQIIL
~
~
REQUE S T F O R &YS TEM PAOPO.SA L 8)
OE8 10 N PROTO TYPES
z
•
(or
•OOEL8
'-----------A
- '_'_'_'C
_A
_T_,.__•_A
_•_<_•_•_T_E_C
_T
_u_•_·----------'n
•ffi
'>
8U8 1N£.8$. &YST"EM
8u&IN E88
A EOUIAE• ENT&
.90LIJTION&
CUSTO~BUILT
A PPLICATI)N
OPEA A TI O N A L SYS TEM
80F't'Wa.RE
I
-
,N&YSTEM
TER,...
.SOLIJTION&
PO S T-A UDIT AE Y IEW
"""'""
,.,..,...
APPACWEO
TECHNOI..OOE8
Strategic Enterpr1ss 1ntormauon Tecnno1ogy Arcnnecture
H
H
Information Systems
Development
Chapter Preview and Objectives
This chapter more closely examines the systems development process that was first introduced in Chapter I. Successful systen1s development is governed by son1e fundamental,
underlying principles that we introduce in this chapter. \Ve also introduce a basic, representative systems de,-elopmeot methodology as a disciplined approach to de,-eloping informnion systems. Although such an approach will not guarantee success, it will greatly
impro,-e the chances of success. You will know that you understand information systems
de,-elopmeot when you can:
I De.scribe the motivation for a standard systems development process in terms of the
Capability Maturity Model (CMM) for quality management.
I Merentiate between the system life cycle and a sysrem development methodology.
I Describe IO basic principles of systems development.
I Define problen1s, opportunities, and directives-the triggers for systen1S development
projectS.
I Describe the PIECES framework for categorizing problems, opportunities, and
directives.
I Describe the essential pbases of systems development. For each phase, describe its
purpose, inputs, and outputs.
I Describe cross life.cycle activities that overlap multiple system development phases.
I De.scribe typical, alternative "routes.. through the essential phases of systems
development. Describe how routes may be combined or custonlized for different types
of projects.
I De.scribe various automated tools for systems development
68
Part ono
1ho Context of Systems l>owlopmont ProjOffl
Work ls getting tmderway at Sow1dStage Entertainment Oub for the systems anllysi.s
and design of their member services Information system. But the more Bob ,_lattloez
Jeams about the system, the more confused he gets. Bob can recall some of his programming assignments in college. ,_lost of them were Just a page or two of bulleted
points listing required features. It was pretty easy to get your head around thac But
the new SoundStage ~tern will lnvolve tracking member contacts and purchase requirements, p romotions, sales, shipments, invet1tory, multfpJe warehouses, \X'eb sJtes,
and more. Bob wonders how they will even list all the requirements, Jet alone keep
them strnlglit. How wUJ they know what data they need to track? How will they tnow
what every piece of programmlng needs to do? He mentioned that to his boss, Sandra.
She said It was all about following • the methodology: He remembered something
about methodology from a systems analysis class. At the time It seemed like a lot of
unnecessary work. But he is starth1g to see now tl1at on a large project, following an
established method may be the only path that is safe to travel.
~~~T_h_e~P_ro_c_e_s_s_o_f_S
_y~ste
~ m_s~ D_e_v_e_lo_p_m
~ e_n_t~~~~~~~~~~~)
systems del'<'k>pmeot
process a set of activities,
methods, best practices,
deliverables, a-id automated
tools that stakeholders (from
Chapter 1) use to develop and
continuously improve informa.
tion syS1ems and software
(from Chaptsrs 1 and 2).
11lis chapter lntroduces a focus 011 information $)'stems development. We will ex.amine
a systems development process. Notice we did nor say ..the" proce.s.,- there are as
many "-arlatlons 011 the process as there are experts and authors. We will pre.sent one
representative process and use ft consistently throughout this book. The ctuprer
home page shows an expanded number of phases compared to the home page of
Chapter I. This Is because we have factored the hlgh~evel phases sud, as system
analysis and system design from Chapter I into multiple phases and actl,itles. We
ba,-e also refined the size and place of the stakel10Jder roles to reflect "involvement"
as opposed to emphasis or priority. And we have edited and enhanced the buiding
blocks to indicate deUverables and artifacts of system development . All of d,ese
modlftcations will be explained lt1 due time.
Why do organ1zatlons emhnce standardJzed processes ro de,--elop lnfonnatlon ~
terns? Information systems are a complex product. Recall from Chapter 2 tl1at an Information system Includes data, process, and communlcatlons building blocks and
technologies that must sen.. the needs of a >'arlety of stakeholders. Perhaps this explains why as many as 70 percent or more of Information system development projects
ha,--e tailed to meet expectations, cost more than budgeted, and are delivered much tater
than promised. The Gartner Grcup suggests tlut .. conslstent adherence to moderately
rigorous methodology gttidellnes can pro,ide 70 percent of [systems de.-elopment J organJzations with a producti'\oit)' improvement of at least 30 percent wtt.hln two yeirs." 1
lncreaslngly, organizations have no d10Jce but to adopt and follow a standatdized
systems de,--elopment proces.,. First, using a consistent process for ~ems de,-etopmenr
creates effidet1des tl1..1t allow muugement to shift resources bet\\"'een projects. Second,
a consistent methodology prod.ices consistent documentation that reduces lifetime
costs to maintain the systems. Finally, the U.S. govemmet1t lllls mandated that any org.,.
nlzatlo11 seeking to de,--elop software for the government must adhere ro certaln quality
management requirements. A consistent process promotes quality. And many other organlzatlons have aggressi.-ely committed to total quality management goals In order to
Increase their competltlve advantage. In order to realize quality and productlvicy• Jm.
provemet1ts, many organizations have tltn1ed ro project and process management
frameworks sud, as the Capahlllty Maturity Model, discussed lt1 the next section.
1Riehurd Rubtd', "AD Project Potdolio M a ~ t ; · Pro«wtinp oftbc- GQN1'M't'Gro11p IT98 Syn1posi11,1'/'E:o:po
(CD.ROM). Tht Gutthet Group ~ 11b illdU!IIU'Y•·•llt'.hi:kls ILlld tc1'C'll..ldl pip tb11t web 11b:I projeeb ibdustl'y th'.bds bt
rr tnab11gdS,
Information Systoms Oovolopmont
Chapter
Tine
69
> The Capability Maturity Model
It h..,s been shown that as an orgailizatlon•s lnformatlon system de,--elopment process matures, project tiruellnes and cost decrease while productivity and quality increase. Toe
Software Engineering Institute at Carnegie Mellon University has oosen-.d and measured
this phenomenon and de,-.Joped the C1pablllty Maturity Model (C!IIM) to assist all
org.1n!zations to achieve d,ese benefits. Toe Cllt.M has developed a wide following, both
h1 h1dustry and go,-.mment. Software evaluation based on Cllll\l ls beh1g used to qualify
h1formatlon technology contractors for most U.S. federal government projects.
Toe Cllt.M framework for systems and software is hllended to help org,1n!zations
improve the maturity of their systems development l'fOCesses. The Cllt.M Is organized
into five maturity levels (see Figure 3-1):
Clpability ~t:tturity
Model ( OIIM) a standardized framework for assessing
the maturity lewl of an organi.
zation's informaion systems
development an:I management processesand products.
It consists of fiw levels of
maturity
Level 1- hif.tlak 1llis Is sometimes called anard1y or chaos. At this level, system development projects follow no consistent process. Each de,-elopment
team uses its own tools and methods. Success or failure ls usually a function
of the skill and experience of the team. Toe process Is w1predictable and not
repeatable. A project typlcally encounters many crises and ls frequendy over
budget and behind schedlde. Docltmentatlon ls sporadic or not co11sistet1t
Crom one project to the next, thus creating p roblems for those who must
maintain a system o,-er Its lifetime. Almost all organizations start at Level l.
Level 2 - Repeatable: Al this level, project management processes and practices
are established to track project costs, schedules, and functionality. 11,e focus
Is on project management A system development process ls always followed,
but It may vary from project to project. Success or failure is still a ftmctlon
of the sk.JU and experience of the project team: however, a concerted effort
Is made to repeat earlier project successes. Eff1:ctlve project m:u1..1gemet1t
practices Jay the fotmdatlon for standardized ptocesses in the next level.
/
RISK
FIGURE 3 - 1
The Capability
Maturity Model
" (CMM)
COMPETITIVENESS
,
70
,
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
'
TABLE 3 - 1 Impact of System Development uProcess" on Quality
CMM Proje ct Statistics for o Proje ct Resulting in 20 0,000 lines of Code
Organization'•
Lewi
Pro je ct
Duration
(mo nths)
Project
Person·
Months
Numbe r
of Defects
Shippe d
1
2
3
30
18.5
15
600
143
80
61
12
CMM
7
Medi on
Cost
($ millio ns)
5.5
1.3
.728
Lowest
Cost
($ millions)
1.8
.96
.518
Highest
Cost
($ millio ns)
100+
1.7
.933
.,
Sourt~ t.fukr S)•en:s. li:c.
Level 3 - Dejlned: In this level, a standard SJ,'Stem development process
(sometimes called a methodology) is purd1ased or developed. All projects
use a callored version of this process co de\o--elop and ma1.nca1t1 Information
systems and software. As a result of using the standardized process for all
projects, each project results In conslstetll and hlg!).quaUty documentation
and deliverables. The procrss Is stable, predlctable, and repeatable.
Level 4- Managed: In this level, measurable goals for quality and producthity
are established. Detailed measures of the standard ~em development process
and product quality are routinely collected and stored in a database. There ls
an eJJorr to Improve indJvidual project management based on this coUected
data. Thus, maiugement seeks to become more proactt,--e than reactive to ~
terns development problems (such as cosr overruns, scope creep, schedule
delays, etc.). E,--en when a project encotmters tmex:pected problems or Issues,
the process can be adJusted based on predictable and measurable Impacts.
Level S - Optlltttzl11g: In thJs level, the standardized system development
process is continuously monitored and lmpro,-ed based on measures and data
analysis established in Levd 4. Tols can indude changing tl1e technology and
best practices used to perlonn actlvlcies required In tl1e standard system
development process, as ,~:ell as adjusting the process Itself. Lessons learned
are shared across the organization, with a special emphasis on eUmlnatln.g
lneffidendes in the system development process wbUe sustaining quality. In
summary, the organJzatlon h ..,s institutionalized continuous systems development process improvement..
system devtlopmeot
methodology a formalized
c1pµ11Jtti;h lU U1:1 ~y~ta111::; U!:1·
velopment process; a stan.
dardized process that includes
the activities, methods, best
practices, deliverables, and
automated tools to be used
for information syS1ems
development.
system life cycle the factoring of the lifatime of an
information sy31em into two
stages, (1) systems dOll91opment and (2) eystems opera.
tion and maintenance-first
you build i~ then you use and
maintain it Ewntualty, you
cycle back to redevelopment
of a new systan.
It is very Important to recognlze that each level ls a prerequisite for the next le...,l.
Otrrently, many organJzations are work.log hatd to adlieve at least C,_0.1 Level 3
(sometimes drtven by a government or organizational mandate). A centraJ theme to
achle>ing Level 3 (Defined) Is the use of a standard process or metl1odology to build
or Integrate systems. As sl1own In Table 3-1, an org.uli zation can realize significant
Improvements In schedule and cost by hlStitutlonaUzlng CM.M Level 3 process
improvements. 2
>
Life Cycle versus Methodology
111e terms systetn life CJ,V:le and syste,n deve.lopnient tnetbodology are frequently and
incorrectly interchanged. ~tost eystem development processes are dertved from a natural system life cycle. The system life cyde Just happens. Figure 3-2 IUustrate, rwo
1Wbite P.ipd'. "Rapidly
llnpfOVi.ns Ptoce,s Ma:utity: Morins Up the Oip!!ba.ity Maturity Modd thtoulta Ou~ou.K'.ib;"
O)OlltOh: ltc'ld'.le, 1997.1998.~
.
Information Systoms Oovolopmont
Chapter Tine
71
, FIGURE 3 - 2 '
The System Life
"\c Cycle
,,..._...
....... ._.
Dwebprnent
-·
PIOcee&" ancl
Dwebprnent
A System
Development
Process
are hi roc:ue or
IN& cnap»r encl
""""""
,
LIS:E·CYC LE STAGE
LIS:E·C YC LE $TAG E
Lifetime
of a
System
System
Operation
and
Maintenan ce
ICleauy using a
sys1em oeveiopment
UMng tile &yatem·s
cho1;en 1nrormauo n
M&tll OCI OIOQ V
tecnno1ogy
Ufe-q•de stages. Notice d1at there are two key e,--ents tl1at ttigger a change from one
stage to the other:
When a system cycles from development to operation and maintenance, a
c.onversto·n must take pL1ce.
At some polnt in time, obsolescence occtus (or is Imminent) and a system
cycles from operation and maintenance to redevelopment.
Actually, a system may be ln more than one stage at the same time. For ex.ample, one ,--ersJon may be in operation and support whlle the next version is in develop,11e1it.
So how does this contrast with a $)'stems de,--eJopment metl1odology? A systems
development methodology "executes" the systems d!velopm ent stage of the system
life cycle. Eacl1 Individual information system has its own system life cycle. The
methodology Is the standard process to build and mtlntaln that system and all other
lnfonnation systems tlvough tltelr life cycles. Consistent with the goals of the CM.M,
methodologies ensure tl1at:
A consistent, reproducible approach Is applied to all projects.
There is reduced risk associated with shortcuts and mistakes.
Complete and consistent dOCltmentation ls produced from one project to tl1e
oext.
Systems analysts, designers, an d builders can be qulddy reassigned between
projects because all use the same process.
As development teams and staff constantly d1aoge, the results of prlor work
c:u1 be easily retrieved and understood by tl1ose who follow.
Methodologies can be purchased or homegrown. Why purchase a methodology?
,_lany information ~tem organJzatlons can't afford to dedicate staff to the development and continuous impro,--ement of a l1omegrown methodology. ~fethodology vendors have a vested lnterest in keeping their methodologies cttrrent wfth tl1e latest
business and technology trends. Homegrown methodologies are usually based on
generlc methodologies and techniques that are well documented in books and on FAST a hypothetical method\X'eb sltes. Examples of system development methodoJogles are listed In the margin ology used throughout this
on tbe following page. You sho,dd be able to research most of them on the Web. Many book to demonstrate a representative syS1ems developof thek w1derlylng methods will be taught in this textbook.
ment process. The acronym's
Throughout this book, we will use a methodobgy called FAST, which stands letters stand for Framework
for Framework for the Application of .S)'stems nllnklng. FAST ls not a rea~world com- for the Application of Systems
merclal methodology. We developed It as a composite of the best practices we've Thinking.
72
Part ono
REPRESEMATIVI:
SYSTEM
DMLOPMENT
METHODOLOGIES
Architected Rapid
Application OMlopment
{Arch~ected RAD)
Dynamic Systims
Development Methodology
(DSDM)
Joint Applicatbn
Development (JAD)
Information Er>gineering (IE)
Rapid Application
Development (RAD)
Rational Uniied Process
(RUP)
Structured Amlysis and
Design {old, but still
oocasionally encountered)
extreme Progrimming ()(P)
Note: There are many
commercial methodologies
and software tools
(sometimes c~led
methodware) tased on the
above general
methodologie!.
1ho Contoxt of Systoms l>ovolopmont ProjOffl
encountered In many commerd.al and reference methodologies. Unlike many commercial methodologies, FAST Is not prescriptive. TI1at is to say, FAST is an agile framework that is flexible enough to provide for different types of projects and Str.ltegies.
Most !mponant, FAST shares much in common with both the book-based and the
commercial methodologies that you will encotmter In practice.
>
Underiying Principles for Systems Development
Before we examine the FAST methodology, let's introduce some gei1eral principles
that should w1derlie all systems development methodologies.
Principle 11 Get the System Users Involved Analysts, prognmmers, and other information tedmology specialists frequently refer to •my system.· Tols attitude tns, in
part, created an "\is versus them• conllict between technical staff and their users and
managernei1t. Although analysts and programmers work bud to create technologtcally
impre~Jve solutions, those solutions oftett backfire because they don't address the
real organJz.atlon problems. Sometimes they even lntroduce new organization probJems. For this reason, system user in,-oJvement is an absolute necessJty for successful
systems de1,,--elopmenr. Th.Jok of ..ystems development as a p:utnershJp between sys
tern users, analysts, designers, and builders. Toe analysts, designers, and builders are
responsible for ~·stems development, but they must engage their owners and users,
itlSist on their participation, and seek agreement from all stakeholders concerning
decisions tl1at may affect tl1em.
,_Uscommunlcatlon and mlrunderstandings continue to be a sfgniflcant prd>lem
h1 many systems development projects. However, owner and user involvement and
education mJnimJze such problems and help to wh1 acceptance of new ideas and
technological change. Because people tet1d to resist change, Information tedu1ology
is often ,iewed as a threat. The best way to COlUlter that threat is tlvough constant
and thorough communication wJth owners and users.
Principle 21 Use a Problem-Solving Approach A system development methodology is, first and foremost, a problemsoMng approad1 to building systems. The term
problem is broadly used d,rougltout this book to indude (1) real problems,(2) oppor-
tunlcies for improvement, and (5) directives from management. Toe classical problemsohing approach is as follows:
I. Study and understand the problem, Its context, and Its impact.
2. Define tl1e requ.fremenrs that must be met by any solution.
3. Identify candldate solutions chat fulflll the requlremetlls, and select the best
solution.
4. Design ancVor implemet1t the chosen solution.
5, Obsen·e and e,':lluate the solution's impact, and refine the solution accordfngly.
Systems analysts should approach all projects using some variation of this problemsol,ing approad1.
Inexperienced or tr.nsuccessful problem sol,-ers tet1d to eUmhure or abbre,iate one
or more of the above steps. For example, tl1ey fall to completely w1derstand tl1e problem, or they premarurely commh to the first solution they think of. Toe result can range
from (I) sol"111g the wrong problem, to (2) incorrectly solving the problem, (3) piddng
the wrong solution, or (4) picking a less-than-optimal solution. A methodology's
problem-solving process, when correctly applied, can reduce or eliminate these risks.
Principle 31 Establish Phases and Activities All methodologies prescribe phases
and actl,itles.111e number and scope of phases and actfvJties vary from author 10 author, expert to expert, methodology to methodology, and business to business.111e
chapter home page at tl1e beginning of this dtapter illustrates the elght phases of our
FAST methodology in the context of your informacion systems framework. Toe phases
Information Systoms Oovolopmont
..
_
,qaei...,..,..--
• ........
•
•
llf'* °"'"
N'dJ!••
•'
'"'~Ollll,..
Jt
•
1
- -- -
0
..- ~- -- -- -I
- 1....-1- • '1 ""1''"1·1-1
-.--.-...
r,
o=
0
Rq.,Nmlnlto.Mltn
0
o=
Dlctllorl
1
0
0
Cinn\t:t:11 .. T...
0
""ld0nl04I"-)'
10 , - ~
I
- 1· 1- 1- 1- "'1""1- 1• • 1• 1-.-1- 1· 1- 1- 1-
·--
I
.,_
I
•
F IG U R E 3 • 3
73
Chapter Tiree
Overlap of System Developme nt Phases and Activities
are listed on the far right-hand side of the Illustration. In each phase, the focus ls on
those building blocks and on stakeholders that are aligned to the left of that phase.
Toe phases are: scope dellnltion, problem analysis, requlremet1ts analysis, logical
design, decision analysis, physical design an d Integration, construction and testh1g,
and Installation and delivery. Each of these p hases w UI be discussed Liter h1 this
d1..1JXer.T hese phases are nor absolutely seque ntial .TI1e phases rend to o,-erlap one
another, as illustrated In Figure 3-3. Also, ti,e phases may be customized to ti,e special
n eeds of a given project (e .g., deadlh>es, complexity, strategy, resources). 111 tills d 1apter, we wUJdescribe each custom1zatlon as alrernatl,·e routes through the methodology and p roble=Mng p rocess.
Prindple 41 Document throughout Development When do you document the
p rograms you wrlte? Be honest. We must confess tl1..1t, Uke most students, we dJd our
docume ntatio11 after we wrote the programs. \X'e tnew better, bur we postdocum ented a nyway.111..1t just does not work in the business world. ln m ed.tum to large organ.il:atlons, $)'stem owners, users, ai1..1lysts, designers, ai1d builders come and go.
Some wlUbe promoted; some wlUl1..1ve extended medical leaves; some wlUquit the
organization~and still others wlUbe reassigned.To promote good commwlicatlon between constantly changing stakeholders, documentation should be a working byp rod.ict of the entire systems developmen t eff<>t't..
Doctunentatlon etiliances communications and acceptance. Documenmtlon re,--eals
stret~ths and weaknesses of th e ~ tern ro multiple sla.keholders. It stimuL1tes user invo(-,.."ffllet1t and reassures management about progres.,.At d1e same tlme, some methodologies ha.-e been critldzed for expecting too much doctunetltation that adds little value
to the process or rest~tillg system. Our FAST methodology advocates a baance between
the -,..illue of doc1.unet1tatlo11 ai1d the effort: to produce It. Experts call this agile ,nodeltng.
Prin<iple 51 Establish Standards In a perfect world, all h1formatlon systems would
be Integrated such ti1at ti,ey behave as a single system. Unforttmately, this never happens because information $)'stems are developed and repL1ced over a very long period of time. Even orga1lizatlons that purchase ai1d lnslall an ettterprise resource
p la11oh1g (ERP) product usually discover that tl1ere are app lications and needs that fall
outskle the ERP system. Systems lotegration has becane critical to the success of any
organ.izatlon•s lnformatlon systems.
To achieve or Improve systems lotegratlon, organizations turn to sta ndards. In
many org.ulizations, these standards rake the form of enterprise Information tedu1ology trebitecture. An IT architecture sets standards that ser,--e to direct technology
solutions ai1d lnformatlon ~tem.s to a common technology -,..1s1on or conflgtuatlon.
• 1•
1.....
74
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
An Information tedmology architecture typically standardizes on the following (note:
lt Is not Important that you know what all these sample technologies are):
Database tecbnology- What database englne(s) wUI be used (e.g., Orad•,
IBM DB2, ~Ucrosoft SQL s,roer)? On what platforms will they be operated
(e.g., UNIX, U11ux, Windows XP, MVS)? What technologies wUI be used to
load data Into online transictlon processing (OL'fl>) databases, operational
data stores, and data warehouses (l.e., Extract Transform and Load [Im.1)1
Sofrtl)(lre tecb11.ology- Whar application developmet1r environment(s)/1tt1guage(s) wUI be used to write software (e.g., IBM's Webspbtre wlthjaw,
,_Ucrosoft's Vfsual Studio ..'VE!' wlth Vfsual Baste .,VE/', Visual C+ +, and/or
Visu.al C#; S)·ebase's Powerbuf.ltler, Oracle's Oracle limns)?
l11terface tech110/ogy- How will user interfaces be developed- with MS
Wl11do1vs components or "('eb languages and components (e.g., an xHnlJL
edJtor such as ~tacromedta's Dreat1'U)Qaver, a portal engine sud1 as 181\il's
Websphero)? How will data be exchanged betwee11 different Information sys.
terns (e.g., a data broker such as IBM's MQ Messaging, an XMLbased data
exchange, or a custom programmed interface)?
Notice how these :ircll.itectun.l questions closely correspond to the technology
drivers In yottr information system model.
ht the absence of an IT architecture, each information system and application
may be built using radically different technologies. Not only does this make it difficult
to Integrate applications, but it creates resource management problems- IT organJz.atloos cannot as easily move developers betweett projects as priorities change or emer.
geodes occur because different teams are staffed wlth technical competencies based
on the '\o-:trlous technologies used and belng used to develop lnformation systems. Cre.
atlng an eillerprlse rr ardlltecture and driving projects and teams to that architecture
make more seitse.
As new tedu1ologies emerge, an IT ardtltectttre must change. But that change
can be managed. The chief tedmology officer (CTO) In an organlzatlon Is frequently d1arged with technology exploration and IT architecture management.
Glven that architecture, all Information $)'stems projects are constrained to lmpJe.
ment new $)'stems that conform to the architecture (ttnless otherwise approved by
the CTO).
process man.agemeot an
ongoing activity that docu.
ments, teaches, oversees the
use of, and imoroves an orga.
nization's chosen methodol·
<¥JY ~he "process") for
systems devebpment.
Process management is con.
cemed with phases, activities,
deliverables, md quality stan.
dards that shoo Id be consistently applied ;o an projects.
project maaagemeot the
process of seeping, planning,
staffing, orgarizjng, directing,
and controlling a project to
develop an information system
at minimum c«st, within a
specified time frame, and with
aa:eptable qu~ity.
Principle 61 Manage the Process and Proiects J\ilost organizatio1ts have a $)"'Stem
development process or methodology, but they do 11ot always use it consistently on
proJect-s. Both the process and the projects that use It muse be managed. Process
m..1.11.agement ensures t11.1t an org;ulization•s chosei1 process or management is used
conslstet1tly on and across all projects. Process mai1.1gement also defines aitd improves the chosen process or methodology o,--er time. Project management ensures
that an information system is developed at minimum cost, within a spedfled time
frame, and with acceptable quallty (using the standard system developmetll process
or methodology). Effective project managemetll ls essential to achieving CM.M Level 2
success. Use of a repeatable process gets us to CJ\iO.I Level 3. C,_0.1 Levels 4 and 5 re.
quire effective process managemet1t.. Project management can occur wlthottt a standard process, but ht mature organizations all projects are based 011 a stanclatdJzed and
managed process.
Process management and project mai1.1gement are h1fluenced by tlte need for
quality management.. Quality standards are built Into a proces., to ettsure that the ac.
tivitles and deliverables of each phase will contribute to the development of a high.
quality Information system. They reduce the likelihood of missed problem, and
requlrements, as well as flawed designs and program errors (bugs). Standards also
make tlte IT organization more agile. As personnel changes occur, staff can be relocated betweet1 projects with tlte assurance tl1.1t every project ls following an under.
stood and accepted process.
Information Systoms Oovolopmont
Chapter Tine
7S
Prindple 71 Justify Information Systems as Capital Investments Information
systems are capital investments, just like a fleet of trucks or a new building . System
owners commit to this Investment. Notice that the itlitlaJ commitment occur s early In
a project, w hen system owners agree to sponsor and fund the project. Later (during
the phase called decisf.0·11 an.afysts), system owners recommit to the more costly ted1n.ical decisions. In considering a capital investme nt, two issues must be addressed:
I. For any problem, there are likely to be se,-.ral possible solutions. Toe si·sterns
analyst and other stakeholders should not blindly accept tl,e first solution suggested.111e analyst who falls to look at altemath-.s may be doing tl1e business a
disservice.
2. After identifying alternative solutions, the ~tems analyst sl1ould e\o-aluate each
possible solution for feasibility, especially for cmt-e ffectlven ess. Costeffectiveness ls measured using a technique called cost--be11.eftt analysts.
Llke project and proce.s., management, cost-benefit analysis ls performed throughout
the ~·stem development process.
A slgnUlcant advantage of tl,e phased approach to systems developme nt Is that It
provides several opportunities to reevaluate cost-effectiveness, risk, a nd feasibility.
There is often a temptation to continue w:idl a project 01'1.ly beciuse of the ln.,--estment
cost-effecti,•eoess the
result obtained f¥ striking a
balance be twee, the life time
costs of develoi::ing, main.
taining, and op«ating an
information sysem and the
benefits derived from that
system. Cost.ef'ectiveness is
1111:1WSUlt1cJ by I..U:ll·Wlle lil
already made. In the long run, canceled projects are usually much Jess costly than Im- analysis.
p lemented disasters.Th.is is extremely important for young analysts to remember.
btost ~tem owners want more from their systems than they can afford or are
willing to pay for. Furthermore, tl1e scope of most Information system p rojects lo. strategic infor-matioo
creases as the analyst leanu more about the business problems and requirements as systems plan a formal
strategic plan (3to 5 years) for
tl1e project progresses. Unfortw1ately, most analysts fall to adjust estimated costs and building and improving an
sd1edules as the scope Increases. As a resltlt, the analyst frequently and needlessly information tectnology infra.
accepts responslblUty for cost and schedule overruns.
strucil.l re and th~ information
Because information systems a re recognized as cap ital investments, $)'stem de- system applications that use
velopment projects are often drlvet1 by enterprise planning. Many contemporary lo. that infrastructufe.
forrmtlon technol<>g)' business unlts create and mah1taln a s trategic io.fo n.uatlo 11
S}''Steins pL"UL Such a plan identlfles and prioritizes lnformatio11 system development
eoterpt ise plan
p rojects. Ideally, a strategic Information systerus pfao Is driven by a s trategic enter- strategic
a formal strategc plan (3 to 5
p rise pL1J1 t11at charts a course for t11e entire business.
years) for an err.ire business
Prindple 81 Don't 8e Afraid to Cancel or Revise Scope There ls an old saying:
• oon't tlvow good money after bad." In other words, don't be afrald to cancel a project
or revise scope, regardless of how much money hts been spent so fur- cut your
losses. To this end, w c advocate n cr<.":cplng commltan.c o.t approach to systems
developmet1t .3 With the creeping comntitment ap proach, multiple feasiblllry d 1eckpoints are built into any systems developmetll methodology. At ead1 checkpoint feasibility is reassessed. All pre"iously expended costs are co1uJdered swlk (meaning 11ot
reco,;erable). They are, therefore, ltrelevant to the decision. 111us, the project should
be reevaluated at each d1eckpoint to determine lf It remains feasible to continue
in,-estlng time, effor t, and resources Into tl1e project.At ead1 checkpoint, the analyst
shotid consider the following options:
Cancel the project lf lt Is no longer feasible.
Reevaluate an d adjust tl1e c05IS and schedule lf project scope ls to be increased.
Reduce the scope if the p roject budget and schedule are frozei1 and not suffi.
dent to cover all project objectives.
T he concept of sunk costs is more or Jess familiar to most fina ncL1l analysts, but ft Is
frequently forgotten or not used by tl1e majority of systems a nalysts, most S)'stem
users, and even many system owners.
~ hotnu Gildebk~ ~ ~ f a l Dttta PIO("fu#lg ~sttnll AJ,<t~M, 2lld ,:d,(F.bgl«1'00d Cli.K, NJ: Pk.ntico: lhll,
198,>,ee:.g
that defines its mission,
vision, goals, S'ttategies,
benchmarks, an:t measures of
progress and achievement
Usually, the straleQic enterprise plan is complemented by
strategic businsss unit plans
that define how ;ac.h business
unit will contribute to the
enterprise plan.The informa.
tion systems plan (above) is
one of those unit.level plans.
creeping commiuneot a
strategy in 'Mlich feasibility
and risks are cootinuously
reevaluated throughout a
project. Project budgets and
deadlines are adjUS1ed
accordingly.
76
Part ono
risk maaagemeot the
process of ide1tifying, evaluat·
ing, and controlling 'M'lat
might go wrong in a project
before it becomes a threat to
the successful completion of
1ho Contoxt of Systoms Dovolopmont ProjOffl
In addltlon to managing feaslblUty throughout the project, we must manage risk.
Risk m.1..o.agemeot seeks to balance risk and reward. Dlfferent organJzatio11S are
more or less averse to risk, meaning that some are willing to take greater risks than
others In order to achieve greater rewards.
Get the System Users
Principle 91 Divide and Conquer Whether you realize it or not, you learnOO the
dtvJde-and-conquer approach throughout your education. Since h.igh school, you've
been taught ro outline a paper before you wrfte It. Ou tlining ls a dJ'\oide-.1n<ko11quer
approach to welting. A sim1L1r approach ls used in $)'stems development. \X'e dJ,·1de a
system Into subsystems and components in order to more easily conquer the prd>lem
and build the L,rger system. In ,ystems analysi.s, we often call tills factoring. By repeated!)• dlvldlng a L,rger problem (,ystem) Into more easily managed pieces (sub>)•stems),
the analyst can slmpllfy the problem.solving process. Thls dl>ide.and.conquer
approach also complements communication and project management by allowing dlf.
feret1t pieces of the system to !;:(! communicated to dtfferet1t and the most: appropriate stakeholders.
The building blocks of yow Information system framework provide one basis for
cfh.idfng and conquering an lnformatlon system's development. We will use this frame-
lnvolwd.
wod: throughout the book.
the project or i'nplementation
of the informa1ion system.
Risk management is driven b'f
risk analysis a assessment.
PRINCIPLES Of
SYSTEMS
DMLOPMENT
Usea ProblemsSo~ing
Approach.
Establish Phlses and
Activ~ies.
Doo.,ment thrcughout
Development.
Establish Standl.rds.
Manage the Processand
Projects.
Justify lnformaion Systems
as Capital 111'11lStments.
Don't Be A~aid to Cancel or
Revise Scope.
Divide and Conquer.
Design Systems for Growth
and Change.
Principle 101 Design Systems for Growth and Change Bush1esses d1..1oge over
time. Their needs change. Their priorities dtange. Accordingly, lnfonnatlon sy,tems
that support a bush1ess must: change over time. For this reason, good methodologies
sho,tld embrace the reality of change. Systems shottld be designed to accommodate
both growth and changing requirements. In other words, well-designed lnforimtlon
systems can both scale up and adapt to the business. But regardless of how well we
design systems for growth and change, there wUJ always come a time whett they
simply cannot support tl,e business.
System scientists describe the natural and inevitable decay of all systems over
time as e11..troP)i As described earlier ln this section, after a system ls Implemented
Jt enters the operatf.011s and 111atnte11a11ce stage of the life cyde. During tllls stage
the attalyst encow1t ers the need for changes that range from correcting simple mistakes, to redesigning the system to accommodate changing technology, to making
modlflcations to support changing user requJrements. Such d1anges dJrect the
analyst and programmers to rework formerly completed phases of the life cycle.
Eventually, the cost of maintaining tl1e current system exceeds the costs of developing a replacement system- tl1e current system has reached entropy and bec..vui ~ vl,:,ult::le,
But system entropy can be managed. Today's tools and tedmlques make It possible
to desJgn systems that can grow and change as requirements grow and change.111ls
book wlU teach you many of those tools and techniques. For now, It's more lmp«tant
to simply recognize that flexibility and adaptability do not happen by acddent- tl>ey
must: be built Into a system.
We have presented IO principles that sho,tld ,mderlle any metl1odotogy. TI,ese
prh1dples are summarJzed in the margin and can be used to evaluate any methodology, Including our FAST metl1odology.
~~~A_S_y~st_e_in~s_D_e_v_e_l_o_p_in
~e_n_t_P_ro
~ ce
~ss~ ~~~~~~~~~~~~~)
In tllis sectJon we'll examine a logical process for systems development. (Remlnder: FAST ls a hypothetlcat metl1odology created for Jeamlng purposes.) We'll
begin by studying types of sy,tem projects and how tl1ey get started. Then we'll
Introduce the eight FAST pluses. Anally, we'll examine alternative variations,
or ..,outes• through the phases, for different types of projects and development
strategies.
Information Systoms Oovolopmont
>
Chapter Tine
77
Where Do Systems Development Projects Come From?
System owners and ~tern users Initiate most projects. 111e impetus for most projects
is some combination of problems, opportunities, and directives. To simplify this
discussion, we will frequently use the rerm probletti. to collectiveJy refer to problems,
opportunities, and directives. Accordingly, problem solvt11g refers to solving problems, exploiting opportunities, and fulfilling directivts.
There are far too many potential system problems to list them all In this book.
However,James Wetherbe developed a usef,d framework for classifying problems.• He
calls ir PIECF.S because the letters of ead1 of the six categories, when pur rogether,
spell the word ..pieces."The categories are:
P the need to correct or improve perfort11a11ce.
J the need to correct or improve infortnation (and data).
E the need to correct or improve eco11.01nics, control costs, or increase profits.
C the need to correct or improve co11trol or secttrity.
E the need to correct or improve efficiency of people and processes.
S the need to correct or improve service to customers, suppliers, partners,
employees, and so on.
problem an u,desirable
situation that prevents the
organization from fulty
achie,,ing its mission, vision,
goals, and/or otjec.tives.
oppo-rtunity a chance to
improve the organization even
in the absence of an identified
problem.
d.irecti,•e a new requirement
that's imposed b'f manage.
ment, gowrnm,nt, or some
external influence.
Flgme 34 expands on ead1 of the PIECES categories.
The categorJes of the PIECES framework are nefther exhaustive nor mu tually
exdusJve- they overL1p. Any given project ls usualtl d1aracterized by one or more
categories, and any given problem or opportunity mar have Implications with respect
to more ti1an one category. But PIECES is a practical framework (used In FAS1), not
just an academic exercise. We'll re>isit PIECF.S several times in this book.
Projects can be either planned or w1planned. Apla,med project Is the result of
one of the following:
t11/or-1natlo11 syste11JS strawgy plan h.as examined the business as a whole
10 identify those system development projects that will retum the greatest
sr.rateglc (long-term) value to the bush1ess.
A business process ff!desig11 has tl1orough.Jy amlyzed a series of business
processes to ellmfnate redw1dancy and bureaucracy and to lmpro,-e efficiency
and Yalue added. Now ft ls tlme to redesJgn the supporting information system for those redesigned bush1ess proces.,es.
All
Toe opposite of planned projects are u.11plamwi projects- ti1ose that are triggered by a spec!Jk problem, opportunity, or directive that occurs h1 the course of doing business. 1-fost Of'gan.lzntlons have tlO shortage of unplanned projects. Anyone enn
submit a proposed project based on something that Is happening h1 ti,e business. Toe
nUJtlOO of unpL1nnecl-project proposals can easily overwhelm the largest h1formation
systems org.,nlzatlon; therefore, ti,ey are frequently screened and prioritized by a
steerlo.g committee of system owners and IT managers to detenn.Jne which requests get approved. Those requests that are not approved are backlogged w1til
re.sources become available (which sometimes never h.appens).
Both planned and unpL1nned projects go through the same essential system development process. Let's now examine the project phases h1 somewhat greater detaU.
>
The FAST Phases
FAST. Uke most methodologies, consists of phases. Toe number of phases will vary
from one methodology to another. In Chapter J you were introduced to the four
classic phases of the system developmetll life cycle. Toe FAST meti1odology employs
•Jwe.c\'ll'ttbC'.tbe ILlld Nic:bol.- P.\litiL;,:ti.S)!tlmu A#4'~sis """ DeoJfi•: Trr¥iriol,al, &.st Pnw:t'it:ff., 4 th C"d. (St. P.niJ,
MN:Wbit PubJi$hills, 1994).ep. 196-199. Jatne.c \'ll'ctbctbe is 11. respC'.C'.ted ini,n:natiob sy,tC'.tnJ educa!Ot rescatc:bd',ILlld
OObJUl11bt.
steering committee an
administrative b)dy of system
O'M"lers and information
technology executives that
prioritizes and approves
candidate syste11 develop.
ment projects.
backlog a repository of
project proposals that cannot
be funded or sttfi:Jd because
they are a lower priority than
those that h@l9 been ap.
proved for systErn develop.
ment. Note that priorities
change over ti1Tl9; therefore, a
backlogged proj;ct might be
approved at some future date.
78
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
The PIECES Problem-Solving Framework and Checklist
The following checklist for problem, opportunity, and directive identification uses Wetherbe•s PIECES framework.
Note that the categories of PIECES are not mutually exclusive: some possible problems show up in multiple lists.
Also. the list of possible problems is not exhaustive. The PIECES framework i.s equally suited to analyzing both
manual and computerized systems and applications.
L
PERFORMANCE
2.
A.
Throughput - the amount of work perfonncd
B.
o.,u some period of time.
Response times - the average delay between
a bansaction or request, Md a response to that
trMsaction or request.
3.
CONTROL (and Stturity)
A.
INFORMATION (and Data)
A.
overload"
6.
7.
8.
B.
lnfonnation that i.s not in a useful famat
lnfonnation that i.s not accurate
lnfonnation that i.s difficult to produoc
lnfonnation i.s not timely to its subsequent use
lnpJtS
l. Data i.s not captured
2 . Data is not captured in time to be useful
3. Data i.s not ac:curately captun:cl - contains
4.
""""
Data is ctifficuh to capture
5.
C.
Data i.s captun:cl redundantly - same data
captured more than once
6. Too much data i.s captured
7. llleg.i,J data is captured
Sto:cd data
l. Data is stored redundantly in multiple files
and/or databases
2 . Same data items have different values in
different files (po« data integration)
3. Stored data is not accurate
4. Ditto. i, not i,eeurc to 11.c:eidc:nt or vo.ncki.fum
5. Data is not well c.ganiu:d
6. Data is not flexible - not easy to meet new
information needs from stored data
7. Data i.s not accessible
ECONOl\,OCS
A. Costs
l.
2.
3.
B.
Costs are unknown
Costs are untraceable to source
Costs are too h.igh
Too little security er control
L Input data i.s not adequately edilcd
2. Crimes (e.g., fraud, embezzlement) are (or
can be) canmittccl against data
Ethics are breached on data or information
- refcn to data or information getting to
unauthorized people
4. Redundantly stored data is iroonsislcnt in
different files or databases
5. Data privacy regulations or guidelines ue
being (or can be) violated
6. Processing errors are oc:curring (either by
people. machines, or software)
7. Occision-mak.ing errors are occurring
Too much control or security
L Burcaucratioc red tape slows the syslcm
2. Controls inconvcnien:e customers or
employees
3. Exoc.ssive controls cause prooc.ssing delays
3.
Ou4>uts
l. lack of any infonnation
2 . lack of necessary information
3. lack of relevMt infonnation
4. Too much infonnation - "information
5.
New markets can be Qplorcd
CWTCnt marketing can be improved
Orders can be increased
B.
EFFICIENCY
A.
B.
C.
D.
People. machines. or computers waste time
L Data is redundantly input er copied
2. Data is redWldantly processed
3. Information is redundantly gcncratccl
People. mach.ines. or computers waste matcnals
and supplies
Effort required fer tasks is excessive
Material required for tasks is exccssi•,c
SERVICE
A.
The system produces inaccurate results
The system produces inconsistent results
The syslcm produces unreliable re.suits
D. The system is not easy to learn
E. The system i.s not easy to use
F. The system is awkward to use
G. The system is inflexible to new or exceptional
situations
H. The system is inflexible to change
L The system i.s iroompatible with other systet1S
B.
C.
Profits
F I GU R E 3 • 4
The PIECES Framework for Problem Identification
Information Systoms Oovolopmont
elghl phases to better define periodic milestones and tl,e dellverables.11,e grid below
compares the FAST phases to the classJc phases. As ~·ou can see, both sets of phases
cover the same ground, bur FAST is more detailed.
Cbssu, Phases
Pl'Oject
System
Sy,1e1n
System
FAIT Phases
Initiation
Analysis
Design
Implementation
Soopedefirition
x
Pn:blem analyas
x
x
Rec,.,irements analysis
x
~ icel design
x
Oeeieion enalvais
(a svsum analysis t,anei, oo phase)
Ph)'Sical de.sign and integration
x
Coneituction and testing
x
lneiallalion end delivery
x
x
Figure 3-5 lllustrotes the phases of the FAST methodology. Each phase produces deliverables that are passed to the next ph..,se, And docttmentatlon accumulates as you
complete ead1 phase. Notice that we ha,--e included ait lconic representation of the
building blocks to symbollze this accumulation of knowledge and work-lo-process artlfacts duting system development. Notice also that a project starts with some combloa.
tlon of PROBLE.\SS, OPPOR11.INITtES, and DIRECTIVES from dte user community (d1e green
arrow) and Bnlshes with a WORJONG BUSINESS SOWTION (the red arrow) for the user
commuolty.
Figure 3-0 shows the FASTmethodology from the perspective of yottr lnfonnation
system building blocks that you learned in a,apters I and 2.The phases are on the
ril!.htt'1and side. The deliverables are built around the buildlna blocks for knowledae.
processes, and communicatlons.111e stakeholders are on the left-hand side. Notice
l1ow we h.ave expanded and duplicated some stakeholders to reflect their lnvolvemenl opposite the phases in whid1 they primarily participate.
NOTE: 11,e remainder of thls section briefly describes each of the eight basic
phases. Throughout this discussion, we will be referrlng ro the proces., flowchart
In Figttre 3-5, as well as the building blocks >iew of the process h1 Figure :\-0. Also
throughout the discussion, all terms prlnred lo S'll.AU CAPS refer ro phases, prerequlsltes (inputs), and deliverables (outputs) shown in Flgttres 3-5 and 3,6.
Scope DefiniNon The first phase of a typical project is SCOPE DEFINITION. The purpose of the scope dellnltlon phase is twofold. First, It answers the question, "ls this
problem worth looking at?" Second, and assuming d1e problem Is worth looking at, It
establishes the size and boundaries of the project, the project vision, any constraints
or limitations, the requlred project participants, and, finally, ti,e budget and schedule.
In Flgttre 3.6, we see ti1.1t the participants h1 the scope definltlon pJ1.,se primarily
include
~ OWNERS, PROJOCT M.ANA.GfltS,
and SYSTE.\.t ANA.1.¥STS. System users are gener-
ally excluded because it Is too early to get into the J.,..el of detail they wlll e>1'11tttally
brh1g to the project.
Chapter Tine
79
BUSINESSCOMMUIUTY
g
START:
Problem&, Opp:utun1aea.
D1rect1vee, 00 nstra1nte.
ANStt
Working
Queln-
11rld\11<$1(11'1
$Tlllf.llll 0WNt.te " NU lbll:Hll
SOIU11M
sy,1em
unp10wment
OtlJecilvea
ProDlem
Ststemefll
stiiemert
Llf• Cycl• St•g•
01Wo.·k
Scope &V181on
SYSTEM
OPERATION
r
REQUIREMENTS
ANALYSIS
OOCU'l'lentalCl'I
&
MAINTENANCE
From Fig.ire a.2
D:lcumemauon
Post·Aud.n
Reo1tew
1
~,
.
,~
~/
9U811'1888
Req.nremeribt
Statement
:ir'::ifll!lllm
4--- ~1n,u:int1111nn
! < ) - - - - D:1cumen1auon
Ooeratlmal
system
/1
n,1n1ng
Mater181$
F=u.nctlOrsl
System
cs
7
r
oocumercaooo
'
OOCllmenllllJcn
)l
Log1ca1
oee1gn
CONSTRUCTION
a
Recl881 IJ16 d
system
TESTING
9.l8ln!I$$
Proposal
Appllcstlon
oee1gn
PrototYs>M
I
Al1:11 tectu re
Pr,ve1ca1
n:i11:11on Slf'IM:111..,.lnri•
( FIGURE 3 • S
Process View of System Development
)
Strategic Enterprise Plan
81
Chapter Tiree
Information Systoms Oovolopmont
Sltateglc 1nrormaao n Systems Plan
Goll:
~&ullnMt
COMt.lJNICATIONS
-
@)
-
~
S T A TEMENT OF W O AI(
PA08LEM S T A TEMENT ( u , 1n9 111$ PIE C E S tr , m o wonl)
IN FORMATION
SCOPE
FUNCTIONAL
COM• UNICATION8
oco..
oco..
Vl910N
VISION
VISION
•
•
•
, 11
~-----• -•_•_'," e &e AE O U IA e111 ENT8 &TA T Er"- '_"_ ' - - - - - ~
8U81NE&8
8u&IN ese a 8'Y8TEII
8u&INE88
CATA
PFICleE88
INTEFIFACE
FIEOUIFIEMEHTS
IIEOUIAE• EHTS
AEOUIAE• ENT&
LOOICAL
LOOICAL
LOGICAL
I
"
IN~
.._•_,_._' _'_"_'•_•_•_o_,_'_"_'_"_'_o_•_,_•_•_'_'_'_'_•_<_•_•_"_•_'_"_'_' _"_•_•_•_"_•_•_••_•_••_>
_, ,
J.J....11
L...:::::::
. :'::'
:."'
:, ..
: ::::::'..._....'.:::::::
o:::::"
:.::::
::::::::._..:::::·:-;::;"
::.:~::::::::.JI~
t
~
I ''
•
[;
iiz
;
'
I
!.
0
'•
8Y8 TE• PR O P OSA L
(o r REQUE S T FOR SYS TEM PAOP0 8A L 8)
;
''
",
•
•
-
-
-
OE 8 1GN & PE C IFI CATI0'\1 8
.........
PHY81CAI.. 8u&INE8S
PIICleE88 0 £.81GN
PMY81CAI..
Oe81GN
PHYSICAL
u&eA 8 8 Y8TSil
INTERFACE
PHY81CAI..
80FTW1'.AE Oe81GN
$PECIFICATION8
8 PEQ ACATION&
..........
OE&ION PROTOTYPES
-
TR A INING • A TEFII A L 8
-
•
c o111• EACIAL
80F'TW!-.AE
Fll.CICAGIES
0
0
COSTOM~UII.T
w
~
•
0 £.81GN
SPECIFICATIONS
A PPUCATION
80~AE
I
I
USER
INTEFIFACE&
.......
H
H
INTEFIFACE&
~~~~~~~--_-_--=:_,~
~
O PEA A TI O N A L & Y 8 TElil
P 08 T- A UOIT AE V IEW
c-1111n1:
..........
......'°
TECl+IOLOOIES
. _.
c:ir.•,1111n1:
llffEAFACE
TECl4IOI..C>GES
Strategic Enterprise 1nrormauon Ti:lenno1ogy Arc111tscturs
F IG U R E 3 • 6
_,,rrw
'-----------'-'_'_'_'_•_•_'_'_o_•_•_•_•_•_"_'_•_'_'_"_'________
FUN C TION A L 8 Y& TEIII
:~
.!.L..11
BuJldtng Blocl<s View of Sy.tern Development
~
82
Part ono
problem statement a
statement and categorization
of problems, opportunities,
and directives; may also
include constraints and an
initial vision to· the solution.
Synonyms inC::ude pr9/imi.
nary Sllo/ and feasibility
8SS95SITl9nt.
coo.straiot t ny factor,
limitation, or restraint that may
limit a solution or the problem.
sotving process.
scope cttep a common
phenomenon wherein the
requirements and expecta·
tions of a project increase,
often 'Mthout regard to the
impact on bud~et and
schedule.
statemeot of work a
contract with management
and the user ~ mmu nity to
develop or entance an infor.
mation system; defines vision,
1ho Contoxt of Systoms l>ovolopmont ProjOffl
In Figure 3-5, we see that the scope dellnltion phase Is triggered by some comblwill add CONSTRAJ.N'J'S and
vtstON).There are several deliverables or outcomes of a scope defhlitlon. One Important outcome Is a PROBLfl\l STATENfN'l;, a succinct overview of the problems, opportunities, and/or directives that trig-d the project.11,e PIECES frameworl< provides an
exceUent outline for a problem statement. The goal here ls 11ot to solve the problems, opportunltles, and dlrecthes but only to catalog and categorize them. We sho,dd
also identify any coostralnts tlm may impact the proposed project. Examples of coost.raints lndude budget Um.its, deadlines, human resources available or not avallable,
business poUdes or goven.went reguL1tlons, and technology standards. Flnally, the
system owners sl1ould be asked for at least: a h.Jgb.Jevel '\oislon for the system
impro,--emet1ts they are seeking.
Given a basic understanding of problems, opportwlitles, directives, constr.dnts,
and vision, '\\"'e need to establish initial scope. Thus, an hlitial SCOPE S'J'ATE.\.U.NT is aJ.1other
important outcome of this phase. Scope defines how big we think the project ls.Your
information system bldlding blocks pro,ide a useful framework for defining scope.
Agttre 3-6 IUustrates that scope and vision can be defined in terms of tNfORW.TION,
f!UNCJ'IONS, and CNTER&CES. Scope can, and frequently does, change during a project.. But
natio11 of PR061.J:MS, OPPORTUNl'JlES, and DIR.OCTJVES (to wll.idt we
by documenting lnlti.'1l scope, you establish a b:iseUoe for controUin.g scope cre.p on
both the budget and the schedule.
Given the Initial problem ,ud scope statements for the project, the analyst can
staff the project team, estimate the budget for system developmet1t, and prepare a
schedule for the remaining phases. Ultimately, this ph.ase condudes with a ..go or nogo" dedslon from system owners. Elther the system owners agree wJth the proposed scope, budget, and schedule for the project, or they must reduce scope (to
reduce costs and time) or cancel the project.This feaslblUty checkpoint is Ulustrated
lt1 Figure 3-5 as a diamond.
The final and most important deliverable is a STATEMENT Ofl WORK. A statement of
work ls a contract or agreement to develop the lnfonnation system. It consolklates
the problem statement, scope Slatement, and schedlde and budget for all parties who
wlU be involved in the project..
scope, constraints, high-level
user requirements, schedule,
and budget Synonyms include
ptq9C1 chBite,, ptq9C1plan,
and S9MC9./9191 ag9f:'1Tl9nt.
Problem Analysis There Is always an existing system, regardless of whether it curret1tty uses Information technology. The PROBLE."1 ANAIYSts phase stud.Jes the existing ~
tern and analyzes the findings to pro,ide the project team with a more thorough
understanding of d,e problems that triggered the project.11,e analyst frequently uncovers new problems and atlSWers the most Important question. .. Will the benefits of solving these problems exceed the costs of building the system to solve these problems?'
Once again, Figure 3-0 provides a graphlcal overview of the problem analysis
phase in terms of your lt1formation system building blocks. Notice that the participants still Include the SYSTEN O'ON"'5 bttt that this phase begins to acth'ely ltwolw tl,e
5YS11:M USERS as well. 111e system users are the business subject matter experts in any
project. (Notice the h1tentlo11al expansio11 of the system users• perspective to o,--erlap
many phases- remember prh1c-lple l: ..Get the system users Involved.") Of crurse,
PROJECI' MANAGERS and SYSTf?.I ANA£YSTS are always h1volved in all phases of a project..
As shown In Figure 3-5, tl,e prerequisites for the problem analysis phase are tl1e
SOOPE and PROBLEM STATEMENTS as defined and approved In tl,e scope deflnltlon phase.
111e deliverable of the problem malysis ph.ase is a set of 5YS11:M L\IIPROVEMfNT osJocnVES
derived from a thorough w1derstandlng of tl,e business problems. These objectives do
not define lnputs, outputs, or processes. Instead, they defh1e the business criteria on
wbid1 any new system wUJ be evaluated. For lnstance, we might define a system
improvemetll objective as any of the following:
Reduce the time between order processing and shipping by three days.
Reduce bad credit losses by 45 percent.
Comp~· with new financL1I aid federal quallflcatlon requirements by January l.
Information Systoms Oovolopmont
Think of system Improvement objectives as the gradt11g criteria for evaluath1g any
new system that you might eventually desJgn and Implement System improvement
objecth,--es may be presented to ~·stem owners and nsers as a written recommenda-
tion or an oral pre.sentatlo11.
Depending on the complexlty of the problem ao:l the project sd,eduJe, the team
may or may nor choose to formally document the existing system. Such documentation frequently ocntrs when the business processes are consJdered dated or overly
bureiucratlc. Documentation of the exlstfng system ls sometimes called an ..AS 15•
BUSINESS Mooa.The as-is model may be accompanled by analysis demonstrath1g lneftl.clencles, bottlenecks, or other problems related ro the business proces.,es.
Every existlng system has Its own terminology, history, culture, and nuances.
Learning those aspects of the system ls an Important by-product of this phase. From
all of the lnfonnation gathered, the project team gains a better understanding of the
exlsting system's problems and opportunltles. Aftet reviewing tl,e fhl<llngs, ti,e system
owners wUJeither agree or disagree with the recommended ~tern improvement ob.
jecmes. And consistent with the creeping commitment principle, we indude anotl1et
go or no-go feasibili ty checkpoint (ti,e red diamond) at the end of tl1e phase. The
project can be eithet:
Canceled if the problems are deemed no longer worth solving.
Approved to continue to the next ph..,se,
Reduced or expanded lo scope (with budget and sd1edt~e modifications) and
then appro,-ed ro continue to the next phase.
Requirements Anatysis Given system owner appto'\o-al to continue from the problem analysis phase,11ow you can design a new system, right? No, not yet! What capabillties should the new system pro"ide for its users? Wbar data must be captured and
stored? What performance JeveJ ls expected? Careft.il This requires decisions about
what the system must do, 1101 how it shot~d do those things. The RJeQUIRmENTS ANALVSJS
phase defines and prioritlzes the bust11ess requirements. Simply stated, the analyst
approaches the users to find our what they need or '\\'ant out of the new system, carefully avoidh1g any discussion of technology or tedmical Implementation. This ls per-
haps the most lmportanr phase of systems development Errors and omissions In
requirements analysis result in user dissatisfaction with the fina l ~·stem and costly
modifications.
Retumlog agah1 to Figute :\-0, notice that the participants primarily lodude both
svs-nru us"'5 (which may indude owners who will actually use the system) and SYSTENS
are also Involved. SYSTE."1 DESIGNERS are omJcced from c.hJs
ph.ase In order to pre,--ent premature attention to technology solutions. The building
bJocts can themselves pro'\oide the framework for defining many business requirements, indudh1g BUSINESS DATA R.EQUUlJ:ME'l(J'S, BUSINESS PlOCESS R.EQU IRE.\.f.DltJ"S, and BUSINESS
AND svsTE."1 INTEllfY..CE REQUIRE.\.U.NTS. Because the business requirements are intended to
solve problems, the PIECES f.ramework can also provide a useful outline, this time for
a requirements statement.
In Figure 3-5, we see that the ~ IMPROV'EME'IT O BJECTMS from the problem
analysis phase are the prerequisite to the requirements analysis phase. The deUvernble
is a WSINESS R.EQUIRE.\.f.DltJ"S STATEMENT. Again, tllis requirements statement does not specify any tedmlcal possibUlties or solutions. The requlrements statement may be a document as small as a few pages, or it may be extt11SJve with a page or more of
documentation per requirement.
To produce a business requJrements stat ement, the systems analyst works
closely wlth ~·stem users to Identify needs and priorltles. Tilis Information is collected by way of Int erviews, questionnaires, and facilitated meetings. The challenge
to tl..e team ls to YaUdate those requirements. TI1e ey•stem improvement objectives
pro,ide the ..grading key" for business requirements: Does each requ.tre111e1,1
co11trtb·ute to 1n.eett11g 011.e or 111ore systettJ. t111prove1ne1,1 objectives? Cl1apters 6
ANALTSTS. P'ROJ£cr MANAGERS
Chapter Tine
83
84
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
and 7 will Introduce systems analysis tools and tedmlques for ldet1tlfylng and documenting user reqttlrements.
Typically, requirements must also be prioritized. Priorities serve two pwposes.
First, If project tlmellnes become stressed, requirements priorities can be used to
rescope the project. Second, priorities can frequet1tly be used to define Iterations of
de.sign and constructio11 to create staged releases or versions of the final product.
The requirements analysis phase should never be skipped or shortchanged One
of the most common complaints about new ~·stems and applications ls that they
don't really satisfy the users' needs. This usually happens whet> system designers and
builders become preoccupied with a tedmlcal solution before fully understanding
the business needs. System ~sJgners and builders are dependent on competent
systems analysts to work with users to define and document complete and accurate
business requlrements before applying any technology.
system model a picture of
a system thatrepresents
reality or a desired reality.
System models facilitate
improved comnunication
between system users,
system analysts, system
designers, and syS1em
builders.
logica.J design the transla·
tion of busines.s user
requirements ilto a system
model that depicts only the
business requrements and
not arrt possit le tec.hn ical
design or impl~mentation of
those requirements. Common
synonyms include conceplhtl
design and essential d'1$g1,
the latter of which refers to
modeling the "essence" of a
system, or the "essential
requirements• independent of
any technologJ. The antonym
01 1og1ca1 aes1gn 1s pflYStC8/
design (define:t later in this
chapte~.
aaal}'Sis paralysis a
satirical term coined to
describe a corn mon project
condition in 'Mlich excessive
system modeling dramatically
slows progress toward implementation of the intended
system solutioo.
Logical Design Business requirements (above) are usually expressed In words. Sys.
terns ai1..1lysts have fow1d ft useful to translate those words lnto pictures called S)'Stem
models to "-alidate the requirements for compJeteness and consistency. {FJgttre 3-5 is
an example of a common system model called a data flow dlagrani) System mode~
in.g Implements :i timeless concapt: ..A plctlU'e ls WOt'th a thous:ind words."
The LOGICAL DESIGN PHASE trao.sL1tes bush1ess requirements lnto system models.111e
term logical design should be Interpreted as"technology lndependet1t; meanlt11 tl,e
pictures Illustrate tJ,e system Independent of any possible technical solution- hence,
they model buslne55 requirements that must be fulfilled by any technlcaJ solution we
mlght want to consider.
DJfferet1t methodologies require or recommend different amotmts and degrees of
system modeling or logical design. Prescriptive methodologies like stru.ctu.red a11al}'
sf.s a11d design, t11/ornU1tlon engineering, and the Ration.al Untft.ed Process (R.UP)
usually requlre that many types and/or Instances of system models be drawn In var!Ol lS Jevels of detail. ForrunateJy, computer-automated tools are a'\o-ailable to a~ist the
systems analyst In these drawl,11 tasks. Alternatively, agUe methodologies like arch/,
teaed raptd applicatlo1i deve.lcp»ient and e.Ytrenie progran1.ntt11g recommend "Just
enough modellng.• Tbis =Ued agile modeling seeks to prevent the project from
degenerating Into a condition cilled aualysls paralysls. This textbook Jeans toward
agUe methods but recognJzes that complex problems m.1)' besr be solved ush1g more
prescriptive approaches.
In Figure 3-0, we see that the participants lndude SYSTEM ANALYSTS (wl10 draw the
models) and SYST6\l USERS (who vaUdate the models). l'RoJECT MANAGERS are always lo.
d uded co et1Sure chat modellng meets scandards and does not decer overau ptoJect
progress. We can draw (1) LOG CAL DATA MODELS that depJct data and information requlrements, (2) J.OGlCAL PROCESS NOoas that depict business processes requirements, and
(3) J.OGlCAL tNTERIIICE Mooru that depict business and system Interface requirements.'
In Figure 3-5, we see that the prerequlslte to logical design Is the BUSINESS REqUlllE·
MENTS STATE.\.W'ln' from the previous phase. In practice, the requ.lremei1ts analysis and
logical design phases almost always have considerable overlap. In other words, as
business requlremet1ts are ldentlfled and documented, tJ,ey can be modeled. The deU,-erables of logical design are the LOGJCALSYSTE.\t MOD fl.SAND SPOCCflJCATIONs tbemseJves.
Depending on the methodology used, the level of detail ln the speciJlcatlons wUJ vary.
For example, we may define a business rule that speclfles the legitimate values for a
data attribute such as Credit Rr.ttng or a rule that specl.tles the business policy for a
Credit Check.
'lhOIIIC' ofyou 111teidy &tniliat with ol:j«t<Ol'm"IIM tnodd..ihgm:ll.lld note- that objtct IDOdch tctld to blur- the boulld.u'iCII
ofour fhitnewott ,ornewhat, but the' ftu..lnt'fl'Ol'k ai..n. llliU bt applied ldtat:e the probJttn to be ,olved iJ,tiUd.tn'u by tht
thh'e futii:laniehtll.l busibc,sp:xd, i.UuJltllttd i.t our fhitnewotk. Thi, • ·a.I be ~ l e d in the- objeetotkbled II..ID1y,i,
lllld ~ c:b11pttt'J of thiJ book.
Information Systoms Oovolopmont
Before we move on to the next phase, we should nore tl1at the SCOPE DEflNlTION,
and LOGICAL OESGN Pli,\SES are collectively recog11.ized by most experts as systetn analysts. Some ex.J)(rtS woldd also lnclude ottr next
ph.ase, DECISION ANALYSIS. Bur we cons.ider ft to be a system analysis ro system design
transition phase because ft makes the traosltlon from the busines., concerns of system
owners and users to the technology concerns of system designers and builders. And
of course, systems analysts are the common th.r ead tl1at ensures continulty as we
make this trai1SJtlo11. Let's ex.amine the trans.itlon .
PR.081£.\.1 ANA.LYSIS, R.EQUUlE.\.W'ltl"SANALYSIS,
Decision Analysis Given business reqttfrements tnd the logical system models,
there are usually numerous alrematlve ways to design a new information system to
fulfill those requlremet1ts. Some of the pe,tltm1t questions lndude the following:
How much of d1e system should be automated wfth information technology?
Sho,dd we putchase software or build it ourseh-.s (called the make-versushuy
tfecls/011)?
Should we design the ~tern for an lnternal network, or shottld we design a
Web.based solutlo11?
Wh.'lt inforcn:ition technologies (p-<>6sibly emeqjog) m.Jght be usefld for this
application?
These questions are ai1SWered ln the DECISION ANALYSIS phase of the methodology. The
purpose of this phase is to (I) Identify candidate technical solutions, (2) analyze ti1ose
candidate solutions for feasibility, an d (3) recommend a candidate system as the target
solution to be designed.
In Figure 3-0, we see that the decision analy,is phase is positioned halfway
tivough the de>-.lopment process. Half the building blocks are positioned higher, and
half are positioned lower.This ls consistent with the decision analysis phase's role as
a transJtlon from analysis to design- and from business concerns of SYSTnt us~ s to
ti1ose of SYSTEM oisJGNERS (and, tdtlmately, system bullders). Designers (ti1e technical
expfflS In specific technologies) begin to play a role here along with system users and
svsTe.t ANALYSTS. Analysts h elp ro define and analyze the alten1atlves. Decisions are
made reg,irding the technologies to be used as part of the application's archltectute.
Ultimately, SYSTE.\.t OWNERS will have to approve or dis1pprove the approved decisions
since they are paying for the project.
Figure 3-5 shows that a dedsion analysis is triggered by validated business
requirements plus any logical system models an d speclflcations that expand on those
requirements. The project team solicits Ideas and opinions for technical desian and
implementation from a dJverse audience, possibly Including rr software ,-endors. CandJdale solutions are identltled and characterized occording ro varlous crirerla. Ir
shotdd be nored that many modern org;ulizations have information rechnology and ardlltecture standards that constrain the number of candidate solutions that might be
considered and ai1..1lyzed. (01e existence of such standards is illustrared at the bonom
of your information system bldlding blocks model In Figure 3-0.) After the candidate
solutions have been Jdet1tlfied, each one is eYaluared by the followb1g crfterla:
Teclmtcal feaslbi/r.ty- ls the solution technlcaltJ' practical? Does our staff
~ave the technlcal expertise to design and build this solution?
Operational feasibility- Will ti,e solution fuUlli the user's reqtdrements? To
wh.at degree? How will the solution d1ange the user's work en,ironmenr?
How do users feel abottt such a solution?
Economic feasibility- ls the solution cost-effective (as defined earller in the
chapter)?
Scbetfule feasibility- Can the solution be designed and Implemented within
an acceptable time period?
Risk feasibility- What's the probability of a successful implementation using
the tedu,ology and approach?
Chapter Tine
as
86
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
111e project team is usually lootlng for the ,no.st feasible solution- the solution that
offers the best combination of tedmlcal, operational, economlc, schedule, and risk
feaslbUlty. Different candidate solutions may be most feasible on a single crlttrlon;
however, one solution will usually prove ,no.st feasible based on all of the criteria.
The key deliverable of tile decision analysis phase is a SYSTEM PROPOSAL. 11lls proposal may be wrlttett and/or presented verbally. Several outcomes are posslble.111e
creeping commitment feaslbUl ty dleckpolnt (again, the red diamond) may result in
any one of tile following options:
Approve and fund the system proposal for design and construction (pos,ibly
including an increased budget and timetable If scope has significantly
expanded).
Approve or fund one of die alternatl,-e candJdate solutions.
Reject all tile candldate solutions and either cancel the project or send it
back for new recommendations.
Appro,-e a reduced-scope TersJon of the proposed solution.
1
Optionally, the dedsJon analysis phase may also produce an APPLICATION ARCHJTB:TURE
for the approved solution. Such a model serves as a hlgJ>.level blueprint (like a sinple
bottse floor pL'ln) for the tt.comruended or approved propos:il,
Before we move on, you may tu,-e noticed in Rgure 3-6 a varlatlon on the 5YS'J'Eld PRO.
POSAL deliverable called a REQUEST fOR ~™ PROP06AI.S (or RFP). This '\o':lriation is for 1 rec-
ommendation to purdwe the hardware an<l/or software solution as opposed ro buildtng
ii in,house. We'll defer any further discussion of dlls option until later in the chapter
when '\\"'e discuss the commerdal pack.age Integration variation of our basic proce!s.
ph}'Sical design the
translation of business user
requirements ilto a system
model that depicts a technical
implementatio1 of the users'
business requ rements.
Common syncnyms include
t9Chrical design or, in
describing the output, impf9.
mentatioo rnod91. The
antonym of ptysical design is
loficaJ d9Sign(defined earlier
in this chapter).
Physical Design and Integration Given approval of the SYSTJ:M PROPOSAL from the
decision analysis phase, you can finally design the new system.11,e purpose cf tJ,e
PHYSICAL DESIGN AND 1NrEGRAnon ph.ase is to transfonn the business requirements
(represented In part by the LOGICAL SYSTEM MODELS) Into PHYSICAL DESIGN SPECCflJCAOONS
that will guide system construction. In other words, physJcal desJgn addresses greater
detail about bow technology will be used h1 the new system. The design wUI be coo.
strained by the approved ARCHJiECTURAL MODEL from the pre\oious ph.ase. Also, design
requires adherence ro any inten1al teclmlcal desJgn standards that en.sure completeness, usabUity, rellability, perfonnance, and quail!)'.
Ph}'slcal design is tJ,e opposite of logical design. Whereas logical design dealt exclusively with business requlremetlls independent of any technlcal solution, physical
design represetlls a speclflc technical solution. Figure 3,6 demonstrates the physical
destgn phase from d1e perspecrtve of your bulldlng blocks. Notice d1..1t d1e destgn
phase is concerned with technology-based >iews of the system: (I) PHYSICAL DA!ABASE
DESIGN SPECCfllCATIONS, (2) PHYSICAL BUSINESS PROCESS and SOP'rWAR.E DESIGN SPECIF1CATIONS,
and (3) PHYSICAL USER AND SYSJ'E.\.1 INTFJIBt..CE SPECIFlCATIONS. The 5YSTEM DESIGNER and Sc'S11:M
ANALYST (possibly overlapping roles for some of the same indi>iduals) are the key participants~ however, certain aspects of the desJgn usually have ro be shared with the
5YSTEM usms (e.g., screen desJgn.s and work flow). You may have already had some
exposure to physical design specifications h1 elther programmlng or database courses.
There are two extreme phllosophles of physical design.
Design by spedftcatton- Physical system models and detailed specifications
are produced as a series of written (or computer.generated) blueprints for
construction.
Design by prototypl11g- lncomplete but functioning applications or subs)'S.
terns (called prototypes) are constructed and refined based on feedback from
users and other desJgners.
In practice, some combination of these extremes ls usually performed.
No new lnformatlon ~tem ex.lsts in Jsolatlon from other ex.Isling lnforrmtion
systems in an organJz.atlon. Co1uequently, a design must also reflect system Integration
concerns.The new ~tern mlLq be integrated both wJth other Information s~tem.s
Information Systoms Oovolopmont
and with the business's processes themseJves. lntegratlon is usually reflected in physical ey•stem models and design speclflcations.
In summary, Agure 3-5 shows that the deU,-.rabres of the physical design and h1tegration phase lnclude some combination of PHYSIC.U DESIGN MODEJ.s AND SPOCCflJCA'J'IONS,
DESIGN PROTOTYPES, and REDESIGNED BUSINESS PROCESSES. Notice that we have included one
final go or no-go feasibility checkpohll for the project (d,e red dL,mond). A project Is
rare~! canceled after the design phase unless lt ls hopelessly over budget or behind
sd1edule. 011 the other hand, scope couJd be decreased to produce a minimum acceptible product h1 a specltled time frame. Or d1e sched,tle could be extended to
bulld a more complete solution In m,tltiple versions. The project plan (sched,tle and
bud~t) wottld need to be adjusted to reflect these decisions.
It sho,tld be noted that in modern methodologies, there ls a trend toward merging the desJgn phase witl1 our next phase, co11structio11. In other words, the design
and construction ph.ases usually overlap.
Construction and Testing
Given some level of Pffi'SJC..U DESIGN MODELS AND SPEOflJCAwe can begin to construct and test system components for that design. Figure 3-5 shows that the primary deliverable of the coNSTRUcnON
TIO* (and/or DESIGN PROTOTYPES),
AND 'mmNc ph.ase is a ruNCnoNA.L SYS"rE.\.1 th:ir ls ttady for lmplementatlon. The purpose
of the construction and testing phase is twofold: (I) to build and test a system that ful.
tlUs bush,ess requhements and physical design specltlcations, and (2) to lmplemetll the
interfaces between the new system and existing systems. Addltio1mly, flNAJ. oocuMENr.moo (e.g., help systems, tralnlng manuals, help desk support, production control h1structlons) will be developed In prepantion for tralnh1g and system oper.,tion. The
construction phase may also involve lnstalbtion of purd1ased software.
Your information system framework (Agure 3-0) Identifies the relevant building
blocl:s and activities for the construction phase. The foetts is on the List row of building blod::s.111e project team must construct or install:
DATABASES- Databases may indude 011111,e tra1JSaCtto·11 processt11g (OL1P)
databases to support day-to-day business transactions, operational data stores
(ODS) to support day~o-day reporting and queries, and data warehouses to
support data analysis and dedslon support needs.
CoMMERCtAL SOF'JWARE PACKAGES and/or CUSTOM-BUll.T SOf'l"WAR.E- Packages are
Installed and customized as necessary. Application programs are constructed
according to the physical design and/or prototypes from the previous phase.
Both packages and ettstom software must be thoroughly tested.
USER AND svsTfl\l JNTf.RFACEs- User lnterfaces (e.a.. Windows and Web lnterfaces)
must be constructed and tested for usablUty and stability. System-t0-6)'stem
fntetfaces must be eid1er constructed or implemented using application integr.,tion technologies. Notice that MlDDLEWARl! (a type of system software) is
often used to lntegrate disparate database, sofn\•are, and Interface technologies. We'll talk more about mlddleware h1 the design unit of this book.
Agure 3-0 also idet1tlfles the participants in this phase as SYSTE2\I BUUDERS, SYSTE2\I
ANAD'STS, SYSTEM USERS, and PROJEcr MANAGERS, SYSTEM D3SJG~S may also be ln\--o(ved to
clarify design specltlcations.
You probably already tu,-. some experiet1ce with part of thls actlvity- appUcation
programming. Programs can be wrlttetl In many dtfferet1t languages, but the cturent
trend Is toward the use of '\oisual and object-oriented programming languages sud1 as
Java: C+ +, or Visual Basic. As components are constructed, they are typically
demonstrated to users In order to solicit feecll>ack.
One of the most lmportant aspects of construction ls conducting tests of both indJvJWal system components and the overall ~tern. Once tested, a system ( or version
of a system) ls ready for JNSTAUAnoN AND oEUVERY.
Installation ancl Delivery What's left to do? New systems usually represet1t a departure from the way business ls current.I)' done~ therefore, the analyst must pro'\oide
Chapter Tine
87
88
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
for a smooth transltlon from the old system to the new system and help users cope
with normal start-up problems. Thus, the J:NSTAJJ..,\TJON AND DEUVERY phase ser,--es to
deliver the system Into operation (sometimes called productl.011).
ht Figure 3-5. the FUNCTIONAL SYSTEM from the construction and resting phase is the
key lnput to the JNSTA.1.LATJON
oEJJV~Y phase. The deliverable ls an OPf.RA'JlO NAL
~
. SYSTE.\t BUILDERS install the ~tern from its de,"(>(opment en"ironment Into the
production en"ironment. SYsrat: ANALYSTS must train~ USERS, write various user
and p roduction control manuals, convert ex.lstlng files and databases to the new databases, and perform final system testing. Any problems may Initiate rewod< In pre.ious
ph.ases thought to be complete. System users pro"ide continuous feedback as new
problems and issues arise. Essentially, the Installation and delivery phase considers the
same bulldh,g blocks as the construction phase.
To provide a smooth transJUon to the new system, a conversion plan should be
prepared. Tills plan may call for an abrupt cutover, where the old system ls terminated
and replaced by ti,e new system on a specific date. Alternath-ely, the plan may rlll ti,e
old and new ~tem.s ln parallel until the new ~tern has been deemed ac ceptable to
replace the old system.
The Installation and dellvery phase also Involves training Individuals who will use
"-"°
the fh1..'ll system and develo ping docu.ruent:itlo n ro aid the system users .11,e I.tuple
met1tation phase usually lndudfs some form of POST-AUDIT REVIEW to gauge the success
of the compJeted systems project.This acthity promotes continuous Improvement of
the process and future project management
system suppon the
ongoing technical support for
users of a sys:em, as well as
the maintenan::e required to
deal with any errors, omissions, or new requirements
that may arise
System Operation and Maintenance Once the ~tern ls plac ed inro operation, it
will requlre ongoing system support for the remainder of its usefu~ productive lifetime. System support consists of the following ongoing actMties:
Asslsttng ,,sen-- Regatd.Jess of how well the users h.a,--e been trained and
how thorough and dear the end-user documentation is, users will eventuaUy
require addition.al assistance as unantldpated p roblems arise, new users are
added, and so forth.
Fixing software defects (bugs) - Software defects are errors tl1at slipped
ti,rough ti,e testing of software. These are lne>itable, but they can usually be
resolved, In most cases, by knowledgeable support.
Recoverl11g the syste111- From tlme to time, a system failure may result in a
program ..crash" an<Vor Joss of data. Human error or a hardware or software
failure may cause this. The systems analyst or tedmlcal support speclallsts
cross life<)'Cle acti,•ity
nl.ay then be called o n ro rccovcc the ~:nem- rh..1.t b , ro re:noce a :sy$tca1'$
any activity that overlaps
multiple phasEs of the system
development process. Exam.
pies include fact.findng,
docvlrt9fltation, pr959ntation,
ssi mation, teesibiNly analysis,
projo(.1 andprocoss managoment, changsmanag91T19nt,
and qulJ/ity memgomort.
files and databases and to restart the system.
Adapttng the syste1,1 to 1wu1 requtre,ne11..ts- New requlremet1ts may lndude
new business problems, new business requlremenrs, new technical problems,
or new technology requlremenrs.
fact-flnd.it1g the formal
process of using research,
interviews, meetings, questionnaires, sampling, and
other techniques to collect
information about system
problems, requirements, and
preferences. It is also called
inbrmation gath9ring or data
coH9c1m.
Eventually, we expect that the user feedback and p roblems, or changing business
needs, will indicate that it is time to start over and relnvent the system. In other
words, the $)'stem has reached entropy, and a new project to create ait entirely new
system development process should be lnltiated.
> Cross Life-Cycle Activities
system development also involves a number of cross life-cycle actMties. These
activities, listed in the margin deflnltlon, are not explicltly depleted In Figure 3-5, but
they are vital to the success of anr project. Let's brief!)• examlne each of these actl'1ties.
Fact-Finding There are many occasions for fact-llndlng d uring a p roject. Factfindlng Is most crucL1l to the euty phases of a project. It Is d uring these phases that
Information Systoms Oovolopmont
the project ream learns abour a business's "-ocabuL1ry, problems, opportunltles, constraluts, requlreme11ts, and priorities. But fact.finding Is also used during the decision
analysis, physical design, construction and tescitlg, and Installation and dellvery
ph.ases- only to a lesser extent. It Is during these latter phases that the project team
re.searches technical alten.l..1t1:,--es and solid ts feedbad: on tedulical designs, standards,
and working components.
Communication skills are essential to the successM completion of any project. In fact, poor communication Is frequendy cited as
the cruse of project deL1ys and rework. Two forms of communlcatlon that are common ro systems development projects are documeotatio11 and preseo.t..1.tio11.
Clearly, documentation and preset1tatlon opportltnlties span all the phases. In
Figure 3-7. the black arrows represent varlous instances of documentation of a phase.
Documentation and Presentation
The red arrows represent Instances where presen1atlons are frequently required.
Finally, the green arrows represent the storage of documentation and other artifacts of
systems development in a repository. A reposJtory saves documentation for reuse
and rework as necessary.
feasibility Anatysis t:onststent with our creeping comrottment approach to systems development, feaslblllry analysis ls a cross life-cycle actMty. Different measures of feaslblllry are applicable In different phases of the methodology. These
meantres Include technlca~ operational, economic, sd1edt~e, and risk feasibility, as described when we Introduced the decision analysis phase. FeaslbUity analysis requires
good estimation techniques.
Recall that the C~lt\t considers ~·stems de,--elopment to be a process that must be managed on a project-by-project basis. For this
reason and others, proces., management and project management are ongoing, cross
Ufe-crde acti"itles. Both types of management were Introduced earller, but their deft.
n.itlons are repeated in the margin on page • • • for your convenJence. Process
ma.oagerueitt defines the methodology to be used on every project- think of It as
the tecipe for building a system. Project ma.oagemeitt is concerned wlth admlnlsterlng a single Instance of the process as applied to a single project.
Failures and limited successes of systems deveJopment projects often outnumber
successful projects. Why ls that.? One reason ls that many systems analysts are unfamiliar with, or undisciplined In how to properly apply, tools and techniques of systems deveJopment. But most failures are attributed to poor leadersh.ip and
management.Th.ls mismanagement results in w1fulfllled or unidentlfled requ.frements,
cost overrwu, and late delivery.
Chapter Tine
89
documeotatioo 1he ongoirg
activity of record ng facts and
specifications fo1a system for
current and future reference.
preseotation the ongoing
activity of comrrunicating findings, recommen:Sations, and
documentation br review
by interested users and
managers. Pres;ntations may
be either ¥Kitten or verbal.
repository a database
and/or file directory where S'iS·
tern developers stcre all dOCU·
mentation, knO'Medge, and
artifacts for one rx more infor.
mation svstems :,r oroiects. A
repository is USl.Blly autanated
for eBSf informalion storage,
retrieval. and sharing.
feasibility amlysis tile
activity by whic:t, feasibility is
measured and assessed.
Process and Proiect Management
>
Sequential versus Iterative Development
The above discussion of phases might lead you to assume that ~·stems development is a naturally sequential process, moving In a one-way direction from phase
to phase. Such sequential deveJopment ls, in fact, one alternative. This approach
ls depicted In part (a) of Figure 3-8. In the tlgttre we have used the four classic
ph.ases rather than the eiglll FAST phases h1 tl1e Interest of slmplidty. Th.ls strategy
requires that each phase be «completed" one after the other lllltil the information
systtm ls finished. In reality, the phases may somewhat overL1p one another in
ti me. For example, some system design can be started prior to the completion of
systtm analysJs. Given its waterfall-like '\oisual ap~arance, this approach ls often
called the waterfall development approacl1.
The waterfall approach l1as lost favor wJth most moden1 ~·stem deveJopers. A
more popular strategy, shown ln part (b) of Agure 3-8, is commonly referred to as
the iterath--e development approacl:a, or incremental development process. This
feasibility a measure of
how beneficial the development of an information system
would be to an organization.
estimatioo the calculated
predction of thecosts and effort required for system development. A some.what facetious
synonym is {IU9$S1mation,
usually meaning that the estimation is basedon experience
or empirical evic'ence bJt is
lacking in rigor-in other
words, a gusss.
process maoagemeot an
ongoing activity that docu.
ments, teaches, oversees the
use of, and implOV9s an orga.
nization's chosen methodol.
ow (the "process") for
systems development
Process man~ment is con.
cerned 'Mth phases, activities,
deliverables, and quality standards that shoukt be consistently applied to all projects.
BUSINESS COMMUNIT'(
8
START:
PIO ble ms. Op po rtu.n.ltlee,
Olrecuvea. core1n1nta,
FIN.ISH.:
Wo111:1ng
Yus1neee
ano v1eion
SVSTtM 0MIER8Al<I U&EFIS
System
1mprtwement
SolltlOn
oqecuve,
Pl'Oblem
Shtem«it
S181:emenl
otWo11C
Life Cycle Stage
SCq>e & Vision
SYSTEM
OPERATION
t
OOOJm&l'b.Oon
&
MAINTENANCE
~
+
,won
Statement
oowm_,.,
-----...,!
.....
Po81:-Audn
Opc,otlOnOI
....
Ooou mc>'*'1bn
system
•
I
Repository 1
~
00~ -...., . ,
-..L---.~. . .,
F1na1
Oocu.mentst1on
~
,I
Furcilon81
System
DocunenWIICl'I
CON STRUC TION
•
Reaee1gneo
TES TING
.........
Bu81neee
Oeelgn
i
Pl'Ol:ofVp•
Pnyaica1 oee1gn
Mu\11:111:1 6 $ l"l'(:lfUS Uunts
F IG U R E 3 • 7
BulllnM•
Requ.1rementll
System Development Documentation, Repository, and Presentation
...
I
LOGICAL
DES IGN
va11oa1:ea
EIIJlllOef:18
Ae(fllremente
LOgleal
Design
Models
ono
Sped11¢i!IIOM
System
Propoeal
AppHcaaon
A.rcn.ttectu.re
The entire
information
system
..
-.
"
(a) The Sequential or 'Watsrfall' Stratsgy
ITERATION
I
1
91
chaptorThree
Information Systoms Dovolopmont
. . . 00
'"
""'
""
•
ITERATION
I
2
•
ITERATION
t
3
AeslJts
In
•
Repeat until no 80Clltlonal
ltenrt1ons needed
(b) The Iterative or Incremental Strategy
F IG U RE 3 • 8
Sequential versus Iterative Systems Development Approach
92
Part ono
project maaagemeot the
process of seeping, planning,
staffing, orgarizjng, directing,
and controlling a project to
develop an information system
at minimum c«st, within a
specified time frame, and
wi1tl acceptab~ quality.
1ho Contoxt of Systoms l>ovolopmont ProjOffl
approach requires completing enough analysis, design, and Implementation to b< able
to fully develop a part of the new system and place It Into operation as qulddy as pos.
slble. Once t11..1r ,--erslon of the SJ'Stem ls lmplemet1ted, the strategy is to thet1 petfonn
some addJtlonal ai1..1lysis, de.slgu, and implementation to release the next version of
the ~·stem. These iterations continue tmtll all parts of the entire lnformatlon system
h»-. been lmplemetlted.11,e popularity of tills Iterative and incremetltal process can
be explained simply: System owners and users have long complained abo« tl,e
excessfve time required to de'.ielop and implement lnfonnatlon systems ushtg the
waterfall approad1. The Iterative approach allows ,-ersJons of useable infonnation to
be delivered in regttlar and shorter time frames. Th.ls results In improved ctlSt•) mer
(system owner and user) satisfaction.
~~~A_lt_e_r_n_a_ti_v_e~R_o_u_te_s~ a_n_d~ S-tr_a_t_e_g_ie
~s ~~~~~~~~~~~~~)
waterfall del,·etopmeot
Gfven any destination, there are many routes to that destination and many modes of
transport. You co,dd take tl,e superhighway, highways, or back roads, or you could fly.
Deciding which route ls best depends 011 your goals and priorities. Do you want 10 get
!ljl,(lf'n:lrh 81 8ppm8r:.h tn
there fast, Ot' do you want rose-• the sights? How much are you willing ro spend? Are
systems analysis and design
that completes each phase
one after another and onty
once.
iterative de,·elopmeot
approach ar, approach to
systems analysis and design
that completes that entire in.
formation syst~m in successive iterations. Each iteration
does some anilysis, some design, and some construction.
Synonyms incllde incremental
and spiral.
you comfortable wlth the mode of travel? Just as you would pJcl:: your route and
means to a tra,--el destination, you can and st1otLl.d pick a route and meaJ.15 for a systems
developmet1t destination.
So far, we've described a ba.slc set of phases tl1..1t comprise our PASTmetl1odology.
At one time, a «one size fits all" methodology was common for most projects~ however, today a >-arietj• of types of projects, tedmologles, and developmetlt strategies
exist- one size no longer fits all projects! Uke many contemporary methodologies,
PAST provides alternatfve routes and strategies to accommodate different types of
projects, tedmology goals, developer skills, and de>'elopment paradigms.
In this section, we will descrlbe several PAS'r routes and strategies. Before we do
so, examine FJgttre 3-9 on tl1e following page. TI1e figure illustrates a taxonomy or
cb.ss!llcatlon scheme for methodological strategies. Notice tl,e following:
Metl1odologies and rotttes can support the option of elther building software
solu.tlons in-house or buyfJ1g a co1n111erdal softtl)(lre solt,tto11 from a soft.
ware vendor. Generally, many of the same metl1ods and techniques are applicable to both options.
Metl1odologies may be either very prescriptive ("Touch all the bases; follow
all the rules") or reL,tl,-ely adaptive ("01aoae as needed within certain
guldeUnes").
Metl1odologies can also be characterized as model.tfrtven ("Draw pictures of
tl,e system") or product-driven ("13\dld the product and see how the users
react").
Modeklriven methodologies are rapidly moving to a focus on the objectorlented technologies being used to construct most of today's ~tems (more
about this later). Earller modeklth-.n approaches emphasized elther process
modellng or data modeling.
Finally, product.cJriven approaches tend to emphasize either rapid protot}pt11g
or wrltlng program code as soon as possible (perhaps you've hearo tl,e term
e.Ytrenie progran1.ntt11g).
So many strategies! Which !holdd you d1oose? A movement ls forming kt1own as
agile tnetbods. In a nutshell, advocates of agile metl1ods suggest tl1..1t system aiulysts
and programmers should l1ave a tool box of methods that include tools and techniques from all of the above methodologies. They should choose thelr tools and
technlques based on the problem and situation. FAST is an agile methodology. It
advocates the integrated use of tools and technlques from many methodologies,
applied In tl,e context of repeatable processes (as in CM.M Level 3). That said, let's
examine some of the route variations and strategies for the PAST process. As we
Information Systoms Dovolopmont
93
chaptor Three
TO lilt(
SO~TWAAE
SOLUTIONS
TOi.llJ.2
SOITWAAE
SOLUTION S
__
.......
.,.
Th;, 00:111011 IO 'bJ'(
~ln511>1dlll bJ~
........
...po,:.
_
U.(ffl)~IOuse
INIIIOdtWIOCMli:f.t•
1:11"
"""udlOn
eno mi,goton Intl) N
:::nJT::,a::.
w...,,
;1
~~
.......
.......
°""'"
continuum
--""""'
~
v1
94
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
na'\oigare through ead1 rottte, we wUJ use red typefaces and arrows to h.ighlighr those
aspects of the route that dlffer from the basic route you've already learned.
>
m odel-O.th•eo
developmeot a system
development rtrategy that
emphasizes ttie dra'Mng of
system models to help visual.
ize and analyze problems,
define busines.s requirements,
and design information
The Model-Driven Development Strategy
One of the oldest and most commonly used approad1es to analyzing and deslgolng Information systems is based on system modeling. As a reminder, a system m<><kl ls a
picture of a system that represents reality or a desired reality. System models facilitate
improved communication bet\\·eett system users, ~·stem analysts, system designers,
and system builders. 111 the FA.'lf methodology, system models are used to Ulustrate
and communicate the KNOWUDCE, PROCESS, or JNTER&CE building blocks of lnformatlon
systems. This approach Is called mod e l-driven develo pment.
The model-driven development route for FAST is illustrated h1 Figure 3-10.11,e
model-drl,-en approach does not: vary much from the basJc ph..,ses we de.scribed earlier. We call your attet1tlon to the following notes that correspond to the numbered
bullets:
1
O
0
O
0
0
l ogicaJ m O<let a p1ct0r1a1
representation that depicts
what a system is or does.
Synonyms indude essential
model, conceptual model,
and business model.
O
O
p h )'Sical m odel a technical
pictorial representation that
depicts what a system is or
does and OOwthe system is
implemented. 3ynonyms in.
elude implem,ntation model
and technical model.
System models may exist from the project that created the current system.
Be carefld! These m o dels
~yt.ltlfll:S.
O
:ire
1to to rlous fOt' being out of date . B-ut they can
stlU be useful as a pohll of departure.
Earlier you learned that lt Is important to define scope for a project. One of
the simplest ways to communicate scope is by drawb1g MODEJ.s THAT SHOW
SOOPE DEftNITION. Scope models show whlch aspects of a problem are wltbh1
scope and wltich aspects are otnsfde scope. 1b.Js ls sometimes called a
co11..text dtagra1n or conte:ct model.
Some system modeling tedlniques call for extet1SJve Mooas Of THE ma:STCNG
SYS"l'e< to identify problems and opportunities for system improvement. 11lls
Js sometimes called the as-ls systetn tnodel ,_lodellng of the current ~·stem
has waned In popularity today. Many project managers and analysts >iew It as
counterproductive or of Ihde '\o-:tlue added. 111e exception ls modeling of as-ls
business processes for the purpose of bush1ess proces., redesign .
111e requlremei1ts statement ls one of the most imponant deU,--erables of ~·stem developmet1t. It sometimes h1dudes MODELS THAT DEP1cr HIGH-LEVEL BUSINESS
REQUIJUMlNTS. One of the most popular modelh,g techniques today Is called
use case (introduced ln Chapter 7). Use cases identify requlreme11ts and track
their fulllllment through the life cyde.
Most model-driven tedmlques require that analysts docume11t business
reqUlrements wtth logical m od els (defined eartlel'J. Btistness requJ..remencs
are frequently expres.,ed ln LOGICAL MODELS THAT DEPlcr MO RE DE'l'AILfD USER
REQU1REMfN1'S. They show only what a system must be or must do. They are
lmplemetllatlon independent; that Is, they depict the system h1dependetll of
any possible tedmlcal implementation. Hence, they are useft~ for depleting
and valldath1g business requirements.
As a result of the decision analysls ph.ase, the analyst may produce system
MODfl.S THAT Of.PICT APPUCATlON ARCHJTOC'JtJR.E. Su ch models Illustrate the planned
technical lmplementatJon of a system.
Many modeklrlvet1 techniques require that analysts develop MODEJS THAT
DEPICT PHYSICAL DESIGN SPECD1CA'OONS (defin ed earlier In this chapter). RecaD
that physical m odels show not only what a system is or does but also
bow the system is implemented with technology. T hey are implementation
depe11dent because they reflect technology d1olces and d,e limltations of chose
technology choices. Examples h1dude database sd1emas, structure charts, and
flowcharts.111ey ser,--e as a blueprint for construction of the new ~em.
New information systems must be interwoven into the fabric of an organlz.atlon•s business processes. Accordingly, the analyst and users may develop
MODEJ.s Of R.EDESIGNID BUSINISS PROCESSES.
THE USER COMMJNTY
eTAnT:
l"'INlell:
W)rklng
C)
Problems,
MOGel8 or tr.
Opportll'.llUff,
Bu81re88
SdlJ:lon
ex~1ngs)'81:em
""
SV&lE• OWJEF&l.tO U&EFI&
•• prefleeto
DlrflCtlVM
syetem improvement
01:4ecuvee
P,olllem
staement
Llf• Cycl• Stag•
"Curr•nt•
0
SYSTEM
OPERATIO N
Model9tl'8t
,now scope
etstement
oe1111aon
(fW<)O(
e
&
MAINTENANCE
C)
REOJIREMENTS
ANALYSIS
Oocuncnldi)l"I
Requ.11'8ment,
s1,1eimrt
ma,1nr:1ue1e
Po81-.1Udll
/1
"
Revow
m0de1,1r1s1:
aeplct nign·
level OU91 nee•
Dxunom:Jlon
Dxunom:Jlon
requ1remenl!J
OptreUor111 3y.tem
~
rrey1nc:1ue1e models
'-<]
l'IISTA LLATION •
tl'e t aep let opera tlO na1
flow end procedure,
•
DELIV ERY
F"unctlo'18.I
syebm
bf
OoOJfflCll'tdion
l<J
OocUTIC!rtdion
t>
LOGICAL
DESIGN
na1n1ngMater1,1,
rrey 1nclu<1& rnoae•
IT'flf lndUJe
mode19Uat
aepicteorwn
a,conalnidMt
Ooeumcn1o1»n
Mocieu,or
0
Reoee1gned
t o~. . . 1
......
• ..
Specn'ICSUOM
tr,at aeoplet
0
MO<lel8 tr,at d@plet
Ap))llt8Uon
oe.1gn
e
MoGel9 that <lep let
P1Yf81C81 088 l{rl
spec:mceaoo,
:
~ GU RE
3 - 10
The Model-Driven System Development Strategy
1 System
Moaei, erti
Propo,e.l
eu,1ne••
Protitypee
f)
L,glcel
ArctllledU"e
dept ct
men
Ge1alleCI
reqiJremert,
""
96
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
0
Construction translates the physical system models lnto software. In some
Cl)
cases, automated tools ex.1st to automatically transL1re software lnto PHYSICAL
11lis is called reverse e1tgl11eertng.
Finally, the operational system may include Moons nv.T DEPICT fl.OW AND
MODfl.S THAT Of.PICT SOFTWARI! CONSTRUCTED.
PROCEDURE. For example, ~·stem models may document bad.-up and recovery
procedures.
In summary, system models can be produced as a portion of the deliverables for most
phases. Model-0riven approaches emphasize system modellng. Once implemented,
the system models sen·e as documentation for any changes that might be needed during the operation and support &age of the life cyde.
T he model-0rlven approach Is beUeved to offer several ad,-antages and dlsad"'10tages, as IJ&ed below:
Ad va11tages
Requirements specttlcatlon 1e nds to
be more thorough and better
documented.
Business reqttlrements and system
designs are easier to '\o-:tlidate with
pJcrures t11an words.
It ls easier to Identify, conceptualize,
and ai1..1lyze alternative technical
solutions.
Design specllkations tend to be
more sound, stable, adaptable, and
flexible because they are model
based and more thoroughly analyzed before they are bullt.
systems can be constructed more
correctly the first tlme when built
from thorough and clear model
based spedftcatlons. Some argue that
code-generating software can automatically generate skeleton or nearcomplete code from good sy,tem
models.
process modeling a
process-c:ente·ed technique
popularized U}I the sructur9d
analysis and ctssign me1hodolo:Jf that used models of b.Jsj.
ness process requirements to
derive effective softNare designs for a system. Structured
analysis introdJCEld a model.
ing tool called the dBi.a flcM
diagram to illustrate the flow of
data through a series of b.Jsj.
ness processes. Structured
design oonverr.ed data flow
diagrams into a process model
called !tructtKP d'larts to illus.
trate a top-dov.n software
structure that lllfills the busi·
ness requirem;nts.
Di.sa.dva.otage.s
It Is time-consuming. It takes tlme
to collect the facts, draw the models, and validate those models. Thls
is especially true if users are uncertain or lmpredse about t11elr system
requirements.
T he models can only be as good as
tl1e users• understanding of those
requirements.
Pictures are not software- some
argue that this redu ces the users'
role in a project to passive pattldpatlon. ,_lost users don't get
excited about pictures. Instead,
tl1ey want to see working software,
and they gauge project progress by
tl1e existence of software ( or Its
absence).
T he model-driven approach Is considered by some to be lnflexlbleusers must fully specify requirements before desJfl.O. desi.lln must
fttlly document technical specifications before construction, and !O
fortl1. Some ,iew sud, rlgldlty as
lmpractlcal.
,_lodeklrlven deveJopment ls most effective for systems for wll.ich requirements are
weU understood and wbid1 are so complex that they require large project teams to
complete. The approad1 also ,,,.orks well wl1en fulfillment of user expectations and
quality ls more important than cost ai1d schedule.
T here are several different model-0riven tedmlques. They differ prlmarily ln
terms of the types of models that they reqttlre the systems analyst to draw and valJ.
date . Let's briefly examine three of the most popufar model-driven de>-.lopment techniques that wlU be taught ln this book. Please note that we are introducing only the
techniques here, not the models. We'll teach the models themselves later, In the ..how
to• chap ters.
ProceH Modeling Process modeling was founded h1 the structured analysis and
design methodologies h1 1978. While structured analysis and design has lost frn,r as a
Information Systoms Oovolopmont
Chapter
Tine
97
methodology, process modeling remains a viable and Important technique. Recall that
your Information system bulldlng blocks Include se,-.ral possible focuses: KNOWLEDGE,
PROCESSES, and INTERFACES.
Process modeling focuses on the
PROCESS
column of building
blocts. Flowcharts are one type of proce55 model (used primarily by SYSrE." BUUDERS)
tl1..1t you may have encountered in a programmJng course. Process modeUng has etl·
joyed sometlllng of a retl..1lssance wlth the emergence of business process redesign
(Introduced !11 Chapter l).
Data flow dL1grams and structure charts have contributed slgnlllcantly to reducing the communkatlons gap thar often exists between nonrechnlcal ~tern owners
and users and technical system desJgners and buildets. Process modeling is taught lo
this book.
Data Modeling Recall that KNOWLEDGE improvement is a ftmdamental goal and set
of bulldlng blocks In yonr frunework. Knowledge Is the product of informat/011,
whlch In tnrn Is the product of data. Data m od elli)8 methods emphasize the know~
edge bulldlng blocks, especially data. In the data modeling approach, emphasis Is
placed on diagrams that capture busfr1ess data requirements and trai1SL1te them Into
database designs. Arguably, data modeling Is the most widely practiced system
modeling technique. Hence, It will be taught In this book.
Object Modeling Object modeling ls the rest~! of technical advancement.Today,
most programming languages and methods are based on the emergei1ce of object
t echnology. While the concepts of object technology are covered extensively
throughout this book, a brlefbut overslmpUJled Introduction Is appropriate here.
For the past 30 years, techniques like process and data modeling deliberately separated the concenu of PROCESSES from those of DATA. h1 other words, process and data
models were separate and distinct. Because virtually all systems lnduded processes
and data, the techniques were freque ntly used In parallel and the models had to be
carefully synchronized. Object techniques are an attempt to eliminate the separation
of concerns, and hence the need for syndvonizatlon of data and process concerns.
This has glvei1 rise to object m odelliig metl1ods.
Btislness objects correspond to real things of importance In the business sud1 as
custotners and the orders they place for products. Each object consists of both the
data that descrlbes the object and the processes th:lt can create. read, update, and
delete that object. With respect to your Information system building blocks, objectorlented analysis and design (OOAD) slgnlficantly changes tl1e paradigm. The DATA
and ?ROCESS columns (and, arguably, the INTERFACE coh1nu1 as well) are essentially
merged Into a single OBfECT column. The models then focus on Identifying objects,
bulldlng objects, and assembling appropriate objects, as with Legos, Into usef,d
infonnatlon systems.
11le cnrretll popularity of object technology Is driving tl1e Interest In object
models and OOAD. For example, most of t oday's popular operatlng systems like
Microsoft Wi11dows and Apple Mac/OS have object·>rletlled user Interfaces ("point
and click," using objects such as windows, frames, drop-down menus, radio buttons, check.boxes, scroll bars, and the Uke). Web user Interfaces Uke t.tJcrosoft
/11teniet E."<plorer and Netscape 1\ iavtgator are also based on object technology.
Object programming languages sucl1 as Java, C+ +, C#, Smalltalk, and Vtsr,a/
Basic .NEr are used to co11struct and assembJe such object-oriented operating systems and applications. And those same languages luve become the tools of choJce
for bulldlng next-generation Information system appUcations. Not surprisingly,
object modeling techniques have been created to express business and software
requlremet1ts and desJgns In terms of objects. This edJtJon of tllls book extensively
integrates tl1e most popular object modeling techniques to prepare you for systems
analysis and design that ultimate ly produces today's object-based Information
systems and applications.
data model.it1g a data.
centered technique used to
model businessdata requirements and design database
·~"ms:: thAt futill thMA
requirements. The most frequently encountered data
models are sn11Y f918Jonship
dag:arns.
object m odefulg a technique that atterrpts to merge
the data and process concerns into singular constructs
called objects. Object models
are diagrams that document a
system in terms of its objec.ts
and their internctiofl3. Objec.t
modeling is the oasis for
oojoct-orionted analysis and
dssign methoddogies.
98
Part ono
1ho Contoxt of Systoms l>ovolopmont ProjOffl
>
rapid apJ>li<atioo
development (RAD) a
system develooment strategy
that emphasizes speed of de.
velopment through extensive
user involvement in the rapid,
iterative, and incremental
construction of a series of
functioning pn,totypes of a
system that ewntualty evolves
into the final system (or a
version).
prototype a small-scale,
representative. or working
model of the users' require.
mi::1onh:: or A prr.fY'~Art dA.(;ion
for an informa1ion system. Arrf
given prototyp; may om it cer.
tain functions or features until
such time as the prototype
has sufficientlv 9/0lved into an
acceptable imi,lementation of
requirements.
The Rapid Application Development Strategy
In response to the faster pace of the economy h1 general, rapid application devel-
opment (RAD) has become a popular route for acceJeratlng systems de,-elopmet1t..
11,e basic Ideas of RAD are:
To more acth,--ely ln\--olve system users In the analysis, desJgn, and construction acthitles.
To organize ~tem.s development Into a series of focttsed, intense workshops
jointly involving ~ ~ s , usms, ANALYSTS, DESIGNERS, and BUW>ERS.
To accelerate the requirements analysis and design phases through an lterati,-e construction approach.
To reduce the amount of d.me that passes before the users begin to see a
working system.
11,e basic principle belllnd promtyplng Is that users know wbat tl1ey want when they
see it working. ht RAD, a prototype e,--entually evolves lnto the final infonnation system. The RAD route for FASTls illustrated In Figure HI. Again, the red text and flows
indicate the de"iatlons from the basic FAST process. We call your attention to the
followtng notes that correspond to the num.bered bullets:
0
11,e emphasis Is on redudog time h1 developh1g applications and systems;
therefore, tl1e hlltlal problem analysis, requirements analysis, and decision
analysis pbases are consolirlated and accelerated. The deliverables are tyi>
lcally abbreviated, again In the Interest of tlme.11,e deli,.. rab!es are said to
be tNrn.u, meaning •expected to change" as the project progresses.
After the above itlitlaJ analysis, the RAD uses an iterative approach, as dlscussed earller in the dtapter. Each Iteration emphasizes only enough ne"'
functionality to be accomplished wlthh1 a few weeks.
t) LOGICAL AND PHYSICAL DESIGN SPECIFlCATIONS are usually sJgnlficantly abbre\oiated
and accelerated. In each iteration of the cycle, only some design spedJlcations
will be considered. Whlle some system models lllllY be drawn, they are select1:,--ely chosen and the emphasis continues to be on rapid development 1be
assumption is that errors can be caught and fixed lo the next iteratlo11.
O In some, but rarely aU, iterations, some business proces.,es may need to be
redesigned to reflect the lll:e!)• Integration of the evol,ing software appllatlon.
O 1n each fteratlon of the cycle, SOME DESIGN PROTOTYPES or SOME PARnAL
FUNCOONAL SYST6\I element! are constructed and tested. Eventually, the
completed application wUI result from the final tteratlon througb the cyde.
9 After each prototype or putlal functional subsystem Is constructed and
tested, system users are gi,;en the opportwlity to experience working whh
that prototype. The expectation Is that users will clarify requlremetlls,
Identify new requirements, and provide BUSINESS FEEDBACK on design (e.g., ease
of learning, ease of use) for the next Iteration d,rough ti1e RAD cycle.
O After each prototype or functionlng subsystem Is constructed and tested,
system analysts and deslgiters wUI re\oiew the applicatio11 archltectu.re and
design to pro"ide TECHNICAL FEEDBACK and direction for the next lteratlon
through the RAD cycle.
O Based on tl1e feedback, sy,terns analysts will Identify REf1NED SVSTE2\I
LW'ROVEMENT OBJ-f.CTIVES and/or BUSCNESS llEQUlR.fl\lENTS. This analysis tends to
focus on re,ising or expanding objectives and requirements and Identifying
user concerns with the desJgn,
O Based on tl1e feedback, sy,terns analysts and system designers will Identify• a
R.EflNED APPLICATION ARCHJTf.Cl1JllE an<Vor DESIGN CHANGES,
(:) Eventually, the system (or a , .. rsion of the system) wUJ be deemed wortl1y of
Implementation. This CANDIDATE Rfl.f.ASE VERSION Ofl 'l'HE FUNCTIONAL ~ is system tested and placed lnto operatio11. The next ,-ersio11 of the ~tern may
continue iterating through the RAD cycle.
STA.RT:
Pl'Oan•.
~·
OA)Ortunltl88,
lHE USER COMMUMTY
ProDlem
,no
Slllement
1
Ol,ootpyc,o
(1ttm
~1011r"' ~-Fi)
2 1-3 -t-0
(l1u111Fl\f'I" 3·~
SC(fle &
V181on
Statement
S'1'81'EM0WMEl'l8NO U3Efl8
"'
W01<
Initial S)'Stem hlprovement Obiectivea
Initial SuainNS Requirements Statement
0
0
Initial System Propoea1
Initial Application Architecture
Refined Syatem Improvement
O bJ ectrv ee enGfor
4 + 6 (tom Rgure 3·51
Buelneee Requ1remente
some Aeo•1gneo
some
DESIGN
FINISH.:
eu,1ne,e
Al!flne<I
ApplcaUcn
&ulul1Qr1
Archttocb.i••
WOr11lng
eu, 1ne, e Proc e,e ee
0
(10,;jlCSI e.n<llor pfr/&ICel)
e
some
Logical al'dfor
8
ana.or
Pr,ye1ce1 O.lgn
D:I011n1nllll!cn
SpfClflC*:lon•
0•1gncnang•
3 + 4 + 5 (lrom ~19-ne 3-5)
...........
...........
~
•1-t"""';
:-~·;
7 (Iran Figure 9-5)
~
:·~
0
Life.Cycle Stage
l))Qlm>nllll!m
Bue1neee n
·current"
SYSTEM
FeedlllCk V
OPERATION
ttcrin1ea1reealllck
Po811'.uan Rev11w
FIGURE3 - 11
Oeelgn Protmvpee
0
, na.o,
Partl81
AJncuona1 system
&
MAINTENANCE
i
some
O
Operetlona.l Sy81:em Vere1on tA
The Rapid Application Development (RAD) Strategy
na1n1rg Mater1a1a
Cl!ln<Hdale
Releue
Ver81on
or the
Funr.t1ore1
syatern
100
Part One
tialeboxi.og the imposition
of a none)(!endable period of
time, usually ro to 90 days, by
'M'lich the first (or next) ver.
sion of a system must be de.
livered into operation.
1ho Context of Systems Dowlopmont Projom
Although not a rigid requirement for RAD, the duration of ti1e prototyping loop can
be limited using a technique caUed tlmeboxlug. Timeboxlng seeks to deUver an operational system to users and m.1nagemenr on a regular, recurring basis. Advocates of
tlmeboxlng argue tl1at management and user enthusiasm for a project can be enhanced and sustained because a working version of the system ls Implemented on a
regular basis.
The RAD approach offers several advantages and disad"-antages:
Ad va11tages
It is useful for projects h1 which
the user requirements are uncertain
or Imprecise.
Ir e ncourages active user aOO management participation (as opposed
to a passfve reaction to nonwoddng
system models). 11lls h1creases enduser enthusiasm for the project.
Projects have higl1er >islblllty and
support because of the extensive
user ln,"'Olvement throughout the
proces.,.
Users and management see working, software-based solutions more
rapidly than they do In mo<feJ.
driven development
Errors an d omissions tend to be
detected earlier ln prototypes than
In system models.
Testing and trahllng are natural
by-products of ti1e underlying prot<>typh1g approach.
TI1e lterarJve approach ls a more
natural process because change ls
an expected factor during
development.
Di.sa.dva.otage.s
Some argue that RAD encourages a
.. code, implement, and repair• met1tallty that h1creases lifetime co.is
required to operate, support, and
maintain the system.
RAD prototypes can easily solve the
wrong problems since problem
analysis ls abbreviated or Ignored.
A RADbased prototype may di~
courage ai1.alysts from conslderilg
other, more worthy rechnicaJ
alternatives.
Sometimes it ls best: to tlvow a
prototype away, but stakeholders
are often reluctant ro do so because
tl1ey see this as a loss of time and
effort in the current product.
The emphasis on speed can
adversely Impact quality because
of ill.advised shortcuts through the
methodology.
RAD is most popular for smaU- to medium-size projects. \X'e wlUdemonstrate prototyping and RAD tedmlques In appropriate dtapters of this book.
>
co-mmetci.al applicatioo
package a software apptica.
tion that can ba purchased
and customized (within limits)
to meet the business requirements of a large number of
organizations ,r a specific
industl')( A synonym is canmorcial o/1./h&-Sholl (COTS)
system.
The Commercial Application Package
Implementation Strategy
Sometimes ft makes more sense to buy an informatio11 system solution than to build
one lo-house. In fact, many organizations increasingly expect to build software lnhottse only when tl1ere is a competitive advantage to be gained. And for many core
applications sud1 as human re!ources, financials, procttremenr, manufacturing, and
distribution, there is little competitive value In building your own system-hence a
commercial appllcatlo n package is purchased. Accordlngly, our FAS1'med1odology
includes a commercL1l sofrware package route .
T he ultimate commercial solution Is enterprise resource planning, or ERP (defined
in Chapter l ). ERP solutions provide all of the core h1formatlon system applications for
an entire bush1ess. For most orginizatlons, an ERP iruplemet1tatlon represents the single largest h1fonnatlon system project ever undertaken b)• the organlzation. It can cost
tens or htmdreds of millions of dollars ai1d require a smaUarmy of managers, users,
analysts, rechnicaJ spedallsts, programmers, consultants, and contractors.
101
Information Systoms Oovolopmont
Toe FAST methodology's route for commercL1l application package Integration Is
not really Intended for ERP projects. Indeed, most ERP vendors provide their own
Implementation methodology (and consulting partners) to help their customers
implement such a massive software solutio11. lnstead,our PASTmetl1odology provides
a route for Implementing all other types of Information system solutions that may be
purchased by a business. For ex.ample, an organization mlght purchase a commercial
appUcarion package for a single business function sud1 as accow1ting, human
re.sources, or procurement TI1e package must be seJected, lnstaUed, customized, and
inregrared Into the business and lts other existing lnformatlon $)'stems.
Toe basic ideas behlnd our commercial application package Implementation
route are:
Packaged software solutions must be carefully selected ro fulflU business
needs-"You get what you ask and pay for.•
Packaged software solutions not only are costly ro purchase but can be costly
to implemet1t.. ln fact, the package roure can actually be more expenst,--e ro
bnplement than an lo-house development route.
Software packages must usually be customJzed for and integrated Into the
busines.,. Additionally, software packages usuallr require the redesJgn of ex.lstlng business processes to adapt to the software.
Software packages rareJy fulfill all bush1ess requirements to the users• complete satisfaction. Thus, some level of In-house systems development is necessary ln order to meet the unfulfilled requirements.
Toe commercial application package Implementation route ls Ulustrated h1 Figure 3-12. Once agait1, the red typeface and arrows Indicate differences from the basic
PAST process. We call your attention to the following notes that correspond to the
numbered bullets:
O
It should be noted that the decision to purchase a package ls determined In
the problem analysis ph..,se, TI1e red diamond represents the ..make versus
buy.. dedslon. The remainder of tllis discussion assumes that a dedslon to
buy has been approved.
0 Problem analysis usually Includes some Initial TECHNOLOGY MARKET RESEARCH ro
identify what package solutions exist, wl1at features are in the software, and
what criteria should be used to evaluate sud, application packages. This
research may in\--oJ,. e. software vendors, IT rese.uch services (sud1 as the
Gartner Group), or consultants.
O After defit1.1ng business requirements, the reqUlrements muse be commwllcated
10 the software vet1dors who offer vL1ble application solutions. TI1e business
(and technlcal) requirements are formatted and commwlicated ro candJdate
software vet1dors as either a REQUF.ST FOR PROPOSAL (RFP) or a REQtlf.ST FOR
QUOTATION (RFQ). 11,e double-ended arrow Implies that tl1ere may need to be
some clarification of requirements and criterla.
O Vet1dors submit PROPos..us or Q UOTATIONS for their application solutions. These
proposals are e"-aluated against t11e business and technical requirements specified h1 the RFP. The douhl"""11ded arrow lndlc,tes that claimed features and
capabUJties must be validated and In some Instances clarified. Thls occurs
during the decision analysis phase.
0 ..\ CON'J'RACT AND ORDER Is negotiated wfth tl1e wltuling vet1dor for tl1e software
and possibly for senices necessary to Install and maintain the software.
0 111e vendor pro"ides the BASWNE COMMERCIAL APPUCA'J'lON software and documeo1atlon. Services for installation and lmplemenmtlo11 of the software are fre.
quently provided by the vendor or its service pro,iders (certified co1mdtants) .
O Whe11 an application package ls purchased, the organization must nearly always
change Its business processes and practices to work efficient~· wld1 the package.
111e need for REDESIGNED Bl6INESS PROCESSES is rarely greeted with enthlL'Siasm,
request for proposal
( RFP) a formaldocument
that communicates business,
technical, and sipport re.
quirements for 611 application
software package to vendors
that may 'Msh tc compete for
the sale of that application
package and services.
request for qu0tatioo
( RFQ) a formal document
that communicates business,
technical, and sipport re.
quirements for 611 application
software package to a single
vendor that has been determined as being able to suppty
that application oackage and
services.
-s
TEClfiOLOGYINOUSTRY
THE USER COMMUNITY
Tee mo10gy Mar1(et lie ,,arch
FIN SM:
Working
~
START:
eu, 1neea
ProDiems,
Oppt>rtunffl Jlfl.
SOIUUon
e
r
S•LE& REPFE&ENl'.IJl'IE&ANO
ana
Olredlwe
TECtfrfOLOGY kTEGRATOAS
Syeten
2 (flom F,91110 3·5)
lrrpn:rtemert
...••
OOJeCl:t•
f)
lif•·Cyc l• Stag•
Q
"Curr•nt"
RFQ
SYSTEM
Statement
OPER ATION
&
MAINTENANCE
«WOl1(
Sc ope , Vie Ion
1
r
3 (Item Figuro 3-5)
op,.,110:• sy,tem
l_
Oocumcn1o!ion
Posi.Auc11tRevleW
0
REOUREMENTS
ANALYSIS
Ooc1,1mon1,1ion
Proposal
o,
Cllotatlon
/1
Dxumonlolion
t)
contract
8 (from FigU'o 3·5)
5 (hom F,9uro 3-6)
l<)- - - - - - - - -[))1Hl''IOl'tdion
11.e•ne•
Requreimrt,
DELIVERY
3:d:ement
.,.........
Ox1,1mon1,1ion
Oocunortdion
Oxunom:Jli:in
C8p8Dlllt188
6 (from F19U'o 3·5)
BUSINESS
PFDCESS
OESGN
{)
C)i stomll'ed
t.E W to lh II Routo
commercl81.\ pp11c 811 on
OJata:ilntl<n
Aequ1,a,mena
INSTAl.U.TION
•
CUST0.11ZATON
F I G UR E 3 • 1 2
The CommeJcial Application Package Implementation Strategy
Q
0
e.e11ne ccrnmet'd81 ApplettlCl'l
"''
o..,
Information Systoms Oovolopmont
103
bur they are usually necessary. In many cases, the necessary changes are not
O
wrong-they are Just dUierent and unfamillar. ~tern users tend to be uncomfortable with chaoglng the way ther ha.-e alway, don e somethlng.
An appUcatlon package rarely meets all buslne!s reqttlrements upon inslallaUon. Typically, a gap analysis must be performed to determine which business requirements are not ftt!Jllled by the package's capabilities and fearures.
For requlrements that will not be fulfi lled, the following options exist:
Request customlzatlons of the package wlthln allowahle limits as specified
by the software .-endor. Most commercial application packages allow the
purchaser to set spedflc options, preferences, and defined '\o-alues and
ranges for certain parameters. Within Um.its, these alStomfzatlons allow you
to «personalize" the package to the business accounting and business practices. Such necessary CUSTONJZATION R.EQUUllNlNTS need to be specified.
Define ADO-ON SOl'I"WARJ! Rf.QUIR6\IIM'S. Adel-On software requirements specify
programs that must be desfgned and constructed to augment the commercial
application package and deU.-er additional functionality. It should be noted
that add-On programs carry some risk that d1e;- may ha.-e to be modified In
the future when a new version of the software becomes a'\o-allable. But this
risk Is nomlna~ and most org.1nlzations take the risk In order to pro.-lde additional functionality.
Oetlne ADD-IN SOf'rWARE R.8;2tllE.\IIEN'J'S. Add-in software requlremet1ts are very
dangerous111,ey specify changes to the actual commercial application package to meet bltSlness requirements. In other '\\'otds, users are reque.sth1g tlut
dwiges be made to the p urchased software, Its database, or !ts user Interfaces. At best, such changes can make .-erslon upgrades extremely dlftlcttlt
and prohlhlti>"elj• expensi>"e. At worst, sud1 dunges can In-validate tedlnlcal
support from the .-endor. (And most ,-et1dors encourage keeping .-erslons
relat!.-el)• current b)• canceling technlcal support on older .-erslons.) Changing
program code and database structures should be discouraged. lnslstet1ce by
users ls often a symptom of unwllllngness to adapt business processes to
work with the application. Many organlzatlons prohibit changes to application
packages and force users to adapt In order to presen-e thelr upgrade patl1.
O
The BASEUNE COM.\IIEtctAL APPLICATION is Installed and tested. Allowable changes
based on options, preferences, and parameters are completed and tested.
Note: These customizations within the limits specified by the software
,·e11dor will typically carry forward to versJon upgrades. In most Instances the
,·e11dor has provided for c1Us level of CUSTOMIZE> COM.\IIEllctAL APPLICATION.
<!:) Any add-On (or adcl-ln) software changes are desgned and constructed to meet
additional business requlrements.11,e system is subsequently tested and placed
jnto operation using the same acthitles describEd in the basic PAST process.
The commerclal application package strategy offers Its own ach:antages and
dlsad.-antages:
Adv.lotages
New systems can usually be Implemented more qu.lckJy because extensJ,·e programming is not required.
Many businesses cannot afford the
sttfllng and expertise required to
develop lo-house solutions.
Application .-endors spread thelr
development costs across all customers that purchase thelr software.
T hus, they can invest In continuous
Dlsadvant.1 ges
A successful COTS Implementation Is
depet1dent on the lo11g-term success
and >"hbllity of the application
vendor- lf the , axlor goes out of
busloess, you can lose your technical
support and furure impro,--ements.
A purchased system rarely reflects
the ideal solution that the business
might adlieve wlth an in-housede.-elcped system that could be
1
gap analysis a oomparison
of business and technical re.
quirements for a commercial
application pac~age against
the capabilities and features
of a specific commercial
application pac~age for the
purpose of defiring the
requirements that cannot
be met
104
Part One
1ho Context of Systems Dowlopmont Projom
Improvements lo features, ctpabllltles, and usability tl1at lndl>idual
businesses cannot always afford.
The application vendor asslmes
responsil>lllty for slgnlficant system
lmprovements and error corrections.
~tany buslness fw1ctlo11s are more
slmllar than dlsslmlbr for all businesses In a given Industry. For exam-
ple, business functions across organizations In the health care Industry are
customized ro the precise expectations of m:uu.gemenr and the users.
There is almost always ar least
some resiSlance to changing busJness processes ro adapr ro the software. Some users will l1ave ro give
up or assume new responsibllltJes.
And some people may reset1r
changes they perceive to be t echnology-drtvet1 instead of busfnessdrtvet1.
more alike than dtfferent. Ir does not
make good business sense fer each
organiz.ation to ..reh1,--ent d1e wheel"
Regardless, the trend roward purchased commerdaJ appUcatlon packages cannot
be Ignored. Today, many businesses require that a package alternative be considered
prior to engaging In any type of In-house developmetll project. Some experts estimate
that by d,e year 2005 businesses will purd1ase 75 percent of thelr new Information system applications. For this reasoo, we wlll reach ~terns analysis roots and techniques
needed by system analysts ro function ln this e nvlronment.
>
Hybrid Strategies
111e PAST routes are not m utually exdusJve. Any gtven project may elect to or be required ro use a combination of, or "-arlatlon of, more than one route. The route to be
used Is always selected during the scope deft111tto11 phase and Is negotiated as p1rt of
the stateme11t of work. One strJtegy that Is commonly applied to both modeklriven
and rnpld application development routes Is an Incremental strategy. Figure 3-13
illustrates one possible implementation of an Incremental strategy in combim.tlon
with rapid application development.T he project delivers the Information system Into
operation In four stages. Each stage lmplements a version of the final system using a
RAD route . Other varlations on routes are possible.
>
System Maintenance
All rotttes ultimately result in placing a new system into operatlo11. System m t intenance is lntended ro aulde projects throuah the operation and support staae ofthefr
life cyde- whlch could last decades! Figure 3-14 places system maintenance Into
perspective. System maintenance In PAST is 11ot really a unique route. As illttstrated in
the figure, Jt is merely a smaller-scale version of the same PAST process ( or route) that
was used to originally develop the system. T he figure demonstrates that the starting
point for system maint enance depends on the problem to be solved. We call your
attention to the following numbered bullets In the figure:
O
Maintenance and reenglneerlng projects are triggered by some comblnatlon
of user and teclmlcal feedback. Sud , feedback may Identify new problems,
opportwlitles, or direcdve.s.
€J TI1e maintenance project Is inltlated by a SYS'J'E."1 CHANGE REQlfEST that in dicates
the problems, oppor tunltits, or directives.
O Tbe slmplest fixes are sorrwARE BUGS ( errors). Such a project typically Jumps
right Into a rec0!'811lucnoN AND rensTING phase and Is solved relatively quickly.
O Sometimes a DESIGN FLAW In the system becomes apparent after
lmplemet1tatlon. For example, users may frequently make the same mistake
due to a confusing screen deslgi1. For tills type of maintenance project, the
PHYSICAL DESIGN AND tNTF.GRATION ph ..,se would need ro be revisited, followed of
course by the construction and delivery phases.
-
ITERATION #1
-E
ITERATION #2
•I
VERSk>N 1
OF SYSTEM
VERSllN 2
orGYGTCM
ITERATION #4
--
ITERATION #3
YEASKlN 4
OF SYSTEM
·VEA3'0N3
OFSYSTE.M
-
0
'"
1
FIGURE 3 • 1 3
An Incremental Implementation Strategy
,--..
-8
0
START:
Feedback
I
I
I
I
I
I
\.,_
BUSINESS COMMUNrTY
I .---J I
ft ~
::.tyetem
Staterrent
0
1mpiovement
o q ec1:1ve,
OfWOt k
FINISH:
Updateo or
1mproW<1
Operational
syetem
f)
New
eua1ne•
Prolllem,
-·
Openiba1111
System
I
...
Lif•·Cycl• S1*g•
SYSTEM
OPERATION
&
MAINTENA NC E
0
Busin•s
Post·Al.ldlt
NewTecnn1ca1 Requ1remerta
0
oee19n
Fl8W
~ug"
C)
••Bushee•
E)
Prooe••
n a1n.1ng
..._
Statement
NewE1ue1nee,Aequ1rernerts
........
......
Aequ1rernerts
0
System
cnange
Requeat
Metet1a1s
198U8
Logical
oee1gn
Reoes1gnea
Bu81neaa
P IOC88888
oeergn
Pn:itotypea
Ph)'61C81
Oe811J1 SpeCll'IC8bona
E RE
3 - 14
ASystemMaimenancePerspective
A.p pl lea 110 n
Arcnltecture
Information Systoms Oovolopmont
In some cases a BUSCNESS PROCESS ISStrE m.1)' become apparent In this case,
only the business process needs ro be redesigned.
0
O
On occasJon,
NEW TECHNICAL REQUUlE.-..m'ltrS might dlccate a change. For example,
an organization may standatdJze on the newest ,--erslon of a particuL1r
database management system such as SQJ. Serwr or Orade. For this type of
project, the Df.CJSION AN.UYSJS phase may need to be revisited to first determine
tl,e risk and feasibility of converting the existing, operational database to the
new ,-erslon. As appropriate, sud1 a project would subsequently proceed to
tl,e physical deslgn, construction, and deU,.. ri· phases as nece55'f)'.
Busfr1es.,es constantly d1ange; therefore, bush1ess requirements for a system
also d1ange. One of the most common triggers for a reenglneerlng project is
a NEW (or revised) BUSCNESS 11.EQutR.EMENT. Gtven lhe requlremet1t, the
lEQUlRfl\lENTS ANALYSIS phase must be revisited wlth a focus on the lmpact of
the new reqttlremenr on the ex.lstfng system. 13.lsed on requirements analysis,
tl,e project wottld then proceed to the logical design, dedslon analysis, phys!·
cal design, construction, and deUveri· phases.
Time out! By now, you've noticed that maintet1..1nce and reengineerlng
projects lnltlate In dlffere11t phases of the baslc methodology. You might be
concerne-d that repeating these phases w o tdd req u ire excessive time :md
effort. Keep in mind, however, that the scope of maintenance and
reenglneerlng projects ls much, mud, smaller than the orlglnal project that
created the oper.ttlonal system. Thus, the work requlred In ead1 phase Is
mud1 Jess than you might ha,--e guessed.
f) ..\gain, as businesses d1ange, significant NEW BUSINESS PROBLENS, opporrunltles, and
constraints can be encountered. In this type of project, wod< begins with the
PR.OBl.l:M ANALYSIS phase and proceeds as necessary to the subsequent phases.
O h1 all cases, the final result of any type of maintenance or reenglneerh1g pro~
ect is ai1 updated operational business system that deJivers lmproved value to
the system users and owners. Updates may lnclude re"ised programs,
databases, lntetfaces, or business proce~es.
As described earlier In the chapter, we expect all systems to eventually reach
e ntropy.The bush1e~ and/or technical problems ai1d requiremet1ts have become so
trouble.some as to warrant ..starting over."
That comp letes our lntroductlon to the systems development methodology and
routes. Before we end tills chapter, we should introduce tl1e role of automated tools
t11..1t support systems deveJopment
( Automated Tools and Technology
You may be famillar with the old fable of the cobbler (shoemaker) whose own children
l1..1d no shoes. That situation Is not unlike the one faced by some systems developers.
For years we've been applying informatio11 technology to solve our users' business
problems~however, we·,--e sometimes been slow to apply tl1..1t same tedu1ology to our
own problem- developh1g lnfonnatlon systems. In d,e not·tOO-Oistant past, the prlncl·
pal tools of the systems analyst were paper, pencil, and flowchart tempL11e.
Today, e ntire sultes of automated t ools 11..1,--e bee11 deveJoped, marketed, and lostallt'd to assist systems deveJopers. Wh.lle system de,~Iopment methodologies do 11ot
a lwa'J'S require automated tools, most methodologies do bet1efit from such technology. Some of the most commonly dted benefits lndude:
Improved productfvJty- through automation of tasks.
Improved quality- because automated tools check for completet1ess, consistency, and contradictions.
Better and more consistent documet1tatlon - bocause the tools make it easier
to create and assemble consistent, high-quality documentation.
107
108
Part One
1ho Context of Systems Dow lopmont Projom
Redu ced lifetime maintei.1.ance- because of the aforementioned system quality
improvements combined with better documentation.
Methodologies tlu t really work- throug)l n~e enforcement and bullt<n exp<rtlse.
a1ances are that your future employer is using or wUJbe using this technology ro
develop systems. We will demoo.strate the use of '\o-:trlous automated roots throughout
this textbook. There are tlvee d asses of automated tools for developers:
REPRESENlATIVI:
CASETOOlS
ComputEI' Associales' &win
Oracle's f»sig;,er 20W
Popkin's SystimArchiect
Ratiooal ROSE
VisibleSysterrs' Visible
Anarst
computer-a!Sisted
software eogloe<'riftg
(CASE) the use of auto.-d
software tools hat support the
drawing and analysis of system
models a.rd associated specifi.
cations. Some CASE tools also
provide protot)Ping and oode
generation ca:J:,B.bilities.
CASE
repository a sys.
tern developers' database
where developers can store
system models, detailed de·
scriptions and specifications,
and other products of SfS ·
terns development. Syn.
onyms data irelude data
dictionary and encyclop9dia.
Computer-aided systems modeling.
• Application developmet1t en'\oironments.
• Project and process managers.
Let's briefly examine ead1 of these classes of automated roots.
>
Computer-Assisted Systems Engineering
Systems developers have long asplred to trai1Sform lnformation systems an d software
development into engineering-like disciplines. The terms syste,ns engi11eertng and
softtl)(lre e11gineerl11g are based on a vision that ~·stems and software developme nt
can and should be perfonned with engloeerlng.Jlke precision and rigor. Sud 1 precision
and rigor are consistent wtth tl1e modekirh,--en approach to systems development To
help systems analysts better perform system modeling, the Industry developed automated tools called computer-assisted software e nglneerlog (CASE) tools. Think
of CASE technology as software that Is used to design and lmplemet1t other software.
11lls Is very slmllar to the computer.aided design (CAD) technology used by most coo.
temporary engineers ro design products such as vehlcles, structures, machines, and so
forth. Representative modeling products are listed In the margin. Most modeling products rw1 on personal computers, as depleted in Figure 3-15.
At the ctnt er of any true CASE tool's architecture ls a developer's database called a CASE repository. The repository concept was Introduced
earlier (see Figure 3-7).
Around th e CASE reposJtorr ls a collection of tools, or fadlltles, for creating system models and documentation.
CASE Repositories
CASE Facilities To use the repository, the CASE tools provide some combltutlon of
the following fad Utles, illustrated lt1 Figure 3-16:
Diagra1n1nl11g tools are used to draw the system models required or recommended lo most system dtvelopment methodologies. Usually, tl1e shapes on
one system model can be llt>ked to otl1er system models and to detailed
desalptloiu (see next i tem belo w).
Dlctf-011.a ry tools are used ro record, delete, edit, and output ddalled documen-
for ward eogiileeriog a
CASE tool capability that can
generate initial software or
database oode directly from
system models.
r everse eogitleerlog a
CASE tool capability that can
automatically generate initial
system models from software
or database code.
tation and specifications. The descriptions can be associated wltl1 shapes
appearing on system models that were drawn with the diagramming tools.
Design tools can be used 10 develop mock-ups of system components str:.h
as inputs and outputs. These inputs and outputs can be assoc.L1ted with both
tl,e aforementioned system models and the descriptions.
Quaflty nm11agement tools analyze system models, descriptions and spec1Jkatio11S, and desJgi15 for completeness, consist:enC)', and conformance ro
accepted rules of tl,e methodologies.
Doc1,1ne11tatton tools are used to assemble, orgartize, and report on system
models, descriptions and speclflcatlons, and prototypes that can be reviewed
by system owners, users, desJgners, and builders.
Design and code generator tools automatically generate database desJgill and
application programs or significant portions of t11ose programs.
'Jesting tools sfmuL1te traiuactlons and data traffic, measure perfonnance, and
pro"ide configuration m.1rugemenr of test plans a nd test scripts.
As previous st:ated, CASE tedu1ology automates system modeling.Today's CASE tools provide two distinct ways to develop system models-forward engineering and reverse engineering. Thlt>k of re,-.rse
forward ancl Reverse Engineering
Information Systoms Dovolopmont
() 6t Edt
r...
t11"'1'
109
o,.., !«* Oi:t~ ~ s ~... tt!b
~"'ll;f [ij ll) fl ~.. ffi· l,ii:.l
~
Chaptorlh,...
!;i l!I M .l;l;II ~ €1€1
.,.. ....., :.., ! O A ooliJ
!I
·-
0-···l!·····-t
.
,,,
.
'
r
"n
....,.,.,.,...
c
Om'II\O'l'tet
om-n D<M
~
n.
"[l
nn
SlcoretM:I• ll Ci
'I
.:.J =1 ~
r,
,..f7
....
-·
..
"
n
a
n
IJ
p-
··········-t
~
.....!ft·
dl...icttt 110)
."'"'.. .." .." .,.~
.l'I
···-- .•.,fl
Slqf'G-SI•.. Cl Q
$1, U ~
$ tc,)'9"'$·~
~
" ' - 140.\
d!..,.;t:, t1J)
rn
~
n
,.. , ,- 1--1
J;IJ
---+----,
i
I
i
I
i
I
'
I
I
I
I
I
Ho«:11 (ll'(Vt
F I GU R E 3 • 1 S
Screen Capture o f Sy.stem An:hite<t CASE Tool
engineering as allowing you to generate a flowchart irom an ex.Isling progran1 and of
forwlt'd engineering as allowing you to get1erate a program directly from a flowchart.
CASE tools that allow for bldlrectlooal, forward, and reverse engineerlng are said to
J'lmvic1P (or .. m11nd.t1'i(l PnglnPP-f'ing." For PX!l m (llf', you rt>VPr'!l.P Png:inP.Pr a fM'\01'1y
designed system Into a system model, edlt and Improve that model, and theo forward
engl.neer the new model lnto an lmproved ~stem.
>
Application Development Environments
The emphasis 011 speed and quallty lo software development has resulted In RAD approaches. The potential for RAD has been amplllled by the transformation of programn~ language compilers into complete applicatio11 developme11t euvirorunettts
(ADEs). ADEs make programmlng simpler and more efficient. Indeed, most programmlnfl language compUers are now Integrated loto an ADE. Examples of ADEs (and the
programmlng languages tl,ey s upport, where appllcable) are llsted In tl,e margin.
AppUcatlon deve.lopment environments pro\oide a number of productl\oity and
quallty management fadlltles. The ADE vendor provides some of tl,ese facilities.Thirdparty vendors provjde many other fadlltles that can integrate Into the ADE.
Progm-111.·111:tng languages or Interpreters are tl1e heart of an ADE. Powerful
debugging features and assistance are us ually provided to heJp programmers
qulcldy Identify and solve p rogramming problems.
interface construction tools help programmers qulcldy build the user lnter-
hces using a component library.
REPRESENTATIVE
ADEs
IBM's Webspiem (Java)
Borland's JB!lilder {.bva)
Macromedia'i Cold Fusioo
Microsoft's V6ual
Studio.NET(VB .NET, Cl,
C++.1-ET)
Oracle's Owei(f)er
Sybase's Po•~tbuilder
applicatio-o development
eoviroomeot (ADE) an
integrated software develop.
ment tool that provides al I the
facilities necessiry to develop
new application software with
maximum speed and quality
A common syncnym is
intsarated dwolopmont
emlironmont QC£).
110
1ho Context of Systems Dowlopmont Projom
Part One
CASE
Workstation
snd
Softwara,
Sy•tel'lle Analyets
""~ ---
Printer
............__
0'8grammla,g
Dictionary
Tool•
Tool•
ayatein
models
ayatein
deecriptiona
O..lgn
Tool•
Oualhy
M•na,gem•nt
Tool•
eyatem
i
quality
prototyp,e.s
report a
and
epecificatione
O..lgn and
Documentation
Tool•
f
c-
Generetor
Tool•
i
project and
deeign models
ayatein
and
documentation program code
te.st rea,lta
and
te.st •cripte
CASI!
lt•po•ttorr
CASE repoaitoriea
are YIYIIIY atored
on aervera •o that
!hey may be aha red
( F I GU R E 3 - 1 6
CASE Tool Architecture
)
Information Systoms Oovolopmont
Mi.dtlleware is softwa re that h elps programmers Integrate the software belng
developed with various databases and computer networks.
Testl11g tools are used to build and execute test scripts t11at can consistently
and thoroughly test software.
Version co1itrol tools help multiple programmer teams manage multiple ,-erslons of a program, both d uring development ai1d after implementation.
Help a ·u thortng tools are used to write on Une help systems, user manuals,
and 01illne trainlng.
Repository ll11ks pennlt the ADE to Integrate with CASE tool products as
well as other ADEs and developm et1t tools.
>
Process and Project Managers
A tll.ird class of automated tools helps us manage the system de,-elopment methodoJ.
ogy and projects that use the methodology. WbUe CASE tools and ADEs are hllet1ded
to support ai1..1lysis, design, and construction of new information systems and software, p rocess manager appllcatio u and p roject m..'Uuger applicatio 11 tools are
intended to support cross llfo.cyde activities. ~Ucrosoft's Prq/ect and Nil-ti's Ope11
Worl:be1,ch and Project ,lla11ager are ex.ampJes of au tomated project management
tools. Because process and project management ls the subject: of the next chapter,
you•n: Jearn more about these automated roots lo thal chapter.
This chapter, along with the flrst two, completes the minimum context for studying
systems analysis and design . We have described that context in terms of the three
Ps- the partldpanis (the s takeholders; Chapter I), the product (the h1formatlon system;
Chapter 2), and the process (the system development; Chapter 3). Armed with this
w1<lerstandlng, you are now ready to study systems allllysis and/or design methods.
For many of you, Chapter 4, • Project Management; wlU provide a more complete
context for studying systems analysis and design. It builds on Chapter 3 hy emphasizlog a "-arJety of management issues related to rhe system deveJopment process.These
lnc.Jude methodology management, resource management, management of expectations, change management, and others.
For those of you who skip the project and process managemetll chap ter, your
next assignment w UI depend on whether your goal b :
• Acomprehensive survey c. systems deVelopment-We recomnend you continue )'OU' SEQuential
path to Chaixer 5, "Systems Analysis." In 1hat chapter you 'Nill study in greater del)1h the scope
definition, problem analysis, requirements analysis, and lo(ical design phases that were
introduced in Chapter 3.
• The study c. systems anal~is techniques-Again, we recommend you continue you- sequential
path to Chaixer 5, "Systems Analysis." Chapter 5 will provile a context for subseQuently studying
Ile tools and techniQues c. systems anal~is.
• Tl'e study c. systems design techniQue&-You might stil w.r,tto quickly skinl or re-.ew Chaixer5,
"Systems Analysis," for context. Then continue you-detail Ell study in Chapter 12, "System
Design." In that chaixer. you wil learn more about the l)(OO!SS and strategies for system design
and construction c. intoonation systems.
d,cptw n,,...
111
process manager
application a-i automated
tool that helps to document
and manage a methodology
and routes, its deliverables,
and quality management
S1B.Jldards. An e11erging
synonym is ITl9C'lodNa.f9.
project manager
application a-i automated
tool that helps to plan syS1em
development activities (pre inabty using the a;,proved
methodology), GStimate and
assign resources (including
people and costs), schedule
activities and resources, monilu1 µ1oy11:1:i1S 1;1.g<'.. imsl ~i.:hal.lul1:1
and b.Jdge t, oontrol and modify schedule ano resources,
and report project progess.
,-([)
0
~
::J
::J
co
:::::0
0
0
Q_
3
0
-u
112
Part One
1ho Context of Systems Dowlopmont Projom
Summary @
l. A systems de,--elopment proces., ls a set of actlvltles, mEthods, best practices, dellverables, and
automated tools that stakeholders use to develop
and continuously impro,--e informatlo11 systems
and software.
2. The capability Maturity Model (C~ll\l) ls a
frame\\'Ork for assessing the maturity level of
an orgailizatlon's lnformation systems deveJopment and management processes and products.
It defines the need for a system developmet1t
p rocess.
3. A system life cycle divides the life of an information S)'&em lnto two stages, systetns develop,nent
and sys:en1s operatto·n and niat11te11a11ce.
4. A systems development methodology is a
process for the system development stage. It defines a set of actlvttles, methods, best practices,
deliverables, and automated tools that systems
developers and project managers are to use to
develop and maintain information systems and
software.
5. 11,e following principles sho,~d underlie all systems development methodologies:
a. Get the system users in,-oJved.
b. Use a problem-solving approacl1.
c. Establish phases and activities.
d. Document througl1out development.
e. Establish standards.
f. Manage the proce55 and projects.
g. Justify Information systems as capital
ln,--erunents.
11. Don't be af.rald to cancel or revise scope.
i. Divide and conquer.
J. ues~n systems for growth and change.
6. System de,-elopment projects are triggered by
problems, opporttmltles, and directives:
a. Problems are undesirable situations d1at prevent the organlzation from full)• achlevtng its
purpose, goals, and/or objectl,-es.
b. Opportunlties are chances to lmprove the organlzation evet1 ln the absence of sped.fie
problems.
c . Dlrectlves are new reqttlrements that are lmposed by management, governmet1t, or some
exten1.1I influence.
7. Wetherhe"s PIECES frunework Is useful for categorizing problems, opportunities, and directives.
111e leuers of the PIECF.S acronym correspond to
Perfonnance, Information, Economics, Control,
Efficleocy, and Service.
8. Tradltiona~ basic systems de,-elopment phases
lndude:
a.
b.
c.
d.
e.
f.
g.
h.
Scope definition
Problem analysis
Requlrements analysis
Logical design
Decision analysis
Physical design and integration
Construction and testing
ltlstalL1tion and delivery
9. Cross llfe<yde actlvlties are actlvlties that o,--erlap many or all phases of the meti1odology. They
may lndude:
a. F:tct-tlndlng, the formal process of uslng re.
search, interviews, meetings, questio1u1.1lres,
sampling, and other technJques to collect information about systems, requlrements, and
preferences.
b. Documentation, the activity of recording facts
and spec-lflcations for a system for cti.rre.111 and
future reference. DoctL01et1tation is frequently
stored in a repository, a database where systems de,--eJopers store all documentation,
knowledge, and products for one or more
information systems or projects.
c . Presentation, the activity of communlcating
findings, recommet1dations, and documertation for review by lnterested users and managers. Presentations may be either wrltten or
verbal.
d. Feasibility analysis, ti1e activity by whlcl1
feasibility, a measure of how beneficial the
dtvdupuieul uf au i.t.tfuru1atiou :,y:,tetu
would be to an organJzation, is measured
and assessed.
e. Process management, the ongoing actlvJty that
documet1ts, manages the use of, and lmproves
a11 organlzatlon's choset1 methodology (the
"process") for systems development.
f. Project management, the activity of dellnlng,
planning, directing, monitoring, and controlling a project to develop an acceptable system
within ti,e allotted time and budget.
10. TI1ere are different routes through the baslc systems development phases. An appropriate route
ls selected during the scope deflnltlon phase
Typical routes Include:
a. Model-driven development strategies, which
emphasize the drawing of diagrams to help
visualize and analyze p roblems, define
lnfom,atfon Symms Oovolopmont
business requirements, and design information systems. Alternative model-driven
strategies lnclude:
I) Process modeling
II) Data modeling
UI) Object modeling
b. Rapid application developme11t (RAD) str.uegies, whlch emphasize extensive user ln\"'Olvement in the rapid and e,-oJution.ary
construction of working prototypes of a system to accelerate the ~'Stem development
process.
c. Commercial application package lmplementa,
tion strategies, wll.ich focus on the purchase
and lntegratlon of a software package or soJution to support one or more busine.s., fw1ctlons and lnformatlon systems.
d. System m.nlntetl.llflCC, wh.lc:h OCC\IJ"S after a system Is lmplema1ted and hlsts throughout the
system's lifetime. Essentlaliy,system maintenance executes a smaller-scale versJon of the
developma1t process with different starting
points depending on the type of problem to
be solved.
11. ,\Utomated tools support all systems developmeat
phases:
,. Computer,,lded systems a1gineerlng (CASE)
tools are software programs that automate or
support the drawing and analysis of system
models and provide for the translation of sys.
tern models Into application programs.
d,cptw Thrte
11 3
I) A CASE repository Is a system developers'
databose. It Is a phlce where deselopers can
store system models, demUed descriptions
and spedftcatlons, and od1er products of
~'stems development.
II) Forward engineering requlres that the sys.
terns analyst draw system models, either
from scratch or from tempL1tes. The resulting models are subsequa1tly transformed
Into program code.
UI) Reverse a1glneerlng allows a CASE tool to
read existing program code aod transform
that code into a representative ~·stem
model that can be edited and refined by
the systems anal)'St..
b. Application development environments
(ADEs) are integrated software de,'elopment
tools that provide all the fac-UJtles necessary to
develop new application software with maximum speed and quality.
c. Process management tools help us document
and manage a metl1odology and routes, Its deUverables, and qu.aUty m:uugemen1 standards.
d. Project managema1t tools help us plan system
developma1t activities (preferably using the
approved methodology), estimate md assign
resources (h1ciudh1g people and costs), schedule actlvitles and resources, monitor progress
against schedule and budget, control and modify sched,~e and resources, and report project
progress.
\';~:=S
Review Questions
C>
I. Explain why having a standardized system
2.
3.
4.
5,
6.
7.
8.
development process is important to an
organization.
How are system life cycie and system development methodology related?
What are the 1O underlyh1g principles for systems
development?
Why ls documentatlon Important throughout the
development process?
Why are process management and project management necessary?
What Is risk management? Why Is It necessary?
Which stakel1olders h'lltlate most projects? What
Is the Impetus for most projects?
Who are the main partlcJpants In the scope
definition? What are tl1elr goals in the scope
definition?
9. What are the tl,ree most important dE!Jverables In
scope dellnltlon?
10. Who are the main participants In tl,e requirements analysis phase? Why are they the main
participants?
11. What feaslblUty analyses are made in the decision
analysis?
12. What Is model-drh.. n development?
13. Why Is model.driven developma1t popular?
14. What Is rapid application developmffit (RAD)?
15. What benefits can RAD bring to tl,e system deve~
opment process?
16. What Is computer,'5slsted software engh,eering
(CASE)? List some examples of CASE.
114
Part One
1ho Context of Systems Dowlopmont Projom
Problems and Exercises
~
I. The Capablllty Maturity Model (C~ll\l) was developed b~· the Software Engineering ltlStitute at
Carnegie Mellon, and is widely used by both the
prJvate and public sectors. W11at ls the purpose
of the a~t framework and l1ow does ft achieve
this?
2. list the ftve maturity levels, and briefly describe
each of them.
3. Table 3-1 in the textbook Illustrates the difference lo a typical project's dwario11, personmonths, quaUry, and cost, depending upon
whethtr an organlzario11's system development
process is at Ot~l level 1, 2, or 3. Between
wh.ich two Ol!lt Jevels does an organ.izatlon
4.
5.
6.
7.
gain the greatest benefit in t erms of percentage
of lmprovemettt? What do you think is the
reason for th.ls?
Systetns ,leve.lop,11.e11t 111etbot10logy and systetn
Ilfe cycle are two terms that are frequei1tly used
and Just as freque ntly misused. What ls the dlfference between the two terms?
Describe how using a $)'stems development
methodology Is In line with C~ll\l goals and
can help an organization increase its maturity
level .
A number of underlying principles are common
to all systems de,-elopment methodologies. Identify tl,ese underlying principles and expfaln tl,em.
11,e PIECES framework was developed by James
Wetherbe as a means to classify problems. ldet1tify tl,e categories, then categorize the following
problems using d,e PIECES framework
a. Dupllcate data ls stored throughout the system.
b . These ls a need to port an existing application
to PDA devices.
c. Quarterly sales reports need to be generated
automatically.
d. Employees can gain access to confidential portions of the personnel system.
e. Uset h1terfaces for the lnventory system are
dtfficttlt and confusing, res,tltlng in a high frequeacy of lncorrect orders.
8. Each phase of a project includes spec!Jk deliverables that must be produced and delivered to the
next phase. Using tl,e textbook's hypothetical
FAST methodology, what are the dellverables for
the requirements analysis, logical design, and
physld design/integration phases?
9. Scope definition Is the first phase of the FAST
methodology, and it is either the first phase or
part of tl1e first phase of most methodologies.
10.
11 .
IZ.
13.
14.
15.
What triggers the scope phase, which stakeholders are involved in th.ls phase, wt1at two
essential questions need to be answered, and
what three lmportant deUverables come Oltt of
this phase?
TI1e requlrements analysts phase is an essential
pan of a system development methodology.
According to the FAST methodology, which &akeholders typically participate In this phase? What
Is tl,e primary focus of requirements analysis'
What is 1101 the focus? How should ead1 proposed requlremei1t be evaluated? What critic,J
error must be avolded?
In the FAST methodology, as well as most system
metl1odologles, system owners an d system de.signers do not participate in the requirements
analysis p hase. What do you think the reason is
for this?
What is t11e essential purpose of t11e logical design phase? How does it accomplish tltls? How
are technological solutions lncorporated ln this
pl1ase? What are some common synonyms
for this phase used by other methodologies?
Who are the typical participants in tltls phase?
What is agile modeling and what Is Its purpose?
What are the deUverables coming out of this
pl1ase? In terms of the development t eam, what
critical transition takes place by the end of this
pl1ase?
What is the essential p urpose of the physical desJg1.1 phase? Who must be invoJ,-ed ln this ph1se,
and wt10 may be lnvolved? What are the two
philosophies of physical design on the different
ends of the contlnlrum. and how are they different?
ls this a likely phase In whicl1 a project miglll be
canceled? Wltl1 what otl1e, phase is there llkefy
to be overlap, and what do you think Is tl,e
reason for this?
A customer has ei1gaged your software development company to de,--elop a new order-processlng
system. However, the time frames are very tight
and inflexible for delivery of at least the basic
part of tl1e new system. Further, user requirements are sketchy and unclear. W11at are two
system development strategies tl1at mJght be
adYantageous to use in tills e ngagement ?
What is the potential downside to using the
strategies described In the p receding question?
Information Systoms Oovolopmont
d,cptor Th,...
11 S
@ Projects and Research
I. Toe Software Engineering Institute (SFJ) at
c,megle Mellon Unlverslty has developed a series
of related CapabUity Maturity Models (CMMs). You
can read about these different C,_0.1 products at
SEl's Web site (http ://wWW.sel.cmu.edu).
a. Identify the current CM.M products helng mah>
rained or developed by SFJ.
b. Wh.at are their differences and similarities?
c. If you were to rate your org..'lnlzatlon, or an
organization with whid1 you are familiar, using
the CMM described in the textbook, at whlch
level would It be? Why?
d. Wh.at steps wouJd you recommend that your
organization take In order to ad·vance to the
a~t Jcvd?
e. Do you feeJ that d1e time, cost, and re.sources t ,)
advance to the next Jevel would be worth the
perceived benefits for your organization? Why
or why not?
ls Intended to be a framework for classifying problems, opportunities, and dhectlves.
Contact one of the ~·stems analysts for your
orgailization, your sd1ool, an<Vor another organizatio11. Ask them about tlte lnfonnation systems
used ht their organization aitd to describe what
the problems are In general terms. Sel«t three of
these ~·stems:
a. Describe the systems you selected, theh problems, and the organizations tl1at use them.
b. Use the PIECES framework in the tectbook to
categorize each system's problems.
c . Describe the PIECES category or categories you
found for each problem. Old each problem genernlly h .•'tve one or more c:a.tegorles assocbted
next
2. )'ou are a new project manager and have bee.n assigned responslblUty for an enterprise h1fonnation
systems project tl1at touches every dJvislon In your
organ.izatlon. The dllef executive officer stated at
project inltlatlon that succe55ft~ly implementing
this project was the number I priority of your organization .11,e project ls in midst of the requirements analysis phase. Wlille it ls on schedule, you
notice that attendance of the system users and
owners at meeting., 011 reqttlrements has been
dropping. A more experienced project manager
hts told you not to worry, that this is nonnal.
Should you be concen:led?
3, There are many different ..ystems development
methodologies ln use, each with lts own terminoJ.
ogy, and number and scope of phases. Search the
Web for frlfonnatlon on two or three of these
other ~·stems development methodologjes, then
do the following:
a. Note the systems development metltodologies
that you found. When, by whom, and why were
they developed?
b. What phases and terminology do they employ1
c. Draw a matrix comparing their phases to the
textbook's PAST methodology.
d. What slgnlfkant dlfferences dld you flnd?
e. Do you see any ad-v antages or disadvantages ht
any of the methodologies that you found con>
pared to the PAST methodology?
4. Toe PIECES framework, which was developed by
James Wethetbe and is described in the textbook,
with lt?
d. For the systems used by dlfferetll organizations,
what commonality dld you find in the categories
of problems? If you found a great deal of con>
monallty of categories, do you think this ls
slgnitlcant or just colnddetltal?
e. Where in the systems development llfe cycle do
you think the PIECES framework would be of
the greatest "-alue?
5. Computer-as.<;isted software et1glneering (CASE)
tools can slgnlficantly help developers Improve
productivity, quality, and documentaticu. Conduct
an Informal survey of about a dozen lnfonnation
technology departments reg,,rding whether they
use CASE tools, and lf so, what type. Also, find out
how long they ha,-. been using tJ,e CASE tools
and whether tJ,ey are used for all or Jmt some
projects. Add any other questions you may find
meaningful. Try to split yolU' survey between public and private sector agencies, and/or large and
small organizations.
What types of organizations dld you survey?
What dld you ask?
Wltat were the results?
Given the Umited and informal nature of tWs
survey, were you able to find any patterns or
trends?
e. Based upon your readings and your survey,
what are your feelings reg,1rdh1g the use of
CASE tools?
a.
b.
c.
d.
6. Projects at times are canceled or abancbned, sometime by choice, sometimes not. Re.search the Web
for articles on project abandonment sttategjes, and
select two of tltem.
116
Part one
Tho Context of Systems Dowlopmont Projom
a. W11at articles did you select?
b. W11at are thelr central themes, finding.,, and rec-
ommendations regard.Jog project abandonment?
c . Compare and contr.tst their findings and their
recommendations. Wllich strategy would you
choo,e, If any?
Minicases
d. Do you think tlut abandonh1g a project Is
always avoldable an<Vor always represents a
failure?
(]l
l. Interview at least two project managers. What are
their experiences with scope croep?
2. George Is the CEO of a major corporation that has
been trying to develop a program that captures the
keystrokes of employees on their computers. The
project Is current!)• $100,000 over budget and
behind schedule and wlll require at least another
Sile Is a • by the book• person who can always be
cow1ted on to do tllings ..rJght." Will Beatrice make
a good project manager?Why or why not?
4. A company is trying to decide between using an
off-the~helf program or developlng a cttStom
program for inventory management. The off-chesheH p roduct is Jess expensJve than tl1e custom
$50,000 and six months: to complete. The CEO
solution :ind still h,s: most of the needed func-
wants to continue the project because so much
has already beetl Invested In It. What Is your
recommendation? Why?
3, Beatrlce is an excellent manager-she ls very capable of nunaglng the bureaucratic process and
following the business rules in her corporatio11.
tlonallty. The CEO believes tl1at the missing capablllty can be addressed through tweaking tl1e
program once It Is purchased. As the CIO of tl1e
company, wh.at are your concerns and recommet1datlons to tl1e CEO?
Team and Individual Exercises
I. (feam) Hold team meetings ush,g different communications mediums. Examples: pl1one, e-mail,
virttta.l environment. Wll..1t dJd you notice about
the Impact of the technology on tile meeting? W..S
the prowctivtty of the meetings the same for each
medium} How did the team feel about the impact
creation of new Jobs when tills happens, but generally t11ere is a time lag between the strucrunl
loss of Jobs and the creation of new Jobs. How do
you feel about that?
3. (feam or Individual) Visit a neonatal hlletlSlve care
unlt at a h1gllly regarded medical center (such as
of the tcchnologlc.:, on the tc.un relatiomhl1>3?
UC 5;lfl fc.,nc.bco), Welte a ~hon papec on your
2. ()11dtvldual) The analysis and design of an Information system, done well, oftet1 eliminates jobs in a
company. Economlc theory strongly supports tile
thoughts of the Involved technology and the impact ft has on people's Uves. At the professor's
discretion, share wltl1 the class.
Suggested Readings
\!W
Amhl<'t; Scott. Agtle Alodeltng: B/fecttve. Practfc.es Jor extrenie Progm111111fng and the Un{fted Pt'Ocess, New Yo lk:
John Wiley & Sons, 2002. This is the ckfuiitht book on ag·
ile blC'thods and modeling.
Af)plfcatton Devetop11ie11t Trends ( ruonthl}' P<'riodical).
Framingh,rn, MA: Soft'\\<are Ptoducth•it)• Gtoup, Inc. This
is our &.vorite periodical for keeping up with the latest
tre,nds in nlC'thodology and autoblated tools. Each
month fC"aturcs se,-c,ral article's o n diffC",rent to pics and
products.
Dc:Marco, Tom. srructured Analysts a1J.d sysreni speaftc~
rton. En.gle\\'Ood aiffs,NJ: Ptt'tltice Hall, 1978. This is the
classic book on structutt-d systems anal-ysis, a proces,;.
ccnte~. modc l-drhtn blC'thodolog):
Gane, Chris. Rapfd systenJS Develop1ne11t. EnglC'Wood Cliffs,
NJ: Pltntkc Hal~ 1989. This book presents a nice ovd'\'le\\'
of RAD that combincs modcl-drh't'n dc-,.'C"Jopmc tt and
prototyping i.n the correct balance.
Gilck,rs!CC','<', ThoblaS. successful Data ProcesSfng S)1rte1ns
Anal)1sts, 2nd ed. EnglC'Wood Cliffs, NJ: Prcntke Hall,
lnfom,atfon Symms Oovolopmont
l S85. We arc indebted to GildcrsleC\'e for the creep·
ing committnc:nt approach. The classic:s ne,tr become ol>sokte.
Jacobson, J-,rar; Grady Booch; and James Rumbaugh. The
Untfted Softu,Ylre. D<!Velop1ne11t Process. Reading, l'i1A:
Addison.Wesley, 1999. The Rational Unified Process is a
currently popular example of a rnodcl.drh'C'Jl, object·
oriented lllC'thodology.
McCorutell, Ste,'t'. Rapta .oevetop1ne11t, Redmond, WA: Ml·
cr:,soft Press, 1996. Chapter 7 of this excellent refettncc
bcok provides "that may be the: dcfmith'C' summary of S)Stem dc,tloprncnt life cycle and methodology \'llriatioas
ttut " 'e call • routes• in o ur book.
Orr, Ken. 1be one Altnute. ,werbodolo~ NC'W Yotk: Dorsett
House, 1990. l'itust lt'ading for those interested in exploring
117
the: nttd for methodolog): This \'C'J')' short book can be read
in one sitting. It '31lov.,s the satirical story of an anal)'St's
quest for the ck,.'C'loprnent sil,tr bullet, • th:: one minute
methodology."
Paulk, l\otatk C.; Charles V. Webc.r; Bill Curtis; and l\otary 8C'th
O\rissis. 1be capabtltty Atarurtty Alodet: Gutdeltnes for
/111/)roVlng the Softu,Ylre. Pt'OC.ess. Reading. MA: Addison·
Wesley, 1995. This book fully describes ,'C'.rsion L 1 of the
Capability l'itaturity l'itodcl. Note that \'C'.r>ion 2.0 '\\':.U
under de\'t'lopment at the time " 'e " 'ere writing this
chapter.
Wetherbc, Jamcs. sysre111s A11af)1sts and Destr1i.· Best Pmcrtc.es, 4th ed. St. Paul, MN:Wcst, 1994. We ate indebted to
Wetherbc for the PIECES frarncv.•ork.
S1raleglc En1erprlse Plan
Strat.eglc 1ntormatbn Systems Plan
.,..
.............
"''"
rnpo,o a..i,_
"''"
lrrp:llf SuSNIU
PACC.....
IO«:M't.EOGE
COMWUNICATIONS
811.TEMEN'f OFWOFI(
11
PFI08LEM ST.ffl:WEHT ~~ N Pl:CES ...,._.,,,
~------,
e------~
INFCRMATION
•COP<
FUNCTION.t.L
&CO. .
OOWMJNICRIONS
SCO,E
VISION
'11610N
""°"
•
•
•
H ..a
II
~------~8USIIESS FIEOUREt.ENTS61ATE~N'f;--------,
....
....
SU51Na$ A SYSTEM
8USIIESS
8U61NESS
PAOOESS
REOUIFBIENTS
FIEOUIFIEWEHTS
HTEAFACE
AEOUAE~N'fS
LOOICM.
<.O<OCA<
HTEAFACE
.____ __,I
MOOEI.S
WOOELS
SY&TEM PAOPOSAL
(or REOUEST FOR SY&TEM PROPOSAL&)
AIJCHITECTURAL MOOEL
PHY61CAL
6U611ESSPAOWS
DESIGN
'""'"
~REDESIG~
SPECIFICATIONS
PHYSICM.
...
...........
USEAASY'STEW
HTEAFACE
"""'
SPECIACRIONS
FUNCTIONAL SY&TEM
OESGN
6PEOFIOOIONS
-
~
I
'
0
0
-·.. I
-·
'""""
CUS10W~ILT
APPI.ICIJION
OPERATIONAL &YSTE•
APPACWEO
TECHNOLOGIES
TECHNOI.OOIU
•!
I•
•
n i•
I
!I
f!
;
I
•
·!
INTE~ACE
SCLUTIONS
........
........
S1rat&gle En1erprlse 1ntormat1on ~enno1ogy Arcnltecture
I
I
•
I
•
I
I
J
r
r
'f
si i• Ir
i; l •
f
I
........
-
........
.........
a• •a
....
INTE~ACE
SCLUTIONS
POST.AUOIT IJEVIEW
APPACWEO
l
·1Ii I
•RAINING •ATERIALS
~Cl'ICIH.
se•
• !I
OE&IGN PROTOT\'PES
.........
......°"
I
!I
R
I
u
•
I
I
•
Project Management
Chapter Preview and Objectives
Project management skills are greatly in demand in the infonnation technology community. Project management is a natural extension of the previous chapter•s introduction to
system development. This chapter provides a process-centric sur,-ey of key project management tools and techniques as they apply to systems analysis and design. You will
knO\\' that you understand the basics of project management when you can:
I Define the terms project and project management and differentiate between project
and process management.
I Describe the cau.ses of failed information systems and technology p,tjects.
I De.scribe the basic competencies required of project managers.
I De.scribe the basic functions of project nunagement.
I Merentiate between PERT and Gantt charts as project management tools.
I De.scribe the role of project management software as it relates to project management
tolls.
I De.scribe eight activities in project management.
I Define joint project plannin.g and its role in project management
I Define scope, and write a statement ofwo1* to docun~nt scope.
I Use a work broakdown structum to decompose a project into tasks.
I Estimate tasks' durations and specify intertask dependencies on a PERT chart.
I Assign resources to a project and produce a project schedule with a Gantt chart.
I Assign people to tasks and direct the team effort.
I Use critical path analysis to adjust schedule and resource allocations in response to
schedule and budget deviations.
I Manage nser expectations of a project and adjust project scope.
120
Part One
1ho Context of Systems Dowlopmont Projom
Bob Martinez was in the office of his boss, Sandra Shepherd, discussing the SoundStage Member Senices system project.
•n,15 sure is a big project; Bob said, "bigger than anything I've ever worked on
before. How will you make sure ft stays on track?,.
.. '\X'ell, first we have to get consensus on the scope of the project and document assumptions and constraints," Sandra ai1SWered... '\X'e also have to negotL1re the ptoject
budget and sd>edule. Then we identify all the tasks that need to be performed.The FAST
methodology ls our template, but we always customize ft for each project. '\X'e have
to plan each task and analyze how its work and iis own schedttle tlt in with the overall
project.Then we assign people and other re.sources to each task. As d1e project goes on
we ha,--e to manage d1e proce.s., to make sure e,-erythfng scays 011 schedule:'
• wowl" Bob replied. •on some of the semester group projects I did lo collew,, we
Just kind of dived right in with the work. If we got behind we Just pttlled a couple of
all-nighters.·
.. Believe me," Sandra sald,"you don't want to be around when the finger pointing
scans on a real $)'Stems project tll..1C lS beh.J.ocl schedule or over budget.. Th.at's sometbit1g a coupJe of all-nlghters won't fix. We have a long road ahead of us, and we want
to plan tills as carefully as possible.•
~~~""
~ h_a_t_l_s_P_ro
~ je_c_t_M
~a_n_a_g_e_m_e_n_t_?~~~~~~~~~~~~~~)
project maaager the
person responsible for super.
vising a systems project from
initiation to conclusion. Sue.
cessful projeC1 managers
possess a wid; range of tech·
nical, manage11ent, leader.
ship, and communication
skills.
project a sequence of activities that mustOe completed
on time, 'Mthin budget, and
according to S,)ecification.
Most of you are familiar with Murphy's Law, which suggests, "If anything can go
wrong, It wlU." Murphy has motl>-ated numerous pearls of wisdom about projects, ma.
chines, people, and why things go wrong. This chapter wlU teach you strategies, tools,
and techniques for project management as applied to information systems proj,cts.
The demand for project man..'lgers ln the information systems commw1ity is
strong. Typically, IS project managers come from the ranks of experienced IS deve~
opers such as systems analysts. Whtie It Is wlllkely that your first Job responsibilities
will include project management, you sl1ould Immediately become aware of project
management proces.,es, tools, and teduliques. Eventually you will combine tlli.s
kt1owledge with development experience plus your own observation of project managers to form tl1e basis for your own career opporrwlitles in project mai1..1gement.
Before we can define projec.t nU11J.age,ne1l.f. we should first define project. There
are as many definitions as there are authors, but we Uke the definition put forth by
Wysocki, Beck, and Crane:
A project is a [temporary) sequence of unique comp!~ and connected activities tl1..1t have o ne goal or purpose and tl1..1t must be completed by a specific time,
within budget, and according to speclflcatlon. 1
111e keywords are underlined to draw yottr attention to some key aspects of the defi.
nltio11. As applied to information system development, we note the following:
A system de,--elopment process or metl1odology, sud1 as FAST, defines a
sequence of acrOiUes, mandatory and optional.
Every system development project is unlqtte· that ls, it ls different from every
other system developme11t project tl1at preceded It.
111e actMties that comp<ise system de>'elopment are relati>'ely complex. They
require the skills tbat you are leaming In d1is book, and they reqttlre tlut you be
able to adapt concepis and skills to changing conditions and unant!dpQ!ed eTI?nlS.
1Robtn K. Wysocki, Robtn lkc.k.,Jt., 11b:I Dav.cl 9. Ch:t1c.E.ftd1it't' Prq«f ,Wfl#lfltll1#:#I: Hatuto P1'1f, ,Wauaat, """
J:klii,,:r t+oj«tso,i n ·nw (1/#ditilbN, BNd&tl<NewYOl.'t:Jobll. Wtl,:y& Sor.. 199». p. -l8.
Projoct Managomont
chapter Four
121
By now, you·,--e already learned that the ph.ases and activities that make up a
system development methodology are generally sequential. WbUe some tasks
may overlap, many tasks are dependent on the completion of other tasks.
The de,-elopment of ait Information system represents a goal. Severa) objecttves may need to be met to achieve that goal.
Although many infonnatlon system development projects do not have
absolute deadlines or spec:lfied times (there are exceptions), they are notoriously completed later than originally projected. This is becoming Jess acceptable to upper management given the organlzationwide pressures to reduce
cycle times for products and bush1es., proces.,es.
Few informatio11 $)'stems are completed within budget. Agait1, upper management Is increasingly rejecting tllls tet1dency.
lnformatio11 systems must satisfy the business, user, and management expectations acr:on11ne ro specfOcarlons (wll.ich we call requirenie11ts tlvoughout
this book).
For any $)'stems development project, effectl,-e project m..1..o.agement is neces- project managemeot the
sary to etlSltre that the project meets the deadline, ls de,--eloped witllin an acceptable process of scop ng, planning,
organizing, directing,
budget, and fulfills customer expectations and specttlcatlo11S. You learned lo a1apter 3 S1affing,
and controlling 1ho dovolop
tl1at project management is a cross life-cyde activity because It overlaps all phases ment of an accxptable syS1em
of any systems developmetll methodology.
ata minimum cost within a
Corporate rigillslzing has changed the structure and culture of most orgmllzations specified ti me frame.
and, hence, project managemei1t. More flexible and temporary interdepartmental teams
tlut tre gtven greater responsibility and authorfty for the succe.s., of organizations have
replaced rigid hlerardllcal command structures and permanetll teams. Contemporary
system development methodologies depet1d on having teams that Include both tedullcal and 11onrecbnlcaJ users, managers, and information technologists all directed to the
project goal.11,ese dynamic teams require leadership and project managemei1t.
Orgail.izatio11S take different approad1es to project management. One approach ls
to appoint a project manager from the ranks of the team (once it has beet1 formed).
Alten1atlvely, many organizations beUeve that successful project managers apply a
unique body of knowledge and skills that must be learned.111ese org;ullzations tend
to hire an<Vor develop professional project managers who are thet1 a~Jgned to one or
more projects.
Toe prerequisite for good project management Is a welklefined system development process. In Chapter 3, we introduced d,e CapablUty Maturity Model (OU.I) as a
framework for quality managemei1t that ls based on a sow1d systems de,--eJopment
p rocess. In Chapter 3 we dlfferei1tiated betweei1 p roject and process manaaemenr.
Project management was defined above. Process m:a.o.agement is an ongoing actt,~- process mao.agemeot the
Jty that docttmet1ts, mai1..1ges the use of, and Improves an organlzatlon•s chosen activity of documenting,
methodology (the ..process") for systems development. Process management is con- managing. and contin ualty
improving the process of
cemed witl1 tl,e activities, deU,-.rab!es, and quaUty standards to be applied to all proj- systems development
ects. The scope of proces., management is all projects, whereas tl1e scope of project
management is a single project. This chapter wUI focus on project management.
1
>
The Causes of Failed Projects
What causes a project to succeed or fall? Chapter 3 Introduced 10 basic principles of
systems de,-etopmenr tl1..1r are critical success factors for all projects. See Chapter 3 for
a re,iew of those principles. From a project management perspective, a project Is
co11Sldered a success lf:
The resu.lting infonnatlon ~·stem is acceptable to the customer.
Toe system is delivered •on time."
Toe system is delivered "within budget.•
The ~·stem development process l1..1d a mlnhml lmpact on ongoing bush1ess
operations.
122
Part One
1ho Context of Systems Dowlopmont Projom
Not all projects meet these criteria, and as a result, not all projects are successful.
Failures and limlted successes far outnumber successful information systems. Project mismanagement can undermine the best appUcation of the systems analysis and
design methods taught In this book. We can develop an appreciation for the Importance of project management by studying the mistakes of some project managers.
Let's examine some project mismanagement problems and consequences:
Fa/Ju.re to establish upper.nw11age111e1U cotntnittnent to the project- Sometimes commltmet1t changes during a project.
Lack of orga11izarto11's cottnnir,nent to the S):Ste,n develop,1,e11t tnethodologyMany .-ystem development med1odologles do little more than collect dust.
Takl11g sborta,ts through or aro·u nd the S)Sfetn develop,11.e nt ,netbodologyProject teams often take shortcuts for one or more of the followlng reasons:
11,e project gets behind sd1edtde, and the team wants to catch up .
The project is over btdge~ and d1e team wants to make up costs by
skipping steps.
The team is not tralne:1 or skilled in some of the methodoJog)''S act:lrtties
and requirements, so It skips them.
Poor e.Ypectatto1,s ttJ.anagetnent- All users and managers ha,-e expectations
of the project. Over time, these expectations may change. 1bls can lead to
two w1deslrable situations:
scope creep the unex.
Scope creep Is d1e unexpected growth of user expectations and bu;!.
pected and g a.dual growth of
requirements during an infor.
mation systerrs project.
ness requirements for an information system as the project progresses.
The schedule and budget can be adversely affected by sud1 changes.
Feature creep is the w1controlled addJtlon of tedulical features to a
system under de,--etopme nt without regard to schedule or budget.
feature creep the uncon.
trolled additior,of technical
features to a sy"Stem.
Pre1nat1,re co,n·,nitnmJ.t to a fixed b ·u dget and schedule- )'ou can rarely
make accurate estimates of project costs and schedtde before completing •
detailed probletn a,mysls or requirements analysis. Prematttre estimates are
inconsistent with tl1e creeping commltment approach Introduced in a,aprer 3.
Poor estl1natl11g tecbnlqr-1es- ~tar1y systems analysts estimate by making 1
best-calctdated esthnate and then doubling t11..1t number.111.ls is not a sdentlJk approach.
OVeropllmtsm- Systems analysts and project managers tend to be optimists.
As project schedules slip, they respond, "No big deal. We can make It up
later;" They fail to recognize that certain tasks are dependent on other tasks.
Because of these dependencies, a schedule slip In one phase or activity wlU
cause corresponding slips ill man)' other pl1..,ses and activities, thus conUibuting to cost overruns.
The mytbl.cal mm•mo11tli'- As the project gets behind schedtde, project
leaders frequet1tly try to solve the problem by assigning more people to tl1e
team. It doesn't world 111ere ls 110 Unear relationship between time and oumber of perso1u1el . The addition of personne l usually creates more communication problems, causing the project to get evet1 further belllnd schedule.
/1,adequate people n1anage1nent skllls- 1"1anagers tend to be tlvust: into
management positions and are not prepared for management responsiblUties.
Thls problem Is easy to identify. No one seems to be ln charge; cusromets
don't know tl1e status of the project; teams don 't meet regtdarly to discuss
and mon itor progress; team members are11't commwlicating with one
another; the project is always said to be •95 percent complete."
Fal/u.re to adapt to bu.sl,~ss change- If t11e project's importance changes
d urlng the project, or if the mai1..1gement or the bush1ess reorg;ul.izes,
Projoct Managomont
chapter Four
123
projects should be reassessed for comp atibility with those changes and their
bnponance to the business.
Jnsufftcient n,sou.rces- Thls could be d ue to poor estimating or to other
priorities, or ft could be that the staff re.sources assigned to a project do not
posses, the necessary skills or experience.
Far.tu.re to '711.anage to the plan"- Vatious factors may cause the project manager to become sidetracked from the original project plan.
Ultimately, the major cause of project failure is that most project managers were
11ot educated or trained to be project managers. Jusl as good programmers do11't always go on to become good ~·stems analysts, good ~·stems analysts don't automatically perform well as project managers. To be a good project manager, you sho,dd be
educated and skilled In the •art of project management .•
>
The Project Management Body of Knowledge
T he Project Management Institute was created as a professional society to gulde the
development and certlflcatlon of professron.a l project managers.The Institute created
the Project Management Body of Knowledge (PMBOK) for the education and certifl.
cation of professional project managers.This diapter~ content was greatly Influenced
by the PMBOK.
Proie<t Manager Competencies Good project managers possess a core set of
competencies. Table 4-1 summarizes these competencies. Some of these competencies can be taught, In courses, books, and professiet.1..11 workshops; however, some
come only with professional experience in the tleld.There are two basic premises of
project management competencies: First, indJ'\oiduals cannot mat1..1ge a process they
'
r TA II LE 4 • 1 Project Manager Competencies
Competency
How to Obtain?
Explanation
Business Achievement Competencies
Bu$iness
m\'Ol'91'1QSS
Bu$iness partner
orientation
CanmitmMtto
qoolity
Ties every systems projed to the miss;on, vi$ion, and goal, of the
organization.
Keeps manogors and u,en in,olv,,d fi roughout a sy,19m, project.
Busines,$ experi"1Ce
Ensure, that r,,ery ,y,tem, project rontribut.. to fie qualily expectation
ol the organization a, a whole.
Busines,$ experi"1Ce
Busines,$ experi"1Ce
Problem·Sotving Competencies
lniiativ,i
lnfonnation
gcmering
Analytical
thinking
Caiceprual
thinking
Demonstrates creativity, calculated ri$k$, and per$i$lence nec»ssary to
get the job done.
Skillfully obtain, the fooual information neai..ary to anolyze, de,ign,
and implement Iha infonnation ,y,tern.
Cano...., ond ,elect appropriat<> systom dovelopmMt proc.. , .. ond
use project management tool, to pion, ,chedule, and budget for
,y,tem development.
Con solve problem, through Iha analflical approach of derompo,ing
,y,tem, into !heir part, ond ihen rea.,.mbling Iha part, into impro,,id
,y,tem,.
Undorstond, , y,tem, iheory and app!i"' it to sy,tom, analy,i, and
des.ign of information systems.
Busines,$ experi"1Ce
Cho pl<>r 6 in ihi, book
pl u$ busines,$ experien c»
Thi, chapler
Chopi<>n 8, 9, end 11 in
th i, book plu, bu ,i....
experien c»
Cho pl<>n 2 ond 5- 11 in
thi, book
continued
124
Part One
TA B L E 4 - l
Competency
1ho Context of Systems Dowlopmont Projom
(Continued)
Explanation
How to Obtain?
Influence Competencies
Interpersonal
awaren&$5
Unden.tonds, recognizes, and reads b interpersonal motivations and
behaviors.
Anticipaticn of
impact
Undorsrond, the politics of the orgonizalicn ond how lo use them in a
project.
Unden.tonds implications of project decisions and ma noges
axpodalicns and risk.
ResourcefJ use
of influence
Skilllully obloin, cooporaticn and (X)ll,en,u, of managers, users, and
technologists to solutions.
Organizational
awaren&$5
Can be learned in course$
but requires. bu$ine$S
Ql(perience
Bu $ine$S Ql(perience
Introduced in this chapter
but requires. bu$ine$S
Ql(perience
Bu $ine$S Ql(perience
People Management Competencies
MotiYOling
Coaches and dirQ individuals to overcome differences and achieve
othon
projod gooli os a toam.
Communicotion
,kill,
Communico19, olfoctiwly, both orally and in writing, in tho ccn!Qxt of
meetings, presentations, memos, and reports.
Monitoring and
ccntroling
Ensures that project team members receive sufficient training,
assignments, supervision, and performance faecbxk required to
ccmple19 project..
D"'9iop, the project plan, ,chedulo, and budget and (X)lllinuou,ly
monitors progress and makes adjushnenb when necessary.
Bu $ine$S Ql(perience
Can be learned in course$
but u,uaily roqu i '"'
bu$ines.$ experience
Bu $ine$S Ql(perience
Tool, and 19chniqu..
!ought in this chap19r, but
requires. project experienoa
Self·Monagement Competencies
S.11-confid•nai
Stress
Comis19ntly moko, and defond, doci,icns wi'h a strong personal
ccnfidenai in the proa,'5 and/or fact,.
Worb oll,ictiYOly under pro'5uro or adY<1nity.
Bu $ine$S Ql(perience
Con$i$1entfy and hones.~y deliver$ on promi$&$ and solution$, Maintains
technical or bu$ines.$ currency in lhe field 0$ appropriate.
Capable of adju$ting proC9$$1 management rtyle, or decision making
based on situoticn, and unan~cipa19d probl<rns.
Bu $ine$S Ql(perience
Bu $ine$S Ql(perience
management
Concern for
;~d,b,lity
\__axibility
I
Bu $ine$S Ql(perience
Soun:~ Ad1pted &om RobM K. ~ Robtrt Bedt. Ir~ 111d O.Vid B. Ci:rul&. Eff«tiT< P,oj«t J/Qtllgosnw: How to P/Ollf. '4411•, #14 Ddi,~ Projtttsott TtM tUld
witlliit lm4g<r (NtwYotkl Job11 V.'ilc,' & .son., 1995).
have never used. Second, mai1..1gers must ba,-e an understand.fog of the business and
ct~ture that provides a context for the project.
Proiect Management functions 111e txtsic functions of a project manager ha,--ebeen
studied and refined by management theorists for many )'ears. These flu1ctions include
scoping, plannlng, staffing, orpnlzlng, sd,edullng, directing, controlling, and doslt1g:
Scopt11g- Scope defines the botmdarles of the project. A project manager
must scope project expectations and constraints In order to plan acti,itlts,
estimate costs, and maiuge expectations.
Pla,111t11g- Plaonlng Identifies the tasks required to complete d,e project.
Thls is based on the manager's understanding of the project scope and the
methodology used to achieve the goal.
Estlmntt11g- Each task that ls required to complete the project must be estimated. How much tlme wJU be required? How many people wUJ be needed?
Projoct Managomont
chapter Four
12S
W11at skJUs wlU be needed? W11at tasks must b( completed before other tasks
are started? Can some of the tasks overlap? How mud1 will it cost? These are
aU estimating issues. Some of these issues can be resolved wJd1 the project
modeUog tools that will be discussed Liter in this chapter.
Scbedull11g- Glven the project plan, the project manager ls responsible for
scheduling all project actlvttles. Toe project sched,de should be developed wid1
an understanding of the required tasks, task duration, and task prerequisites.
Orga1J:f.zt11g- TI1e project manager should make sure that members of the
project team w1derstand their own indl\oidual roles and responslbilltles as
well as their reporting relatlonshlp to the proj,ct manager.
Dlrectt11g- Once tlte project has begw1, the project manager must direct the
team's actfvJties. Every project mai1..1ger must ck>monstrate people management
skills to coordinate, delegate, motl'\o-ate, ad"ise, appraise, and reward team
members.
Controllt11g- Ptthaps the manager's most dlffindt and important function Is
controlling tlte project. Few plans will be executed without problems and
delays. 11te project manager must monitor and report progress against goals,
schedule, and costs and make approprlate adjustments when necessary.
Clo&lng
Good proje.ct managers :ii-ways assess successes and f:illtr.res at the
conclusion of a project. They learn from their mistakes and plan for continuous Improvement of the systems development process.
All the above functions are dependent on ongoing Interpersonal co111.1n·u11:lcaff-011
among the project manager, the team, and other managers.
Proie<t Management Tools and Techniques-PERT ancl Gantt Charts The
PMBOK Includes tools and techniques that support p-oject managers. Two sucl1 tools
are PERT and Gantt charts.
PERT, which stands for Project Evalt,atlo·n a1ul Revle11J Tecb11:lque, was devel- PER'f cban a graphical net·
oped in the late 1950s to pL1n and control L,rge weapons developmetll projects for work model use:t to depict the
the U.S. Navy. A PERT chart is a graphlcal networt model that depicts a project's interdependencies between a
tasks and the relationsh..lps between those tasks. A sample PERT chart is illustrated project's tasks.
In Figure 4-1. PERT was de,'eloped to make clear the lnterdepe,ubmce betweet1 prot
ect n.sks before those tasks are scheduled. TI1e boxes represent project tasks (we
used phases from Chapter 3), (fhe content of the boxes can be adjusted to show Gaott c han a bar chart
to depict s:roject tasks
various project anrlbutes sud1 as schedule and actutl start and finish times.)The ar- used
against a calendar.
rows lnd..lcate that one task ls dependent on the st.arc or completion of another task.
The Gantt cb:ut, B..rst concei"-e-d by Henry L G:intt in t 917, is the m o st commo nly
used project scheduling and progress evaluation tool A Gantt cb...1.rt is a simple horizontal bar chart that deplcts project tasks against a calendar. Ead1 bar represents a
named project task. The tasks are listed vertically In the left-hand coluntn.11te horlzonttl ax.ls is a calendar tlme line. Figttre 4-2 illustrates a ph..,se..level Gantt d1.art, once
ag,110 based on Chapter 3. We used tlte same project tl1at was illustrated In Figure 4-1.
Gantt charts offer the ach--antage of clearly showing overlappt11g tasks, that is,
tasks that can be performed at tlte same time. Toe oors can be shaded to clear~· h1<licate percentage completion and project progress. The figure demonstrates which
phases are ahead of and behind scbedtde at a glance. Toe poptdarlty of Gantt charts
sterns from tl1elr simpliclty- tltey are easy to learn, read, prepare, and use.
Gann and PERT charts are not mutually exclusive. Gantt d1arts are more effective
when you are seeking to communicate schedule. PERT d1arts are more effective
when you want to study the relationships between tasks.
Proiect Management Software Project management software ls routinely used to
help project managers pL1n projects, develop schedtdes, develop budgets, monitor
progress and costs, get1erate reports, and effect change. Representatfve automated
project managemetll tools are listed In the margin.
PROJECT
MANAGEMENT
sonwARE
Niku's Projed Manag«
Artemis lrtemdiooal
ScltAions Capo,ation~
{KJ(!J
Computer Asiociates'
Al/Fusion Pr<eess
Manag11T1ent Suite
Microsoft's Project
Primawra's Project Planner
and Project Maiager
C/S Solulioni' Risk+.
126
Part One
1ho Context of Systems Dowlopmont Projom
Scope 0-ifiNtion
Legend
I
Task
I Scheduled
Start
Schedued
Rnish
Actual S1art
AC1U'1
Rnish
I
II
I
intertask
dependency
I
I Scheduled
S1art
Scheduleo
Finish
AciUal Start
Actual
Finish
I
I
I
Task
I
Oacision Anatysis
''
.
6-13-2001
''
7-30-2001
B!f!HfiiiifHfI Bii+HfEFiiHfI FiffHf-fFfHfI
i
Physical Oesign
( FIGURE 4 - 1 APERTChart
\X'e wUJtead1 you project modeling and mai1..1gement techniques ln the context
of project management software. We used ~ficrosoft Project because that tool is
frequet1tly avalL1ble to students and Institutions at special academic prices through
their college bookstore. ,_Ucro!oft Project, like most project management software
tools, supports both PERT and Gantt dtarts.
Figure 4-3(a) Ulustrates one possible ~Ucrosoft Project Gantt d,art for the Sow1dStage Member Services project.We call your attetlllon to the following numbered oollets:
O
0
TI1e black bars are sutntnary tasks that represent project phases that are fur.
ther broken down into other tasks.
Toe red bars indicate tasks that have been determined to be critical to d,e
sd,eduJe, meaning that any extension to tl,e d uration of d1ose tasks will delay
oth er tasks and the project as a whole. \X'e1J talk more about critical tasks later.
Projoct Managomont
ID
Chaptor Four
127
TaticName
1
Problem Analysis
2
Requirements Analysi.s
9
Logical Design
4
Decision Analysis
S
Ph)'Slcal Design
6
Co~truction & Teating
7
Implementation & Delivery
-
Today
Legend
-
Compa.1,•
U R E 4 - 2 A Gantt Chart
)
CF I G--------~
~·
O
O
0
The blue bars lndlcate tasks tllat are not critical to the sd1edule, meaning
they have some slack time during which delays will not affect other tasks
and the project as a whole.
The red arrows indicate prerequisites berween rwo critical tasks. (fhe blue
arrows indicate prerequlsltes between two noncrltlcal tasks.)
The teal diamonds l.ndlcate milestones--e,tenrs tl1..1t ha,--e no duration. They
,ignlfy the end of some signlflcant task or deli,erable.
Figure 4 -3(b) shows a Microsoft Project PERT chart based on the same project
plan that was illustrated ln the Gantt chart. The contents of each cell ln the task rectangles are able to be customized In ~Ucrosoft Project.
( The Project Management Life Cycle
Recall from a.apter 3 d,at d,e capablllty Maturity Model defines a fnmeworl< for assessing the qualtty of an organization's Information ")'Stems development acttv!tles. CMM
Level I ls defined as•initial' and Is characterized by the lack of any consistent project or
process management function. The first stage of maturity impro,--ement ls to Jmple.meut
a consistent project management function- called O~f Leve.I 2. In this section we
introduce a project management life cyde representative of Cl\lM Level 2 maturity.
Figure 4-4 lllustr2tes a project management process or life cyde. Recall that project
management ls a cross Ufe-cyde activity; that is, project management actlvltles overlap
all the system development phases that were Introduced In a,apter 3. The illustrated
project management actlvJties correspond to classic man..1gemet1t functions: scoping,
planning, estimating, scheduling, organizing, dlrectln@, controlling, and dosing.
The project management process shown in Figure 4-4 lncorpor2tes a Joint project
planning (IPP) technique. 3Joint project planning QPP) Is a strategy wherein all
~ k i . Beek. arid Cltitnc-. liffev:th~ P,vd«t ,Va11'«1!1:1Nfflt: llot11 to Pfa,i, ,lf'11'«1!1:, i1Nd Dclivtl Pn:j«ts ON Tinit mNI
tt'itbi,,Bud,t
J?al!!.
Joint project plarutiJlg
(JPP) a stratsg/ in v.nich all
S1akeholders atend an inten·
sive workshop aimed at
reaching consensus on
project decisions.
128
Tho contoxt of Systoms Dovolopmont Projocts
Part one
J.!)'."'
Ult-,
i'oo"' , _
£""'
~~ ~
--____
10 Ii \l 4i[)i :,. A flll ~ C "' 'fo - •-- at•. tJ
• ...... • II I 11. ;5 -tt ,s
.,.G_
. , ...
' ..
......
·--·
. 0
...'""'""'_,.
-....---__ '""i-0...c:-...'\.-_--,,··--}._.._....
~--,
··--·--·
___
_
~·---·
·
,
.
--l~
~
-·-·
)..----·
_..._..,
~ ..i..;..,----··----··.,_.-__
0
,,_...,
___
•l,.,.,...........
.i, ..._
_
--
~Je.o-.....- -
1,_ _ _ _
,...
•l _ __
...
,,~-··-·
_..__- _
_____
......._____,
1:1 ,_
... .. _
" °""'*" ___
0
.:J'.:.I
.;...
~ !!!!!!!!::irh
(a)
...
~€" i9 /JIM ! - ~ -
o~ g •t\.:J
- :,- ,
14,.
f!<tqo.: ~ :t'"
•
·-
-a
.' ,
.----,.
..
.-----,._
.___,.
·-·
I
·--
.'
c
(b)
F IG U R E 4 • 3
Microsoft Project Gantt and PERT Charts
)
Projoct Managomont
chapter Four
129
CENTERS oi: EXCELI.E.NCE
~
metnoao1ogyorproceeaetandilra,
_ _ .:. ~~J
~.,. .
. . . . .f
METHOOOU)CY .l!CI
o, .,.....
.:i:
Prooe• ana Pro1ect
Manl!lgement
----
1111111
.1. . .
, ..1
.-----· - ·,
I
comp1eteo
1
exper1enoee,
011servation,.
ana
Project
Experiences
~::-1
team
i,u11c11ng
e.uggestlon,
!
...+----- ....
TM·i PROJECT TEAM
.,.
Pf1:19te88
_
ana
Mtl.matee
ana1ye1s
oprn1one
S'1'8TEM OwNEA&, U9ER8, OUCNEA&,
9Ut.OEFl9, AHO AHALY81'8
Ml.lee.tone
i
comp1et1on
reaoutte
commitment,
(external )
Progree,
~r~
..
~ ,
..
AMlgnmentt
ana euaget
IIANAGEME.NT
J_
.• ·• . ..
.
M.lNACEFIS N)T ON THE
PROJECT TEAM
G
GU R E 4 • 4
A Project Management Life Cycle
•
,+--Scneau1ea
Taak8
'
____
stakeholders ln a project (me:uling system owners, users, analysts, designers, and
builders) partldpate In a one- to tbree-0ay project mmagernent workshop, the nmdt
of wlllch ls consetlS\lS on project scope, schedule, res)urces, and budget. (Subsequent
wod(shops or meetings may be required to adjust scope, budget, and sched,de.)
Notice that In JPP, d,e project team is actively lnvolwd In all inputs and deliverables
of all project mai1..1gement actl\oitles.
In the following subsections, we will review eadl of the illustrated project managemet1t activities and discuss how rouse appropriate p roject management tools and
tedmlques.
)
130
Part One
1ho Context of Systems Dowlopmont Projom
>
scope the boo ndaries of a
project-the areas of a
business that a project may
(or may not) address.
Activity I-Negotiate Scope
Perl1..1ps the most important prerequisJte to effective project management occllJ'S at
the beginning. All partles must agree to the project scope before any attempt Is made
to ldentlfy and schedt~e tasks ot to assign resources (people) to tbose tasks. Scope defines the expectations of a project, and expectatlons ultlmately detennlne satisfactlon
and degrees of success. Accordltigly, the negotL1tlon of project scope ls a necessary activity In the project management life cycle. What Is scope? Scope defines tl,e boundaries of a project- the parts of the business tbat are to be studied, analyzed, designed,
constructed, lmplemetlled, and ultimately improved. Scope also defines the aspects of
a system that are considered outsJde the project .The answers to five basJc questions
influence the negotiation of project scope:
Product- What do you want?
Quallty- How good do you want It to be?
Tt1ne- Whet1 do you want Jt.?
Cost- How much are you willing to pay for It?
Reso·urces- What re.sources are you willing or able to bring to the table?
Ncgo tL'ltio n o f the abo ve facto t3 l3 a give-and-take .1.ctJ:vJty that lncludc.:, ,nuch he,.1.-
statemeot or wor k a
narrative description of the
work to be performed as
part of a proje:t. Common
synonyms include scope
statomont, pro;.ct delinifon,
pmject ovQtlliew, and
docvmont ol <nderstandng
tlon .The deliverable ls an agreed-on s t..1.temei1t o f work tl1at describes the w«k to
be performed d uring the project. In consulting engagements, the statement of work
has become a commonly used contract: between tl1e consultant and client. Tilis
approach works equally well for internal system developm ent projects to establish a
contract between business management and the project: manager and ream. According ro Kean e, Inc . , a leading project management consulting firm,
The statement of work affirms that the project manager understands who Is really
in diarge of d,e effort, who Is controlling tl1e purse strings, what Is the formal and
informal organizatlon within which tl1e project w UJ be developed, who are tl1e
.. klng.1 and queeiu" t11at ha,-e lnrerest, and other similar bur maitlly nontedulical
issues. It establishes a firm business reL1tJonsbip between the project manager
and both the customer and tl1e extet1ded project team.'
An outline for a rypJcal statement-of-work document ls sl1own ln Figure 4-5. The
size of the documet1t wUJ "-ary fn dtfferei1t organJz.atlons. Ir may be as small as one ro
two pages, or it may rtm several pages.
>
wor k bteakdowo
structure (WBS) a
graphical tool •Jsed to depict
the hierarchic.al decomposition
of a project into phases,
aciivities, and tasks.
Activity 2-ldentify Tasks
Given the project scope, the next acmity Is to identlfy project tasks.Tasks identify the
work to be done.Typically, this wod< Is defined in a top-down, outline manner. In Chapter 3, )'OU learned about system developmetll routes and their phases. But phases a,e too
large and complex for pfaonlng and scheduling a project. We need to break them down
into actlvJtles and tasks w1til each task represet1ts a m:uu.geable amotmt of wort that
can be planned, schedtded, and assigned. Some experts advocate decomposing tasks until the tasks represent an amotmt of work that can be completed h1 two weeks or (es,.
Ultlmately, tl1e project maooger will detennlne the level of detail in the outline;
however, most system developmet1t methodologies decompose phases for you- lnro
suggested actfvitles and tasks. These actl'\oitles and msks are 11ot necessarily car,l!d in
stone~tl1..1r is, most methodologies aUow for some addition, deletion, and changing of
acmities and tasks based on tl1e unique nature of eacl1 project. One popufar tool used
to Jdet1tlfy an d doatn1et1t project acthitles an d tasks ls a work breakdown structure.
A work breakdown s tnictu re (WBS) is a hierarchical decomposition of the ptoject
h1to pl1..1ses, actl'\oitles, an d tasks.
•up,:bkd ILlld ltY~cd by Doriald H. Plutnbd; P,o,{Ndi(.ily ,llatM&f:l#fflt: KININtS Proj«t ,llRnafFl#ff# App,o,ubfo,
S)'lllWU lkt'l'kpNW#I 03otton: ~ Inc.,
1~9'). 22:,
Projoct Managomont
STATtMEHT Of WORK
I.
II.
Ill.
ll\Jrpose
Bacl(graund
A. Problem, opportunitY, or directive statement
8. History leading to pioj ect request
C. Prtject goal and obj ectives
0 . Product description
Scope
<rw:io« h ~ ol N: inJorm.,,;on ¥1Cm b.ildris bbcls)
A. Stakeholders
IV.
B. Knowledge
C. Processes
0. Communications
Project Approach
A. Route
8. Deliverables
V,
MancQerial Approach
A. Team-building considerations
8. Manager and experience
C. Training requirements
0. Meeting schedules
E. Repating me1hods and frequency
VI,
!=. Conflict management
G. Scope management
Cc:ns1raints
A. Start date
B. Deadlines
C. Budget
D. Technology
VII.
Ballpal( Estimates
A. Schedule
B. Budget
VIII,
Cc:nditions of Satisfaction
IX
A. Success criteria
8. Assumptions
C. Risks
Appendixes
Work breakdown structures can be drawn usfr1g rop-down h.ierarchy charts similar to organization charts (Figure 4-6). In ~Ucrosoft Project, a WBS Is depicted using a
simple outline style, Indentation of actl>itles and tasks on the Gantt d1art">iew" of the
project. ~Ucrosoft Project also offers a military numbering scheme to represent hlerarcblcal decomposition of a project as follows:
I. Phase I of the project
I.I Actlvlty I of Phase I
I. I.I Task I of Actlvity I h1 Phase I
I. I. 2 Task 2 of Actlvlty I h1 Phase I
12 Actlvity 2 of Phase I .. .
2. Phase 2 of the project . . .
If you reexamllle Figure 4-3(a), you will notice tlut ~Ucrosoft Project pro>ides a
column for the WBS in the Gantt chart. Also notice lts use of the Indentation and
numbering ro dtfferentlare between tasks and subtasks.
chapter Four
131
FI G URE 4 -S
An Outline for a
Statement of Work
132
Part One
FIGURE 4 - 6
A Graphical Work
Breakdown
Structure
1ho Context of Systems Dowlopmont Projom
-
•
•
•
•
•••
milesto-ne an event signify.
ing the completion of a major
project deliverable.
\X'e may want to lnclude In a WBS specL1l tasks called milesto nes. 111e.se are
events tl1..1t sJgnlfy the accompUsbment or completion of major deliverables dwing a
project. In lnforllllltlon systems projects, an example of a milestone might be the completion of all the tasks assodatoo with producing a major project deUverahle su:h as
a requirements statement (see Chapter 3). It might be usef,tl to dlstlngulsh milestones
from otl,er tasks In a WBS by \Lqng special formattlng, such as Italics.
> Activity 3-Estlmate Task Durations
Gh,--en a work breakdown structltte wJd1 a suitable level of detail, the project man.1ger
must estimate duration for each task. Duration of any task ls a random '\o'a1'L1ble subject
to factors such as the size of the team, number of users, avalL1bUity of users, aptitudes
of users, compJexJty of the business system, lnfonnatlon technology an:hitecrure,
experience of team personnel, time commltted to other projects, and experience
with other projects.
Most system development methodologies not only define tasks but also provide
baseline estimates for task duration.T he project manager must adjust these baselines
into reasonable estimates for eacti unique project.
In Mlcrosoft Projec~ all pltases, actlvltles, and tasks of a methodology are sinply
called tasks. The work breakcbwn structure thetl consists of both summary and
primitive tasks. A su.1n1nary task is one thar consists of other tasks (sud1 as pltases
and actJvltles). Aprltnltive task ls one that does not consist of any other tasks. Ir is
the prlntltlve tasks for whlch the project manager must estlmate duration. (Uke most
project management software, )ticrosoft Project will auromatlcally calntlate t11e duration of a U summary tasks based on t11e estimated durations of their component
prlntltlve tasks.)
Projoct Managomont
133
chapter Four
for those prlmitlve tasks tl1at are not milestones, we must estimate duration. In
e.stlmatlng task duration, ft ls lmportant to underSland the concept of elapsed titne.
Elapsed time takes into consideration two important factors with respect to people:
Effe.ctency- No worker perfonns at 100 percet>t efficiency. Most people take
coffee breaks, lw1cb breaks, restroom breaks, and time ro read their e-mail,
check their calemlars, participate In nonprojed work, and even engage In
k:Ue conversation. Experts differ on Just how productive the average w orker
Is, bm one commonly used figure Is 75 percent.
Jnterrupff-011s- People experience phone calls, visitors, and other unplanned
Interruptions that increase the time requlred for project work. Tills Is variable
for dtfferet1t workers. Interruptions can consume as little as 10 percent of a
worker's day or as mud1 as 50 percent
Why is tills important? Gh-etl a task that cotdd be completed In JO hours with 100 percent efficiency and no interruptions, and assuming a worker efficiency of 75 percent
and 15 percent Interruptions, the true estimate for tl>e msk wo,dd be
10 hours+ 0.75 efficiency = 13.3 hours+ (1.00 - 0.15 interruptions)
= 1S.7 hour..
There are many techniques for estimating task du.ration. For the sake of demonstration, we offer the following da~Jc technique:
1. &tlnUlW the nJl11:l1n·u111. m11.o·u nt of tlttie it tiould take to perfortn the task.
\Xe'II call this tl1e optimistic duration (OD). Toe optlnllstlc d uration assumes
that even the most llkeJy interruptions or deL1ys, such as occasJonal employee
Uk1esses, will
1J.ot
happen.
2 . &tlnUlW the nUlXf.n1.·u111 aniou.nt of tltne It 1io·11.ld take to perjbr,n the task.
\Xe'II call this tl1e pesslmlstlc duration (PD). 111e pesslmlstic duration
a!Sumes tl1ar nearly anytlling d1at can go wrong will go wrong. All possible
lnterruptlons or delays, such as L1bor strikes, illnesses, inaccurate spedfication
ol requirements, equJpmetll delivery delays, and underestimation of the system's complexlty, are assumed ro be lnevJtable.
3. l!sttmate the expected duration (ED) that will be needed to perform the
tr.sk. Don't Just take the median of tl1e optlnllstlc and pesslnllstic durations.
Attempt to Identify interruptions or delays tl1..1r are most Ukely to occur, sud1
a! occasional employee illnesses, Inexperienced perso1u1el, and occasJonal
tnlnlng.
optimistic duration (OD)
the estimated ninimum
amount of time needed to
complete a task.
pessimistic dur.uioo
(PD) the estim:tted maxi.
mum amount of time needed
to complete a task.
expected duration (ED)
the estimated amount of time
required to com 1,lete a task.
4. Calculate the in05t llkcJy d,1ro.tloJ.l. (Dh as foUo ws:
D = (I XOD) + (4XED) + !l XPD)
6
'\\i1ere 1, 4, and l are default weights used to calculate a weighted average of
the three estimates.
Developing OD, PD, and ED estimates can be tricl-y and require experlet1ce. Se,•.
eral techniques are used in estlmatlng.11vee of the most common techniques are:
Decomposition- a simple technique wherein a project Is decomposed into
small, manageable pieces that can be estimated based on lllstorlcal data of
past projects and slmllarly complex pieces.
COCOMO (pronow1ced like "Kokomo")-a mode~>ased tedmlque wherein
standard parameters based on prior projects are applied to the new project
to estimate duratio11 of a project and its tasks.
Fu.11ctlo11 pot11..ts- a model-based tedulique wherein the ..end product• of a
project Is measured based on munher and complexlty of Inputs, outputs,
files, and queries. The number of function pohlts Is then compared to pro~
ects t11ar had a sim1L1r number of ftmction polnts to estlmare duration.
most likely duration (D)
an estimated amount of time
required to com 1,lete a
task,
based on a weighted average
of optimistic, p9SSimistic, and
expected durations.
134
Tho contoxt of Systoms Dovolopmont Projocts
Part one
Some automated project management tools, such as CS/10000 and Cost•)fperr,
pro,ide expert system technology that =es these estimates for you based on your
answers to sped.fie questions.
Milestones (as defined in the pre,ious subsection) have no duration. They simply
happen. In Microsoft Projec~ milestones are designated by setting the duration to
zero. (In the Gantt chart, those zero-du.ratio11 tasks change from bars to diamonds.)
>
Activity 4-Specify Intertask Dependencies
Gfve11 the duration estimates for all tasks, we can now begin to develop a p roject
schedule. The project schedule depe11ds 11ot only on task durations but also on Inter.
task dependencies. In other words, the start or completion of lndlvldual tasks may de-
pend on the start or completion of other tasks. There are four types of intenask
dependencies:
Fl1Jlsb-to-start (FS) - The 6.n.i.sh of one task triggers the start of another n.sk.
Start-to-start (SS)- The start of one task trlggers the start of another task.
Fl11ts/J.to-ft11isb (FF) - Two tasks mnst flnlsh at the same time.
Start to ft,1:lch (SP) 11le start of one task slgnJt'ies the B.nlsh of another t:lsk.
Intertask dependencies can be established and depicted In both Gantt and PERT
charts. Figure 4-7 illustrates how to enter intertask dependencies in the Gantt chart
view ln 1'iUcrosoft Project We call your attention to the following annotated bullets:
O
Intertask dependencies ma)' be entered In tl,e Gantt chart >iew In tl,e Prede-
cessors column by enterlng the dependent tasks' row numbers. Note. that a
task can have zero, one, or many predecessors.
Intertask dependencies ma)' also be entered ( or modlfted) by opening the
Task I1ifor111atlo11 dialogue box for a gtveo task.
0
!.!11:1'" !.• ~ ....... ~ 1.., ~ ~ I:!>'>
l) ~ Q Q Q':t ) Qia ft <'
'6 ~••• e::iv G *"wi
+ + + - , -. ....l
• 11 • " I JJ S! 8 •
t.1 1.dl>
_
..................
""-~~~~~~~~-·~o-==
-I-~'cc:c..f.:...fi:t:ic.!::i:......55~:.:t\
°".,,_.....
f '·f~;~~"~LL~...£
',,l..l..,,.
t ...
l l - - ~·_.,.....ci•-·
+· ,~....
--.
l':>~<1 <'6•··-~""'
- 1 11o_. ......,...
_,
Jl-"'N<u,•~-
..
J;.,,..._.,
:,
........
1,_.. ,._,
:
1mnmzm
='~7:: &--s=•·~~-:=-c"~~~~~~~~~~~~~~~,
1.-19
,,,..._.... ~ =i::11(1
:::==::. .~ii=·:r,,
,,_
J~NIII·~
..
, . ._
1y.,,o
,..,.DK_•_
l.
.,r
F I G U RE 4 • 7
Entering Intertask Dependencies in Microsoft Project
Projoct Managomont
O
O
Chaptor Four
135
The type of dependency can be entered In the Task lnformatton dialogue
box for any given dependent task.
Intertask dependencies are graphlcally lllustrat<d In the Gann chart as arrows
betweet1 the bars that represent each task. Arrows may begin or terminate
on the left side (to lndlcate a • start• dependency) or right side (to lndlcate a
'finlsh" dependency).
Miiestones (as defined earller) almost always have several predecessors to signify
those tasks tli.1t must be completed before the mUeslone has been achJeved.
Given the start date for a p roject, the tasks to be completed, the task durations,
and the lntertask dependencies, the project can now be scheduled. There are two
app~,aches to schedt~lng:
Fonvard sched,1.Utig establishes a project start cbte and then sd1edules
btward from that date. Based on the plaimed duration of required tasks, their
Interdependencies, and the allocatlon of resources to compJete those tasks, a
projected project completion date Is calculated
Reverse scheduling establishes a project deadline and then schedules backward from tl1.1t date. 'Jasks, tl1elr duration, lnterdependendes, and resources must
be con.sldctcd to
that the project cun be completed by the deadline.
<'·t lStlt<'
Each task can be given its own start and finish dates. Uke most project nw1..1gement tools, Mlcrosoft Project actually builds the schedule for you as you enter the task
d urations and lntertask dependencies (predece~ors). On the Gantt chart, the task
bars are expanded to reflect duration and shifted left and right to reflect start and e11d
dates. ~ticrosoft Project can also produce a tr.tdltlonal calendar view of the final
schedtde, as shown In Figure 4-8.
}4i'.I C,. (Ill »..... II-' f'IJIW
I Dll r;i, ii <!I~~
..
_
~ e,q,t ~ " '
o.r.~
-\
.... J
'
N
tz
'
~4'
I"
-
_
..............
ii-,sdot
..
•
..
n
Ht,11•
---"'-"'-
j
·-..
·-••
"
F I GU R E 4 • 8 The Project Schedule in Calendar View
w
forward scheduling a
project schedul hg approach
that establishes a project start
date and then schedules
forward from thtt dale.
reverse s<'.lle<1Uli.Og a
project schedulhg strategy
that establishes a project
deadline and then schedules
backward from tlat date.
136
Part One
1ho Context of Systems Dowlopmont Projom
>
REPRESEMATIVI:
ROLES IN A
PROJECT
111e pre"ious steps resulted ln 'a" schedule, but not "the" schedule! \X'e have yet to
consider the allocation of re.sources to the project. Resources include the following
categories:
Aud~or
Business AruJ:,st
Business SubjlCI Matter
.People- includes all the system owners, users, ai1.alysts, desJgners, builders,
external agents, and clerlcal help that w ut be Involved In the p roject In
any way.
Servlces- lndudes servic es such as a quality revJew that may be charged on
a per-tlSe basis.
Facflltf.es and equ.q,ment- lndudes a ll rooms and technology that will be
needed to complete the project.
Supplies and materials- Includes everything from pencils, paper, and notebooks to toner cartrJdges, tnd so on.
,lfo,wy- indudes a translation of all of the above into budgeted dollars!
Expert
Database Admnistrator
Executive Sponsor
Information S)'Stems
Manager
JAD Facil~ator
JAD Scribe
Management Sponsor
Network Administrator
Programmer
Project Manag3r
System Modelir
Activity 5-Assign Resources
111e availability of resources, especially people an d faclll ties, can slgnlllcantly alter tJ,e
project sched,de.
Most system development methodologies Identify people resources requlttd for
each task in the form of roles. A role ls not the same as a job tltJe.Thlnk of a role as a
..hat" that someone wears because he or she possesses a certain sklll(s). Any given lndlvldual may be capable of wearing many hats (thus playing many roles) . Also, many
people may possess tJ,e skills re:iulred to play a given role.11,e project manager's task
is either to assign speclflc people to fl Uroles or to gain commitments from manageme11t to pro,ide people to fill roles. Representative roles from tJ,e FAST methodology
are listed In tJ,e margin .
In ,_Ucrosoft Project, roles and assignments are speclfled in the Resou.rce Sheet
view, as shown In Figure 4 .9(a). Predefined roles and resources may be avallahle in tJ,e
chosen methodology and rotne temp lates.
0
11,e project manager entets tJ,e names or tides of people (rotes) In the
Resou.rce Na-,ne column. Re.sources may also include specific services, facilities, eqtdpment, supplies, materials, and so for th.
€) Notice that the Resource S>eet pro,ides a column for establishing what
percentage of a resource wUJ be allocated to the project. For ex.ample, a
database admlnlstrator ndght be allocated one-quarter time (25 percetll) co
a project. Allocations greater tl1..1n JOO percent indJcate a need for more
than one person to fi ll a given role In tJ,e project. By serting Ma.-.. Units to
250 percent for that resource, there would be a need for the equlvaletll of
2)1 full-time programmers.
O Project also allows the project manager to estimate the cost of ead1 resource.
These costs can be estimated based on company h.Jstory, consulting contr.J.cts,
or lnten1al cost accounting stan dards. Notice d1at both standatd and overtime
costs can be estimated. T hese costs are usually based on stan dards to pro1ect
Information about anyone'! actual saL1ry.
O Each resource has a calendar that considers the standard worJ.."Week and
holidays, as well as indJvid.lal '\o-:tcatlons and other commltments.
Givet1 the resowces, they now can be specifically a~Jgned to tasks, as shown in
Figure 4.9(b). As resources are assigned to the tasks, the project manager wo,dd specify the units of that resource that will be reqttfred to complete each a~Jgned task.
(fhls may be a percentage of a person's time needed for that tasl<.)
As these resources are formally assigned, tJ,e sd1edule will be adjusted (which
happetu automatically in tools such as Project). If you enter the cost of re.sources,
tools sud, as ~Ucrosoft Projec1 will automatically calctdate and maintain a budget
based 011 the resources and schedlde.
Projoct Managomont
"' v.,.
•
41
"' ' l '!
CJ~ 13 Ill 111 «! 111
-~- ·-- --·~ ...... ... .......·-...-··~--.. -·-·-·-·~ ...... - -. . ..·---.......
....
-...
......
.....
---__
....
_
,
..
..
--- s.- - -··~~ II)~--~ s•••-
s......,;;,,,,-...
&
s,-°"""'
,,$,.... ~
E$.:>.1'411)(;',l(,o
~
,,
-...-;_..;.oii,,;..
,,_......
,,_,....,,
.......
e,-.u...
~
:,-
.............-.o(o)
""
'""
""
""
""
.......
.,,_,,...,.
'"'-"'",...
<.lt.,.Uu( •I
..,.
,....,.
,,s,nn_ld"'
~-,~
: 1- .NWAI
s,- -...
;,..,°""'.,.
""''''
"r..,..-1;1,1~
--·
-·o.-
,,...,llflV'O
s, ....e.._
-..chi.-
,,..,...ca,_
""'"'"°''fff.Nl4\M
,,
OAW<...0"1'1(9-•
$,_,..,..
.....,_,.,
"'
w
;,
·"""""'~
s,-o...,.
• 7•
C) "'""I
,)J,x:,,,
.,.
IIJ.((11•1- ......
C>
IOtOI • - -
.,.
....
ltll'J.1'1(11.
..,
""''
toCIQt• ·-•w
"'""
w-
..,
Jli.lQI•
ft WotM<i'! ~
l ·S• -
0
...
ll.o.l'Wotl-11"
,.,_..,
~
~
J"O
h .,
taioooi,
.,,
""'' """"
,,,_
"""'·I
t)(il)I , f'l\1,-
-""'"'·A,)'IN(I " '"
··-....
'"- ' ""''!""""
·_.....,...
,,,....
ll:lto1•1
"
""'°'
.,,....
''"'"
,NW•
l(lO!ll o flo'<)-
IIJaot, _ _
1'!,1)00,,1
,;,o:,,, llr(i,IIJOOI• ~
IO).o)l,1~-
..,
MOOO! o "'""-
ffltcl' • - -
tmrot• -·116
t).00, , llr(,-
..,
$,_..._.
s,_.._
C"or,o<tv ......,•
......-...
""''
..,,,,_
....
$!$,)(IOI,
-.:, ......
,,s,~e..-
_ .,.:fflil:...
,
l"fMo<o"'°'3'·-
i,a,,...
""
""
••
.,,.
St '*10ett,O
,._,.,,,,.._
~-••P
.....-.
t(I.O::,, , iw,....,
~~o:ti,
__
.....
....
..,....
""'·1-~·-·-__
.......
"
~f--....
....
-.. .....~-1
'"
s, .....r .."""'
137
Chaptor Four
IO.tOh -
11)(1)1•1~ ...,,.,
IOOOt• ....,._
'"'
~
A(o)ri(I'. . . .
....,
·.....
--·-. ...-........'°'*
j-~
-·
·-b.,.....,
A"""'Ct-•"""
/1'-!lq, °to
•I
,....
(a)
-
-....!.-__
·--
------
-
------=-- ----·-- ,;,;.____
IJll![.lEl
-
-
• • + -
~1...::.1
. 1•• • •. . . . . . . . . •.• •. . .• . .•. .';,.;;
• ..:1..
:.il i;;;.."..1'. .'•i•i........1.·.~••~ - -- - - - - - - - - - - - - - -
frilcr,o Oii y.... ~ t'IJnol i - e,.,.it ~ tM>
Oll ~ lii e~~ ).Ch.e-c1
-,...- - • ioe:iv e ~a~ · ~co
~.,._.rrqif.__.__
,,• ......_.
ll~N-'<l.v,cl~
11c.,i.tu•.........._...,__• f l ~
'9'$,C.,...,,
):)1.t, ... ,,__..,....,
j
1, _ _ _<olcoryomf
11)
II
H
~ -· ~
-
. .. .
tot
-·
,. ,_,...._ . .....__
,•tu..-,....,...-w,
S$~t•h,.......,
. .!l
( b)
( F I G U R E 4 • 9 !Jenning and Assigning Project Keso=es
·I
,....
_____
)
138
Part One
1ho Context of Systems Dowlopmont Projom
Assigning People to Tasks Recruiting the righr ream members can make or break
a project.Toe following are guidelines for selecting and recntlcing the team:
Recruit talented, highly motivated people. Hlghly skilled an d mowrated team
members are more likely ro overcome project obstades unaided and are
more likely to meet project deadlines and produce quality work.
Select the best task for each person All worl<ers h.a>'e strengths and weal:.
nesses. Fifectlve project nunagers learn to explofr the strengths of team members and avoid assigning rasks to ream members nor skilled ht those areas.
Project managers should select ream members who
will work well together.
Plan for the Ju.r,,re. Junior personnel with potential to be mentored by pro~
ect leaders must be considered. Although Junior perso,mel mlgh.t not be as
productive as the seasoned veterans, project managers wUJ need them and
ha>'e to rely on them on fu ture projects.
Keep the teatn size stna/1. By Um.iting the team sJze, communication overhead
and dltncttlcies will be reduced. A i.person team has only I communlcacion
path~a 4-person team has 6 communication paths~and a 50,person team ltas
at least 1,200 communication patl1S.111e more commwlication paths thett are,
the greater the probability d1at ti1ere will be Increased commwllcatlon prob.
Jems. By the same toket1 the teams should be L1rge enough to provJde adequate bacl.'Up and co>'eragi, In key skills If a team member ls lost.
Protnote tean1 bart1101i)i
So far, we have idet1tified tasks, task duratlo11S, and intertask depet1dendes and assigned resowces to each task to produce the project schedule. It ls
commo11 to overallocate resources whett assJgili..ng resources to tasks. Overailocate
refers to the act of assigning more resotirces t11.1n are available.
For example, d uring a speciflc period In ti1e project (day, week, etc.), a project
manager may have assigned a sped.fie person to work on multiple tasks that add up to
more ltours tl1.1n the person has available to work during that period.Th.is renders tl1e
overall schedule lnfeasible because tlte overallocated resotirce cannot reasonably
complete all assigned tasks according to sched,tle . To correct tills problem, project
managers must use a technique called resotirce leveling. Resource levellog ls a strategy used to correct resource overallocatlons by some combination of deL1ylng or
splltullg tasks. Let's briefly exphlt1 botl1 approad,es.
Delaying tasks Is based on the concepts of crlttca/ path and slack time. When It
comes to th e project schedule, some tasks are more SetlSJtive to schedule delays tlt.an
others. f<>r tlll.S reason, project managers muse become aware of tbe crJcJcal path for a
project.Toe critical path for a project ls the sequei,ce of dependent tasks that ha>..
the brgest sum of most likely tf•ratlo11s. T he crltlcal path determines the earliest pos.
slble complecion date of the project. (We pre>'lously described h.ow to estimate most
likely duration for a task.) Toe critical path tasks ha>.. no st.ck ume av.,Jlable- thus,
any delay In completion of any of tl1e tasks on the critical path wUI cause an o>'erall deby 1t1 the complecion of the entire project.111e opposite of a cricical task ls one that lllls
some slack time.The s l ack time a'\o-ailable for any noncritical task is tl1e amount of deby that can be tolerated between the starting tlme and the complecion cime of a task
wlthouc causing a delay ht the completio11 date of the entire project.Tasks that have
slack tlme can get behind sd1edt~e by an amount less than or equal to tJ,e slack tlme
without h.a>'ltlg any Impact on the project's flnaJ completion date.T he a...UabUity of
slack tlme In certain tasks pro,ides an oppor tunity to delay the start of the tasks to
level resotirces whlle not affecting tlte project completion date. Of course, It miy be
necessary to delay a crltlcal path cask ro level resources, unless you can split the task.
Splitting tasks ln>'ol>'es breaking a task Into mulciple tasks to assign alternate
resources co the casks. 111us, a slngle cask for wh.lch a resource was overallocated ls
now apportioned to two or more resources tl1.1t are (presumably) not o,-erallocated.
Splltcing tasks requires Identifying and assigning new resources such as analysts,
contractors, or consultants.
Resource Leveling
r esource 1e,·elitlg a strat·
f!!Jf for correc.1ng resource
overallocations.
critical patb the sequence
of dependent 1aSks that deter.
mines the earliest completion
date br a project.
slack time the amount of
delay that can be tolerated
between the s:arting time and
the completior,time of a task
'Mthout causirg a delay in the
completion da-.e of a project
Projoct Managomont
chapter Four
139
Resotirce JeveUng can be tedious to perform manually. For each resotirce, the
project m.uuger needs to know the total time a'\<-:tlL1ble ro the project for the resource,
all task assignments made to the resource, and the snm of all durations of those task
asslgnments o,--er various time periods. All project ma.n.1gement software roots, such as
~Ucrosoft Projec~ automatically detennlne critical paths and slack tlmes.11lls enables
tl1ose same software tools to track re.source allocations and automatically perform
resource leveling. It Is extraordlnarily rare for any modem project manager to manually
level resotuce assignments.
Resource le,--ellng will be an ongoing act:l\oity because the schedule and re.source
assfg11met1ts are likely to change over the course of a project.
Schedule and Budget Gtven a schedule based on leveled re.sources and givet1 the
cost of each re.source (e.g., cost per hour of a ~·stems analyst or database administrator) the project manager can produce a printed (or "X'eb-based) document that commwlicates the project plan to all concerned parties. Project management tools will
provide multiple '\oiews of a project: such as calendars, Gantt d1..1n:, PF.RT d1..1rt, resource and re.source leveling reports, and budget reports. All that remains ls to direct
re.sources to the completio11 of project tasks and deliverables.
Conwnunication The statement of work, timetable for major deliverables, and overall project schedule should be commtmlcated to all partles Involved ln tl1e project.
Thls communlcatlon must also lndude a pL1n for reporting progress, both orally and
in writing, the frequency of such commwlications, and a contact perso11 and metltod
for parties to submit feecll>ack and suggestions. A corporate Intranet can be an effective way to keep everyone lnformed of project progress and issues.
>
Activity 6-0ired the Team Effort
All the preceding project management activities Jed to a master plan for the project.
It's now time to execute that plait. TI1ere are several dlmettsJons to directing the
team effort. Tom Demarco states In his book The Deadll11e: A 1\fovel abo,,t Project
,lfanage1ne11t t11..1t the hardest job ln management is people.
Few new project managers are skilled at supervising people. ~tost: learn supenision tbrough thek own experiences as subordh1.11es- tlllogs they Uked and disliked
about those who supenised them. Thls topic could easily take up an entire chapter.
In the margin checklist, we provide a classic list of project supenislon recommendations from 1'be People Side of Systems, by Keith London.
AS 11oted by Graham !\tCLeod ai1d Derek sm1t11, Mh1dJvJduats brougJ.1t together itt a
systems development team do not form a dose-ktlit unlt immediately." ~tcleod
and Smltl1 explain that teams go tltrougb stages of team development, as shown In
Figure 4-10.
In The One ,lft1,uJe Afan.age,; by Ketu1eth Blanchard ai1d Spei1cer Johnson, a
classic and Indispensable ald to anyone managing people for the first time, the authors
sl1..1re the simple secrets of mai1..1glng people and adlieving success through the
actions of subordinates.
Most young, and many experienced, managers have dlftkulty with the subtle arts
of dtJegatlon and accolUltabiJity. '\X'orse still, they ltt subordinates reverse-delegate
tasks back to the mai1..1ger. This leads to poor tlme m:.u1..1gemei1t ai1d mai1..1ger frustratlo11. In The One All11u.te Alanager Aleets the ,lfo1ikey. Kenneth Blanchatd teams with
Willhm Oncken and Hal Bttrrows to help managers overcome this problem. The
solution is based on Oncl::ei1's dasslc prlncJple of"the care ai1d feed.Jog of monkeys."
,_lonkeys are "problems" that managers delegate to their subordinates, who In turn
attempt to reverse-delegate bad:: to t11e mat1..1ger. In this 125-page book the authors
teach mai1..1gers how to keep t11e monkeys on the subordlnates• backs. Doing so
increases t11e manager's aYailable work tlme, accelerates task accomplishment by
subocdlnates, and teaches subord.J.nates how ro take rtsponslblUty and solve their own
problems.
10 HINTS FOR
PROJECT
LEAOERSHIP
Be Consistent
Provide Sup!X)rt.
Donl Make Promises You
Can't Keep.
Praise in Pub1ic~ Criticize in
Private.
Be Aware ol Morale Danger
Points.
Set Realistic Deadlines.
Set Perceivatle Targets.
Eicplain and 91ow, Rather
Ttun Do.
DonlRely Just on Status
Re!X)rtS.
Encourage a Good Team
Spirit.
140
Part One
1ho Context of Systems Dowlopmont Projom
OAENTATION STAGE
FIGURE 4 - 1 0
EStaibltsh struch..n and rulQ.s
c11rny team memt>er relatlonshlps
Stages o f Team
Ma turity
FORMING
ICklntny resp.ons1:11a19s
oevel·OP a ptt1n toaCNeve goals
Sovre~: Ad.apt:4 fio111 Olllblon:I
McLeod Olld lntU Siaitb.
Jl,nr,1llllg l"fo,1111itirM Ttclisot.
oo Proj«ts l'('.-bd• MAt
Covne. T~ lulology. 1996).
INTERNAL PROBLEM-SOLVING STAGE
Re&Olve 1nterparsont11 conn1ct
Further clarffy Nits and goats
Oevel·OP a partk:fl:titrve cnmate
STORMING
GROWTH AND PROOUCTIVITY STAGE
Direct toam a,ctlvtly towaro goats
Provtde and oet reecJbe·Ck
NORMING
snare raeas--grONlng cOhQ.sron
lnelvtdu81s real
gc,.oa 81:>out ea·ch other
EVALUATK)N AND CONTROL STAGE
•
•
•
More ,aoClb8Ck and eva1uat:1on
Adherance to tQflfll norms
Roki-s ot team strEngthened
PERFORMING
• Strong team motrvauon to share g08's
>
Activity 7-Monitor and Control Progress
Whlle executlng the project, the project manager must control the project, that ls,
monitor its progress agaitlSt the scope, sd1edule, and budget. TI1e manager must
report progress and, when nectssary, adjust scope, schedlde, and re.sources.
Progress Reporting Proe:res! reportine: should be frequent enouel1 to establish accountability and control, but nor so frequent as to become a burden and lmpedJment
to real project progress. For example, Keane, Inc., a co11Stllting firm, recommends that
progress reports or meetings occttr e,-eC)' two weeks- consistent wlth the firm's
project-planning strategy that decomposes projects into tasks that produce deliverables that require no more than 80 work hours.
Project progress reports can be verbal or wrltte.11. Ffgure 4-11 Ulustrates a
template for a wrftten progress report.. Project progress reports ( or preset1tations)
should be l1onest and accurate, evet1 if the news ls Jess than good. Project progress reports sholdd report successes but sholdd dearly Identify problems and concen1S such
that they can be addressed befae they e.scaL1te unto major Issues or catastrophes.
As tasks are completed, f"Ogress can be recorded in Microsoft Project (see
Agure 4-12). We call your attention to the following Gantt progress Items:
O All the tasks in the preliminary lnvestlg,1tlon phase are complete as Indicated
0
by the yellow lines that run the full length of each task bar. Notice that
because all these tasks are complete, they are no longer critical- the bars
have changed from red to blue.
In ti,e problem analysis phase, only the first task, •Analyze the current
system," ls 100 percent complete.
Projoct Managomont
PROJECT PROGRESS REPORT
chapter Four
FIGURE 4 - 11
Outline for a
I.
Cover page
A Project name or identificatio n
B. Project manager
C. Date of report
II,
111.
Summaiy of piog-ess
A Sched..Jle analysis
B. Budget analysis
C. Scopeanalysis
(descnbemy~lhdtrNJYMie«1imp:r.tanluhrep-ogess)
D. Process analysis
(cies-<Y>')'pcbkmsencounttnxl..;tl,stnteyyamdl,odohsY)
E. Gantt progress chart(s)
l\ctWity analysis
A Tasks completed since last report
B. current tasks and deliverables
C. Short-term Mure tasks aid delt.'erables
IV,
V,
Prcviou~ µroule111~ di KJ i~~o
A Action item and status
B. New or revised action items
1, Rec:ommendaticn
2. Assignment of responsibility
3. Deadline
New problems and issues
A Problems
(O<t1/olor""6dpo/od)
B. Issues
(O<t1/olor""6dpo/od)
C. Possible solutions
VI.
1, Rec:ommendaticn
2. Assignment of responsibility
3. Deadline
Attachments
(induderdewmtpintoutslromproject~ntsdtwtn)
O Notice that the .. Eslabllst1 system lmprovement objectives" task bar has a par-
O
0
tial yellow Une running 60 percent of Its length. This Indicates the task Is
about 60 percent complete. 11,e task bar Is stlli red because any delay In
completing the task will tlveaten the project completion date.
All remaining tasks shown In the dlspfayed chart ha>.. not been started. Actual
progress will be recorded when the task ls staned, In process, or completed.
Progress for any given task is recorded h1 the ttsk Information dialogue box
for that task. In thls example, the project manager ls recording 10 percent
completion of the named task.
~Ucrosoft Project also provides a number of preconfigured and customizable reports
tl1..1t can pre.sent useful project status informatlo11.
Change Management It ls 11ot w1commo11 for scope to grow out of control e,--en
when a properly completed statement of work was agreed on early in the plaiuling
process. '\X'e refer to scope growth as ..cbange." As noted by Keane, lnc.,"Change is fre.
queotJy a point of contentlo11 between the customer and the lnformatlon systems organ.il:atlon, because they disagree on whether a particular ftmctlon is a d1ange or a
part of the Initial agreement."The inel-itablUty of scope d1..1nge necessitates that we
have a formal strategy and process to deal with change and its impact on schedule
141
Progress Report
142
Tho contoxt of Systoms Dovolopmont Projocts
Part one
,i,,.
ltl ~ ,_, "I,-
t,oll
e,.,.., ~ -
t,llt
o ~ g & Cl :f j Q:i ec • -. • <#-<• av tz
•o..-.o
ii
1,11oo1,
_ .....,...,,,,,,.,,. _
• $
-·
,1........,..-..
_
"
•
t
11
&. •
• -
4i,,.
l:! 1" " " ' -
,,_....
·~-,--
•• -
....... II<_ _ , . ,
})~·-·--""'-
;·,--.e................_
., • .ll.!!.-
......,"'__ -
.............
.,
,...,".
·:,,~-IO(W---·
~-·1..
.111_..
~
I "-'- I ~--- l
l••,e,~,ardre< ..,~
eµ-
r,,-~
..,
~
O
Ol,lu
~h , _
lfl<,'01
.•J
- . :,
- - - - - 1~
I
"'-'tMI
~~
r~
r;;;--..J
6',tl,c j Fol ~
I
.:I
••~. .~ - t l• ,)oo(l ..:,W(!I
--
~''-"'* ___ "'__
~C.,.,,.hoo....-.--..
....
...~
................................
~,-~-..._,;..-,
~,~
.L.~..._
.f'
C
- -- - - - - - - - - F I GU R E 4 • 1 2
cbaage maoagemeot a
formal strateQ!' wherein a
process is established to
facilitate changElS that occur
during a project.
Progress Reporting on a Gantt Otart
)
and budget. Cb.1.0.ge ma11ageme11t is intended to protect d1e project manager and
team from being heJd accow1table for schedule and budget overruns tl1at were driven
by changes In scope.
01aoges can be the result of various e,-ents and factors, lndudlng:
An omission In defining lnl!W scope (as documented In tl1e statement of work).
A mlsunderstandln1t of the Initial scope (the desired product Is more complicated than originally commwllcated or perceived).
An external event such as government regulations that create new
requlremenrs.
Organizational changes, such as mergers, acquisitions, and pannershJps, that
create new busine.s., problems and opporrw1Jtles (not to mention "players"),
Avalfablllty of better technology.
Shifts In planned technology that force unexpected and slgnlllcant chatll!l'S to
the business org;ulizatlon, cultttre, and/or proc~es.
1'ilaoagemenr's desire to ha\--e the system do n1ore than was orlginaUy
requested or agreed ro.
Reduced funding for the project or Imposition of an earlier deadline.
A change management system results in a collection of procedures for docume11tlng a change request and defines the steps necessary to consider the change
based on the expected lmpact of tl1e change. 1'ilost change management systems require rhar a change request fotm be lnitiated by one or more project stakeholders
(e.g., system owners, users, analysts, designers, or buliders). Ideally, cbange requests
are considered by a cba11ge co11tro/ board (CCB), which Is responsible for approving
or rejecting all change requests n,e CCB's composition typically Includes members
Projoct Managomont
chapter Four
143
of the project team as well as outsiders who may have an lnterest or stake In the
pro)ect. 11,e CCB's decision sho,dd be based on Impact analysis.
Feasibility Impact analysis shotdd assess the Importance of the change to the business, the Impact of the d1ange on the project schedule, and the Impact of the d1ange
on the project budget and long-term operating costs.
Ultimately, change management bolls down to managing the expectations of the
stakeholders. In the next section, we lntroduce a simple but conceptually sound framewort for managing expectations and d1elr impact on project schedule and budget.
Expectations Management Experienced projec1 m:u1..1gers often complain tl1..1t
matuging $)'stem owners' and users• expectations of a project ls more difficult tl1an
managing cost, schedtde, people, or quality. In this section we Introduce a simple tool
tl1..1t we11 caU an expectations 111a11.agenie11t niatrlx that can help project m:u1..1gers
deal with this problem. We first learned about this tool from Dr. Phil FrledL1nder,
a consultant and trainer then with ltfcDonnell Douglas. He attributes the matrtx to
• folklore• but also credits Jerry Gordon, of Majer, and Ron Leflour, a project management educator/trainer. Dr. Friedlander's paper (listed In the Suggested Readings for
this chapter) Is adapted In this text for this presentation.
F.,"'P.r)' p1'njP.rt h:as ef\!l ls a n<I ron.<ttr:t ints. whpn fr rnmps rn ro...r, ~P.<lulp, r-ropP., :1nrl
quality. In an Ideal world, ead1 of these parameters could be optimized. Managemetll o~
ten h.,s that expectation. Reality suggests, however, that you can't optlmJze them allyou must strlke a baLmce tlu.t is both feasll>le and acceptable to managemenr.1bat ls
tl1e pwpose of the expectations management matrix. An expectations m.a.n..'lgemeut
matrl., is a rlde-drh,--en tool for helping management understand the dynamics and
impact of d1anglng project parameters such as cost, schedt~e. scope, and quality.
The basic marrix, show11 in Figure 4-13, consists of dvee rows and tlvee columns
(plu! headings).The rows correspond to the measures of success in any project: cost,
sd1edule, and scope ancVor quality. The colunuu correspond to prlorltles: first, second,and third. To establish expectations, we assign names to tl1e priorities as follows:
expectations
maoagemeot matri..~ a
tool used to understand the
dynamics and impact of
changing the pa-ameters of
a project.
Jlfaxf1nize or 1ni,if.tttf.ze- the measure of success that ls determined to be
the most Important for a given project.
Constrat,i-the second most important of the dvee measures of success ln
, project.
Accept- the least important of the three measl.l'es in a project.
Most managers wotdd, Ideally, like to give equal priority to all three measures;
experience suggests d1.1t tl1e three measures tend to balance them.selves naturall); For
cxample, lf you increase scope or quality requirement$, the project will take more tlruc
and/or money. If )'OU try to l!l'I any Job done faster, you generally h.we to reduce scope or
PRIORITIES
'
i
MEASURES OF SUCCESS
Sdle<fule
Scope and/or Quality
-+
Constrain
Accept
FIGURE 4 - 13
A Management
Expectations Matrix
144
Part One
1ho Context of Systems Dowlopmont Projom
FIGURE 4 - 14
Management of
Expectations for
the Lunar Landing
Project
PRIORITIES ..
Max or Min
Constrain
Accept
,MEASURES OF SUCCESS
c~
•
x
$20 bllllon (estimated)
Schedule
•
Dec 31, 1969 (deadllnei
Scope ond/0< Quality
•
Land a mnn on the moon
•
Get him back ,..fely
x
quality reqttlremenrs or pay mott money to compensate. The management expecta.tlons
matrix helps (or forces) management to understand this through three simple rules:
I. For any project, you must record three Xs within the nine available cells.
2. No row may contain more than one X. In other words, a single measure cf
success must have one and only one priority.
3, No column 1lL1)' contain m«e tl1an one X. In other words, there must be a
first, second, and third priority.
Let's Ulustrate the tool using Dr. Ftledlander's own ex.ample. In 1961 President
John E Kennedy established a m,jor project- land a man on the moon and return him
safely before the end of the decade. Figure 4-14 shows the reallstlc expectations of the
project. Let's walk through the example:
I. The system owner (tl1e public) had botl1 scope and quality expectations. The
scope (or reqttlrement) was to successfully land a man 011 the moon. The
quality measure was to return the man (or men) safely. Because the public
would expect no less from the new space program, tills had to be made the
first prlorJry. ln other words, we l1ad to maximize safety and ruinJmJze dsk
as a first prJorJry. Hence. ,,,.e record the X in column l. row 3.
2. Ar t11e time of t11e project's inception, the So"iet Un.ion was ahead in the race
to space. 1bls was a matter of national pride~ therefore, the second priority
was to get the Job done by the end of the decade. We call this the project
constraJnr- tl1ere ls 110 need to rush t11e deadline, bur we don't want to miss
the deadline. Thus, we record tl1e second X In column 2, row 2.
3. By defu,dt, the third priority had to be cost (estimated at $20 bUllon In 1961).
By malting cost the third priority, we are not stating that cost will not be con,
trolled. We are merely stating that we may ha,--e ro accept cost overrtms to
achleve the scope and quallty requlremetll by the constrained deadline. \XI,
record tl1e third X lo column 3, row 1.
History records thar we acb.ieved the scope and quality requirement, and did so
h1 1969. The project actually co,r well In excess of $30 billlon,more than a 50 percent
cost overrun. DJd thar make the project a failure? On the contrary, most people
perceived the project as a grand success. The government managed the public's
expectations of the project In realizing that maximum safery and minimum risk, plus
meeting the deadline (beating the Soviets), was an acceptable trade.off for the cost
overrw1. The government brUlhnt.ly managed public opitlion . Systems development
project managers can learn a valuable lesso11 from tills baL'lOciog act.
Projoct Managomont
chapter Four
14S
At the beginning of any project, the project manager should consider lntroduclng
the SJ'Stem owner to the exp«tations matrix concept ind st1ould work with the ~em
own,r to complete the llllltrlx. For most projects, It wot~d be dlflkult to record all the
scope and quality requirements In the matrix. Instead, d,ey would be listed In the statemenl of worl<.The estimated costs and deadlines cot~d be recorded directly In the matrix.
The project manager doesn't e.stablist1 the priorities; he or she merely enforces
tl1e rules of tl1e matrix. This sotmds easy, but it rarely ls. Many managers are tmwlllillg
to b( pinned down on the prlorlties- ..Shou.ldn't we be able to maximize every-
tlllng?"These managers need to be educated about the reason for the priorities. They
need to understand the priorities lf they cannot ma.xlmize aU three measures. Th.ls
lead, to Intelligent compromises Instead of merely guesswork.
What lf a system owner reftlSeS to prJorftlze?111e tool becomes less usefltl, except
as a mechanism for docttmentlog concenu before they become disasters. A system
owner who refuses to set priorities may be setth1g the project manager up for a no-win
performance re"iew. And as Dr. FriedL1nder points oul,..Those who do not''believe'the
prindples (of the matrix] will ew,11tually 'know' the o-uth. You do not h.ave to believe
In gn>ity, but you w!U hit the ground Just as hard as the person who does~
let's a~ume the management expectations mattix that conforms to d1e aforementlonEd t'ldes, How does this heJp :t project nun.ager U1.'UUge expectations? During the
cotme of the average systems de,--elopment project, prlorJtles are not scable. Various factors such as the economy, government, and company politics cut change the priorities.
Bu~ts may become more or le.s., constralned. Deadlines may become more or Jes, Important. Quality may become more important. And, most frequently, requlrements it~
cre:L<e. As already noted, these changing factors affect all the measures In some way. The
trick ls to manage expectations despite the e>-.r<hanging project parameters.
The tedulique ls relatively stnJghtforward. Wheaever the ..max/mln measure" or
the ..constrain measure" begins to slip, ft can result In a potential management expectations problem. For example, consJder a project manager who ls faced with the
following priorities (see Figure 4-15):
I. Explicit reqttlrements and quality expectations were established at the start of
a project and gh1'1l the highest priority.
2. Ao absolute maximum budget was established for the project.
3. The project manager agreed to sboot for the desired deadline, but tl1e system
owner(s) accepted the reality that if something must slip, it should be schedt~e.
Now suppose tlut d uting systems analysis, slgnllkant and tmantidpated business problems are Identified. The analysis of these problems has placed the project behind schedule. Ftuthennore, sol"ing the new business problems substantially expands d1e user
Constrain
PRIORITIES -+
' FIGURE 4 - 1 s'
A Typical Initial
'MEASURES OF SUCCESS
" Expectations Matrix,
Schedule
Sccpe and/or Qunllty
x
146
Part One
FIGURE 4 - 16
Adjusting
Expectations
(a sample)
1ho Context of Systems Dowlopmont Projom
PRIORITIES -+
Max or Min
Constrain
Accept
iMEASURES OF SUCCESS
requirements for the new system. How does the project manager react?There should be
no overreaction to the schedule slippage- schedule slippage was the •accept" priority
in the matrix.The scope Increase (in the form of se,. eral
.
new requirements) is the more
sfgnlJlcant problem because the added requJremenis will increase the cost of tl1e pro~
ect. Cost ls the constralned measure of success. As Jt stands, an expectations prd>lem
exists. The project manager needs to review tl,e matrix with the system owner.
First, the system owner needs ro be made aware of which measure or measures
are In Jeopardy and why. Then together, the project mai1..1ger and ~·stem owner can
discuss courses of action. Se,-enl courses of action are possible:
1
T he resources (cost and/or schedule) can be reallocated. Perhaps the system
owner can find more money somewhere. All priorities would remain the
same (noting, of course, the revised deadline based on sched,tle slippages
already et1counrered du.rint. systems ai1..1lysls).
T he budget mlght be lncrtased, but ft would be offset by additional planned
sched,tle slippages. For instance, by extending the project Into a new tlscal
year, additional money might be allocated without taking any money from
ex.Isling projects or uses.1tlis solution is shown in Agure 4-16.
11,e user requJremenrs (or quality) mlght be reduced through prioritizing !hose
requlremenrs and deferrlng some of those requlremenrs until ,--ersJon 2 of the
system. 'Thls alternative would be appropriate if the budl!l't cannot be Increased.
Finally, measurement priorities can be changed.
Only tl,e system owner may inlliate priority d1anges. For example, the system
owner may agree thar the expanded requlremet1ts are '\\'Orth the ackUtlonal cost. He or
she may allocate sufficient hmds to cover the requirements but may migrate priorities
sud 1 that mlnlntlzing cost now becomes the highest priority (see Rgure 4-17, step I).
But now the matrix violates a rule- there are two Xs ln column l .To compensate, we
must migrate the scope ancVor quality criterion to ai1other column, lo tllis case, the constrain column (see Figure 4-17, ,tep 2). Expectations have been adJusted. In effect, the
system owner Is freezing growth of reqttlreme11ts and stlll accepting sched,tle slippage.
T here are three final comments about prlorfry changes. First, priorities may
change more tl1an once during a project. Expectations can be managed tlvough any
number of d1..1nges as long as the matrix is balanced (meartlng Jt confonns to our
Projoct Managomont
PRIORITIES ..
Max or Min
Constrain
Accept
chapter Four
147
FIGURE 4 - 17
Changing Priorities
~MEASURES Of' SUCCESS
Sccpe and/or Quollty
rules'). second, expectacto11 managemenc can be achieved through. any comb1nauon of
priodty changes and resource adjustments. Finally, system owners can Initiate priorlty
d1..1nges even if the project is on sdtedu.le. For example, govenwent regtdation mlght
fore, an uncompromising deadline on an existing project.Th.at would suddenly migrate our ..accept" schedule sl.Jppages to "max constrainr."The other Xs wotdd have to
be migrated to rebalance the matrix.
Willie the managemet1t expectations matrix ls a simple tool, It m.1)' be one of the
most effective.
Schedule Adjustments-Critical Path Analysis When It comes to the project
schedule, some tasks are more sensltlve co schedule cklays d1an others. For this reason,
project m.uugers must become aware of the critical path and slack times for a project.
Understanding ti,e critical path and slack time ln a project ls lndlspensable to the
project manager. Knowledge of such project factors lnfluences the people management declslons to be made by the project manager. Emphasis can and shot~d be
placed on the critical path tasks, and If necessary, resources might be temporarily
dJvetted from tasks with sL1ck time to help get critical tasks back on sd1edu.le.
Toe critical path and sL,ck time for a project can be depleted on both Gantt and
PERT charts; however, PERT charts are ge11erally prefured because they more dearly
depict Intertask dependencies that define the ctiUcaJ pat11. !\toSI project management
software, lndudlng Mlcrosoft Project, automatically calcttlates and hlghUghts the
critical path based on lntenask dependencies combined wlth durations. It is useful,
howe,--er, to understand how the critical path and slack times are calculated.
Consider the following hypothetical example. A project conslsts of the nlne prlmltlve tasks sl1own ln Flgure 4-18. The most likely d uration (ht days) for ead1 task is
recorded. There are four distinct sequet1ces of msks in a project. They are:
hth I:
hth2:
hth 3:
hth4:
A~B~C--+0--+l
A~B~C--+E~l
A~B~C--+F--+G--+l
A~B~C--+F--+H--+l
The cotal of most likely duration times for ead1 path is calct~ated as follows:
hth I:
hth2:
hth 3:
hth4:
3
3
3
3
+
+
+
+
2
2
2
2
+
+
+
+
2
2
2
2
+
+
+
+
7
6
3
3
+
+
+
+
5
5
2
I
=
=
+
+
19
18
5 = 17
5 = 16
In this example, path I Is the crttf.ca/ path at 19 days. (Note: You can have mltltlple
critical paths If they have the same total duration.)
-...
TASKD
I.IC 2120/01
·-·
I ue :V..!Wtll tl d W)'5
TASK.A
Mon 215J01
"'Kdays
Uon 2/5J01 ri"days
TASKS
TASKC
Wf!ld2fTI01 "dil""'Wed217/01 W\days
Fri Z/9J01
Fri 2191()1
Name
Eo11)' Fil\iSII
Oura1ion
Late Ftn1sn
Total s1ae1<
I
Crlic.31
I
Noncn,1ca1
( F I GU RE 4 • 1 8 Critical Path Analysis
·~
"d.in
~ ...
ASKE
TASK I
Mon 2/1!W0118da)'t
Tue :1127/01 l!>d.iys
ue 2120/01 11 day
Tue 2127/01 I0<13ys
TASt< F
TASKG
Wi!4 2/14I011J aays
fu 2116/01
Fri 2/16J01 "dav5
Tue 2/20rol 12 days
I I Critical Milestone I I CrOO'II Surrmary ~
I II Nonctitie::tJMi:e~one I INOl'l.<:liicolStrnffl.lry ~
I
t2 d111ys
Cr.1ical Subp(O)eci
I II
l wonc:nt~ISubi)ro,ectl
CrHlcal MarkM
I)
u::~~·l\oCl.nl~IM..u l~ed '.I
)
Projoct Managomont
chapter Four
149
In thJs example, tasks E, F, and G are not on the critical path; they each have some
slack time. For example, task E Is Included in a path tint has one day less duration than
tl1e critical path; therefore, task E can get belllnd by as much as one day without adversely affecting d1e project completion date. Similarly, tasks F and G can combine for
a maximum slack of two days wlthottt delaying the entire schedule.
In Figure 4-18, the critical path is shown in red. The tasks that have slack capacity
are shown in bL1ck. Sim.JL1rly, project management software also uses color to differentiate critical path tasks h1 a Gantt or PERT chart.
>
Activity 8-Assess Project Results and Experiences
Project managers must Jearn from their mistakes! They shottld embrace continuous
process lrupro,-.ment. This final activity Involves soliclth1g feedback from project
team members (lnduding ctistomers) concerning their project experlet1ces and
suggestions aimed at impro"ing the project and process m.u1..1gemenr of the organization. Project re,iew(s) should be conducted to answer the following fw1damental
questions:
Did the fl.naJ product meet or exceed user expectations?
Old the project come h1 on sched,de?
Old the project come h1 under budget?
The answers to these questions should be followed up wlth the basic question
.. Why or why not? .. Subsequently, and based on the rtsponses to the abo,--e questions,
d1..1oges should be made ro lmpro,--e the ~·stem development and project management methods tl1..1t wlUbe used on future projects. Suggestions for lmprovements are
commlullcated to .. Centers for Excellence," whkh can modify standards and
processes, as well as share useful ideas and experJet1ces with otl1er project teams tl1..1t
may solicit their help or expertise. Project assessments often contrlbute Improvements to specific project deliverables (milestones), pioce.s.,es or tasks that created the
deU,-erahles, and the overall management of the project.
/
Where you go from here depends on where you are coming from and where you
wan, to go. If you are readh1g through the chapters sequentially, you should probably
move on to Cl1..1pter 5, ...~·stems A11..1tysJs," to expand your understanding of ~·stems
analysis tasks, tools, and tectmlques. Alternatively, it you are enrolled ln a ~·stem
design-focused course, you mlght sklp ahead to either Chapter 11, • feasibUity Analysis and the system Proposal" (which marks the end of systems an~lysls), or Chapter 12,
·systems D<!slgn" (whid1 provides an h1-depth look at the actMties of system design,
protorypfng, and rapid application development).
Some Instructors l1..1ve deferred this project managemet1t d1..1pter to the end of
your course. If so, you may be Interested in expanding your knowJedge of project
n:wu gement tools, teduliques, and methods. Some schools offer a project n:w1..1gement course. If not, you may flnd that your systems analysis and de.sign instructor
might supervise you to complete an independet1t study course on tl1e subject. If so,
we direct you to two sped.fie references at the end of th.ls d1..1pter as possible texts:
(I) the Wysocki et al. hook Is well organlzed aromxl 1he Project Management Body of
Knowledge that we presetlled fn our chapter, and (2) the Mcleod and Smlth hook ts
e.spedally compre.henst,--e in lts coverage of project management d.JmetlSJons tl1..1t we
could not cover fully in our chapter.
,-CD
0
--..
::J
::J
CQ
:::::0
0
0
Q_
3
0
-0
I SO
1ho Context of Systems l>owlopmont ProjOffl
Part One
Summary @
I. A projed is a (temporary) seqt1e11ce of unique, complex, and connected actlvltles that have one goal or
putp0se md that must be completed by a speciJlc
time, within budget, and according to speciJlcatlon.
2. Project m:u1..1gement ls the process of scoplng,
planning, staffing, organlzing, directing, and controlllng the development of an acceptable system
at a mlnJmum cost wlthh1 a speclfled time frame.
3, Process management is an ongoing activity that
documeats, manages the use of, and lmproves an
organlzatio11's chosen metl1odology (the .. processj
for systems development.
c.. Estimate task durations. There are many techniques and tools for estimating task durations.
d. Specify Intertask dependencies. The start or
completion of Individual tasks may be depen-
dent on the start or completion of other t:uks.
11,ese dependencies impact the completion of
any projed.
e. Assign re.sources. The followlng re.sources may
impad a projed sd>edule: people, services, fa.
cilltles and eq,tlpment, supplies and materials,
and money.
4. From a projed management perspectlve, a project
ls considered a succe.s., lf the resulting lnformatlon
l) Such re.sources must be assigned to taslis to
system is acceptable to the customer, the system ls
il) Resource leveling ls a strategy used to cor-
dellvered •on time" and "wlthlt1 budget; and the
system development proce55 had a mltlltnal lmpad
rect resource overaJJocauons by some
on ongoing business operations.
5. The Project Management Institute has created the
Projed Management Body of Knowledge (PMBOK)
for the education and certification of professional
project managers. It addresses:
a. Project manager competencies.
b. Project management functions.
c. Tools and techniques such as:
I) PERT charts, graphical networl< models that
dq,ict a project's tasks, and the relationships
bdweett those tasks.
II) Gmtt diarts, simple horizontal bar charts
tlut depld project tasks ag.11nst a calet1dar.
d. Project management software.
6. Project man.11,ement is a cross Ufo-cyde activity: that
Is, project management tasks overlap all the system
development pluses. A project management process
Is e..enthl to achle,ing CMM Level 2 maturlt)'.
7. Joint prqect plannlng(JPP) Is a strategy wherein
all stakeholders In a projed participate in a one- to
three-<lay project management workshop, the result of which is consensus agreement on project
scope, schedule, re.sources, and budget.
8. The tasks of projed ma,1agemetll Include:
a. NegotL1te scope. Scope defines the boundaries
of a project and Is lt1duded lt1 the statement of
work, a narratl,t> description of the work to be
performed as part of a project.
b. ldenriy tasks. A worl< breakdown strudure
(WBS) is a hierarchical decomposition of tJ,e
1
develop a sd>edltle.
combination of delaying or splitting
tasks. Resource leveling requires know].
edge of:
(I) The critical path- that sequence of de-
pendent tasks that have the largest sum
of most illcely durations. The critical
path determlt,es the earllest possible
completion date of the project.
(2) Slack tlme- tl,e amount of delay that
can be tolerated between the starting
time and completion time of a task
without causing a deL1y ln the completion date of the et1tlre projed.
f. Dlrect the team effort. One of the most important dimensions of directing tl,e team effort is
the supervision of people.
g. 1.torutor and control progress. uurmg the project, the project manager must monitor project
progress against the scope, sched,tle, and bud-
get and, when necessary, make adjustments to
scope, schedule, and resources.
I) Progress reporting Is an essential contrcl
process that uses communication to keep a
projed within scope, on time, and within
budget.
ii) A complete project plan provides mecha-
nisms and a process to manage requests for
changes to scope. This Is called diange
management..
ill) Change management frequently requJre, that
project lnto lts tasks and subtasks. Some tasks
represent the completion of mile.stones or the
a project m:uuger manage the expectations
of management and users themselves. An
expectations management matrtx ls a rule.
completion of major dellverables during a
project.
driven tool for helping managemetll wulerstand the dynamlcs and Impact of changing
Projoct Managomont
project parameters such as cost, schedu.le,
scope, and quality.
iv) Sd>edt~e adJustments are required whetl a
project's scope changes or when other factors drfve schedule or budget out of the
projected range.
chaptw Four
151
h. Assess project results and experiences.This fi.
naJ activtty im-olves soJJdting feedlnck from
project team members (h1duding customers)
concerning ti1elr project experiences and suggestions aimed at Improving the project and
process m:u1..1gement of the organlzatio11.
\ ';:::S Review Questions
I. Whatls a project?
2. Of the many dlfferent reasons that projects fal~
what is the major cause of project failure?
3, What ls the difference betwee.n scope creep and
feature creep?
4. What are the five main categories of competencies that a project manager should have?
5, Why are business achle,--emet1t competencies
important?
6. What are the baslc project management hr.nctions?
7. What are PERT' and Gantt d1..1rts? How do we
decide wh.lch one to use?
8. What are the eight major actlvtties In the project
management life cycle?
Negotiate scope
Identify tasks
F.stimate task durations
Speclfy hllertask dependet1des
l. .\ssume you are a systems analyst and a proud
AssJgn resources
Direct the team effort
ltfon.itor and control progress
Assess project results and experJet1ces
9. Why is negotiating scope hnportant? What is the
deliverable In d,e process of negotiating the scope?
10. What is a pop,~ar tool used to identify tasks In
the project m:u1..1aenlet1t life cyde?
11. What are the factors to consJder in estimating
task d u.rations?
12. What are the differet1ces between forward sched-
uling and re,--erse scheduling?
13. What are the categories of resources ro be
allocated to the project?
14. What should project managers do to manage
changes that occur and/or are requested d u.r-lng a
project?
15. Why Is critical path analysis hnportant?
@:
Problems and Exercises
3. As a newly appointed project manager, you are
member of a project team that has Just comp leted
eager to get started on your first project. W11..1t
a major project that spanned several years and
t11..1c touched aJ.moSI every bustness l llllt in your
sho,tld your first activity be? How Important Is it?
organlzation. The project was completed ahead of
,chedt~e and well within b udget. Development
and lmplementatlon went very smoothly wJt11
,·1.rtually no disruption of business operations. A
postimplementation survey ind.Jcates tl1..1t system
users have bee.n able to use the systenl wlth mlnlmal tnlnlng, although there h.ave been some comments from the more vocal users that ft wasn't
qu.f.te what tl1ey expected and doesn't do some
of the things they thought II wo,tld. Sho,tld the
project be considered a success?
2. Executt,--e management is concerned that some
users are less th:u1 satisfied with the new systenl
described in the preceding question and have
assigned you to lead a postlmplementatlon work
group to determine the cause. Of ti,e dozen project mismanagement problems descrf.bed h1 the
1extbook, wllich ones do you tllink were most
Jlkely to h.ave contributed to user dissatisfaction!
Who Is typically Involved? W11..1t questtons do you
need to make sure are atlSWered? What's the ultimate outcome from this activity, and what is
h1duded in this deliverable?
4. You are the project manager of a medium-size
project ti1at is sd,eduled to take 10 months from
project initiation on September I st through deliv-
ery 011June 30th. It ls 11ow April 1st, seven
months sh1ce the project began, and the project
is slightly hellind schedule, hy perl1aps a week.
Draw a Gantt chart (you may use the style shown
h1 Figure 4.2 or anoti1er Gantt chart style If you
prefer). Assume you are usf.ng tl1e PAS( metl1odology, and ti1at project phases can ovedtp.
5. )'ou are the project manager for a company that ls
building a behavioral healtl1 system for some of d,e
counties h1 your state. The project is slightly ahead
of schedule and tl1ere haven't been any signllkant
problems to date. In reviewing some of the
screens under construction, you are surprised to
152
Part one
Tho Context of Systems Dowlopmont ProjOffl
find a number offeatures that were not part of the
design. TI1e system builder was one of your most
talented and creative programmers. When you ask
about these features, the builder proudly tells you
tbat they add to the functionality of the system
wlthoul taking any addltlonal programmlng time,
and that they '\\"ere intended to be a surprise. You
can see that d,e features definltely do add to the
f,u1ctlonallty of the system. The code has already
been written for them-should you allow them to
be included in the system, even though they were
not part of the apprc"-.d technlcal design?
6. 11,e methodology used In your organlzatlon calls
for change requests to be considered by a change
control board (CCB). After some reflection and a
discussion wlth the programmer, you have de.dded to submit a change request to the CCB to
schedule.1ltls presents an expectations conflict
since scope ls the constrained measure of
success. W11at should you do at this polnt?
9. suppose the CEO decides that no matter what,
the new features absoJuteJy must be added in order for the new system 10 be competitive. What
issues does this raise, and how would tills be
reflected ln the expectations matrix?
10. You are working on the sd1edu.le for the system
design phase and are trying to estimate ti,e dlration of a complex design task. From breaking tills
task down into smaller tasks shnilar to ones that
you've had experience with on other projects,
you estimate the task should normally take an expected duration (ED) of three workdays, given a
typical 75 percent worter eftlclency rate and
add the new features. ht your presentation to the
15 percet1t lnterruptlon factor. But you also know
of some it1Stances where absolutely 11othit1g went
CCB, wh:it reason might you give for the ch.aoge
right, and Jt took up to two full workweeks, or a
request and what thing., should you take into
consideration?
7. The COO of your organl22tion was so Impressed
with your List project that you have been given responsiblllty with a L,rger, even more Important pro~
ect.111e CEO calls you ln for a discusslon regarding
the Importance of the project, and tells you that the
very survival of the organl22tion may hinge upon
compleling this project and rolling out the new system to atStomers before a cermln date when a competitor ls expected to complete a similar project.
11,e company can affo«J 10 budget only up to a
certain maximum, althougt, if othe,; less crltlcal
projects-lo-progress are delayed, there may be some
addltiooal fundlng available If ati.olutely necessary.
Anally, ln order 10 be a competltive product in the
matket,the new ~·stem must conmln at least acertain mhtlmu.m fearure set, although more would be
destrabk!, and che quaUty must be of the hJghest
level. Al the conclusion of this discussion, the CEO
shakes your hand and wishes you good luck. Use
the priorities set by ti,e CEO to create an lnltlal
management expectations matrix.
8. Now suppose that during the course of this
project, ft becomes apparent that costs were
signlflantiy w1derestlmated and ti,e budget is
rapidly becoming depleted. In addition, d,e head
of marlretlng bas picked up a trade mag,1zine and
read that your organtzatlon•s main competitor is
addlng some really exciting features to d1elr product without changing their release date.11,e budl!l'I
overage is not the major problem; you know
addltiooal money can be allocated, althougt, it
may delay oti1er p rojects. But you also know that
your ourketing stakeholders will be demandlng
that simllar features be added to ti,e system you
are developing wiille keeping 10 the original
pesslmlstlc duration (PD) of 80 hours, 10 complete the design task. Using ti,e classic technique
described In ti,e textbook, calculate the mosl
likely duration of the task.
II. In the precedh1g question, what technique did
you use to estimate the expected duration of the
desJgn task.? Descrlbe some of the other ted1.
nlques you could use to estimate task du.ration.
IZ. During one phase of the p roject, you review the
project sched,~e and realize that a member of
your project team has been assigned multiple
tasks that add up to more hours than the person
bas ava!L1ble to wort during that period. What
technique could you use to resolve th.ls?
13. You have been asked 10 complete a project In
shortest time posslble. The project tasks, most
likely duration (in days), and predecessors are
shown below. What are the different paths
(sequence of taskS) and the number of days for
each? What ls ti,e critical path, that ls, the shortest time in which the p roject can be comple1ed1
ls ii actually Important h1 the business world for
project managers 10 w1derstand critical path
analysis, or is this Just theoretical knowledge!
Tasks
Duration
Pl'edecessors
A
2
None
8
2
,
None
c
0
4
A
E
F
5
G
H
I
,
•
None
8
c. 0
A, E
4
F
7
G,H
Projoct Managomont
14. ,\Sa new project manager In a rapidly growing
orgart.izatlon, you have been asked to lead a project team for an lmportant project. The scope of
tl1e project Is not too broad, project time frames
are somewhat on tl1e tlght side but definitely
doable.and the budget ls more than generous. In
fact, you have been given the authority to hlre a!
many people as you want for your project team.
153
You estlm.1te tl1..1t 5 people would be 1bout rlght
for tills type of project, 8 wottld provide a healthy
amount of bacl.-up, and IO cottld give i·ou the
re.sources to deUver an outstandlog system ln
record time. W11..1t is something you might want
to keep in mh1d before making your declsion on
how many people to hire?
12
I. Projects fall, sometimes spectacttlarl)'. Seard, tl1e
Chapter Four
Projects and Research
d. Professionals In many fields, such as medldlle,
Web for articles on major project failures; numerous
engineering, accow1tancy, and law, are required
artldes should be readily a>'1llable. Find and review
artldes on approxlmatelj• IO major project failures
during the past decade, dm1 do the following:
to be Ucetued or certlJled. Do you thhlk professional certllkatlon shottld be required before
a. List the p roject failures that you found, and
describe them.
b. What was the cost of each project failure?
c. W11at were the consequences of each project
failure?
d. Categorize the reason(s) for each project's failure based upon the causes listed In tllis chapter.
e. W11at were the most common causes for the
p roject hllures?
f. In Wndsight, how many of tl1e project failures
were a,-oJdable?
g. W11at is the most important lesson that new
systems analysts can learn from these project
failures?
someone can manage a large project?
3. You work in the infonnation tedu1ology dtvlslon
of a large law firm with offices througl»ttt the
state. One of the vice presidents of the company
has asked you to manage the deveJopment of an
automated case-tracking system for your company.
TI1e project, whid1 ls Just beglrullng, Is the first
large project you 11..1,--e beet1 asked to n:w.1..1ge.You
take your duties '\o"ef)' serlousJy and want to do an
exempL1ry Job on this project.
a. You are meeting with the vlce president of the
company to discuss the scope of the project. In
yoltr meeting, what questions need to be answered and negotiated ln order to be able to
determine the scope of tl1e project?
2. Toe Project Management Institute (P~U) ls one of
the leadh1g and perl1aps the Jeadlng project mana«ement oraanli.atlon h1 the world. Pt.fl created
acd malntahu the. Project Management Body of
Knowledge' (PMBOK), wlllch Is a de facto staod,rd for project managers. PM! also certlfles a
project manager who passes its knowledge and
b. Once you have flnlshed negotiatlllg 9.."0pe, the
vice presJdent lw asked you to wrfte a Statement
of Work. What does the Statement of Work represent In tills situation? How Jong should it be?
experience requirements as a ...Project lttanage-
(ald1ougl1 that will probably never happetl In
real life).
metll Professional' (PMP).
a. Go to the PMI Web site (w,uw.pml.org). What
are the requirements to become certl.tled as
aPMP?
b, Based upon your readings and experlence, how
important do you tlllnk the PMP certlJkatlon Is
for the project managerY Do you think lt ls
worth the in,-estment?
c. What about the organization that employs a
P,_IP? ls the certification an assurance tlut d1e
org.1nlzatlon's projects wlll be completed suc-
cessfully. How much more should an organtzatiao
pay a project manager with a PMP cert!fkatlon?
c. Write a Statement of \X'ork, uslog t11e outlloe
shown h1 Figure 4-5 as an example ..~ume that
tl1e vice president l1..1s given you catte bL10che
4. Project m.1nagemet1t software, sud1 as 1,Ucrosoft
Project, have become commonpL1ce. ~tmy of tl1em
Incorporate traditional tools, such as PIR1' and
Gantt charts, wllld1 were de,'doped decades ago.
a. Conduct an lnformal survey of about a dozen
project managers In industry. How many of
tl1em use project management software?
b. For those who do11't use project management
software, wl1..1t are their reasons for not using it?
c. For those who do use project management software, which ones do they use? What are tl1eir
opinions regarding the software they use?
154
Part one
Tho Context of Systems Dovelopmont ProjOffl
d. Search on the Web for dlfferent project management programs. Whid1 ones dJd you tlnd?
e. Review thelr features and specifications. Do any
of thttn appear to have unique features? Which
one do you thlnk Is the most popular, or at least
the one most widely used? Whlch one would
you pick if cost was not a consideration?
5, You are mai1..1ging the deveJopruent of a case.tracking system project for your L,rge law firm.
The requirements phase of the project is almost
complete,and preliminary design work has begun.
The project Is running several days behind schedule, whlch you don't consJder serious, and it ls
within budget, but barely. Quality, in terms of requirements analysis, has gei1erally been acceptable
so far In your opinion, but some of the project
team members have mentioned that they are not
sure if certain Issues have been fully re.soJved.
Based upo11 th.ls infonnation, write a Project
ProgressRepon, using the outline in Figure 4-11 as
Minicases
an example and following the gtddelines described
In Activity 7 In this chapter.
6. As part of continuous lmprovement, It is lmportant
for project managers and project teams to asses,
the results and their experiences once a project
has been compJeted.111ere are numerous methods
and teduliques for doing this. Search 011 the V:~b
for pertlnetll articles, using phrases such as project
assessment, project postlmplementatlon reports,
and the like.
a. What articles tUd you find?
b. Describe the methods and techniques ti,ey
suggest:.
c. Select the ones you feeJ are the most "-aJuable,
and explain why.
d. Do you thJnk that assessing project results can
make a significant difference In the quality of
future projects?
ti
l. You are on a team that ls de,--eloping a \X'eb site for
a local bnslness, Olstom Car Care. There ls a set
schedule of four months for requlremetlls analysis,
developmet1t, and successM deployment. The
team is en sdtedu.le, ln week 8, and has Just shown
Debbie, the CEO of Custom Car Care, the prototype. Debbie is very happy with your work so far,
but has some additional capablllties she would like
added to the site. Altl1ough the addltions are not lo
the previous time or cost estimate, she requlres
that you stay on schedule and wJthln current
budget. What do you do?
2. Alida and John are a team coding a dlftlcult and
sizable program In Java. They hm, some experience wJth the language, but wUJ h.a,--e to )earn a
significant amotlllt ..on the fly:'They h.a,--e estimated that the project will take two months as the
optimistic estimate, three months as the expected
estimate. and four months as the pessimistic estimate. You are their project manager and must
develop a contract for completion wJt11 the client
for the code deveJopment. How much time should
you allow in the contract for this dellverable?
3. Develop both a forward and bad-ward schedule of
tasks and tlmellnes for a major project you are
completlng for a class. If there Is discrepancy between the two schedules, err on the side of frontloadlng your tasks. Monitor your project tlmeline
and keep track of the milestones as you complete
the project. At the end of the project, submit your
tlmellne and project notes to your professor, along
with a copy of ti,e class project. Did ti,e sd,edule
development and management of the project help
you? S11are wlth your class yotU' experience.
4. In an Interview wlth a project manager, find out
how often perso1u1eJ issues affect the successful
(and on.tJme) completion of a project. How does
thls project manager deal with personal or family
problems that distract or remove key memben of
a team?
Team and Individual Exercises
l. For the p-of~or to dJrect: Create teams of four and
designate one as d,e project manager. Assign them a
chaliengklg task with a shon deadline. It shotdd be
doable for the class, but certainly not easy. ~Udway
through the project, exchange one member per
team so tlut ead1 team h.as lost: one member and
gah1ed one new member. Do not allow the team to
co11,--erse with the member that was ..hired away."
Have the project manager document how
they hantUed the situation, what p roblems
arose, and how they would handle a team differently in tl1e future (knowing that they could
Projoct Managomont
Jose a teammate at any time and without any
notice).
2 . (Team or lndlvldual) For each of the class projects,
develop a Rolling Wave tlmellne for completion.
Write down everything you can think of that could
go wrong and a contingency project pL1n. Advice:
Front~oad ead1 project.
chaptw Four
l SS
3, As a team, go out to lunch or dfnner. Share some
aspect of your life that your team may not know
about. Find Oltt something you didn't know about
each of your teammates.
e]]
Suggested Readings
Blanchard, Kcrutcth, and Spencer Johnson. The One iWltltlfe
At,1nager. New Yotk: Bcrldc>• Publishing Group, 1981,
1$82. Arguably, this is one of the best people llWl."tgctncnt
bcoks C'\'t'r written. A,'ailable in most bookstores, it can be
rc1d o,'t'might and used for discussion material for the
lighter side o f project blanagc-lllC'nt (or any kind of rnan·
anti Practtces 2, no. 6 (March/April 1992), pp. 26-29. We
adapted our expectations rnanage,mcnt bl."ltri.x from
Dr. Fricdlander's v.'Otk.
Kcnuci:, Harold. PrOject ,Wanage1nent: A S)istettlS Approach
to Pfa1111.t ng, SCJJed1dt11g, anti 0>11trollt11g, 4th ed. New
York: Van Nostl'.Uld Reinhold, 1989. Many cX-l)C'rts
a.s,:'blc!nt) . Thi,; i:1 bltir.:t t'C!lld:ins; f o r '1.U c ollege r.:tuddltl';
con:1ick.r thi,.; book to be, the, defui.iti";,;, 'WOtk in the, fi,dd of
v.'it.h managclllC'nt aspirations.
Blanchard, Kenneth; William Oncken, Jr.; and Hal Burrov.-s.
Tl.-e. one iWtnute ,wanager Afeets the ,wonke)t Nev.• Yori::
SiJOOn & Schuster, 1988. A sequel to Tbe One ,Wttltlfe
Af,111age,; this book effectively looks at the topic o f delc·
gar.ion and titllC' managclllC'nt. The monkey l'C'fers to
Oncken's classic article, •Managing ~tanagclllC'nt Time:
Who's Got the ~tonkcy?" as printed in the Har,,.ard Bu$11uss Revtetv in 1974. The book teaches managers hov.• to
achtc\'t' l'C'Sults by helping their staff ( their rnonkC')'i)
soh't' their o wn problems.
Brooks, Fred. 1be ,11J•thtcal Ata1i-..,.1011tb. Reading.MA.: Addison·
Wesley, 197S. This is a classic set o f essays on software
engineering (also kn,ov.,n as systcblS analysis, design, arid
implernc,ntation). Emphasis is on managing compla
projects.
Catapult, Inc. ,Wtcrosoft .Project 98: Step ~1 Step. Redmond,
W.\.: ~1krosoft Pl'C'SS, 1997. An update fo r Project 2000 is
cxpoctcd.
Ocrnarco, Tom. The DeadlttJe: A JVOtJ(!/ about Project ,WanaJseinent, Nev.• Yotk: Dol'SC't House Pu.blishjng, 1997. This
v.<ould be an excellent companion to a project manage-·
lllCnt text, cspcc-ially fur a graduatc-l<"\'C"l course. It demon·
stratcs the •good, bad, and ugly" of project managc-lllC'nt,
told as a stot):
DtUlc.m, William R., Dircctoi:, and Standards CommittC'C'. A
Gutde to the .Project Afanage1ne11t Bod)1 of Knou.'fedge.
Uppc,r Darby, PA: Project ManagelllC'nt Institute, 1995.
This is a concise overview of the gcncl'l.!ly accepted Proj·
cct Management Body o f Knowledge and pncticcs us<d
fo r ce,rtiftcation of project managers.
Frioclandet:, Phillip. • Ensuring Softvi.ral'C' Project Success wilh
Project Buyers," Softtvare. E11gt11-emng 1bols, Ted.J11tq1us,
project managclllC'nt. Dt. Kern2cr's seminar; and coul'SC's
on the subject arc l'C"flowncd.
London, Keith. 11.Je People. Side of S)istetnt, New Yotk:
~tcGraw·Hill, 1976. This is a timeless classic about ,'llrious
people aspects of systems wotk. Otapte,r 8, • Handling
a Project Team," docs an excellent job of teaching the
leadership aspects of project rnanagc-ment.
Mcleod Gl'.tham, and Ocl'C'.k Smith. Alanagtng Infonnatton
Technology Projects. Cambridge, MA: Course TC'Chnol·
ogy, 1996. If you al'C'. lo oking for a goo d academic boo k
for a co urse or independent study project to expand
your knov.,ledgc o f IT project and process managcrnc,nt,
this is it! The book pro,'ldes a compl'C'.hensive treat·
ment o f ,'lrtually all dimensions of rr project and process
managelllC'nt.
Roetxhcitn, Wi.lliarn H., and Reyna A. lkaslc): Sojtu,Ylre. ProjeCI
Cost anti scJJeaule Estunartng: Best Prar.rtces. Uppc,r
Saddle Ri,tt:, NJ: Prentice Hall, 1998. This is one of the
mol'C' complete boo ks on the subject of estimating tech·
nkfucs. lktter stil~ the book inc'ludcs C'\'llluation copies of
Cost•XJ)ert, Rtsk•XJ)ert, and Stmtegy•xpert ('-of~tarott,
Inc.), software tools fo r estimating.
Wysock~ Robert K; Robert Bock, Jr; and OJ.vid 8. Chne. Ef
fecttve. Project Afanage1ne1u: Hotv to Plan, !ltanage, and
De/ttJ(!r Projects on 11tne and lJJfthtn Budget, 2nd ed.
Nev.• Yo rk:}ohn Wiley & Sons, 2000. Buy thi! book! This is
our nevi.• benchmark for introducing project managctncnt.
It is easy to read and v.•orth its v.'Cight in @Old. We wcl'C'.
surprised hov.• compatible the book is with past editions
of o ur book, and our project management dittctions
continue to be influenced by this v.'Otk.
Part Two
Systems Analysis Methods
The five chapters in Part Two introduce you to systems analysis activities
and methods. Chapter 5, "Systems
Analysis," provides the context for all
the subsequent chapters by introducing the activities of systems analysis.
Systems analysis is the most critical
pbase of a project. During systems
analysis we learn about the existing
business system, come to understand
its problems, define objectives for improvement, and define the detailed
business requirements that must be
fulfi~ by any subsequent technical
solution, Clearly, any subsequent system resign and implen1entation of a
new ,ystem depends on the quality of
the ireceding systems analysis. Systems analysis is often shortchanged in
a project because (1) many analysts
are not skilled in the concepts and
Jogic,J modeling techniques to be
used, and (2) many analysts do not
understand the significant impact of
those shortcuts. Chapter 5 introduces
you D systems analysis and its overall
importance in a project. Subsequent
chapters teach you specific systems
analysis skills with an emphasis on
logical system modeling.
Chapter 6, "Fact-Finding Techniques for Requirements Discovery,..
teaches variow fact-finding techniques and stra!egies used to solicit
user requirements for a new system..
In Chapter 7, "Modeling System
Requirements with Use Cases," you
will learn abou! the tools and techniques necessary to perform use-case
mcxieling to docun1ent system
requirements.
In Chapter 8, "Data Modeling
and Analysis,"' we teach you data
modeling, a tedlnique for organizing
and documentiog the stored data
requirements for a systen1. You will
learn to draw entity relationship
diagrams as a tool for structuring
business data that will eventually be
designed as a database. These models
will capture the business associations
and rules that must govern the data.
Chapter 9, "Process :-.iodeling,"
intrcxluces process nuxfeJin.g. It explains how data flow diagrams can be
used to depict the essenti:1.1 business
processes in a system, the flow of
data through a system, and policies
and procedures to be implemented by
processes. If you've done any programming, you reoognii.e the importance of understanding the business
processes for which you :1re trying to
write the programs.
Chapter JO, "Object.Oriented
Analysis and Modeling 1>ith UML;'
teaches you about the object-oriented
approoch to performing systems
analysis using UML tools.
Chapter I I, "Feasibility Analysis and the System Proposal,"
teaches you how to brai r.storm
possible system solutions, analyre
those solutions for feasibility, select
the best O\o'etall solution, and then
present your recommendation in the
form of a written and oral proposal
to management.
--·
Gall:
ICNCJWUmQE
8TATEMENT (If
wo,i.c
l" ROBLEM &TATEM ENT ("llltl thl l" IECE8 lfl .. lWOfk)
INFORM*,l10N
OCOPE
•
.......
FUNCTIOML
COII.UNICAllON8
SCOPE
SCOPE
VISION
\118ION
•
•
8Y8TEM IM,IIOVEMENT 08JECTIVE8 (01U19 tlte PIECE8 f11•1w 1 1•)
eve Ole . . . . . e GUI ft EM CNTI eTAT eM eNT
~
;
:•
:
•
.•••
••
•••
..
M
0
9U81NU&
PAOCE83
AEOUIFIBl&fTS
LOGICAL
DATA
LOGICAL.
PAOCE83
MOOEL8
IIOCELI
DATA
i•
•i
9U81NE8$
AEOUIFISIENT&
•••
•,
I
9U91N El88. 8V8TUI
INTERFACE
FIEOUIJI EMEHTS
LOOICAL
INTERFACE
MOOEUI
'rT'W i
•
~~~~, ~~-·-·
~·-T_·_·~·~·-·-·-·~·-AA
_l"l"·~LICATION
-<-·-·~·~·-·-·-·ARCHITECTUftE
~·-·~·-·-·~·-·~·-T_·_·~·~·-·-·~·-·-A
~·-·-·~~~ ·
:_
,
~
~
•
OE&ION PROTOTYPES
9U8 1NE88 PJIOCEM
PHYSICAL.
PHYSICAL
OE.SIGN
OATMASE
OEl91GN
USER • 8 Y81lM
INTEFIFACE
OE81GN
PWY81CA.
8 0FTWAA E 0:.&IGN
8 PEO ACATION&
aPECI FICATION8
8 PEO ACATONS
- ......,...
5
FUN C TION A L 8Y& TE •
TR A ININ G MATERI A L&
-
COll•EAOAL
80~
11E
OAV.8A8E
80LUTION
.i
.
•
i
0
~
••
0
CUSTOM.SIIILT
~
OPEFI A TION A L 8V& TE N
A PPLICATON
8 0 FT'WM.11E
•
...
,
INTERFACE
8 0WTION8
........
INTEFIFACE
8 0WTION8
-
P 08 TA U OIT FIE V IEW
"""'""'
.....
.,.'°
...,.....
""'"""
APPFIOVEO
INTeFFACE
TECI-HOL.OOIES
"'°""'°"''"
Cor1'1!roN: APPFIOVEO NeTWOFll(TECI-HOL.OOIES
I
l
•
I
f
I
Systems Analysis
Chapter Preview and Objectives
In this chapter you will learn more alx>ut the systems an:l.lysis phases in a systems development project-namely, the scope definition, problem :malysis, requirements analysis,
and decision analysis phases. The first three phases are collectively referred to as syste,ns
a.11Dlysis. The latter phase provides transition between systems analysis and systems design. You will know that you understand the process of systems analysis when you can:
I Define systems analysis and relate the term to the scope definition, problem analysis,
re~uirements analysis, logical design, and decision analysis phases of this book•s
systems development methodology.
I De.scribe a number of systems analysis approaches fer solving business system
problems.
I De.scribe the scope definition, problem analysis, requirements analysis, logical design,
and decision analysis phases in terms of your information system building blocks.
I De.scribe the scope definition, problem analysis, requirements analysis, logical design,
and decision analysis phases in terms of purpose, par!icipants, inputs, outputs,
techniques, and steps.
I ld!ntify the chapters in this textbook that can belp you learn specific systems analysis
to,ls and techniques.
NOTE: Although some of the tools and techniques of systems analysis are previewed in
this chapter, it is not the intent of this chapter to teach tOOse tools and techniques. This
chapter teaches only the process of systems analysis. The tools and techniques will be
taught in the subsequent six chapters.
160
Part 1wo
Systoms Analysis Methods
Bob Martinez rememoos learning In college that systems analysis deJlnes what tn Information system needs ro do whlle system desJgn defines how ft needs ro do Jr. Ar
the time, lt sounded like a simple tw<>Step proce55. Now, as he begins wortlng oo tl1e
SoundStage t.tember Servlces ~·stem project, he sees that there are multiple pltases
and several steps within systems analysis and system design .
The SoundStage project Is at the begitmlng of systems analysis, In what Sandra, his
boss, calls the scope dellnltion phase. After that they'll do problem analysis, requirements analysis, and decisJon analysis. It sow1ds like a lot of work just to w1derstand
t1Jbat the system needs ro do. 81Jt tllis ls a complicated system . As Sandra says, woldd
you build a house without a good set of plans?
~~~""
~ h_a_t_l_s_S_y_s_te_m
~ s_A
~n_a_ly_s_i_
s ?~~~~~~~~~~~~~~~~)
In Chapter 3 you learned about the systems de,--eJopment process. In that d1..1pter we
systems aaal}'Sis a
problem.sotvirg technique
that decomposes a system
into its component pieces
for the purpose of studying
howwell those oomponent
parts work and interact to
accomplish thtir purpose.
systems design a complementary probltm.sotving tech·
nique (to systems analysis)
that reassemHes a system's
component pi9ces back into a
complete systtm-hopefully,
an improved S'/stem. This may
irrvotve adding deleting, and
changing pieces relative to the
original syS1em.
iaformatioo systems
aaal}'Sis those development
phases in an information SfStems development project that
primarily focu~ on the busi·
ness problem and require.
ments, independent of any
technology tht t can or will be
used to implement a solution
to that problem.
r eposito,y a. location (or set
of locations) v.here systems
analysts, stS1ems designers,
and system b1.1ilders keep all
of the documE11tation assoc.i.
ated 'Mth one ,r more SfStems or projects.
purposefully limited our dlscu;slon to only briefly examlnlog each ph.ase. lo this
chapter, we take a much closer bok at those ph..,ses that are collectively referred to as
systems aualysls. Formally de6ned In the margin, systems analysis ls the study of a
system and its components. It is a prerequisJte to S}'Stems d esign, the speclflcatlon
of a new and Improved system.Tols ch.apter will focus on systems analysis. Chapter 12
will do the same for systems design.
Moving from this classic definition of systems analysis to something a bit more
contemporary, we see tl1at systttJJS analysts is a term that collectively descrlbes tl1e
early phases of systems developmet1t. Agure 5-1 uses color to ldet1tlfy the sy,tems
analysis phases in the context of the full da55lc route for our FAST methodology (from
Chapter 3). There has never been a wllversally accepted definltion of systems malysls. ln fact, there l1as never been universal agreement on when information s~tem.s
analysis e nds and when infonnation systems design begins. For the purpose of tills
book, iafonnatio11 systems a1ulysis emphasizes business Issues, not tedulicaJ or
implemet1tatlon concerns.
Systems analysis ls drlven by the business concerns of SYSTEM OWNERS and s-c'STEM
USERS. Hence, it addresses the KJ,,OWLf.DGE, PROCESS, and COM."1UNJCATIONS building blocks
from SYSTE.\t ~ s' and 5YSTEM usERs' perspectl,-es.The SYS11:MS ANA1¥STS serve as facilitators of systems analysis. 111.ls context is illustrated In the chapter home page that
preceded the objectives for this chapter.
The documentation and del!verables produced by systems analysis tasks are typl·
cally stored In a repository. A repository may be created for a single project or shared
by all projects and systems. A repository is nonnally lmplemetlled as some combination of the following:
A network di.rectory of word processing, spreadsheet, and other computer.
get1erated flies that contain project correspondence, reports, and data.
One or more CASE tool dlctJonarJes or e ncydopedias (as discussed In
Chapter 3).
Printed documetllatlon (such as that stored In binders and system libraries).
An l11tmnet Web slte Interface to the above compone nts (useful for
commwlicatio11).
Hereafter, we will refer to these components collectl,-ely as the repository.
This dtapter examines each of our flve systems analysis phases In greater detail.
But first, let's examine some overall strategies for systems analysis.
Systems Analysts
Chapter Ftvo
161
BUSINESS.COMMUNITY
START:
Pn:iblllNI,, o,pol!UIIPllt.
Dirt.--, c:ii111,ni1n111,
..,~,
......
FHISH:
-
......
..............
0111..::ow,
• nd'll..on
........
...
~
SYSTEM
OPER4TION
&
MANTENANCE
"'''""
""'"
......
q,rd<nll
8
.
INSTA.U.ATION
OELNEAY
.. --M
·-M
..
.,.
........
...._
..,,
.....
.....
~-L..L..L-~
'-- -,.
:-_,
."'.-,---4~
..
6
,.,.
PH't'&IC.,.L
NTEG:AtlON
~SflCtle•~
( FIG U RE 5 • 1 The Context o f Systems Analysis
)
( Systems Analysis Approaches
Fw1damentally, systems analysis ls about prob(e111 solvi1ig. There.are many approaches
to problem solving; therefore, Jt shouldn't surprise you that there are many app roaches to systems analysis. These approaches are often viewed as co111petl1Jg alternath,--es. In reality, certain comblnatlons can and should actually complement one
another. This was d1aracterlzed in Chapter 3 as aglk methods. Let's briefly examine
the "-arJed approaches.
N011l:The intent here Is to develop a high-level understanding only. subsequent
d1apters ill th.ls tllllt will actually tead1 you the w1derlylng rechnJques.
>
Model-Driven Analysis Approaches
Structti.red anaJysi.s, lnformation engineering, and object.oriented anaJ.ysls are examples of model-dffl"ell analysis. ,.,lodeJ-drtven analysts uses pictures to communicate
model-driVeo aaal)'Sis a
pro~em...solvingapproach that
emphasizes the drawing of
pictorial system models to
document and \El.lidate existing and/or proposed systems.
Ultimately, the system model
becomes the blueprint for de·
signing and constructing an
improved system.
162
Part 1wo
Systoms Analysis Methods
model a representation of
either reality or vision. Since
''a picilJ re is 'M>rth a thousand
words: most models use pictures to repreEent the reality
or vision.
business problems, requlrements, and solutions. Examples of models with which you
may already be familiar Include flowdiarts, structure or hlerarchy charts, and organJ.
zatlon charts.
Today, model.driven approacl1es are almost always enhanced by tl1e use of autc,.
mated roots. Some analysts draw system models with general-purpose graphics software such as ,_Ucrosoft Vlsio. Other analysts and org;ul.izatlons require the use of
repository.1,ased CASE or modellng tools sucl1 as System Arch/tee~ Visible Anal}st, or
Rational ROSE. CASE tools offer the ad-vantage of consistency and completeness
analysis as well as rule-based enor d1ecklng.
Modeklriven analysis approaches are featured In the modekltiven methodologies
and routes that were introduced In Chapter 3. Let's briefly examine today's three most
popubr model.driven analysis approad>es.
Traditional Approaches VariottS tradltlonal approaches to system ai1..1lysls and design were developed beginning In the 1970s. One of the first formal approaches,
which Is stlU widely used today, Is structu.red analysts. Structured anal}'sls foctrses
on the flow of data through business and software processes. It is sald to be processce11..tered. By process-centered, we mean that the emphasis is on the PROCESS building
structured aoal}'Sis a
model-driven, PROCESS·
centered technique used to
1:1ith1:11 i:111Wy£1:1t111 YJ1.t:>011y
bocks in your lnf01'm.ntlon system framewo rk.
system or defile business
requirements lor a new SfStem, or both. lhe models are
pictures that illustrate the
system's component pieces:
One of the key tools used to model processes is tl1e data flow diagram (Figure S.2),
whlch depicts the existing and/or proposed processes In a system along with their lo.
puts, outputs, and data. The models show the flow of data between and through
processes and show the places where data is stored. Ultimately these process m:>dels
serve as blueprints for bush1e.s.s processes to be implemented and software to be
p urcl1..1Sed or constructed.
processes and their associ·
ated inputs, ovtputs, and files.
,
FIGURE S - 2
A Simple Process
Model (Also Called
a Data Flow
Diagram)
'
~
Accounts
c..c1t
,-= ...i.--.._
------,
L _ c.. c1t raUng and lint
'--'-~ - - ~ -
Mam* onlerrMponse
c.edttraUng
and lkntt -
n,tlog
and
llmlt
Bonus ~
o.der ~
Order
- to be
filled
o.der to be
flied
Existing order details
Order to be flled - - ~
~L-''-------~
Revised automatic order
Chapter Flvo
Systems Analysis
plated Dy·
p1aees
&EIIIS;
ISs<>Hon
.
.. ..
,
1, elYOled unoar;
appleS to
genElfflles;
estaDUShEIO by;
generated Dy
astaDI BnaS
18 INtureo in;
•
•
163
FIGURE S - 3 '
A Simple Data
Model (Also Called
an Entity
Relationship
'- Diagram)
• t •
19811.19S
The practice of structured analysis for software design has greatly diminished In
frn,r of object-oriented methods. However, process modeling Is enjoying something
of a re'\oival thanks to the renewed emphasis on bush1ess process redesign, wh.lch ls
discussed L'lter In this ch.apter.
Another traditional approad1, called lnfonnaHon engineering (IE), focuses
on the structure of stored data in a system rather tl1an on processes. Thus, ir was said
to be data-ce11..tered, emph..,slzlng the analysis of KNOWLEDGE (or data) requirements.
The tey tool to model data requirements Is the et1tity rebtlonshlp diagram (Hgure 5-3).
Entltr relationshlp diagrams are stlUwidely used h1 designing relational databases.
Orlglnally, lnformatlon engineering was seet1 as a competing approad1 to struc-
tured analysis. But over time many people made them as complementary: using data
flow dL1grams ro model a system's proces.,es and et1tlry relatlooshlp diagrams to
model a ~tern's data.
Obje<t·Oriented Approach Tr.iditional approaches deUber.itely separat ed the
concerns of KNOWLEDGE (data) from those of PROCES.515. Although mosr systems analysis methods attempted to ~·nchron.ize data and process models, the attempt did not
a lways work well lo practice. Object technologies have since emerged to elimloate
this artlfldal separation of data and processes. The object-oriented appro<1ch
vlews information systems not as data and processes but as a collection of objects
that encapsulate data and processes. Objects can contain data attributes. However,
the only way to create, read, update, or delete an object's data is through one of Its
embedded processes (called methods). ObJecr-orlenced programmJng languages,
sud, as Java, C+ + , and the .NET languages, are becomlng Increasingly pop,tlar.
The object-oriented approach h ..,s a complete sulte of modeling tools known as
the Unified Modeling L,nguage (UML). One of the UML diagrams, an object dass
diagr:am, is shown In Figure 5-4. Some of the Uf.fl tools have gained acceptance for
systems projects even when the lnfonnation system will not be Implemented with
object-oriented technologies.
>
Accelerated Systems Analysis Approaches
Disco,-.')' prototyping and rapid archltected developmetll are examples of accelerated systems analysis approaches that emphasize the construction of prototypes to
more rapJdly idet1tify business and user reqttlrementsfor a new ~·stem. ,_lost sud1 ap.
proaches deri,-e from some variation on the construction of prototypes, workh1g but
incomplete samples of a desired system. Prototypes cater to the .. 111 know wl1at I
want when I see tr• way of thinking that is characteri.51:ic of many users and mai1..1gers.
By ..incomplete; we mean that a prototype will not Include the error checklng, Input
data validation, security, and processing completeness of a finished application. Nor
will It be as polished or offer the user help as in a flnaJ system. But because it can be
i.aformatioo eogineetitlg
(IE) a model-diven and
DATA·e&ntered, bJt PROCESS-sensitive, techn(lue for planning, analyzing, and designing
information sy"S'ems. IE mod·
els are pictures that illustrate
and synchronize the system's
data and proces.ses.
object the encapsulation of
the da1a (calledpmpottiss)
that describes a discrete per.
son, object, place, eveni or
thing, with all of the processes
(called tn9t uxfSJ that are allowed to use or update the
data and proportioe. Tho only
WS!f to access er update the
object's data is 10 use the
object's predefired processes.
object-orieoted
approach a model-driven
technique that integrates data
and process concerns into
constructs called ctJjects.
Object models are pictures
that illustrate the system's
objects from various perspec.
tives, such as the strucil.lre,
behavior, and interactions of
the objects.
prot0type a small-scale, in.
complete, but W)rking sample
of a desired system.
164
Part 1wo
Systoms Analysis Method s
.
FIGURE S - 4
An Object Model
(Using the Unified
Modelins Language
Standa rd)
...
.
has record f or>
o.:
TRANSCRIPT COURSE
developed quicldy, it can qulckly identify the most crudal of business.level require.
ments. Sometimes, prototypes can e\--olve into the actual, completed inforrmtlon
systems and applications.
ht a sense, accelerated ai1.alysls approad1es place much emphasis on the COMMUNICATIONS bulldhtg blocks in your information system
framework by constructing sam-
ple fonns and reports. At tl1e same time, the software tools used to bulld prot<xypes
also address tl1e DATA and PROCES bulldlng blocks.
These accelerated approaches are common In the rapid application de,"'elopment (RAD) metl1odologles and routes that were introduced In Chapter 3. RAD
approaches require automated rools. Whlle some repository-based CASE tools lnclude
very simple RAD facilltles, most analysts use true RAD programming environments
such as Sybase Po·u;erbu.tttter, l\Ucrosoft Access, ~ucrosoft Yfsuat Baste .,ver; or IBI\t
Websphere Studio for ApplicaNo11 Development {lava.based).
Let's briefly examine two popt~ar accelet11ted analysis approaches.
disco,·ery prototyping a
technique use1 to identify the
users' business requirements
by having them react to a
quick-and-dirty implementa·
tion of those requirements.
Oi1<overy Prototyping Discovery prototyping uses rapid development tedmo~
ogy to help users discover thelr business requirements. For example, ft Js very common for ~·stems analysts to use a slmple development tool like t.Ucrosoft Access to
rapidly create a simple database, user Input forms, and sample reports to solicit user
responses as to whether the database, forms, and reports truly represent business requirements. The Intent Is usualtl to develop the final new ~·srem in a more sopllistlcated appUcatlon development tool and L1nguage, but the simpler tool allows the
analyst to more qulckJy prototype the user's requirements.
In dlscovery prototyping, we try to dlscourage users from becoming preoccopled
with the flnaJ "look and feeJ• of tl1e system prototypes- that can be changed during
system design! Therein lies tl1e primary crltldsm of prototyping- software tempL1tes
exlst ln prototyping tools to quickly generate some very eleg.,nt and ,isually appealing
prototypes. Unfortunately, this can encourage a premature foctis 011, and commitment
to,deslgn represented h1 the prctotype. Users can also be misled to believe(l) tlut the
completed system can be built just as rapidly or (2) tl1at tools like Access can be used
Systems Analysis
Chapter Flvo
16S
to build the final system. While tools like Access can indeed accelerate systems de,--eJ.
opmmt, their use In d!sco.-ery prototyping Is fast only because we omlt most of the detailed database and application programming required for a complete and secure
applJcatlon. Also, tools like Access typically cannot support the database sizes, number
of users, and network tra.fflc that are reqttlred of mosl enterprise applicatlons.
Regardless, discovery prototyping is a preferred and recommended approach.
Unfortunately, some systems analysts and de.-elopers are using dlsco.-ery prototyping
to completeJy replace modeJ-drJven desJgn, only to learn what true engineers
have known for years: you cannot prototype without some amount of more formal
design ... enter rapid archltected analysis.
Rapid Architected Analysis lfapld archltected analysis Is an accelerated analysis approach that also builds system models. Rapid a,chJtecture analysis Is made possible by reverse-engineering technology that Is Included In many automated tools
such as CASE and programmlng languages (as Introduced In Chapter 3). Re.-erseenglneerlng tools generate system models from existing software applications or
system prototypes.11,e rest~tlng system models can d,en be edited and lmpro.-ed by
systems analysts and users to pro'\oide a blueprint fot a new and lmpro,--ed system. It
~hot1ld be appaccot th.1.r capld .ucbitccted ana.ly:,l:, b a blendJng of n1odeJ-dctven and
accelerated analysis approaches.
There are two dlffere11t tedmlques for applying rapid archltected analysis:
btost systems have already been automated to some degree and ex.1st as
leg.,cy Information systems. Many CASE tools cm read the underlyh1g data-
base structures and/or application programs aild reverse engineer them into
Tarlous system models. 111ose models ser,--e as t point of departure for defining model-drJvet1 user requirements analysis.
If prototypes ha>.. been built Into tools Uke Microsoft Access or Visual Baste,
those prototypes can sometimes be reverse engineered into their equJvalent
system models. Toe system models usually better lend themsel.-es to analyzing
the users" requlremetlls for consistency, completeness, stahlllty, scalablllty, and
OexibiUty to future change. Also, the system models can frequently be forward
engineered by the same CASE tools and ADEs (appUcatlon de.-elopment
en'\oironruents) lnto databases aitd application templates or skeletons that will
use more robust enterprise-level database and p-ogramrolng tedu1ology.
rapid arcb.itected
analysis an approach that
attempts to deri'Je system
models (as described earlier
in this section) from existing
systems or discovery
prototypes.
re,·erse eogi.neeri..og the
use of technology that reads
the program code for an existing database, application pro.
gram, and/or us;r interface
and automaticaty generates
the equivalent S'/stem model.
Both techniques address the pre.-Jous Issue that engineers rarely prototype In the
total abset1ce of a more fonna l design, and, at the same time, they preserve the
ad-vantages of accelerating the systems analysis phasts.
>
Requirements Discovery Methods
Both model-drJven and accelerated systems analysis approad1es attempt to express
user reqttlrements for a new system, either as models or as prototypes. But both approaches are, In turn, depet1detll on the more subtle need to actually Identify and
matuge tl1ose reqttlrements. Fttrthermore, the requk'ements for systems are dependetll on tl1e analysts' abiUty to dlsco.-er the problems and opportunities that exist In
t11e current system- thus, analysts must become skilled In ldentlfyfng problems, opportunities, and reqltlrements! Consequently, a ll approaches to systems ai1..1Jysis require some form of req,1lremei1ts discovery. Let's briefly survey a couple of
commo11 requ.lrements discovery approaches.
FacHinding Techniques Fact-fhtdiug Is an essentlal skill for all systems analysts.
The fact-6ndh1g redmlques co.-ered In this book (In fie~ In the next chapter) Include:
Sampling of ex..lsting doctunet1tation, reports, fonns, files, datab.1Ses, and memos.
• Research of relevant Uteratu.re, benchmarking of others• solutions, and sJte visits.
requiremeot! discove,y
the process, used by systems
analysts, of ider1tifying orex.
trac.ting syS1em oroblems and
solution requirements from
the user community.
fact-fiodiog tile process of
collecting inforrration about
system problems, opportunj..
ties, solution requirements,
and priorities. Ato called
inbtmatioo gat"i9fing.
166
Part 1wo
Systoms Analysis Methods
Observation of the curret1t system lo action and the work environment
Que.stioru1..1lres and surveys of the management and user community.
Interviews of appropriate managers, users, and tedmlcal staff.
cation of the JRP techniques
Joint Requirements Planning TI1e fact-finding teduliques llsted above are invaluable~ however, they can be time-consuming In their dassJc forms. Alten1atlvely, requirements discovery and management can be signlftcantly accelerated using joint
requirements planning ()RP) techniques. A)RP-tr.llned or .cert!Jled analyst usually
plays the role of facilitator for a workshop that will typlcally run from three to five
full working days. Thls workshop can replace weeks or months of dasslc fact.fludlng
and follow-up meetings.
JRP provJdes a working en,·ironment In which to accelerate all systems arulysis
tasks and deUverables. It promotes ert11..mced SYSTEM OWNf.R and ~ USER participation in systems analysis. Bttt it also requires a fadlitator with superior mediation
and negotiatio11 skills to ensure that all parties receive appropriate opportwlitles to
contrlbute to the system's de,--etopment.
JRP is typically used In conjunction with the modeklriven analysis approad1es
we described earlier, and It ls typically Incorporated Into rapid application develop,
to thA AntirA ~r.:iri:im.<: c1AVAlnp.
ment (RAD) methodologies and routes (which were introduced in Chapter 3).
joi.ot requirements
planning O RP) the use of
facilitated workshops to bring
together all of the system
owners, users and analysts
and some sys:ems designers
and buik:ters to jointly perbrm
systems analysis. JRP is gen.
era! ty consktered a part of a
larger method called joint ap.
pNcalcn dwe/opfTl"'1t (JAD),
a more comprehensive appli.
ment process.
>
business process
r edesign (BPR) the
application of systems analy.
sis methods tc the goal of
dramatically changing and
improving the fundamental
business processes of an
organization, hdependent of
information technology.
Business Process Redesign Methods
One of the most Interesting contemporary applications of systems analysis methods ls
buslness process redesign (BPR). The Interest In BPR was driven by the dlscovery
that most cturent Information 5'/stems and applications h.ave merely automated existing and inefficient business processes. Au tomated bureaucracy ls still bureaucracy;
automation does not necessarllr contrlbute value to the business, and It may acnr.illy
subtract value from the business. Introduced !11 Chapter !, BPR ls one of many types
of projects triggered by the trends we call total quality numageme11t (!'QM) and
co11.tl11uous process i111prove1nent (CPI).
Some BPR projects focus on all business processes, regardless of their
automatlo11. Each business precess ls thoroughly studied and at1alyzed for l>,nJeneck.s, value returned, and opportunities for eliminatio11 or streamlining. Process
models, such as data flow diagrams (discussed earller),help organizations visualize
their processes. Once the busi.oess processes l1ave been redesigned, most BPR projects conclude by examlning how Information technology mlght best be applied to
the Improved business processes. This may create new Information system and
application development projects co implemenc or s upporc cbe new bustness
processes.
BPR ls also applied within d,e context of Information system development pro.
jeers. It ls not llllcommon for IS projects to indude a study of existing business
processes to ldet1tlfy problems, bureaucracy, and lneffidet1des that can be addressed in requirements for new and Improved information systems and computer
applications.
BPR has also become common In IS projects that will be based on the purchase
and h1tegration of commercial off-the-shelf (COTS) software. The purchase of COTS
software usually requires tl1..1t a business adapt its business processes to flt tl1e software. An analysis of exlstlng bush,ess processes during systems analysis Is usually a
part of such projects.
agile method the integra.
tion ofvariousapproaches of
systems analysis and design
for application as deemed ap.
propriate to the problem being
solved and th, system being
developed.
>
FAST Systems Analysis Strategies
Uke most commercial methodologies, our hypothetical FAST methodology does not
Impose a single approad1 on systems analysts. Instead, It Integrates all the pop,tbr ap,
proaches introduced In the preceding paragraphs Into a collection of agile methods.
11,e SoundStage case study will demonstrate these methods h1 the context of a typical
Systems Analysis
first tsslgnment for a systems analyst.The systems analysis teclmlques will be applied
within the framework of:
Your information system building blocks (from a,apter 2).
Toe FAST phases (from Chapter 3).
FAST tasks that Implement a phase (described In this chapter).
Given this context for studytng systems ai1..1lysls, we can 11ow explore the systems
analysis phases and tasks.
( The Scope Definition Phase
Recall from Chapter 3 that the scope tieflnition phase Is the first phase of the classic
systems development process. In other methodologies this might be called the prelt1nl-11ary tnvesffgatlo1i phase, Initial st1,dy phase, Sllrvey phase, or planning phase.
The scope dellnltion phase answers the question, •1, this project worth looking arr
To aa.swer tllis question, we must define the scope of the project and the percetYfd
p rul1h:-1u:s, opi,,ortuu.iliC":s, -.uu.l Jirec..11~.:, lh.tl u·fgge1:~ tlut ptvj~l. &:nuuiug llut pro-
ject Is deemed worth looking at, the scope definition phase must also establish the
project pLm ln terms of scaJe,development strategy,scheduJe, resource requ.lrements,
and budget. 1
Toe context for the scope dellnltion phase is shaded in Figure 5-5. Notice tl1at the
scope definition phase ls concerned primarily with the SYSTEM OWNERS' view of the
existing system and the problems or opportunities that triggered the Interest. System owners tend to be concerned wlth the big picture, not details. Furthermore, they
detetmlne whether resources can and will be committed ro the project.
Figure 5-0 is the first of five task diagrams we wUI h1troduce in this cllapter to take
a doser look at each systems analysis phase. A task dlagran1 shows the work
( = tasks) that sl10,tld be perfonned to complete a pba.<e. Our task diagrams do not mandate any speclflc methodology, but we wlUdescribe in the accompanying paragraphs
the approaches, rools, and reclmlques you mighr wanr ro consider for ead1 rask.
Figure 5-6 shows the tasks requlred for the scope deOnltion phase. It is Important to
remanber that these task diagrams are only templates. The project team and project
man1ger may expand on or alter these templates to reflect the unique needs of any
given project.
As shown in Figure 5-0, the final deUverable for the preliminary in,-.stlgation
ph.ase ls comp letio11 of a PROJOCT CHARTER. (Sud1 major delh,--erables are indicated In
each task diagram In au-capital letters.) A project clwter defines the project scope,
plan, methodology, standards, and so on. Completion of the project d1arter represents
the first milestone In a project.
Toe scope deflnltion ph.ase is intet1ded to be q<tlck. The entire phase shottld
not exceed two or three days for most projects. T he phase typlcaUy includes the
following tasks:
I. I
1.2
I. 3
I. 4
1.5
identify baseline problems and opportunlties.
Negotiate baseline scope.
Assess baseline project worthiness.
Develop baseline schedule and budget.
COrurnwllcate the project pL1n.
ter•s now examine each of these tasks in greater detail
IJf you: oourx or- N'lldi..ns ha• il..lte:ady illocluded Chaptl'.r 4. yo11 ,hould ~ t the.st pla.nbi..ns detnctits u p:,:rt d
prtj«• tnatiagdDeht, Chaptl'.r 4 s u ~ ILlld ~ k d the- ptocc,s u,fd by prtj«t tnatiagdll to dC"O'dop a
prtj«1pbt1,
Chapter Flvo
167
168
Part 1wo
Systoms Analysis Methods
S1tateg1C en1erpr1&e Plan
--"""'""""'
&TA TEIIENT OF
wo ,iec
l" RO BLEII S TATEMENT , • •• ,_, •• • PIECES
.....
IT]
,,,,.,wo,• )
COlll•UNICATlONS
SCOPE
OPE
•
OU $ 1NC6e l'ICOUll'ICMCNTe
•
lll810N
$ T A TCMCNT
~
•~
•••
8U91N£18
PAOCESJ
AEO UIASilENT&
8u&INEi88f; 8 Y8TEII
AEO UIAE• ENT&
•
LOGICAi..
D<TA
LOGICAL
PAOCE8i
•OOEL8
•OOEU
LOGICAL
..TEFIFACE
M00EL8
8U81N£.8$
•z
D<TA
•>
•>
.••
••
•
0
•z
••
~
•,
0
•
•••
•,
•~•
&Y8 TEM P AOPO &A L
(or
..TEFIFACE
JIEOUIAEMENT8
JIE O UE8 f FO A 8Y& TEM PFI OP08AL 8)
APP LI CA TION A R CHITEC T U RE
;
.........
OEalGN
INTERFACE
0£.SIOIN
.•
........ .i
!
COUMEFIOAL
80FTW.V.E
~
0
0
aPECIFICATION8
TR AININ G MATERI A L&
F U N C TION A L 8Y& TEM
OATA8A8E
8 0WTION
PHY81CAL
USER •s'»'8'n•
PHYSICAL
80FTWAl'IE DUlc:¥\1
8 PECIFICATON&
SPECIFICATION&
CU8'1CIM~ILT
i
OPER A TI O N A L SYS TEM
A PPLICATI )N
80FTW.V.E
d
'!
H
n
.
.••'
.
2
~
0
•;
••
~
g
'•
!i!
•~
•~
~
8U8 1NE8$ PJICCE88
tM.TABA8E
1a
,;
~
OE&ION PROTOTYPES
PWY81CAI..
H
USER
0
INTERFACE
80UJT10N8
••
INTERFACE
80UJT10N8
.,.....
PO & T· AUO IT RE VIEW
"""'""
APPA~ eo
INTEFIF..ce
TECHNOLOOIES
Sltateglc Enterpr199 1111:lrmauo-. T&cnnoiogy Ncnnecture
F I G U RE S • S The Context of the Scope Definition Phase of Systems Analysis
u•
u
§
I
•
••
I
•§
t
l
•
•I
~!
Ii
••
5
Systems Analysis
Chapter Flvo
169
' FIGURE S - 6 '
Tasks fo r the Scope
Definition Phase of
" Systems Analysis
PROJECT
CHARTER
!
--.
....
!
problem
.-.
(PIECES)
-- ....•
probh,m
..tementof-...:ri;
projeot ..:hedule
•nd re,ouroe
•••is...,..,ni.
I
Preliminety Pro blem
.,
end ,1,op,
•
.-.,..
.
problem
.tn,me,nl,
-.ith•ciop,
Si.tern, nt -.ith Soope
j
I
>
Task I . I -Identify Baseline Problems and
Opportunities
one of d1e mosc Important t.asks of the scope defln..tuon pt1ase ls escabllshLng an
lnltlu baseline of tl1e p roblems, opportunltles, andior directives that triggered the
project. Each p roblem, opportunity, and directive ls assessed with respect to urgenq•, vlslblllty, tangible benefits, and priority. Any addltlonal, detailed analysis is
not relevant at this stage of the project. It may, however, be useful to list any perc eived constraints (limits) on the project, suc h as deadlines, maximum budget, or
general t echnology.
A setllor systems analyst or project manager usually leads tills task. Most of the
other participants are broadly dasslfled as SYSTEM owr~ s. This includes the executive
sponsor(s), the hlghest~evel manager(s) who will pay for and support the project. It
also lndudes managers of all organlzatlonal unlts that may be impacted by the system
and possibly includes lnfonnatlon ~·stems managers. SVS're.t USERS, svsTE.\.t DESIGNERS,
and """"" BUIU>ERS are not typically involved In tills ttsk.
As shown in Ffgure 5-6, a PROJOCT REQUEST OR ASSIGNMJ.:NT triggers the task.Th.ls trfgger may take one of several altenutt,--e forms. It may be as simple as a memorandum
of authorJty from an Information systems steering body. Or ft may be a memorandum
from a business team or unit: requesting systems development . Some organJz.atlons require tl1..1t all p roject: requests be submltted on some standard request.for-service
fonn,sucb as Figure 5-7.
scope tne oounaaries 01 a
project-the areas of a busj.
ness that a project may (or
may not) address.
170
,
Part 1wo
FIGURE S - 7
Systoms Analysis Methods
'
SoorwlSta,ge Ent ertarlment Club
Rl!OIJES'f l•OR
INl'ORHA'flON
SYS'fllH SllllVICUS
ldormoti<:IJ Sy.tom $erviotw
Phone: '9....0EISI k x ,e,.0999
Internet: t!!!£!~
.• ound11t!9e.eom
Intn,net: t!!!£!~
.eound11t!9e.eom l!!:!;
A Request for
'-Systems Services
DATE.OJ:REOVEST
I
Jenuery 9, 2003
I
SERVla. REQUESTED FOR 0E'ARTM£Nl'{S)
Mem~r Sef'Vioee, Warehouee, Shipping
SUBMITTED BY Ikey u, et' c:ontee.t)
N•me
Title
Offce
,none
....
EJ<ECUTM S,ONSOR (fu:nding eutbority)
....
S•reh Mllrtmen
8ueinefe Ar,elpt, Member Setvioee
'9....0987
TYPE OJ: SERVlCE REOUIESTEO:
0 lnformwtion Stn,t,,gy Pl•nning
0
N•me
Title
Offce
Phone
Buein- Prooefe Atlely'l!i•end Red:l'lfign
New Applioetion Development
Other (pie- epeoify)
0
0
0
Gelen Kirkhoff
Vioe P,.eid~ Mem!Hr &,rvi~
G2A2
49,.12,2
E xitting Applioetion Enhenoemeint
E xitting Applioetion Mei ntenenoe (problem
NotS.u~
fuel
&RIEF STATEMENT 01:'. PAOSLE:M, OPPORTUNITY, OR DIRECTIVE £,erttaoh edditione.l dooum$nt.tion • • n.oMMryl
The informetion ttrd:t9Y pl,nning gro up h•• tor9eted mem.ber.ervffl, m..,ktting, ,nd or-dorfulfillment (inolwivo
of $hipping} for- b~ine., prooo• • rodooign N integr~d opplioetion dovebpm,ont. Currently • orviood by•opertte
informetion •v-tomt, thete oro•• ,ro not well int$9r•d to m~m.i:re e-ffioiont order • orvioo• to our m.ombort. The
~•·" -"' "'V.,.,.,....,.,.,""" .....,,......hi•'""'·"
"'l'idl,,nh"'"Oi"O (""'4•......, ""d _...,,..._ 1,. .,....,..,.. _
_p,,,_ .................
ox ~ for • imi ~r prod~ ond oorvioo• . Som, of thooo • ~m• were inherited through m.$r9e,- thc,t expended our
produc:it• ,nd • -ffl. Thero obo ex~ • ove·ol m,rutirig opportunitie.to inoro- our p , -noe IO our mem.bert.
Ono oxom,ple ird udo• Internet oommeroe •rvioo• . Fin,lly, tho automatio idontifioetion tyttem. being d eveloped fo,
the w ,rohouoo mutt fully int$ropor.co with nombor • orvioe..
&RIEF STATEMENT OF EXPECTEO SO LUTIQI.I
W o onvioion oompl~ly n- ond ttreom.lined bwin- prQOl!!Mtf that mi nimito the '"PonM time IO m.ombor
orde,- for pro d uou and oervioo• . An or<hr o'1oll not be OOl'$ider-ed fulfilled until it h•• been reoeived by the
member. Tho n- ..,.com • hould provide for- expended olu b and m.ombor flexibility aid tdeipttbility of b,oio
bueinoo• prod~ ond oorvioo• .
W e onvioion a¥tem thc,t exten~ to th, do•ktop oomputeu cl both omployoo• and m.ombort, w ith ,pproprft
• hor•doervioo• provided toroeo the networ•, oon•~ent with the ISS d~ibuted ,rohitecture. Thio it oon•~ent wit',
etr•gio pl,._ to rfbre th• AS/400 oent,.1 oom.p.ltl!lr •nd repla:ie it w ith • orveu .
ACTION tlSS Offiot UM Only}
0
k•fib ility , .._ m•nt opprcwfd
l!I kffib ility . .._ mfnt Wf.ivfd
AMig ntd t.o S•.ndr• Sh!f:h•fd
Approvfcl ludg,rt I
St.r10.t•
ASAP
0
RoquHt d•I•.,..
a .clcbg g.ci until d.t•:
0
RoquHt r•i-,ct•d
R-t1:
Authoriifd Signe'll.ltM:
I<e.lz~c,«; J
r.h.-i,. 1i::i::
--rr2.J)
c..,.,....;... i;:._..;.,o Cindy
.SO,QOO
O••dlin•
....
~1.r.aK~
~ - ·c-::"~.
l'ODI IJ5.l«MUS' <1--- - 0..00.,N, Im)
The key deliverable of this task, the PRELIMINARY PROBLE.\t STATEMENT. consists of the
problems, opportunlcies, and directlves ci1at were ldet1tlfled. T he PROBLEM STATE!dENrS
are stored In the repository for later use ln the project. Figure 5-8 Is a sample d0ct>
ment that summa rizes problems, opporrunltles, an d directives in terms of:
Urgency -In what time frame must/should the problem be soh,"f!d or the
opportunity or dlrectlve be realized? A r1ltlng scale cot~d be developed to
consistently ailSWer this question .
Vislbfllty- To what degree wot~d a solution or new system be visible to
customers an<Vor executive management? Again, a rating scale could be
developed for the answers.
Benefits-Approximately how much would a soJution or new system lncrease
annual re,-enues or reduce annual costs? This Is oftet1 a guess, bur if all participants are Involved in that guess, it should prove sufficiently conservaffi"e.
Systems Analysis
Chapter Flvo
171
Problem Statements
Pro.ecti
Member seivices information system
Prtject ma,ageri
SiJldra Shepherd
Created by,
SiJldra Shepherd
Last updated by,
Robert Matinez
Date last i.pdated1 Janua,y 15, 2003
Date created1 Janua,y 9, 2003
Brief Statements of Problem,
Opportunity, or Directive
1, Order response time as measured fiom
time o f order receipt to time o f custamer delwef'Y has increased to an
Annual
Urgency
Vlslblllty
Benefits
Priority
or Rank
Proposed
Solution
ASAP
High
$175,000
2
New da'elopment
2. The recent acquisitions o f Private
Screenings Video Club a,d GameScreen w ill further stress the througlp ut requirements for the a .11rent system.
6 months
Med
75,000
2
New da'elopment
3. CUrrently, three different order entry
systems setVice the a.Jdio, video, and
game dt.'isions, Each system is designed to interface with a different
warehousing system; therefore, the
intent to merge inventory into a single
warehouse has been delayed.
6 months
Med
515,000
2
New da'elopment
4, There is a general lack of access to
management and decision-making
information, This w ill become exasperated by the acquisition of two
additional order processing systems
( from ~ivate Screenings and Game-
12 months
Low
15,000
3
average of 15 dais.
After ne,.,, system is
developed, prc,.,ide
userswUh
easy-to-learn and
" se reporting tools.
Screen).
5. There currently exist data inconsistencies in the member a,d order
files.
3 months
High
35,000
1
Q.Jick fix. then reN
development
6. The Private Screenings aid
GameScreen file SJStems are
incorrpctib le \Mth the SoundStage
eq.Jivalents, Business data problems
include data inconsistencies and lack
o f input edit contiols.
6 months
Med
Unknown
2
New da'elopment.
A.dditioral auantification of benefit
mig,t increase
urgency.
7. There isan oppatunitytocpencrder
systems to the Internet, b ut security
and contiol are a, issue.
12 months
Low
Unknown
4
~uture wrsion of
newly
developed system
8. The a .11rent crder entry system is
incorrpctib le \Mth the fathcoming
automatic identification (bar<oding)
S)'Stern being developed for
the warehouse.
3 months
High
65,000
1
Q.Jick fix. then reN
development
( F I G U R E S • 8 Sample Problem Statements
)
172
Part 1wo
Systoms Analysis Method s
.Prf.orlry- Based on the above ai1SWers, what are the consensus prlorftles for
each problem, opportunity. or directive. If budget or sched,de becomes a
problem, these priorities will help to adJust project scope.
Possible solutr.ons (OP1)-At this early stage of the project, possible sole.
tlons are best expressed in simple terms such as (a) )eave well enough alone,
(b) use a qtdck ftx, (c) mal:e a simple to moderate enhancement of the existing system, (d) redesign the existing system, or (e) design a new system. Toe
participants listed for this task are well sulted to an appropriately high.level
discussion of these optlon.s.
111e PIECF.S framework that was Introduced In 01..1pter 3 can be used as a framework
for categorizing problems, opportunities, directives, and constraints. For example,
Problem I in Figure 5-8 could be dass!Jled according to PIECES as PB. - Perfonmnce,
Response TI mes. (See Figure 3-4 in Chapter 3). Problem 4 in Figure S-8 could be clas-
sUled as l.A..2- lnfonnation, Outputs, Lack of necessary lnformatlon .
The primary technlques used to complete this task Include fact.finding and meeting.1 with~ OWNERS. These 1ecboiques are taught ln Chapter 6 .
>
Task 1.2-Negotiate Baseline Scope
scope defines ti,e bo,u,dary of the project- d1ose aspects of the business tbat will and
will not be Included in the projEct. Scope can change during the project; however, the
initial project plan must establish the preliminary or baseline scope. Then If the scope
cbanges slgn!Jkantly, all parties in,-.,J,-ed will have a better appreciation for why tl,e budl!l't and schedtde bave also chang;,d.This task can occur in parallel with the prior ttsk.
Once again, a senior ~terns analyst or project manager usually leads this task.
Most of the oti1er participants ate broadly dassUled as SYSTEM OWNERS. This Includes the
executive sponsor, managers of all organizational units that may be Impacted by the
system, and possibly information ~·stems mai1..1gers. SYsTfl\l USERS, SYSTE.\t DESIGNflt\ and
SVSTEN BUIU>ERS are not typically 10,-olved lo tills task.
As shown In Agure 5-0, this task uses the PREUt.DNARY PRO BUl\l S'J'ATE.>,.{E'II( produced
by the pre>ious task. It sho,dd make sense that ti1ose problems, opportunities, and dlrectfves form the basis for defining scope. TI1e S'J'ATJ:ME'l(J'S OF PROJECT SCOPE are added
to the repository for larer use. These statements are also formally doa1mented as the
task deUverable, PR WMCNARY PROJ!,LJ:M STATfMENTWTTH SCOPE.
Scope can be defined easily w!dlin the context of your Information system building blocks. For example, a projoct's scope can be described lo terms of:
What types of DATA descrll:,, the system being studied? For example, a sales
information system may require data abour such tllings
PRODUC'J'S,
and SA.LES
What business
as CUSTOMERS, o ROms,
R.EPRES~trATIVES.
are included ht the ~tern being stud.Jed? For example, a sales information system may lnclude business processes for CATALOG
PROCESSES
M.ANA.G~ CUSTOMER M.ANA.G~ ORDER lllll'RY, O RDER FULftLLMENT, ORD f.R
and CUSTOMER lll.ATIONSHCP MANAGEMENT.
How must the ~tern tNTElfACE with users, locations, and other systems? For
example, pote11tlal Interfaces for a sales Information system ndght Include
M.ANAGe,.mr,n',
CUSTOMERS, SALES 11.EPR.ESENTATIVES, SA.LES Cl.f.RKS AND MANAGERS, REGIONAL SAJ..ES OFFICES,
and the
ACCOUNTS R.OCflVABLH
and
lN\'E'lll"ORY CONTROL lNFOR..\tATION ~ .
Notice that each statement of scope can be descrlbed as a simple list. We don't
necessarily .. define,. the Items lo the list. Nor are we very concerned wlth precise requirements ai1..1lysis. And we dtfinlt:ely are not concen1ed with any time-conslmlng
steps such as modeling or prototyping.
Once again, the primary technlques used to complete this task are fact-finding
and meetings. Many analysts prefer to combine this task with both the pre>iom and
the next tasks and accomplish them wltbin a single meeting.
Systems Analysis
>
Chapter Flvo
173
Task 1.3-Assess Baseline Project Worthiness
Thls is where we answer the question, "ls this projea worth looklng at?" At this early
stage of the project, the question may actually boil down to a • !,est guess· : WIU solving the problems, exploiting the opportunities, or fulfilling tbe directives return
enough '\o'alue to offset the costs that we will incur to develop this system? It ls
Impossible to do a thorough feasibiUty analysis based on the Umlted facts we"ve
collected to date,
Agait1, a senior ~·stems ai1.alyst or project manager usually leads this task. But the
SYSTE\I oWNERS,Jndusfve of the executi,. e
. sponsor, the busines., unit managers, and the
information $)'stem.s managers, should make the decision.
As shown In Figure 5-6, the completed PREU~ARY PRO BLE.\.1 STATEMENT WITH SCOPE
triggers the task.11lls pro>ides the level of information required for this preliminary
asse!sment of worth. There is 110 physJcal deliverable other than the GO OR NOGO
DECISION. There are actually several altematt,--e dedsloru.111e project can be appro,-ed or
canceled, and project scope can be renegotiated (Increased or decreased!). Obviously,
the remaltllng tasks In the prelimlnary lnvestlgatlon phase are necessary only If the
project has been deemed worthy and approved to continue.
>
Task 1.4-Develop Baseline Schedule and Budget
If the project has been deemed wortl1y to concinue, we can now plan the project in
depth. The ltlltlal project plan sho,dd consist of at least the following:
A preliminary master plan that indudes schedule and re.source assignments
lor the encire project. Thls plan wlU be updated at the e11d of ead1 phase of
the project. It is somecimes caUed a baseline plan.
A detailed plan and sd>edule for cornpletit1g tbe next phase of tl,e project
(the problem analysis phase).
The task is tl,e responslbiUty of tl,e project manager. Most project managers fit1d
it useful to lndude as much of the project team, lnduding
DESIGNERS, and BUUDERS,
SYSTE.\t OWNERS, usms,
as po~ible. a1apter 4 coined the term joint projeaplan-n ing
to dtscrlhe the team approach to bulldit1g a project plan.
As shown in Figure 5-0, tills task ls triggered by the GO OR NC>GO DECISION to continue the project. Th.ls dedslon represents a consensus agreement on the project's
scope, problems, opportunities, directives, and wortlllness. (lllis "wortlllness•
must still be presented and approved.) 111e PROBLEM s r ~ wrra SCOPE are the key
lnp<n (from the repository). The deliverable of this ta<k is the BASWNE PROJECT PLAN AND
SCHEDULE. TI1e STATE.~ Ofl WORK (see Chapter
ASSJG:-wENTS
4) and PROJ.f.CT SCHEDULE AND RESOURCE
are also added to the reposJtory for continuous monitoring and, as
approprL1te, updacing. The schedtde and resources are typically maintained in the
repository as a project mai1..1gement software file.
The techniques used to create a project plan were covered in depth in Chapter 4.
Today, these techniques are supported by project management software such as
~Ucrosoft Project Chapter 4 also discussed the detaUed steps for completing the plan.
>
Task 1.5-Communicate the Project Plan
In most org.ulii.atlons, there are more potential projects than resources to staff and
fond those projects. Unless our project has beet> predetermined to be of the hlghest
priotlty (by some sort of prior tactlcal or strategic pbrullng process), then lt must be
prese11ted and defended to a steerl.tig body for appro'\o-a.l. ,_lost organizations use a
steerlng body to approve and mo1lltor projects and progress. 11,e majorlty of any
steering body should consist of non-information systems prof~Jonals or managers.
,_lany organJzatlons desJgil..1te "ice presidents to serve on a steerlng body. Other
steering bod)' a committee
of executive business and
system managers that studies
and prioritizes ~ mpeting proj.
ect proposals to deterrn ine
which projects will return the
most value to tha organization
and thus should be approved
for continued systems devel.
opment. Also called a steering
ccmmittee.
174
Part 1wo
Systoms Analysis Methods
organlzatlons assign t11e dlrect reports of vice presidents to the steering body. And
some organJzatlons u tilize two steering bod.Jes, one for vlce presJdents and one for
their direct reports. lnfonnatlon systems managers serve on the steerlng body only to
answer questions and to communicate priorities back to developers and project
managers.
Regardless of whether or not a project requlres steering committee appro..t, It ls
equally Important to formally L,unch the project and commwllcate the project, goals,
and schedule to the entire business commwlity. Opening the lines of communication
is an important capstone to the preliminary investigation. For this reason, we advocate
the ...best practices" of conducting a project kickoff eve11t and creating an l11tra11et
project Web sue. 111e project kickoff meeting ls open to the entire business comnn•
nity, not Just the bush1ess wlits affected and the project team. TI1e lntranet project
Web site establishes a community portal to all nonsensitive news and documentation
concerning the project.
Ideally, the executive spo1uor should Jointly facilitate the task with the chosen
project manager.111e >islbillry of the executive spo1uor establishes Instant credbiUty
and priority to all who participate In the kickoff meeting. Other kickoff meeting participants sho,dd inciude the entire project team, including assigned SVSTEN o1'NE!s,
USEllS, ,\.NA.t¥£TS, omtcNms, :ind ButLOms. Ideally, the kicko ff meeting dlo ldd be open ro
any and all Interested staff from the bush1ess community. Tols bullds commwllty
awareness and consensus wh.lle reducing both the volume and the consequences of
rumor and misinformation. For the lntraoet component, a Webmaster or Web author
should be assigned to the project team.
As shown h1 Figure 5-6, this task ls triggered by the completion of the BASEUNE
PROJ.f.CT PLAN AND SCHIDUI.£, The PROBLEM STATfl\lml'S ANO SCOPE
are
avalL1bl e from
the
reposltory. The deUverable ls the PROJECT CHAJtTER. 111e project charter ls usmlly a
docttment. It lndudes "-arJous elemet1ts that define the project In terms of p articipants, problems, opportunitle.s, and directfves; scope~ methodology; statement of
work to be completed; deliverables; quality standards; sci1edule; and budget. 111e
project charter sho,dd be added to the project Web slte for all to see. Elements of the
project d1..1rter m.1)' also be refonnatted as slides and handouts (using software such
as ~ficrosoft Pou:erPo-1111) for Inclusion ht the project klckoff event
Effective Interpersonal and commwlicatlons skills are the keys to this task. These
include principles of persuasion, selling d,ange, business wrlth,g, and puhUc speaking.
This conciudes onr discussion of the scope definition phase. Toe participants In
the scope defulltlon phase ollght decide the project ls not wonh proposing. It is also
possible the steerh1g bod)• may decide that other projects are moro Important. Or ti1e
execurtve sponsor mlghc not ertdorse the project. ln each of these uucances, the protect ls tennlnated. Little time and effort have been expended. On the other hand, with
the blessing of all the ~tern owners and the steerlng committee, the project can now
proceed to the problem analysis phase.
~~~T_h_e_P_r_o_b_le_m
~A
_n_a_l_y_s_is_P
_h_a~se~ ~~~~~~~~~~~~~~)
111ere is an old saying, .. Don't try to fix ft unless you w1derstaod It." That statement
aptly describes the problem a,udysrs phase of systems analysis. There is always 2 cnrrent or ex..lstlng system, regardless of the degree to which ft ls automated wlth infor.
matlon tedu1ology. 111e problem ai1..1lysis ph.ase provides the analyst wlth a more
thorough w1derstandlng of the problems, oppomullties, and/or dlrectlves thal triggered the project. The problem analysis phase answers tl1e questions, •Are the prof>.
Jems really wortl1 solving?" and "ls a new system really worth building? .. In other
metl1odologles, the problem an.tlysls phase may be known as the stu.dy phase, #udy
of the current system, deta(.{ed tnvesttgat/011 phase, or feaslbillry analysts phase.
Can you ever skip the problem analysis phase? Rarely! You almost always need
some level of understandJng of the current system. But there may be reasons to
Systems Analysis
acceler.ite the problem analysis phase. First, If the project was triggered by a stnteglc or tactical plan, ti1e worthlness of the project Is probably not in doubt - the
problem analysis phase wouJd be reduced to w1derstanding the current system,
not analyzing It. Second, a project may be Initiated by a directive (such as comp!J.
ance wlth a governmental dfrectlve and deadline). Again, In this case project worthJness is not In doubt. Finally, some methodologies and organ.izations deliberately
consolidate the probJem at1alysls and requirements analysis phases to accelerate
systems analysis.
The goal of the problem analysis phase ls to study and w1derstand the problem
domain well enough to thoroughly analyze its problems, opportunities, and constraints. Some metl1odologies encourage a very detailed lUlderstanding of the curret1t system and document that system in painstaking detail using system models
such as data flow diagrams. Today, except when business processes must be redesigned, the effort required and the value added by such detailed modeling Is questioned and usually bypassed. TI1us, the current ve,slon of our hypothetical PAST
methodology encourages only ettough $)'stem modeling to refine our understan ding
of project scope and problem staremenr, and ro ckfine a common vocabulary for
the system.
The context for the problem :U.t..'llysis plt..'lse is sll:ided in Figure S 9. Notice tlt..'lt
the problem analysis ph.ase ls concerned primarily with both the SYSTE."1 OWNERS'
and the ~ usms• views of the existing system. J\'otlce that we build on the lists
created In the prelimloary ln,--estlgatlon p hase ro ai1.1lyze the KNOwt.EDGE, PROCESS, and
OOMNUNICATIONS bulldlng blocks of the existing syslem. Also notice ti1at we Imply
mJoim.al system modeling . We may still use the PIECF.S framework ro ai1..1lyze each
building block for problems, causes, and effects.
Figure 5-10 ls the task diagram for the problem attalysls phase. T he final phase deliverable a nd milestone is producing ~ IMPROVfMENT O BJOCTIVES that add.res., prob.
!ems. opportunities, and directives. Depe11dlng on ti1e size of the system, Its
complexity, and ti,e degree to whlch project worthiness Is already known, the IUustrated tasks may consume one to six weeks. ,_lost of these tasks can be accelerated by
JRP-like sesslons.11,e problem analysis phase typlcallj• lndudes the followi ng tasks:
2.1
2.2
2. 3
2.4
2.5
2.6
Understand the problem domain.
Analyze problems and opportwllties.
Analyze business processes.
Establish system lmproveme11t objectives.
Update or refine the project plan .
Commwlicate Bndin.e:s ai1d recommettdatlons.
Let's now examine each of these tasks in greater detail.
>
Task 2.1-Understand the Problem Domain
During ti,e problem analysis phase, the team ltlltially attempts to team about tl1e Cttr·
rent ~tem. Each svsTE."1 OWNER, usm, and ANA.CYST brings a dJfferenr level of understand.fog to the $)'stem- different detail, different vocabulary, different perceptions,
and dJfferenr opinions. A well-conduct:ed study can prove revealing ro all parties, lod udi.1g the system's own management and users. It fs important to study and u.11dersta1ul the problen1 donU1i11, tl1..1t domain in wbid 1 the business problems,
opporttmlties, directives, and constraints exist.
This task will be led by the project manager but facili tated by the lead systems
analyst. It is nor uncommon for one lndi"idual to phy both roles (as Sandra does lo
the SoundStage case). Other SYSTE.\SS ANALYSTS may also be involved since tl1ey conduct inter'\oiews, scribe for meeting.,, and docttmtnr findings. A comprehensive
stud~· should include representative SYSTEM OWNERS and USERS from all business wt.its
that will be supported or Impacted by ti1e system and project. It ls extraordinarily
important tl1at enough users be induded to e ncompass the full scope of the
Chcpter Flvo
17S
176
Part 1wo
Systoms Anclysls Methods
Stta'3gle Enlerprl&e Plan
---
00111:
1mp-8U1N•
PFIOCESSlS
ICNCJWLEDOE
~a
& TATEMENT OF WOIIIK
l"RO BLEM 8 TA TEMEIIT , ••• ._, t h, l"IECE8 ,,, .. ,wofk)
-·
.......
IT]
SCOPE
•
•
VISION
lre •ework)
8 Y8 TEM IMl" aOVE.ENT OBJECTIVE& (•1l1t9 t ltl l"IECE&
i"
9USIN£$
8U&INE88f; 8 YSTE1,1
PROCEilH
••••
OU81N£.8&
DUA
AEO UIAB,IEN'T&
AEOUIAQIIENT&
INTEFIFACE
AEOUIAEMENTS
LOGICAL
>
LOGICAL.
DUA
•oon.e
'
~
•
•
I
'
'
••
••
>
•••
•,
•oow
(or
H
LOGICAL
INTEFIFACE
IIOOEUI
PROCEilH
&Y8 TEM PAOPO &A L
1-
COlll•UNICATIONS
SCOPE
RE O UE8 f FO A 8Y& TEII PR O P 08AL 8)
m
~
t
~
.•
0
.........
8U8 1NE8$ PJICICE88
PHYSICAL
ueER • snn •
INTERFACE
PHY81CAt.
&OFTWAAE DE.&1(;114
OE81GN
af'ECIFICATION8
8 PECIFICAll)IC&
TA AIION O MATERI A L&
FUN C TION A L 8Y& TEM
.•
OAll.8.ASE
s ownoH
~
0
i
COM• EAOAL
8 0FTWAF.E
""""''"
CU810M.SUI LT
A PPLICATl)N
80FTWAF.E
O P ER A TI O N A L SYS TEM
USER
••
0
80WTIOH8
••
80WTIOH8
.:
INTERFACE
"'"""
INTERFACE
POST-A UOIT RE V IEW
°"""""
APPAOVEO
INTEFF.rce
TECHNOLOOIES
SIJateglC Enterprise lnt:irmauo, T&chnoiogy NcnheclUrs
F I GU RE S • 9
~
n
n
·i
p
.
i!.
8
;
••~
g
ii
;
•
••
t
••
!
u•
•
OE& I O N PR OTO T Y PE S
PHYSICAL
OATA&A8E
OEalGN
8 PECIACATION&
~
~s
.;
A PPLI CATION A A CHITEC TUJIE
u
.2
.•
The Context of the Problem Analy,is Phase of Systems An alysis
i
·I
n
I
I
••
!II
•5
Systems Analysis
Chapter Flvo
177
Tl,£ 8USINE8S C:0...UNITY
r FIGURE S - 10'
I to c,ontinue pr-o je<:tfr-om prelimi rwy ir-iiglltiori)
(• ppr-
Tasks for the
Problem Analysis
Phase o f S,stems
'- Analysis
J---------,
_ _ _..:,:. - - ·~;,«et....,
&'l's11:•0wtc.,._ u, c:,i,
l
.:I
(OfthCJINCI 00.11'1"1,(I
l
!
Problem Oen.in
•
.
SYSTEM
IMPRCNEMENT
f
OBJECTIVES
,.,...rent.y.te,m
do1;ument.tion,
qne>m model•
!
......,
..
probhm .tn,me,nt,,
•uMl,,,ffec,t
•nel,-,,
I
problem clorn,in,
prooe,,model,,
pr-oo,.. •nelpi,
prcjeot
,
•
.
.
probli,m ,n,1,,._,
..,.wtem irpr<Mlfflerrt objl>Cltive,,
end oonmi nt1'
M!l®M
II
Lasystttn being studied. In some organizations, one or more experienced users are
.. loaned,. to the project full-time as b·usltiess an.a lJ.sts; however, ft is rare that any
one user can fldly represent the interests of all users. Business at1alysts can, however,serve as fadUtacors to gee cbe rlghc people involved and sustain etfecttve communicatio n back to the business units and management.. SYSTEM DESIGNERS and
BUILOERS are rareJy Involved In this task wlless they are Interviewed to determine
any tecbn.lcal limitations of the current system.
In Figure 5-10, dlls task Is triggered by APPROVAL ro CON"JlN\ffi 11iE PROJlrt'-from the
scope definitio n phase. (11,e dashed Uoe Indicates this approval is an ew,111 or trigger,
not a data or infonnatlon flow.) The appro'\o-al comes from the SYSTEM OWNERS or steering commlttee.111e key infonnatlonal input is the FROJ-f.CT CH,\RTER and any CUR.RENT
svsnru OOCU"""'1'AllON that may exist In the repository and program libraries for the
curre11t system. Cturent system documentation doesn't always exist. And when It does
ex.1st, ft must be carefully checked for currency- most such docttruentatlon is notorJ.
ouslJ out of date because analysts and programme.ts are not always diligent about
updating that documentation as d1aoges occur throughout tl1e Ufetlme o f a system.
The deliverables of this task are an understanding of the PROBLEM oo MACN AND
BUSINESS \'OCABULARY. Your underst.andfng of the existing problem domain should be
documented so tl1at It can be verified tl1at you truly understand it.111ere are several
ways to document the problem domait1. Certainly, drawing SYSTE."1 MODEJ.s of the cttrrent system can help, bll! they can lead to a pheno mmo n called •analysis paralysis; In
wtlich the desire to prod uce perfect models becomes counterproductive to the
178
Part 1wo
Systoms Analysis Methods
schedule. Another approach mlght be to use your h1fonnation system bulldh1g blocks
as a framewod< for llstlng and dellnlng the system domain:
KNOWLEDGE-List all the ..things" about which the system ctttrently stores data
(Jn Bies, databases, forms, etc.). Define ead1 thing In business terms. For
ex.ample, "A1.1 ORDf.R is a business trai1Sactlon in wbid1 a customer requesls to
purchase products."
Additionally, we co,dd list all the reports produced by the curretll system
and descrlbe their purpose or use. For example, *The open orders report
descrlbes all orders that h..ive not been filled within one week of their
appro"-al to be fllled. The teport is used to inltlare customer relatlonshJp managemet1t through personal contact."
PROCESSES- Define each business event for which a business response
(proces.,) is currently Implemented. For example, ..A customer places a new
order," or ..A customer requests changes to a previously placed order," or "A
customer cancels an order."
CoM."1UNJCATIONS- Detlne all the locations that the current $)'stem serves and
all of the users at each of those locations. For ex.ample, ..The system is currently used at regional sales offices h1 S.m Diego, Dallas, St. Lolds, Indianapolis,
Atlanta, and ,_lanhattan. Each regional sales office h ..,s a sales mai1..1ger, as~Jstant sales mai1..1ger, administrative assistant, and 5 to 10 sales clerks, all of
whom use the current $)'S1em. Each region ls also home to 5 to 30 sales representatives who are on die road most days but wt10 upload orders and other
trai1Sactloos each e,-ening."
A11other facet of intethces is $)'stem interfaces- that is, interfaces that
ex.1st between the cttrrent lnformatlon system and otl1er lnformatlon systems
and computer applications These can be qulddy listed and described by the
information systems staff.
Ultimately, tl,e organlzation 's Sfstems development methodology and project plan
will determlne wl1at types and Ie,-.1 of documentation are expected.
The business vocabulary de!h-.rable Is all too often shortchanged. Understandh1g
the business vocabulary of the ~·stem ls an excellent way of understand.fog the system itself. It bridges tl1e commlm.lcatio11 gap tl1..1t often exists or develops between
business and tedmology experts.
If you elect to draw svsre.t MODELS d u.ring this task, '\\"'e suggest that "lf you want to
Jearo anythl11g, you must not uy to leam everytbl11g- at least not all ln dlis task." To
avoid analysis paralysis, we suggest that the following system models may be appropriate:
KNOWLEDGE- A one-page data model is ,--ery useful for establishing buslne;.s
vocabulary and rules. Data modeling Is taught In Chapter 8.
PROCESSES- Today, it is widely accepted tl1.1t a on e- or two-page functional
decomposJtio11 diagram st1ould pro,--e sufficient to get a feel for the curra1t
system processing. Decomposition modeling ls taught In a1.1pter 9.
CoM."1UNJCATIONS- A one-page context diagram or use-case dtagrams are very
useful for illustrating tl1e 5'/stem's inputs and outputs wlth other organizatio11S, business units, and systems. Context dtagrams are discussed below. Use
case diagrams are taught In O:tapter 7.
Several other techniques and skills are useful for developh,g an understanding of an
exlstlng system. Obviously, fuct-llndlng techniques (taught In the next chapter) are crltl,
cal to teaming about any existing system. Also, Joint requirements pL1nnh1g, or )RP, techniques (also taught In tl,e next dupter) can accderate this task. Finally, the abUity to
deady communicate back to users what you\'e leamed about a system Is equally crucial.
Context Diagram 111e purpose of a context diagram is to ai1..1lyze how the $)"'Stem
interacts with the world arow1d lt and to specify in general terms the system ioputs
and outputs. Context d11grams can be drawn in various ways. Chapter 9 prese111s tl1e
traditional format, wbid1 was done as the first step In drawlng data flow diagrams.
Systems Analysis
Chapter Flvo
179
I
PastMem
r
SUbscrlpUon
;:-·--·-.
Renewal
I
Resubscripdon
Offer
Mem
Ion
PotenUal Member
L
Accounts Rec<>lvable
-...
'
Suboeriptton O
ff••
Mombor
~ - - - - Promotion
NewP,ogram
Systom
•
Warehouse
--+--4>-- VMtous Inquiry ResponMS -
~ - - - - - - Mem
Cllb Member
ber
°"""
0
Member S ervices
A
Pad<l n g O - ~
_ SUbscrlpllon
Program
Member
Marl<eUng Department
____J
Reports
I
and Member Reports
(_F_I_G_U_R_E_S_-_1_1_ c_o_n_re_~_ Di_·a_g_ra_m
______________________)
01..1pter 7 shows a different fonnat for a context diagram.The context diagram shown
In Figure 5-11 employs a hybrid approach. It emp loys use case symbols as use cases
are becoming a generally accepted tool of the reqttlrements ai1..1lysls ph..,se,
Toe system itself is shown as a "black box'" In the mlddle of the diagram. We are
11ot yet ready to look inside the box. For 11ow we JuS1 want to see how everyone will
use the box.T he stick figures around the outsJde of the diagram are the persons, organ.il:atlons, and other Information ~·stems tl1..1t wUJ interact with the system. In use
cases, these are called actors, and we can call them that h ere. In tradJtlonal data flow
dL1giams, they are called exten1al agents. In Chapters 7 and 9 you will learn that once
you look lnsfde the ~tern box, other thing., such as time or de"ices like sensors can
also be actors or external agenrs. But for a context dhgram they are rarely show11.
Toe Unes Indicate the Inputs (arrows pointing to the system) provided by actors
to the system and the outputs (arrows pointing to the actors) created by the system.
Ead1 Input and output Is Identified with a now, phr.tse that describes It.
To build a context diagram ask the users what business transact:Jons the system
must respond to; these are the lnputs. Also ask the users wl1at reports, notlflcatlons,
and other outputs must be produced by the system. .\ system can ha,--e many reports
180
Part 1wo
Systoms Analysis Methods
that can quickly clutter d,e diagram; consolidate them as needed to keep the diagram
readable. During other phases In the process they will be analyzed separately.
\X'e certainly cotlldn't build an lnformatlon ~·stem from a context dL1gram. But Jr
is a solid first step. From tllis simple diagram we kt1ow wh.at lnputs the system must
respond to and what outputs Jt must produce. In other words, it helps us tmderstaod
the problem domait1. We will see ht a1apter 7 how ro detect use cases from a context
diagram. That wUI be the first step in cracklng open the• bL,ck box.· We are following
the principles for systems de-.elopment presented In Chapter 2: • use a problemsol"ing approad1" and«dJ"ide and conquer;"
>
Task 2.2-Analyze Problems and Opportunities
In addJtlon to learning about the current system, the project team must work wJth
system owners and system users ro a11alyze probletns a11d opport1,11lttes. You
mlght be asking, • werei1'1 p roblems and opportunities identllled earlier, In the prellmlnary investigation phase?' Yes, they were. But those lnltial problems may be only
symptoms of other problems, perh.aps problems not as well known or understood
by ti1e users. Besides, we h.aven't yet really analyzed any of ti1ose problems In ti1e
classJc set1Se.
cause-and-effect aaal}'Sis
a tec.hn ique in which problems
are studied to determine their
causes and efects.
True problem analysis ls a difficult skill to master, especially for inexperienced systems analysts. Experience suggtsts that most new systems analysts (and many system
owners and users) try to solve problems without trttly analyzing them. They mlght
state a problem like this: .. \X'e need to ...• or "We want to ...• 1n dolng so, they are stating the problem ln terms of a solution. ,_lore effective problem sol,--ers have leanled to
trttly analyze ti1e problem before stating any possible solution.11,ey analyze each. percelved problem for causes and effects. In practice, an effect may actually be a ,ymptom of a dlfferet1t, more deeply rooted or basic problem. That problem must abo be
analyzed for causes and effects, and so on until such a time as the causes and effects
do not yield symptoms of other problems. Cause-and-effect analysis leads to true
tmderstanding of problems and can lead to not-so-obvious but more creative and
valuable soJutions.
SYS11:NS ANALYSTS facilitate this task~ howe,--er, all SYSTENS OWNERS and us~s should
actively participate In tl,e process of cause-and-<,ffect analysis. They are the problem
domain experts. SYsTE."1 DESIGNERS and BUILDms are not usually involved in this process
unless they are called on to ai1..iyze teclmlcal problems that may exist in the ctl'rent
system.
As shown in FJf,l\ltt 5-10. the team's w1derstaodfna of t h e ~ DOMAIN AND
BUSINESS VOCABULARY triggers this task. 1b.ls w1derstandtng of the problem domtln is
crucL1l because the team members should not attempt to ai1..1lyze problems u.lless
they WlClerstand the domain lt1 which. those problems occur. Toe other Informational
lt1put to thls task ls the lnltial P>OBJ.£ -" s'J'ATE."1NTS (from the scope deflnltlon phase).
111e deliverables of this task are the updated PROBLEM STATEMENTS and the CAUSE-EFFOCT
ANAIYSIS for each problem and opportwllty. Figure 5-12 Illustrates one way to doct•
met1t a cause-and-effect analysis.
Once again, fact.finding and JRP techniques are crucial to tills task. These techniques, as well as cause-and-effect ai1..1lysls, are taught In the next d1..1pter.
>
Task 2.3-Analyze Business Processes
11lls task ls appropriate only to busl11ess process redesign (BPR) projects or system
development projects that build on or require sJgnl.flcant business process redeslgtl.
In sud1 a project, the team ls asked to examine its business processes In much
greater detail to measure the value added or subtracted by ead1 process as it relates
to the total orgaillzatlon. Business process analysis can be politically cliarged. System owners and users alike can become very defensive about their existing business
Systems Analysis
Chapter Flvo
181
PROBLEMS, OPPORTUNITIES, OBJECTIVES, AND CONSTRAINTS MATRIX
Prtjecti
Member Seivices Information System
Prtject Managen
Sandra Shepherd
Created by,
Robert Martinez
Last Updated by,
Robert Matinez
Date Last Updated1
Janua,y 31, 2003
Date Created1 Janua,y 21, 2003
CAUSE-AND-EFFECT AMAI.YSIS
SYSTEM IMPROVEMENT OBJECTIVES
Problem or
Opportunity
causes and Effects
1, Oder response time
1, Throughput has increased
6 uiacceptable.
while number o f o rder
required to process a
c lerks was cb.M1sized.
Time to process a single
order has remained
relatively constant.
single order by 30%.
~. system 1s too Keyt>Oa~
dependent. lMtf o f the
same values are ke-Jed for
most orders. Net result is
(with the current system)
each order takes lo nger to
piocess than is ideal,
3.
Data editing is performed
by the AS/400. As that
computer has approached
its c apac:ify, o rder edit
responses have slOW'ed.
Beca.Jseorder clerks « e
trying to work faster to
keep 1,.pw ith the volume,
the rumber o f errors has
increased.
System Objective
1, Decrease the time
2 . Eliminate keyboard data
entry for as much as 50%
System Corutralnt
1, There w ill be oo increase
in the order processing
workforce.
2. Aro/ system deteloped
must be compatib le w ith
the existing Wincb,,vs 95
o f all ordeis,
3. !=or remaining orders,
reduce as marry ke-Jstrokes as possible by
replacing keystrokes w ith
point-and-click objects
on the computer d isplay
oesktOP stand.,.d.
3. New system rrust be
compatible w i:h the
already appro,e:d
a.Jto matic idertific atio n
system (far bar codire)
screen.
4, Mole d ata editing fro m a
shared c omputer to the
desktop.
5. Replace existing p icking
tickets Wth a paperless
communication system
betwun member
services and the
w arehouse.
4, Warehouse picking tickets
for orders were never
~
ignP.ir't to m.:i)dmi7P. thP.
e fficiency o f o rder fillers.
As w arehouse operations
gre.v, o rder filling delays
were inevitab le.
~G U R E
S • 1 2 A Sample Cause-and-Effect Analysis
_ _ _ _)
processes. The analysts involved must keep the focus on the processes, not the
people who perform them, and constantly rem.Jud everyone that the goal is to
Identify opportunities for fundamental business chaJl!e that wUI benefit the business
and everyone ln the business.
One or more systems analysts or business analysts facili tate the task. Ideally, the
ANAD'STS should be expe,let1ced, trained, or certified in BPR methods.The o nly other
participants sholdd be approprL1te SYSTEM OWNERS and USERS, Bush1ess process ai1..1lysls
sl1otild a\--old any temptation ro focus on lnformatlon technology solutions untll well
182
Part 1wo
Systoms Analysis Methods
after the business processes hive been redesigned for m.1Xfmum efficiency. Some
analysts find it useful to assume the existence of• perfect people" and "perfect technology• tl1.1t can make anythlng"posslble~They ask, •If the world were perfect, wotdd
we need tills process?"
As depleted h1 Figure 5-10,, business process analysis task Is dependetll only on
some PROm..a< DOMAIN knowledge (from Tusk 2.1). The dellvenbles of this task are business "as is" PROCESS MODEJ.5 and PROCESS ANALYSES. The process models can look very
much Uke data flow diagrams (Figure 5-2) except they are slgnUlcantly annotated to
show ( l) the volume of data flowing through tJ,e processes, (2) tJ,e response times of
each process, and (3) any delays or bottlet>ecks that occur h1 d,e system. The process
analysis data provides addltiorul information such as (a) the cost of each p rocess,
(b) the value added by ead1 process, and (c) the consequences of eliminating or
stream.lining the process. Based on the as-is models and their analysis, the team
develops"to be" models that redesJgn the business processes ro ellmfnare redw1dancy
and bureaucracy and increase efficiency and service.
Several tedmlques are applicable to tills task. Once ag.110, fact-finding techniques
and facllltated team meetings (01.1 pter 6) are Invaluable. Also, process modeling techniques (Chapter 9) are critical to BPR success.
>
objective a measure of
success. It is ~omething that
you expect to achieve, if given
sufficient resources.
coo.straiot fomething that
'Mii limityour f exibility in
defining asolltion to your
objectives. Essentiall~ oon.
straints cann01 be changed.
Task 2.4-Establish System Improvement Objectives
Gh,--en o u r underSlandfng of the current system's scope, problems, and opportunities,
we can no w establish systen1 f.111prove111e1it objectives. TI1e p u rpose of this task is to
escabllsh d1e criteria against wh.ich any Improvements to the system will be measured
and to Identify any constraints that may limit flexlbUlty ln achlevlng those lmJYOVements. The criteria for succe.s., siloldd be measured ln terms of objecth--es. Objectives
represent the tlrSl an:empt to establish expectations for any new system. ln addJtlon
to identifying objectives, we must: also Identify any known constraints. Coost.rJ.lots
place limitations or dellmltatioos on achlevlng objectives. Deadlines, budgets, and
requited technologies are examples of constraints.
The SYST6\ISANA1¥STS faci litate this task. Other participants lndude the same sc'STEM
OWNERS an d USERS
who have participated h1 oti1er tasks lo this problem analysis phase.
Again, we are not yet concerned with technology~ therefore, svsTE.\.t DESIGNERS and
BUILD ms are no t in\--ol,-ed ln this task.
This task ls triggered by the PROBLEM ANALYSES completed lo Tasks 2.2 and 2J. For
each verlfted and slgoitlcant problem, the analysts and users shotdd define spedflc
5YSTEM IMPROVE.\.f.G'ltr OQJ.f.C'JlVES. Titey sholdd also idet1tify any CONSTRAINTS that m.1)' Um.it
or prevet1t them from acbie"in@ the ~·stem impro,--emet1t objectives.
SySlem Improvement objectives should be precise, measurable Slatemeuts of
business performance that define the expect.a tlo ns for the new system . Some
examples are:
Reduce the number of lUlCollectible CllSl:omer accotmts by 50 percent within
the next year.
Increase by 25 percent the n u mber of loan applications tl1..1t can be proces~
durh1g an eight-hour shift.
Decrease by 50 percent the time required to reschedlde a productio11 lot when
a wotkstatlon malfunctions.
11,e followh1g Is an example of, poor objective:
Create a delinquent accounts report.
111is Is a poor objective because it Slates o nly a requlremet1t, not an actual objective.
Now, Jet's reword that objective:
Reduce credit losses by 20 percent through earUer ldentlllcatlon of delinquent
accounts.
Systems Analysis
Th.ls gtves us more flexibility. Yes, the delinquent accow1ts report w ould w orlc Bur a
customer delinquency inquiry might pro'\oide an even better way to adlieve the same
objective.
System Improvement objectives may be tempered by identlJlable constraints.
Conrualnts fall into four categories, as Usted below (with examples):
Schedule: The new system must be operational by April 15.
Co.st: The new ~tern cannot cost more than $350,000.
Teclniology: 111e new system must be online, or all new systems must use the
082 database management system.
Polley: Tue new ")'Stem must use doubledecllnlng-balance hwentory tedmlques.
The List two columns of Agure 5-12 documet1t typical system Improvement objectives and constraints.
>
Task 2.5-Update or Refine the Project Plan
Recall tl1..1t project scope is a mo'\oing target. Based on our baseUoe schedlde and budget ftom the scope detlnltion ph.a se, scope may ha,-e grown or dimlnlshed In size and
complex.lty. (Growth Is much tnOt'e commo11f) Now th.•'lt we're approaching the com.
pletion of the problem analysis phase, we shot~d ree>'aluate project scope and update
or reft11e the projecrplan accordingly.
The project manager, in con/unction wltl1 SYSTa.t OWN~s and the entire project
team, facilitates this task. The SYSTE.\SSANALYSTS and SYSJ'E.\.t ~ s are the key indJvJduals lo this task. The analysts and owners should consider ti,e possibility tllat not all ob,
jectlves may be met by the new system. Why?11,e new system may be larger ti1an
expected, and they may h.a,--e to reduce the scope to meet a deadline. In tills case the
system owner will rank the objectives it1 order of importance. Then, if the scope must
be rEduced, ti1e higher-priority objectives will tell the analyst what's most Important.
As shown In Figure 5-10, this task Is triggered by completion of the SVSTEN
IMPROVEMENT OBJOC'OVES. The lnltial PROJECT PLAN is another key Input, and the UPDATED
PROJ£CT PLAN Is the key output.The updated plan should now mclude a detailed pL1n
for the reqtdrements analysis phase that should follow. The techniques and steps for
updating ti,e project pL1n were taught in Chapter 4, "Project Management."
>
Task 2.6-Communicate Findings
and Recommendations
AS wtc.h the scope defillltlon ph..,se, tbe problem anaJysiS pt1.,se condudes with a commwlicatlon task. We must co111»1.·u,it.caw fl11dt11gs a1ul reco·,n1ne11.daffo11s to the business community. The project manager and exectrtt,--e sponsor should jolntly facUitate
tills task. Other meeting participants should Include the entire project team, including
assigned SYSTEM OWNERS, USERS, ANA.LYSTS, DESIGNERS, and a UJJDERS. And, as usual, d1e meeting sho,dd be open to any and all mterested staff from the bush1ess communlty. Also,
if an Intranet \X'eb site was established for the project, Jt should have been maintained
tluougbout the problem analysis phase to ensure continuous commwlication of
project progress.
This task is trlggeied by the completion of the UPDATED PROJEC'J' PLAN. lnfonnational
inputs lndude d1e PROBLEM ANAIYSES, any ~6\1 MODEJS, the SYSTEM L\IIPROVfl\lfNT OBJOC'JlVES,
and any other documet1tation that was produced dwlng the problem analysis phase.
Apptoprlate elements are combined inro the SYSTJ.:M ™PRCWl:ME'ln' osJocnVES, tl1e major
dell,,erable of the problem analysis phase. 111e fom,at may be a report, a verbal
presentation, or an h,spectlon by an auditor or peer group (called a walktbrougb). An
outline for a written report ls shown In FJgttre 5-13.
Interpersonal and communications skills are essential to this task. Systems analysts should be able ro wrJte a fonnal business report and make a bush1ess presenratlon without getting lnto technical issues or alten1atl•1es.
Chcpter Flvo
183
184
Part 1wo
Systoms Analysis Methods
FIGURE S • 1 3
An O,tline for a System Improvement Objectives and
Recommendations Report
Analy,i, of lhe Currant
Sy,tem
I. ExecutiY<> summory (approximately 2 pag..)
A. Summary of rerommendotion
B. Summary of problems, oppar1unitie,, and directiv..
C. Brief ,la1"ment of ,y,tem impl'OY9IM!lt objecliY<>>
D. Brief explanation of report (X)l11,inl$
II. Background information (approximately 2 pag..)
A. Li,t of intervi""'' ond facililated group meeting, ronducted
B. Li,t of other ,ource, of information lhat W9re exploited
C. Deocriplion of ana~cal »chnique, u,ed
Ill. Overview of lhe current sy,i.m (approximately 5 page,)
A. Strategic impliootions (if he project is part of or impads an axis.ting information
sy, tern, ,trategic plan)
B. Model, of the current
1. Interface model (,ho,.ing project ,cx,pe)
2. Dol<J model (,howing projed ,rope)
3. Geographic model, (,howing projed ,rope)
4. Proce,s model (,howing functional deoompooition only)
IV. Analy,i, of lhe currant sy,ton (approximately 5-10 page,)
A. Performance problems, cpportonities, and cause-effed anatysis
B. Information problem,, oi:por1unitie,, ond oou,e-effect onaly,i,
C. Economic problems, oppor1unities, and cause-effect analy!is
D. Control problems, opportunities, and oouse-effed analysis
E. Efficiency problems, opportunities, and oouse-effed analysis
F. Service problems, opport..inities, and cause-effect analysis
V. Dekliled recommendation, (approximately 5-10 page,)
A. System improvement objectives and priorities
,ys...,
B,, Constraints
C. Projed plan
1. Scope reassess.ment Old refinement
2 . Rovisod mostor plan
3. Dekliled plan for the definition pha,e
VI. Appendix..
A. Any deloiled ,y,tem model,
B. Other document, as appropriate
Thls condudes the problem analysis phase. O ne of the following decisions must
be made after the conclusion of thJs phase:
AUtl1orlze the project ro continue, as ls, to the requirements analysis pl1ase.
AdJust the scope, cost, an<Vor schedule for the project and then continue to
the requirements analysis phase.
Cancel the project due to (I) Jack of resources to further develop the system,
(2) realization tl1at the problems and opportw1lties are slrup~· not as Important
as anticipated, or (3) reallntlon that the benefits of the new system are not
likely to exceed the costs.
With some level of approval fmn the SYSTEM OWN"'5, the project can now proceed to
the requirements arwysls phase.
Systems Analysis
Chapter Flvo
l8S
( The Requirements Analysis Phase
,_lany Inexperienced analysts make a critical mlscake after completing the problem
analysis phase. The temptation at that point Is to begin looking at altematlve solutions,
partlcufarly technical solutions. One of the most freq.iently cited errors In new lnformatlo11 systems ls illustrated lo the statement, ...Sure the system works, and Jr is tecbn.ically lmpresst,--e, bur ft just doesn't do what we needed ft to do ." The requ.lretnents
a1,alysis phase defines the busines., reqttlrements for a new system.
Did you catch the key w ord in the quoted sentence? Ir is "'What," nor ..how " ! Analysts are frequently so preoccupied with the tedmlc.al solution that they inadequately
define the business requirements for thar solutlo11. The requirements analysis ph..,se
aOS\'letS the question, "\Vhat do the users need and '\\·ant from a new system?"The requ.fremenrs aiulysi.s phase ls crJtlcal ro the success of any new lnfonnatlon system. In
dlffesent methodologies the requlrements analysis phase might be called the tlejlnitf.011
phase or logical design phase.
Can you e,--er skip the requlremet1ts analysis ptwe? AbsoJuteJy notl New systems
will always be e'\o-aluated, first and foremost, on whether or not they fulfill business ob.
Jecti'res and reqttlremet1ts, rega«Uess of how tmpr~Jve or complex che redutologtcal
solution might be!
ft should be acknowledged that some methodologies Integrate the problem analysis
and requlrements analysis phases Into a single ph.ase.
Once again, your Information systems building bbcks (Figure 5-14) can se,,-e as a
useful framework for documenting the infonnatlon systems reqttlrements. Notice tl1.1t
we are still concerned wfth the SYSTEM us~s· perspectl,--es. Reqttfrements can be defined In terms of the PIECES framework or In terms of the types of data, processes,
and Interfaces that must be lnduded In the system.
Figure 5-15 illustrates the typical tasks of the requlrements analysis phase. The
final phase deJl,-erable and milestone ls producing a BU\tNESS RfQUUlE.,m<rs '1"""""""1" that
will fulfill th.e system lmpro,-emet1t objectives Identified In the pre,-ious phase. One of
ti,e first things you may notice In this task diagram ls that most of the tasks are not as
sequentlaJ as those ln pre"ious msk diagrams. Instead, many of these tasks occur lo
parallel as the team '\\'Od::s toward the goal of completing the requirements statement
The requlrements analysis phase typically h1dudes the following tasks:
3. 1 Identify and express system requirements.
3.2 Prioritize system requlrements.
3, 3 Update
01'
refine the project plan.
3.4 Commwlicate the requirements statement.
Let's now examine each of these tasks in greater detail
>
Task 3.1-ldentify and Express System Requirements
The inltlal task of the requirements analysis phase ls to tde,itlfy and express requ./retnents. Whlle tllis may seem to be an e~· or trfvL1l task, ft ls often the source of many
errors, omissJons, and conflicts.111e foundatlo11 for this task was established in the
problem analysis ph.ase whetl we Identified system lmpro,-.met1t ob)ectl,-es. Mhilinally,
fu.octiooaJ requi.temeot
a description ofaciivities and
tlli.s task translates those object:Jves into an outline of flu1<1iou..1.l and 001UU1xtioo...1.l
requiremettts tl1.1t will be needed to meet the objectives. Ftmctlon.al requlremenrs are
frequet1tly Jdentlfled ln terms of lnputs, otnputs, precesses, and stored data tl1.1t are
services a system must
provide.
needed to satisfy the system lmpro,-ement ob)ecmes. Examples of nonfunctional
requirements lndude performance (throughput and response time); ease of learning
and use; budgets, costs, and cost saving.,; tlmetables and deadlines; docttmentatlon and
ooo.fuoctioo21
trab.ting needs; quality management; and seatrfty and internal auditing controls.
Rarely will tills definition task ldet1tlfy all ti,e functional or nonfunctional buslnes., requirements. But tlte outline will frame your th.Joking as you proceed ro later
of other features, characteristics, and constJc.ints that
define a satisfactory system.
requiremeot a description
186
Part 1wo
Systoms Anclysls Methods
SltateglC 1nrormauon Syslems Plan
S ltateg!C Enterpriee Plan
--·
00111:
lnpo,!t
""°"LEDGE
-
-
&TATEME r T ( F WORI(
;i
I•
:J
v
••
..,..
,.,!
~OH
....
I
-
PFIO V EMENT OBJE C
~
•••
9 ( u • •ng 1110 PIE C E S
-<::.... _7
•
I
v
I
•
r
I
I
•
~
•' t
!
tw
z
Iii
a
ffi
0
•
E
f
;
~
ii:
~
••
E
~
8USINES$ 8 8 Y8T'EIII
PFIOCE88
INTEFIFACE
JI EOUIFIEIIENTS
....
........
LOGICAi.
PFIOCE88
IIIOOEU
LOGICAL
'
<••
LOGICAL
INTERFACE
M00EL8
A
A
RE OU E 81 FOR SYSTEM PAO P O&A L S)
OE81GN PR OT.,TYPE&
'
A
80.,IN EN PFOCE88
PHYSICAL
USER A SYSTEM
0£.81011
PHYSICAi..
.......
Ol.TABASE
INTERFACE
OUIGN
PHYSlctL
SPECIFICATIONS
90F'T'Wll.FIE [ £.SIGN
SPECIFICATIONS
'
FUN C TION A L SYSTEM
~
w
-
•
tM.TABME
80UJTIOH
•
-
OPEJI A TION A L &Y8TEU
o:i,-ironi:
"""°"'°
OUJS48E
11::CHNOLOOIES
F I GU RE 5 • 1 4
~
0
0
TR A INING M A TEJII A. L 8
..,,.,.,...
-
COM•EAOJJ..
80~RE
8•
~
l
CUSTOU.S JILT
A.PPLICATl)N
80~RE
•
m
....
'
.,.,,..
A
INTEFIFACE
80UJTION8
INTEFIFACE
8 0UJTION8
-
PO &T. A. UOIT AE V IEW
a•
~
I•
.•.•
~
0
.
11 I o".
n
m
•i
J0
m
I
·~
I
>o
A PPLIC A TION A R C HITE CTU RE
'
r~!
m~
I
\
A
>
I
H
'
&Y8TEU PROPOSAL
em
.....,<'11
8USINES9
REOUIFIEMEHTS
h
I •
A
OTATCMCNT
8 PECIFICAllOH8
=
-
FIEOUIFI EMEHT8
!
•
~
....
8USINE88
..
YI
ouoo,coo nce u1"c•cttTo
!
tr• mow
co.uu
'? '"
-·
..
· ~
I
A
BO~ LEII STATEMENT ( u , 1119 t llo PIE C E S
&Y8T •
I
..
.. . .
a.•-
....acES<ES
~
•e
f~
~§
• :1
I
I •••
,~
.,
I
I
I
n
• !!
!~
z§
I ••z
I • ii
.
i
~
>
f
0
•••g
•••
.••
>
J
m
m
~
~~
·~
c"
<"
'
I
c,...,..
"""°"'°
INfEFIFN:E
TECHNOLOGIES
The Context o f the Requirements Analysts Phase of Systems Analysts
~ !!
~
Systems Analysts
Chapter Ftvo
187
THIE 81J8 1NIE&8 COMMUNITY
' FIGURE S-1
Tasks for the
Requ irem en ts
Ana lysis Phase of
~ Systems Analysis
l
BUSINESS
REQUIREMENTS
STATEMENT
Funcilona1
ana
Nonfuncuonal
eysteom Improvement oblee'I w,,
tunetlonal and nort1'unct1ona1
requirement•
l
rinal
req1.11remente
• na p11orrt1ee
I
I
I
L
-
valld8U'O
requirements
With p110tltlee
I
I
I
proJeet
comp1etea
~
v1,: :an ~1e~
Requirement,
ana Pr1orrt1e,
J
tasks that will add new requirements and details to the outline. Thus, neither completeness nor perfection is a goal of tills task.
SvsrEMs ANA.LYSiS fadUtate the task. They also document the results. Ob"iously,
SYSTIN USERS are tl1e primary source of business requ.fttments. Some SYSTE.\1 OWNERS may
elect to participate in this task since they played a role In framing the S)'stem Imp rovement objectl,-es that will gtdde the task. SYSTl::',t DESIGNERS and BUUDERS should not
be involved because they tend to prematurely redirect the focus to the technology
and technical solu tions.
As shown in Figure 5-15, this task (and phase) Is triggered by the APPRO\'AL TO
OONnNUE THE PROJECT FROM nm PROBLEM ANALYSIS PHASE. The key input ls the SYS'J'fl\l
WPRom.uNT OBJf.C'11V1'S from the problem analysis phas, (via the repository). Of course,
any and all relevant Wonnatlon from tl,e problem analysis phase Is a>'3llable from the
repository for reference as needed.
The only deUvernble of this task is the DRAPT flUNC'OO NAL AND NO NFUNCTIONAL
REQU!llE.\U~·l'fS. Various fonnats can work. In lts simplest format, the outline could be
divided into four logical sections: the original list of system improvement objectives
and, for each objective, a sublist of (a) inputs, (h) processes, (c) outputs, and (d) stored
data needed to fulfill the objective. Increasingly, however, system analysts are
s'
188
Part 1wo
use case a bJsiness see.
nario or event for 'M'lich the
system must ~rovide a
defined response. Use cases
evolved out of object-oriented
analysis; howwer, their use
has become c:immon in many
other methodclogies for
systems analysis and design.
Systoms Analysis Methods
expressing ftmctlonal requirements using a modeling rool called use cases. Use cases
model business scenarios and events that must be handled by a new system.They are
introduced in Chapter 7 and used throughout this book.
The PIECES framework thai was used earller to Identify problems, opportunities,
and constraints can also be used as a framework for defhling draft requirements.
Several techniques are appl cable to this task. Joint requlremet1ts pbnnlng iJRP)
is the preferred technique for rlpldly ou tlining business requirements. Alternatively,
the ai1..1lysts coldd use other fact.finding methods sud1 as surveys and lnreniews. Both
JRP and fact-llodlog are taught In ti,e next dtapter.
>
ttmeooxi.Og a tec.nn1que
that delivers information SfStems functiondity and require.
ments through versioning. The
development t~am selects the
smallest subset of the syS1em
that. if fully implemented, will
return immediate value to the
system owners and users.
That subset is developed,
ideally 'Mth a t me frame of six
to nine months or less. Subse·
quentty, value.added versions
of the system ue developed
in similar time frames.
Task 3.2-Prioritize System Requirements
We stated earller that the success of a ~ems de,--elopment project can be measured in
terms of t h e ~ to wtlid1 business requirements are met. But not all requirements
are created equal. If a project gl!IS behind schedule or over budget, it may be useful to
recogrtize which requirements are more important than others.111us, gtven the validated requirements, system owners and users should prioritize syste,n requiretntnts.
Prioritization of requirements can be facilitated using a popular tedmlque called
timeboXitig. nmeboxtng anempcs to dJvJde reqUltements tnco "d1unks"' that an be
implemented within a period of time that does not tax the patience of ti,e user and
management community.11mel:oxing forces priorities to be dearly defined.
SYSJ'E.\.GANALYSTS facilitate the prioritization task. SYS11:M OWNERS and usflt5 establish
the actual prloritles. SYs11:M DESIC-NfltS and BUUDERS are not invoh,--ed ln the task. The task
is triggered by the VAUOATED RJeQUlllE."""'5. It should be obvious that you cannot adequately prlorftlze an Incomplete set of requirements. 111e deU,-erable of this task is the
REQUIR.E.\.W'ltl"S WITH PRJORf'JlES. Prlorltles can be cla~i.fled according to their relative
importance:
A mandatory requ.lreme111 is one that must be fulfll led by ti,e minimal system, versJon 1.0. The ~tem is useless wJthout ft Careful! There ls a temptation to label too many requirements as mandatory. A man datory requirement
cannot be ranked because It ls essential to any solution . In fact, lf an alleged
mandatory requirement can be ranked, It is acruaUy a desirable requirement
A destmble requiretnerJ.t ls one that ls not absoJutely essentL1l to verslon 1.0.
It may still be essential to the vision of some future version. Desirable reqttirements can and should be ranked. Uslng ,--erslon numbers as the ranking sd1eme
is an effecth'e way to communicate and categorize desirable requ.iremet1ts.
>
Task 3.3-Update or Refine the Project Plan
Here again, recall tl1..1t project scope is a mo,ing target. Now that we've idet1tified the
business ~tern reqttlrements, we should step bad:: and redefine our understanding
of tl,e project scope and update our project pan accordingly.The team must consider
the possibility that ti,e new sy&em may be L,rger than originally expected. If so, ti,e
team must adjust the sd1edule, budget, or scope accordingly. We should also secure
approval to continue the project into the next phase. (Work may have already stirred
on the design phases; however, the decisions still reqttire review.)
The project manager, In ca.1jwictlon wJt11 SYSJ'E."1 OWNERS and the entire ptoject
team, facili tates this task. As usual, the project manager and SYSTE!\I OWNERS are ti,e key lodMduals in dlis task.11,ey shot~d consider the possibility that ti,e requirements now exceed the origlnal vision that was established for the project and new system.They may
have to reduce the scope to meet a deadline or lncrease the budget to get the job done.
As shown in Figure 5-15, this task Is triggered by completion of the coNPUrrED
REQUIR.E.\.W'ltl"S AND PRIORITIES. The up-to-date PROJOCT PLAN is the other key lnput, and
it Is updated lo the repository as appropriate . The tools, techniques, and steps for
maintenance of the project plan were covered in Chapter 4, • Project Management."
Systems Analysis
>
Task 3.4-Communicate the Requirements Statement
Commwlicatlon is an 011gofng task of th e requirements analysis ph..,se. We must commwlicare requirements and priorities to the buslntss communlty throughout the
ph.ase. Users and managers will frequently lobby for requirements and priority consJderatlo11. Communication ls the process tlvough wb.lch differences of opinion must
be mediated. The project manager and executive sponsor should Jointly facilitate
this task. Today, a project Intran et or portal Is freque ntly used to communicate
requirements. Some systems allow users and m:u1..1gtrs to subscribe to requirements
documents to ensure they are notified as changes occur. Interpersonal, commwlicatlon.s, and negotiation skills are essential to this task.
>
Ongoing Requirements Management
The requirements analysis phase ls now complete. Or ls Jt.? It was once popular to
freeze the busines., requirements before beginning the system design and construction phases. But today's economy has become lncreash1gly fast-paced. Businesses are
meamred on their ability to qulckly adapt to constantly changing requirements and
oppoctu.nltJc3. lnfocn1.1.tlon :,y:nenu c.n be n o Je:,.3 rc~pon:dve th.n the b luJ.ne:,.3 k$lf.
Thus, requirements analysis really never ends. WbUe we quietly transltlon to the remaining phases of our project, there remains an ongoing need to continuously manage requirements through the course of the project and the lifetime of the system.
Requirements managemet1t defines a process for system owners, users, ai1..1lysts,
designers, and bullders to suhmlt proposed d1anges m requirements for a system.The
process specllles how changes are to be requested aml documented, how they will be
Jogged and tracked, when and h ow they will be assessed for priority, an d how they
will evei1tually be satisfied (if they are ever satisfied).
( The Logical Design Phase
Not tU projects embrace modek:lriven developmet1t, bur most lnclude some amount
of system modeling. A logical design further documents business requirements uslllg
system models that Ulustrate data structures, business proces.,es, data flows, and user
Interfaces (Increasingly using object models, as Introduced earlier In ti1e chapter). In
a sense, they validate the requirements established In the previous phase.
Once again, your information systems building blocks (Figure 5-16) can serve as a
usefuJ f.ramewod: for documenung the lnformatlon syscem.s reqtt1remet1ts. Notice chac
we are still concerned wJd1 the ~ E.\t us:ERs' perspectives. In this ph..,se, we draw varJ.
ous eysrem models to dOCltment the reqtLlremet1ts for a new and impro,-ed system.The
models depict various aspects of our bulldlng blocks. Altematively, prototypes could be
bu.flt to "disco,--er requirements." Discovery• prototypts were introduced earUer h1 the
chapter. Recall tiut some prototypes can be reverse engineered Into system models.
Figure 5-17 Illustrates the typical tasks of ti1e logical design phase.11,e final phase
deU,-erable and milestone Js producing a BUSINESS R.EQ1JUlJ:ME'l(J'S STATEMfNT that will fuJ.
611 the system improvement objectives idet1tlfled In the pre,ious phase. On e of the
first dlings you may notice lo this task dtagram is that mosr of the tasks are 11ot as sequential as In previous task diagrams. Instead, many of these tasks occur In parallel as
the ream works toward the goal of completing d1e requirements statement.
The logical design phase typically indudes ti1e following tasks:
4. Ja
4 . Jb
4 .2
4.3
Structure functlonal reqttfrements.
Prototype ftmctional requirements.
Validate functlonal requlremetlls.
Define acceptance test cases.
Let's now examine each of these tasks in greater detail
Chapter Flvo
189
190
Part 1wo
Systoms Anclysls Methods
Stta:eg1c I nrormauon Systems Plan
-
...........
. .---·
8 TA TEMEN
O
""'"
WOAI(
h
••
•
'Al.
PE
N
8Y8 TE
IM
AO V EMENT 0 8JE C T Y E
OVOINCOO
....
.-.......
.........
i
I
!
I•
.
~
II
TO OTATCMCNT
....
.......
••
•m
MC
8USINU8
P ROC. . .
FEOUIFEllllNTS
.,.,
~
I
ncou,n
( u • 1ng t11 , PIE C E&
~
I
B
!
I
8Y8 TE •
(o r
PR O P OSAL
!
>o
REQUE S T FOR SYS TEM PAOP0 8AL 8)
J"
a@
A PPLI CA TI O N A R C HITE C TURE
• 11
ii:z
.
OE 8 10 N PAOTOf Y PE 8
•m
8U&INES8 PAOCES8
0
oe.,10...
PH YSICAL
OATABA8E
DESIGN
8 PECIFICATION8
~
~
•
~~
PH YSICAL
~~
USER • 8 Y8TEM
INTEFIFACE
OElSIGN
PHYSICAL
8 0FTWAAE IE.Sl(;frt
8 PECIFICA110NS
8 PECIFICATION8
0
,o
FUN C TI O N A L SYS TEM
.........
SOLUTION
w
<
~
0
i
-
~
COMMEFIOAL
8 0FT'W.AIIE
..
°"""""
,......
APPACNeO
TECHNOI..OGIE.$
I
•
PACICAGU
CUSTO•~UILT
APPLICATION
8 0FT'W.AIIE
O PER A TION A L 8Y8 TE•
.., ';:,.
~J
TR A INING M A TERI A L S
~
I-
!~0
use•
z
INTEFIFACE
..,.....
80LIJTIONS
• ii
·~
o~
INTEFIFACE
80LIJTIONS
~e
!~
P 08 T- A IJOIT RE V IEW
.., ';:.
Qi,-il'Ol'I:
APPACMO
P ROCO$
11::CHNOLOIJIES
.., !""
.....,...
c:ir.Tolllnt
INTERFACE
TEO+IOI..C>GE S
OOnsrroN: APPAOYEO NElW:iAK f"ECH,Q.OGE S
I
SltateglC El'lt&fl)JIEI& 1nrorma11or,Tecrino1ogy Arcnlteell..re
F I GU R E 5 • 1 6
The Context of the Logtcal Design Phase o f Systems Analysts
•
I
~
•i
0
•!•
•••
••
I
•••
~
Systems Analysts
THE BUSINESS
COMMUNJTV
191
' FIGURE 5-17
Tasks for the
Each ~unct1ona1
Requirement
Logical Design
Phase o f S,stem s
, Analysis
system
M00el8
ayttem mo<1e1s ana apecmcatlone
f\inctlonal
prototype --(>
eystem rmp,ovement ooect1ve•
and
• ccepta nee teet ca1ea
>
Chapter Flvo
Task 4.1 a-Structure Functional Requirements
One.approach ro logical de.sign is to structu.re the fu.1utfonal requ.h'e,nents. 11lis meailS
that, using agile methods, you should draw or update one or more system models to
illustrate the functional requlrement.These may include any comhinatlon of data, process,
and object models that accurately depict the busines< and user req,tlremenrs (but not
any technlcal solution) . System models are not complete until all appropriate flUlctlonal
reqturemenrs have been modeled. Models are frequ<'fltly supplemented with detailed log,
ical spedllcadons tlut describe data attributes, business rules and policies, and the like.
SvsrEMs ANALYS'J'S fad.litate the task. They also document the results. Obviously,
svsnru USERS are the prlmary source of facttta.l detalls needed to draw the models. As
shown in Figure 5-17, this task (and phase) is triggered by each ruNCTIONAL REQUIREMENT.
The outputs are the actual SYSTE.\t Moons AND DeTAll.ED SPECCFJCATIONS. The leveJ of detail
required depends on the methodology being followed. Agile methods usually requlre
../list enough,. documentatlo11. HO\\' much Is enough? That is arguable, but agile
methodologists hold that every deliverable should be essential to the forthcoming
design and programntlng phases.11tis textbook will tead1 you a \"Uiety of different
system modeling tools and techniques to apply to logical design.
192
Part 1wo
Systoms Analysis Method s
>
Task 4. I b--Prototype Functional
Requirements (alternative)
Prototyping ls an altenutlve (and sometimes a prereqttlslte) to system modellng. ~ometlmes users have dtfficulty expressing the facts necessary to draw adequate system
models. In sud1 a case, an alterru.tive or complementary approad1 to $)'stem modeling
ls to build discovery prototypes. Prototyping ls typically used In the requirements
analysis phase to build sample h1p uts and outpurs. These Inputs and outp uts help to
construct the underlytng database and the programs for inp utting and outputtlng the
data to and from the database. Although discovery prototyph1g ls optional, It ls frequently appUed to systems development p rojects, especlally In cases where the users
are having cllflkulty stating or visualizing their business requirements.The phllosophy
is that the users will recogrtize their requirements wbett they see them.
SYSJ'E.\.G BUW)ERS facilitate this ai1..1lysls task. SYSJ'E."1 ANALYSTS documet1t and amlyze
the results. As usual, SYSTEM us&s are the primary SOl U"Ce of factual input to the task.
Agttre 5-17 demonstrates that this task ls dependent on one or more FUNCTIO NAL
REQUIRE\!ENTS 111.11 !1.we been ldentUled by the users. The system bullders and analysts
respond by constructing the PROTOTYPES. As described earlier ht tllis chapter, tt may
be possible co reverse engt11ei!r some SYSTE.\.t MODELS directly from che prototype
databases a nd program llbrarJe.s.
>
Task 4.2-Validate Functional Requirements
Both SYSTEM MODELS and PROT01YPES are representations of the users• requirements.
111ey must be '\o-alldated for cornpJeteness and correctness. SYsTE.\SS ANALYSTS facilitate
the prioritization task by Interactively engaging system users to identify errors and
omissions or make darlflcatlons.
>
Task 4.3-Define Acceptance Test Cases
While not a required task, most experts agree that lt Is not too early to begh1 plaunh1g
for system testing. System models and prototypes very etlectlvely define the processing requirements, data rules, and business rules for the new ~tern.. Accordingly, these
spedficatlons can be used to dtfine TEST CASES that can ultimately be used to test programs for correctness. Elther SY>TEM ANALYSTS or svsTE.\.t BUILDERS can perform thb task
and YaUdate the test cases wfth the SYSTE.\.t USERS,
Recall that
SYS'l'C.'1 L'1Plt.0Vl!MCN'l'
o ,u.ccnvt:ls WCf'C defined earlier In the project. Tc.st
cases can be defined to test these objectives as weU.
~~~T~
he_D
_e_c_i_si_o_n~A_n_a_l_y_s_is~P_h_a_s_e~~~~~~~~~~~~~~~~)
Gh,--en the business requirements for an improved lnformatlon system, we can finally
add.res, how the new ~·stem- induding computer-based alternatlves- 1n-lgbt be implemented with technology.The purpose of the decfs/011 analysis phase ls to Identify
candJdate solutions, analyze those candJdate soJutlons, and recommend a target system that wUI be desJgned, constructed, and lmplemented. a1ances are that someone
has already championed a "i sJon for a technical soJutlon. But alten.1atlve solution!, pet·
haps better ones, nearly always exist. During tJ,e decision analysis phase, lt Is Imperative tl1.1t you ldet1tlf)• options, analyze those options, and thetl sell the best solution
based 011 the ai1..1lysls.
Once agah1, your Information systems bulldlng blocks (Figure 5-18) can serve as a
usef,d framework for the decision analysis phase. One of the fi rst things you should
notice ls that lnformatlon technology and archltecture begin to lnfluence the decisions we must make. lt1 some cases, we must work within standards. In other cases,
Systems Analysts
Chapter Ftvo
193
Stn11eg1c I ntonna11on Systems Plan
~
.. t••
8TATEIIE T
•
llEM STATEMENT ( •
F WORK
PIECES
Ir••••
0
•"""
••
8Y8TE
RO\IEMEMT OB J ECT
O U 6 1"t:66 flCQ\ll fl.
..
.,
( • • l• t
t•• PIECES
T6 6TATCMC N T
h
••
•
iir
•
~
•Q
I
•
u i•
"! l•
•
~II
;•
=
r.I
;
I
1
I
!
I
!
I
!
r
•
~
E
aYeTe• ••o•oaaL c•r aeoueaT •o• aYaTe• ••o•oaaLa1
;
APPLICATION &aCHITl!CTUae
I
I
I
~
;•
I
d
!•
~§
I
9•
..
F NC
IOMAt. SYSTEM
•
I;•
•
I
!
I
•
I
0
. . TIONAt. 8Y8TE•
-
.........
..........
TB>HNDLOOIEI
CCll'ISlllllm:
APPFICWEO
PAOC£88
TECIN:ll.OGIES
COntlnlN: APPFCNEO NElWOAK TEO-N:ll.OGE 8
S118teglc Enterprise 1na:irmauon T&<:MOlogy AICl1tecture
f IG U RE 5 - 1 8
!
The Context of the Decision Anatysls Phase of Systems Analysts
ii
•I
9~
la
I
I
I
5
194
Part 1wo
Systoms Anclysls Methods
Tl€ 8 USINESS CO...l>IJTY
TECHNOLOGY INOUSTA'I'
FIGURE S - 19
Tasks for the
Decision Analysis
Phase of Systems
Analysis
·1-L*"' __
-
M l'l:•Owtc""NC>u, c:,,,
-
-from n,qu.-e- - -
m,m, n,IYl!I'•)
~
I
i ==~!§::=I+-- _,
SYSTEM
PROPOSAL
bue,ineN requiremerrt,,
o, ndicl,m, ,olutio,,.
!
t.,ibility
....,..i,
.,......
..-
- - .....
<I
,olution
Repo, ito,y
croo~
1I
14-----~
•II Olndid,tee'
Meibility
•n•tyee,
projec,t ••dule
end reeouroe
,,.i91T11enllf
Upd.ted
PrqeotPle.n
.,
..
Solution(•)
~ oornfl'encled
we can look to apply different or emerging tedmology. You should also 11otlce that
the perspectives are in transition- from those. of the SYSTEM usF.Rs to those of the.
SYSTEM DESIGNERS. Again, this reflects our transition from pure business concerns or
tech110Jogy. &Jt we are not yec deslgntng. The buJJdtng blocks tndJcace our goal as
developing a proposal that wlll fulllll requirements.
Figure 5-19 lllustrates the typical tasks of the declslon analysis phase. The final
phase deliverable and milestone Is producing a SYSTEM PROPOSAL that wlll fulfill the
business requlrements ldentlfled In the pre,ious phase. The dedslon analysis phase
typically lndudes the following tasks:
5.1 Identify candldate solutions.
5.2 Analyze candldate solutions.
5.3 Compare candidate solutions.
5.4 Update d,e project plan.
5.5 Recommend a $)'stem soludon.
Let's now ex.amine each of these tasks ht greater detail.
>
Task 5.1-ldentify Candidate Solutions
Gh·en the business requirements established ln the dellnltlon phase of >)'stems analysis, we must first Jde11tify alteroatl,-e candidate solutions. Some candldate solutions
will be posed by design Ideas acd opinions from SYSTEM OWNERS and USERS. Other, may
Systems Analysis
come from "-arlous sources indudfng 5YSTENSANALYSTS,SYSTENS DESIGNERS, technical consultants, and other IS profe55ionals. And some technical choices may be llmlted by a
predefined, approved technology ardlltecture. It ls the Intent of tills task not to evaluate tJ,e candidates but, rather, simply to define possible candidate solutions to be
considered.
The SYSTE.\.SSANA.LYSTS facilllate this task. SYSTEM ~sand usflt5 are not normally
directly ilwoh-.d in this task, but they may contribute ideas and opinions that start the
task. For example, an owner or user may have read an artlde about, heard about, or
learned how some competitor's or acquaintance's sJmJL1r system was implemented.
In any case, it is politically sound to consider the Ideas. SYSTEM DESIGNERS and ButLOERS
such as database administrators, network administrators, tedutology archltects, and
programmers are also a source of Ideas and opinions.
As shown ln Figm-. 5-19, this task is formally triggered by tJ,e APPROVALTO CONnNUE
THE PROJECT FROM THE REQUIR.fl\lmt'S ANALYSIS phase. In reality, ideas and opinions have
been generated and captrn-.d sinc e the prellmil1ary lJwestlgation phase- it Is human
nature to suggest solutions througt1out any problem.solving p roces.,. Notice that, In
addltlon to coming from the project team itself, m&.SAND oPtNIONS can be generated
from both lnten1al and exten1al sources. Each Idea generated is considered to be a
CANOIIMTE SOLUTION
to the
8ustN'E68 n.EJQutn.EM6N'l'S.
The amount of information descrlbh1g the characteristics of any one candidate solution may become overwhelming. A candidate matrix, sud1 as Figure 5-20, Is a useful
tool for effectlvely capruring, organizing, and comparing the characteristics of different candidate solutions.
As bas beet1 tJ,e case througbom tllis d1apter, fact-finding and group fadUtation
tedlolques like )RP are the principle techniques used to research candidate system
soludons. Fact-flndil1g and group facllitation techniques are taught ill the next chapter.
Also, a,apter I O,"Feaslblllty Analysis and tJ,e System Proposal; wlll tead1 you how to
actually generate candidate ~·stem solutions and doatment them In the mattix.
>
Task S.2-Analyze Candidate Solutions
Ead1 candidate si·stero solution must be analyzed for feasibility. Thls can occur as each
caoddate Is ldentlfled or after all candidates have been ldentlfled. Feasibility analysis
shotdd not be Um.ired to costs and benefits. r.tost analysts evaluate solutions against at
least four sets of criteria:
Teclmtcal feaslbi/r.ty- ls the solution technlcaltJ' practical? Does our staff
~ave the technical expertise to desiiu1 and build this solution?
Operational f easibility- Will tJ,e solution fuUl li the ,rser·s requirements? To
wh.at degree? How will the solution d1ange the user's work en'\oironment?
How do users feel abottt such a solution?
F.conomlc feasibility- ls the solution cost-effective?
Schedule feasibility- Can the solution be designed and Implemented within
an acceptable time period?
When completing this task, the analysts and users must: take care 11ot to make
comparisons between the candidates.11,e feasibility malysl.s is performed on each h1dividual candidate wlthom reg.ml to the feasibility of other candidates. This approach
discourages the analyst: and users from prematurely making a decision concenling
wlllch candidate is the best.
Again, the SYSTEMS ANALYSTS facilitate the task. Usually SYSTEMS OWNERS and USERS
analyze operational, economic, and sc hedule feaslbillty. SYSTEMS DESIGNERS and
ftUD.JjERS usually contribute to the analyses and play the critical role in analyzing
techolcal feasibility.
Figure 5-19 shows that the task is triggered by the completion of ead1 candidate
solution; however, it is acceptable to delay the task until all candidate solutions have
been idet1tlfled. Input to tJ,e actual feasibility analyses comes from tJ,e various team
Chapter Flvo
19S
FIGURE S-2 0
Charaderiltics
Porrion of System
Com-ud
Briefdaaiilon cl that portion of
the lY,.iml Jt would be
ccn,pvle rized
'
A Candidate Systems Matrix
in this oordidate.
lenefih
Candidate 1
Candidate 2
Candidate 3
OOTS podrage Plotirum
Plt.G f10m Enterbinment
Software Solutions would
be pun::hcued and
OJsbmized to soti ,fy
Member Services required
hnctionolity.
Member Services and
woreho~se operotions in
relation o older fuKillmEnt.
Some as candidate 2.
Thi$ $0l,tion can be
FJly wpxufs u'Strl required
b.isineuproa1Sses for
Some as candidate 2.
this oondidofl!.
implemented quiddy
because irl o p.in:hosed
solution.
Servers and Work,tation.
Tedriically, on:hitech.re
A descri ptior of the s81'Wf'\ ard
wrsk:stationsneeded to wpport this
dicbt1n Pentii.m PIO, MS
Briefdaaiplon cl
the busineu
benefib that t10uld be realized for
Candidate ...
Soundskge Inc. Plus more
efficient nt&nxlic:n with
rnemberaccounb.
Some asCU'ldidote 1.
Some as candidate 1.
MS Visool Basic 5.0
MS Visual Basic 5.0
Sys.iml An::hited 3.1
System An::hitect 3. 1
lnt&mel Expbrer
Internet Explorer
Package $0l,tion.
Custom iolition
Some as candidate 2.
Method of Doto Pro«ttsin,g
Generally so-ne oorrbinotion cl
a,l;ne, bald,, de!..-..d bath,
remOII botch, and real lime.
di&nt/serwr.
Some OS CU'ldidote 1.
Some as candidate 1.
Output Davie• and
lmpltcotio••
(21 HPAMV depa-.,,
Some as candidate 2.
Adescriptior of ootp.,t devices that
(2) HPSSI LAN low
(21 HP4'\V depamnent
10$er printer&.
(2J HPSS IANlowprintim.
oordidote.
Wll'IIX)W\ NT cb!o$ w..rt
and PEnlium,MS Window\
NI' A.O worlc.:s.iltiorn
(donO).
Software TOO,, Needed
MS Visual C++ ard M.S
Software b:> $ needed to design and Jlcx:esl for cusk:rnizatic:n
package to pro'l'ide
bu;l:l lhe condklole (e.g., doiolxue cl
report \lj'l'ffing and
managern&nl lY,.'l&m, errulobn,
integration.
c,,e,ating
etc.).
'.t"",lall.7''
t-bt g&nero I:, applioo~ i
q:,plioations ;ohware podragel
are to be p.ichosed.
Application Software
A descri ptior of the software to be
b.ii\e,
pun::hcued,
oc:oassed, or some
ccrnbinotion of se techniqu&.
would be uSfd, $pedal
;r
loser printen.
printen.
sequiremenb(e.g., nehloo
(1J PRINIRONtX ba«xxle
printer (hc:ludes software &
t i ~)
""""""n~ frrm1., ah- ). nn n11tr,i it
'M\b pogel must be
desifnecl b VGA
reso utioi. All internal
screens wi II be desigied
ocnsiderolions (e.g., liming
ccnslraints).
for Si/GA resolution.
Input 0.vi«t6 ond
lmpltcotio••
Keyboard & mouse.
Awe "Q.iick bke" digital
cam&ra end software.
A descri ptior of i rpvt methods b be
used, inp.,t devkei (ke),boosd,
f:!;l PSC Q.iicboan loser
r cod• soann&I'$.
mouie, et.), $pedal input
sequirernenb(eJ:., new a reviied
fonni fn::rn "'hi data would be
inpvtL and inp.,t coniiderolic:ni
(e.g., lirnirg ofoctuol inp.,ts).
(1) HP SoanjetAC ffabed
ioonner.
Kt1)'D:l(lrd & mo1.Ge.
Storo,ge O.vic• and
iin.&ccrtion,
Brief daaiplorn of what dato
would be
what dab would
be occeued TOrn exislin~ $'torei,
'<ld,ot itoroge media wood be used,
how much $'torot,:'pocitywould
be needed, end
dab would be
organized.
MS SQL Server DBMS
Some oi caididote 1.
Some as candidate 2.
Some oi candidate 1.
with 1OOGll oriayed
capability.
,-.-.d,
~
Systems Analysis
participants~however, It ls not uncommon for extetn.al experts (and influet1ces) to
also pro,ide data. The feasibUity analysis for ead1 candidate ls saved In the repository
for later comparison to other candidates.
Fact.flndlng tedmlques, again, play a role In this systems analysis task. But the
ablUcy• to perform a feasiblUcy• analysis on a candidate system solution Is essentlal.111at
tedmlque Is taught In a,apter 10, • feasibility Analysis and the System Proposal.'
>
Task S.3-Compare Candidate Solutions
Once the feasibility analysis has been completed for each candJdate solution, we can
compare the candidates and select one or more solutions to recommend to the svsTfl\l
OWNtRS and USERS. Ar this point, any lnfeaslbJe candidates are usually eliminated from
further consideration. Since we are looking for the most feasible solution of those remainlng, we will identify and recommend the candk:late tl1at offers the best overall
combination of tedmlcal, operationa~ economlc, and schedt~e feasibilities. It sl10,~d
be noted that in selecting such a candidate, ft is rare that a givet1 candidate is found to
be the most operation.al, technlcal, eco11om.ic, and schedule feasible.
Once again, the SYSTE.\SSANA!YSTS facilitate the ta$k. SYS11:M DESIGNERS and eUILOms
shou.ld be a"-ai.lable ro answer any rectuucal feastbllJty quesuons. tsut urumarety,
the SYSTE.\SS OWNflt5 and us~s should be empowered to drive the final analysis and
recommet1datlon.
In Figure 5-19, thls task ls triggered by the completion of the feasibility analysis of
all candJdate solutions ( NO MORE CANDCDATE SOWTIONS), 111e input ls All OflTHECANDCDATES'
FEASCl!WTY ANA!YSES. Once again, a matrix can be used to communicate the large volume of Information about candidate solutions. Toe f.....,lbillty matrix In Figure 5-21 allows a side-by-side comparison of tite dlfferetll fealibillty analyses for a number of
canddates.
The deU,-erable of this task is the soLuTior(s)To ~ llECOMMENDm. If more than one
solution is recommended, prlorlties sJ1ouJd be established.
Ag.sin, feasibility analysis tedmlques (and the matrix) wlU be taught In Chapter I 0,
• Feasibility Analysis and the System Proposal.'
>
Task S.4-Update the Project Plan
Hopefully, you noticed a recurrlng theme throughout this chapter. \X'e are continually
updating our project plan as we learn more about a system, its problems, Its requirements, and ks so Jutioiu. We ue adjusting sco pe :iccot>dJogly. Thus, b:ised o n our rec.
om.mended solutlon(s), we sholdd once again reevaluate project scope and ·u pdate
the project plan accordingly.
The project manager, In conjunction with svsrn, OWN"'5 and the entire project
team, facllltates thls task.The SVSTENSANAIYSTs and SYSTc" OWNERS are the key lndMduals
in ~task.Bur because we are transltlonfog into technical system design, we need to
begin it1volving the SYSTEM DESJGNEt5 and BUW>ERS In the project pL1n updates.
As shown In Agure 5-19, thls task ls triggered by completion of the SOWTION(s)TO
BE R.B::OMMENDED. The !are.st PR.OJ.f.CT SCHEDULE AND RESOURCEASSJGN.\.W'ltl"S must be reviewed
and updated. The UPDATED PROJOCT PLAN Is the key output. The updated plan shot~d
now Include a detaUed plan for the system design phase that wlU follow. Toe
tedmlques and steps for updating the project pfan were taught lt1 a,apter 4,«Project
,_lanagemenr."
>
Task S.S-Recommend a System Solution
As with the prellmlnary lnvestlg.stion and problem analysis phases, the decision
analysis phase condudes with a communication task.We must rec.o1n111e11d a systettJ.
solu.tf-011 to the busines., community.
Chapter Flvo
197
198
,
Part 1wo
Systoms Analysis Methods
'
FIGURE S -2 1 A Feasibility Analysis Matrix
r-1biltyCrhrSa
w.,...
ep.ronoM ,.011b•tty
3111<
fundtono" ' A descrtpllon
of to whot d911ree tie
a,nd--.ld beoeftt .....
organllallon aid how "'911
tie IY$1em woJd worl
(co,dldcn l
O~ y wppcm -.be<
Servlc• requl......,.,
a,d cunent b-...1ne1$
c...d....,.3
Condido,. 2
ful y aupporh UW'$
Condido .. . ..
Sorre 0 1 oondldale 2.
requlr«I funcflonaltty.
proc:•1• woJd hove
k> be modified to tlb
odvo~e of 1oftwore
funcnonallty.
Po•n~I. A de1cr1p11on of
how W&II reoat¥&d lhl$
$CluHon would be from u1•
management, -..er, ord
organllallon )ellpecnv..
, ..h....t .... b. lty
3111<
T.dlnoloa')tt An OH_,.IWlf
el .._ moh.rlty, c,,,olloblhty
(or abdtty to ccqulre], ord
d•lroblltty of tie oomputw
ll!lehnology n.ded to
$Upport til$ condldote.
S.-»r.: 100
Current producnon release of
Plallnum Plu1, package h
Y&lllon 1D ard ha& been
&tiff ho$ only Powerbullder
Althou~h current ll!lehnlcd
91P9".-.c., the senlcr
""""°
en ..._ morbitfurenly6WW.,. onolyn
,ow Iii• MS
Mah.rnyof proclJd 15 a rtsk, Vhucd 8o$k: demonslrotlOn
a,d a,rnpany charge, a,
ord p11Wdollon have
oddlnonal monthly N for
oglffC the lrOrGlllon wtll be
1ectri1cal &upport.
s.lrrplea,d flrd1ng
91P-1n:ed Ya progrornmen
RecfJlred to hire or !rain C+ + wtll be eml• than flrdlng
Powerl:iudder prograrrrnin
e)IJl• 1he to peri:irm
modlfioonons. for titegronon ard ata much cheaper 00&1.
lXptrtlM. M ouewnw
of lhe lO<hnled ........
needed to dMop, operale,
ard rnalntlln the ca,dldate
-·
req!Jremenh.
MS VltJal 8a,1c 5.0 ls.o
_ , . i.cmolcgy baled
on -,ion number.
s-« so
l conomlc: ,.011b• tty
Co" to d.wlop;
Poybock ,..rSad
~
Mtt pN•nt vah•:
O.tda.d c:Sulot1on,:
Although current ll!lehnlcd
&ti ff 11, comfortable wtth
Powwbulld• , rnonagernin
1$
conc.,,,.i wtlh , . - ,
acq1111,111on of l'o'Y,erbulld.by ¥,a,. Inc. MS SQI.
Server Ii a cunent coff1)0ny
&tlndad and oornpetel
wtth SYBASE In it., dl,wrt/
DBMS market.
9&cauM of lhl$we have
no guaranlee future
ver,.k)nS, of floww.
bvid• wil ~p1oywe11~
wtth our cunent ver,.IOn
aerv•
SQLServer.
s-., 60
ApprQldmately $350,CXX>.
App,o;•maloly $418,0AO.
App'°"'maloly $400,000.
ApprQldmately A.5 yecn.
ApprQldmately $210,CXX>.
Appro;Clmalely 3.5 )e(lfl.
App'°"'maloly 3.3 )O(HS.
App'°"'maloly $325,500.
See Anochrn,wrt A.
See Anochment A
S-. 60
u,,,
Schodule , _ ...
>n a$1• 1mert of how long
t. a,ohJlon W, de IO d•lgl
S.-»r.: 95
s-., 100
3111<
...........
(
S-. 60
1111<
i..1 than 3 rnonti&.
App,o;•maloly $306,7AS.
See Atochment A.
S.-»r.: as
9-12 nonlhs.
s-., 90
9 month$.
ard Implement.
l
llaold09
100%
S-.95
S.-»r.: 80
s-.,as
60.S
92
83.S
,I
T he project manager and executive sponsor sho,dd Jointly facilitate this task.
Other meeting participants should Include the entire project team, Including assigned
~ OWNflt5, USERS, ANALYSTS, OISlG NERS, and 8UlLOflt5. As usual, the meeting st1otL!d be
open to any and aUinterested staff from the business community. Also, lf an inrranet
Web site was established for the project, lt shotdd have been maintained throughottt
the problem analysis ph.ases to ensure continuous communication of project progress.
Th.ls task ls triggered by the completion of the UPDATED PROJ-f.CT PLAN. TI1e T.\RG ET
$YSTE."1 soLtmON (from Tusk 4 .3) ls reformatted for presentation as a SYSTEM PROPOSAl. T he
format may be a repor t, a ,--etb.'ll preset1tatlon, or an inspection by an au ditor or peer
group (called a walk.t hrough). An outline for a written report is shown in Rgure 5-22.
The Next Generations: Systems Analysis
Predidi ng the future of systems analysis is not easy, bJt
we' ll make an attempt. CASE technology will continue ,a
improve, making it easier to model system requirements.
Fin l, CASE tool, will include object modeling ta ,uppcrt
emerging object-oriented analy,i, techniqu... While
,om• CASE tool, will be purely object-oriented, we believe that the demond for other type, of mode Ii ng ,uppcrt
(e.g., data modeling for databa,e,, proce" modeling for
BPR) will place a premium on comprehen,ive CASE tocl,
that can ,upport many type, of model,. Second, the
rE:WeBe-engineering technology in CASE tools will continue
ta improve our ability ta more quickly generate fint-dratt
systen models from existing databases and application
programs.
In the meantime, RAD technology will continue ta en·
able occelerated analysi, approache, ,uch a, prototyping.
We clso expect the trend for RAD and CASE tool, to inta-operah> through rever,e and forward engineering ta h.r1h....- :>irnpliry 6ulh :..y:..lvrn rn0Jylin9 und Ji:,.oovy1 y
protctyping.
~ject-oriented analysi, will "'entually replace ,tru:tured analysis and information engineering as the best
pradice for sys,tems analysis. This change may not occur as
rapicly a, object pun,b would like, but it will occur all loo
rapicly for a generation of ,y,tem, analyst. who are ,killed
in the older math od , . Th ere i, a grand opportunity for
lolented young analyst. lo lead the tran,ition; however, career opportunities will
remain ,trong for analy,h who know data
modeling that will continue to be u..d for
databa.. de,ign. Al,o, the prOC9', modeling renaissance will continue as BPR
projects continue to proliferate.
We al,o predict our ,ysh>m• proposal,
will continue to get more interesting. AJ
the Internet, e-oommerai, and e-busines,
become increa,ingly perva,ive in our
economy, ,ysh>m• analy,b will be
propo,ing new a~emative, to old problem,. There will be a fundamenlol
change in busine,s and information 'Y5'"
terns to u'9 these new technologies.
One thing will not changel We will
continue to need ,ysh>m, analy,i. who
z
CD
x
----t-
w
CD
:::J
CD
--,
0
----t-
0
:::J
undw:i:lunJ how lo rundurn"'ntull., inv1Ali·
gall> and analyze bu,ine" problem, and
define the logical bu,in .., requirement,
a, a preface to ,ysh>m d..ign. Bui wi, will
all have to do that with increa ..d ,peed
and accuracy to meet the accelerated SY5'"
h>m• development schedul.. required in
tomorrow', fo,h>r-paced economy.
Interpersonal an d commwlicatlons skills are essential to this task. Soft skills such
as salesmanship and persuasion become Important (1\ilany sd1ools offer speech and
c ommunJcatlons courses on these subjects.) Systems analysts should be able to wrfte
a fonnal busines., report and make a bush1ess presentation wlthottt getth1g Into tecbn.ical Issues or alternatives.
This concludes the decision ait.alysls phase. And Jt also concludes our coverage of
systans analysis.
F IG U R E S • 2 2
An Outline for a Typical &fstem Proposal
I. Introduction
A. Purpo,e of the report
II.
Ill,
IV.
V.
VI.
B. Background of the project leading lo thi, n,port
C. Scope of the project
0 . Slruclure of the report
Tool, and technique, u,ed
A. Solution generah>d
B. Fea,ibility analysi, (co,t-benefit)
Information $y,1em$ requirements
Alh>mative ,olution, and fea,ibility analysi,
Recommendation,
Appendi..,,
199
Q_
0
E
v
11lls chapter provided a detailed overview of the systems analysis phases of a project.
)'ou are now ready to learn some of the $)'stem.s skills introduced In this chapter. For
most students, this would he the Ideal time to stud)• the fact.finding technique, that
were identitled as critical to almost every phase and task that was described ii this
chapter. Chapter 6 teaches these skills. It Is recommended that you read Chapter 7,
•Modeling System Requirements with Use Cases; before proceeding to any of the
0
modeling chapters since use cases are commonly used to fadUtate the activity of
0
0:::::
0)
c
c
I....
0
(])
.-l
modeling.
The sequencing of the system modeling chapters Is flexible; however, we personaUy prefer and recommend that Chapter 8, •oata Modeling and Analysis; he studied first. All information systems lndude databases, and data modeUng Is an essential
skill for cbtabase developmenc Also, it ls easier to synchronize early data models
with later process models than vice versa. Your instructor Ol.1)' prefer that you first
stud)• Chapter 9, •Process Modeling.• Advanced courses may elect to Jump straight to
Chapter IO to Jeam about ob)ect-0rlented analysis and modeUng with UML
If you do Jump straight to • system modeling chapter from this chapter, mike a
commlbllent to return to Chapter 6 to study the fact-finding techniques. Reg.'ltdiess of
how well you m.1ster system modeUng. that modeling sklU Is entirely dependent on
your ability to discover and collect the business facts that underlie the models.
For those of you who have already completed a systems analysis course, this
chapter was probab~· scheduled only as a re>iew or context for systems design. We
suggest that you merely re>iew the system modeUng chapters and proceed directly to
Chapter 12,"Systems Deslgn.•Toat chapter will pick up where this chapter left off.
Summary ~
I. Formally,systems analysis ls the dissection of a S)'Scem tnco Its component pteces. J\S a problem-60Jving
phase, it precedes systems design. With respect
to lnformation systems development, systems
analysis ls the preUminary investigation of a proposed pto)ect, ti,e study and problem analysis of
the existing S)'stem, ti,e requirements analysis of
business requirements for the new system, and the
decision analysis for alten1att,--e solutions to fuLtlJJ
the requirements.
2. The results of systems analysis are stored h1 a
repository for use In Liter phases and projects.
3. There are se,-.raJ populu or emerging strategies
for systems analysis.11,ese techniques can he used
ln combination wJth one another.
a. Modeklriven analysis techniques emphasize ti,e
drawklg of pictorial S)'stem models that repre-
set1t clther a current reality or a target vision of
the $)"stem.
200
l) Structured analysis ls a technique that
f0ctises on modeling processes.
Ii) Information et1glneerlng ls a technique
tl1at focuses on modeling data.
Ul) Object-oriented an~·sis Is a technique tl1at
foctises on modeling objects that encapsulate d1e concerns of data and processes that
act on tl1at data.
b. Accelerated an~·sis approaches emphasize the
construction of working models of a $)'Stem ln
an effort to accelerate systems analysis.
l) Discovery prototyping ls a technique that
focuses on building small.scale, fw1ctlonal
subsystems to dlscover requlrements.
Ii) Rapid archltected analysis attempts to auto-
matically generate system models from
elther protorypes or existing systerns.11,e
automatic generation of models requirts
reverse engineering technology.
'
Systems Analysis
c. Both model-drJvet1 and accelerated system
analysis approaches are depe11dent on requirements discovery techniques to identify or
extract problems and requirements from system
owners and users.
I) Fact.finding ls the fonnal process of using
research, intervJews, que.stio1u1..1ires, sampllng, and other technlques to collect
information.
ii) Joint reqttlrements planrtlng ORP) techniques ltse fadlltated wod<shops to bring
together all interested parties and acceler·
ate the fact-finding process.
d. Buslness process redesign ls a technJque tl1..1t
focuses on slmpllfyh1g and streamllnh1g fw1dame11tal business processes before apply!ng Information technology to tl1ose processes.
4. Eich phase of systems analysis (prellmlnary lnvestlg,.tion, problem analysts, req,urements analysts,
acd decision analysis) can be understood In ti,e
context of the h1fonnation system building block,:
KNOWLfDGE, PRCX:ESSES, and COMMUNICATIONS.
5. Toe purpose of ti,e preliminary investigation
phase is to detennlne the worthlness of the project and to create a plan to complete those
projects deemed worthy of a detailed stud)' and
ualysls. To accomplish the prelirolnary lnvestlg,1tlon phase, the systems analyst will work with the
system owners and users to : (a) list problems, opportunltles, and dhectlves; (b) negotiate prellmlnll')' scope; (c) assess project worth; (ti) plan ti,e
project, and (e) present the project to the business
commwllty.11,e deliverable for the preliminary in·
vestlgatlon pl1..1se is a project charter that must be
approved by ~'Stem owners an<Vor a dedsionm.1king bod)', commonly referred to as the &eettng
committee.
6. The purpose of ti1e problem analysis phase ls to
answer the questions, Are the problems really
worth solving, and ls a new system really worth
building? To answer these questions, the p roblem
analysis phase ti1oroughly analyzes the alleged
problems and opportwllties first lde11tlfled In the
preliminary hwestlgation phase. To complete the
problem analysis phase, the analyst will continue
to work wlth the system owner, system users, and
other IS management and staff. The S)'Stems ana.
lj>t and approprL1te participants will (a) study
the problem domain; (b) thoroughly analyze
problems and opportwllties; (c) optionally, analyze business processes; (d) establish system improvement objectives and constraints; (e) update
the project plan; and (/) present the findings
and recommendations.111e deliverable for the
Chapter Flvo
201
problem analysis phase ls the system improvement
objectives.
7. The purpose of ti,e requirements analysis phase ls
to lde11tify what the new system ls to do without
the consideration of technology- In other words, to
define the business requlremet1ts for a new S)'S·
tern. As In the prellmlnary investigation and problem analysis phases, the analyst actively works
with system users and owners as well as other JS
professionals.To complete the requlremet1ts
analysis phase, the analyst and appropriate participants will (a) define requirements, (b) analyze
flU1ctlonal requlremet1ts using system modeling
and/or discovery prototyping, (c) trace and complete the requirements statement, (d) prioritize
the requirements, and (e) update the project plan
and scope. 111e deliverable of the requirements
analysis phase is the business requlremet1ts state.
ment. BeC1.t1se requirements are a ruo,·ing target
with no finalization, requlremet1ts analysis also
includes tl1e ongoing task of mai1aglng changes
to the reqttlrements.
8. 11,e purpose of ti,e logical design phase ls to docttroent bush1ess reqttlremet1ts using system models for the proposed system.11,ese system models
can, depending on the methodology, be any combh1..1tlon of process models, data models, and object models.111e models depict various aspects of
our bltllding blocks. Alternatively, prototypes
could be built to .. discover reqttlrements." Some
discovery prototypes can be reverse engineered
hllo system models. The systems analyst and approprL1te participants will (a) structure or prototype ftmctlonal reqttlrements, (b) validate
flUlCtlonal requlremet1ts, and (c) define acceptance test cases. These tasks are not necessarily
seque11tlal; they can occur In parallel. The deUverable for the logtcaJ design pt1ase ts the bustness
requlremet1ts statement.
9. 11,e purpose of ti,e decision analysis phase ls to
transJtion the project from business concerns to
teclullcal solutions by identifying, anal)•zing, and
recommending a tedl.ll.lcal ~·stem solutlo11. To
complete the decision analysis phase, tl,e analyst
and appropriate participants will (a) define candidate solutions; (b) analyze candidate solutions
for feasibility (teclullcal, operational, econonllc,
and schedule feasiblllty); (c) compare feasible
candidate solutions to select one or more recommended solutions; (ti) update the project plan
based on the recommended solution; and (e) pre.
sent ai1d defend tl1e target solution. The deliver.
able of the decision analysis phase ls the system
proposal.
202
Part 1wo
Systoms Analysis Methods
Review Questions
\'~~:=S
C>
l. Wh.at are the business factors that are drfving
system! analysis? Based on these factors, wt1..1t
should ;,J'stems analysis address?
2. What Is model-driven arwysls? Why is It used?
Gfve se7eraJ examples.
3. What Is the major focus of structured analysis?
4. What Is the major focus of infonnatlon
engineering?
5. Why has object-oriented analysis become popuL1r? Whit problems does ft soh,--e?
6. What are the tlve phases of systems analysis?
7. What is the goal of the scope deflnition
phase?
8. Wh.at are the flve tasks that you do In the scope
dellnition phase?
9. What is the trigger for communicating the
p roject plan, and who Is the audience? Why Is
10. Why do many new systems analysts fall to effectively analyze p roblems? What can ti,ey do to
become more effective?
11. What is a popular tool used to Identify and express the fllllctlonal requJrements of a system?
12. What is a common!)• used teclmique for priorltiz.
Ing $)'stem requirements?
13. When co,tld prototyping be used instead of
system modeling for detennining functional
requirements?
14. Why Is the decision analysts phase needed?
15. What are some ways to identify candidate
solutions?
communicating the project plan important?
Problems and Exercises
@:
1. 111ere ;re many different approaches to $)'stems
analysis. Despite tl1ese different approaches, what
Is the universally accepted deflnltlon of systems
analysis? What ls the general consensus as to
when systems analysis begins and when it ends?
As a project manager, what is lmportant to know
regarding ti,e definition of systems analysis, and
what ls important to etlSure ln your organization
reaarding ti,e definition?
2. As a sy,tems analyst, you will be exposed to
and use many different approaches to systems
CENTRICITY
(data. process. etc.)
STRUCTURED
ANALYSIS
INFORMATION
ENGINEERING
AND DATA
MODELING
OBJECT·
ORIENlEO
ANALYSIS
analysis tivoughout your career. It Is important
that you understand the conceptual basls of
each type of approach, and thelr e55e11tlal differences, streogtllS and weaknesses. Conslder the
differences in structured :u1..1lysls, lnformatlon
engineering and data modeling. and objectoriented analysis, all of which represent mode~
drlven analysis, and fill in the matrix show11
below.
TYPE OF
MODELS USED
ESSENTIAL
DIFFERENCES
Systems Analysts
3 . .\ccelented systems analysis approaches are
based on the premise that prototypes can help
reveal the most important busfr1ess requirements
faster tl1..1n other methods. Descrlbe the two most
commonly used approaches to accelerated ai1..1(y.
,Is. What do they do and how do they do It? Wh,t
ls one of the criticisms of prototyping? Do the accelerated systems analysis approaches completely
tepL1ce more formal approaches, such as structured analysis?
4. During the scope definition phase, what ls one
question that you should never lose sJght of? And
how do you aJ.lSWer th.ls question? What ft,--e taslis
,ho,tld occur during the scope dellnltlon phase?
5, \'ou are a new systems analyst and eager to prove
~·our abllitles on your first project. )'ou are at a
problem analysis meeth1g wlth the system owners and users and find yourself saying, .. \X'e need
10 do
this to solve the problem," Into what
the project pl:in or allowing stakeholders to con
11.
12.
13.
1
,. Reduce the time requlred to process the
order.
b. 111e new system must use Oracle to store dat1.
c. 111e data lnput screens must be redesJaned so
they are more user-friendly.
d. 111e ctlStomer satlsfactio11 rate wlth the onllne
orderlng process must be lncreased by
IO perce11t.
.\re these examples of good system Improvement
objectl,-es? Why or why not? If not, how could
tJ,ey be reworded? Also, objectives frequei1tly
have constralnts that are tied to them; what, lf
any, do you tlllnk tl,e matdllng constraint mlght
be for ead1 of tJ,ese objectives?
7. You'>.. made It through the problem analysis
phase of the project, and are now begimllng the
requlrements analysis phase. During the first
meeting 011 the business requirements, one of tlie
other analysts on the project team asks the sys.
1em users, .. How should the new $)'Stem meet
203
your needs?,. Wh.at common mistake is the anal)'St
making? Wh.at are ofteit the consequences of
making this mlstake?
8. What ls the difference between fm1ctlonal and
nonfw1ctlonal reqttlrements, and what ls the purpose of categorizing them lnto these categories?
What are two formats that an anal)'St can use to
document the functional system reqttlrements?
9. Is it Important to prioritize system requiremei1ts,
and lf so, when should the requlrements be prioritized? Wh.at ls one technique t11..1t can be used,
and what ls the difference between mandatory
and de.si.rable requlremei1ts? Wh.at ls one way to
test whetlter a mandatory requirement ls truly a
mandatory requiremei1t?
10. Once the system reqttlrements are idattified and
prioritized, sl10,tldn't e>.. ryth!ng be frozei1 to pre.
vent scope or fearure creep? Does11't updating
common trap are you h1 danger of fallfr1g? W11..1t
1edulique could you use to avoid th.ls trap?
6. Your project team has completed tl,e scope detlJ>.
ltlon phase,and ls now at the point In tl,e prob,
!em analysis phase for establishing system
improvement objectf,les. As the systems :u1..1tyst
on the project team, you are the facilitator of a
brait1Stormb1g session to define the system improvement objectl,..s. Since several of the project
owners and users have never done this before,
describe the characteristics of good system fm.
provement objectl,-es and provide some examples. Members of the project team suggest the
following objectives:
Chapter Flvo
14.
15.
tltme to request changes Just delay S)'1em design
and construction, and maybe even project completion Itself/
Why should acceptance test cases be dellned durh1g the logical design phase? After al~ the tedmlcal desJgn hasn't been done yet, let alone building
the $)'Stem. Shouldn't testing actlvltle! at least
watt tmtU construction is actually tm<bway?
How ls tJ,e logical design phase different from
the req,tlrements analysis phase?
Let's say you are on the project team of a project
that had a great deal of dlfllCltlty during the req,tlrements analysis phase, and fell se,·eral weeks
behind schedule .111e project manage, wants to
try to catch up by eitl1er skipping or abbrevlatlt1g
some of tl,e tasks in the logical design phase.
After all, tlte project manager reasons, we really
have a dear Idea of the requirements now, tl1e
desJgners and builders are really expe,:tenced, and
they don't really need the logical design h1 order
to do the tedmlcal design. ls this a legitimate
method to get back on schedule? W11.11 are tJ,e
posslble consequences?
In ldet1tlfying and deftn!ng possible candidate solutions, wh.at are the typical roJes of the '\o-atJous
stakeholders who are involved in the project?
You are a systems anal)'St and have been asked to
fadlitate the analysis and evaluation of several
candidate system solutions for thelr feaslblllty.
What sets of criteria wo,~d you typically use?
Who do you involve in this task? Should you compare the candidate soJutions against eich other at
this point? Why or why not? W11.11 ls the typical
deU,.. rable comh,g out of tills task?
204
Part 1wo
Systoms Analysis Methods
Projects and Research
~
l. Select an fr1fonnatlon system wlth whid1 you are
familiar, ,nd whlch you feel needs to be improved,
based ui:on your experiences as an employee, customer, other system user, or system owner. Swltch
roles and perspectives as necessary to perfonn or
answer the following:
a. Describe the nature of the information $)'stem
you have selected.
b. Describe the organization that owns and malo-
taitu d1e Information system.
c. Identify the baseline problems and opportwlltles, per Task l. l.
d. Develop a prellminary problem statement, using the format shown in Figure ~2. ~ume ~·ou are the now a systems analyst on the
project described in ti,e preceding question. Executive management was extremely lmpressed by
your work 011 the problem statement. As a result,
they h.we gh'en the project tl,e go-ahead, the baseline schedule and budget have been developed,
and ti,e project pL1n has been approved by the executive steering committee. As the systems ai1..1lyst,
you now ha,--e beett tasked to do the following:
a. Develop and document )'OlU' w1derstanding of
the problem domaln and business vocabuL1ry,
using the textbook's information system bulldlng blocks framewod< as described in Task 2.1.
b. Analyze problems and opportwlltles using
cause-and-effect analysis (Tusk 2.2).
c. Analyze business processes and de,-elop
proctss models (Task 2. 3).
d. Establish system lmprovemetll objecth'es
('l\"'k 2 .4).
e. Prepare a Problems, Opporttullties, Objecth-.s,
and Constraints Matrlx,ush,g Agure 5-12 as an
example.
3, Communicating findings and recommendations ls
the final task in the problem analysis phase. As a
systems malyst on the project, you have been
tasked with preparing ti,e System Improvement
Objectl\'eS and Recommei1datlons Report. For tills
exercise, prepare 01lly ti,e Execuu,-. Swrunary
Minicases
portion of the report, using the format shown lo
Figure 5-13. The executive steering committee wUJ
use this summary to make lts dedsJons regardlt1g
the recommendations.
4. Your strong work on the project to date h ..is con-
tinued to Impress executt,--e management..You
have received a pay increase and have beett tasked
wlth conducting dte requirements analysis pti1Se.
SpeclJlcally:
a. Identify tl,e system requirements, and prepare an
outline of functional and nonfunctional requ.f.re.
ments,perTosk 3.1.Since your orgart.izatlon uses
structured aiulysis and does 11ot employ use
case modelh1g, list each system lmprow,metll objective, and d'le inputs, processes, outputs, :tnd
stored data needed to meet ead1 objective.
b. Assume that the requirements )'OU identified in
the preceding step have been ...udated. Prioritize
the requirements according to their relative importance, using the med1od desctibed ln'last 3.2.
5. Your work has helped keep d,e project well ah•ad of
schedule, so executtve management gives you a couple of weeks of paid ,-acatloi> When you retum, the
project ls mo,ing hllo d,e decision analysis phase.
Your next task ls to identify• candidate solutions.
a. Describe the process for identifying candidate
soJutions. Wh.at should you be carefu.l ,iot ro do
at this point?
b. OeveJop a candidate systems matrix, ush1g the
fonnat in Figure 5-20 as an example, and in·
dude three possible solutions.
6. After idet1tlfyh111. candidate solutions. ti,e next step
ls to analyze these soJutions.
a. Describe the process for analyzing candidate
solutions. Wh.at sl1oti.ld the project team 1101 do
in completing this task?
b. Develop a Feaslblllty Analysis Matrix, based
upon the candJdate solutions ldentlfled in the
precedh1g question, and using the fonnat
shown h1 Figure 5-21 as an ex.ample. Determlne
what your weighting factors shot~d be.
~
l. You are the ao of a major retailer. Recently, you
read •sp)ing on the Sales Floor• in the Wall Street
jo·ur11al 011 December 21, 2004. You see that your
competitors are using video mhling to analyze consumer bel1avtor. Sho,~d your company also adopt
thls tool (video mlnh1g)? What are the strategic
Systems Analysts
lmpllcatlons to your company of your competlton'
move? Wh.at opportunities have been created?
1breats?
2 . Read "Human Reenglneeting," by Cooper and
,_larkus, ln the Sloan Afa11age111e1it Revf.eu.1, Stunmer 1995. In this artlde, Okw10 works on lnstltut·
ing a posltt,--e attitude toward change. How does
he do tills? Dlscuss the importance of d1aoge accrptance by employees to the success of a tech-
nology implementatlo11.
3. Refer to Mlnlcase l. You, as the ao, belleve that
the b usiness gains for implementing vldeo mining ln your retall stores wll1 outweigh any nega-
Chapter Flvo
205
rive customer perceptions. Your company ls
Baby's R Us, a child company ofToys R Us. Do an
economJc feaslblUry study for tllis investmet1t.
Be sure to include a listing of intangible costs
and benefits, as well as an argument for your
chosen discolUlt rate. What is the ROI of the
video ml1llng? Try to keep your anal)•,ts to under
15 pages.
4 . Develop a project plan and schedl~e feasibility
study for the vide0,mlnh1g Investment into Baby's
R Us. Be sure to Include a Gantt and PERT/CPM
chart, as well as a dear discussion of aU tasks tl1..1t
need to be completed.
~ Team and Individual Exercises
I. Hnw often do you tWnk legal issues play a role in
project success? Think of an example of a potentially
good lnfonnation system or program tlut was constrained or not feasible due to legaJ requirements.
2 . As a team, brait1Storm some ways to enhance empl.oyee change acceptance of new information
systems or business proce~es.
3, Tilink of an example when business process Improvement ls more appropriate than business
process reenglneerlng. Share wlth tl1e clas.,.
rs]]
AfJpltcatfon Deoofop1ne11t 1tends ( month!}' pc,riodical). Natick, MA: Softwatt Producthi.t)• Group, a ULLO Interru·
tional compan): This is o ur f:n'O rite systems ck\•e lop blc':nt
periodical. It fo llO\\<s syste,ms a nalysis and design stl'l.tr·
girs, me thodologies, CASE, and other ttle,.'atlt trends. Vii it
its 'Web s ite at '""'"''.adttnag.com.
Gause, Donald C., and Ge,l'J.ld M. Wei.nbc,rg . Are Jtiur Lfgbts
Ou? Hou; to Ftgure our wbar the .Probfetn REALLY Js.
N~ Yotk: Dorset Hou.se Publishing. 1990. Here •s a tide
ttut should really get you thinking. and the e ntire book adc.bt$SC'S one of the least pu blished aspects of systems
atulysis: problc,m sol-vi.Ilg.
Ham.tnct:, ~ti:kc. • Rccng in«ri.ng Work: Don' t Automate, Oblit·
ehte.• Harvard B11S11Jess Revtetv, July- Aug ust 199),
pp. 104-11. Dr. Hamme r is a noted expert on busindtS
process redesign.This seminal paper ex.amines soblc': classk cases w here the techniq ue dramatical!}' added \'llluc to
bu.incsscs.
Suggested Readings
Wetherbc, Jamcs. sysre111s A11af)1sts a1Jd DeSfftJ.' Best Pmctfces, 4 th ed. St. Paul, ~tN: West Publishing, 1994. We arc
in<kbtcd to Dr. Wetherbc for the PIECES fuwcwork.
Wood.Jane, and Denise Sih'C',r. ptnt AJ)plfcatfon Destg11.· HotlJ
to Desfgn Quattty S)1ste111s ,,, 40% Less 1fnw. Ne\\• Yotk:
John WJey & Sons, 1989.T his book provides an excelle nt
in-depth p resentation o f joint application ck\'C'lopme nt
OAD).
Yourdon, Edward. ,Wotlern Structr1ret1 Anaf)1sts, Engle\\•ood
Oiffs, NJ: Yourdon Pttss, 1989. This u pdate to the classk
DcMarco text on the same subject de.fines the c urrent
state of the p nctice fo r the structu red analysis a pproach.
Zachman, John A. •A Fl'.Ullc:Work for tnfo r nution Syste,m
Att:hitccture." /BJW S)1ste111sJ011mat26, no. 3 ( 1987) . This
a rtic·lc pltSdlts a popular conceptual fn mcwork fo r
info rmation systems sul'\'C)'S and the dc,tlopme nt of an
info rmation architectu re.
Slrategle Enterprise Pian
S11'W91C m:irmatbn s,rtems Pian
•npo,•"''"
a,,...,
COMWUltCATIONS
-
&TATE • EIIT OF WOIJI(
PIJ08LE •
S TA TE . ENT ( Ut l11 9 t ho PIE CE S 1r, 111•wo r k)
...•
.,
FUNCTIONM.
ICO. .
- ~
CO•MJNICA1l0118
.....•
Vl80ff
8 Y8 TE• IMPRO V EMENT O&JECTI Y E8 ( u t l11 9 tho PIE CE S u , m• wo rk)
~
•..
I
•
~
)
I!!
~
•
v
Ii
!
!!i
..
~
~
iii
~
t;
~
i
i!
I;;
!;
~
-
....
-......
8U8 NE88
PAOCES&
IIEQJIFE• ENT&
18
....
......
LOGIC.Al.
PAOCES&
•oons
&Y8TE• PROPOSAL
l?
(or IJEOUE8T FOR &Y8TE• PROPOSALS)
ARCHITECTURAL NOOEL
8!
OE&IGN PROTOTl'PE8
8U61NES8 PA0~ 8
~
>
~
......
PHV61CAL
DESIGN
S PECIACRIONS
~AEOE.SIG'I
""""
5
--
NTEAFACE
OESGN
6PEOFIOOIONS
SPECIFICATIONS
FUNCTIONAL SY&TEM
-RAINING •.t.TEFIIAL8
.........,.,
'"""""
cu&10w~1n
.........,.,
~
J
PHYSICAL
USEA &Sm-EW
...
..,_,,
-
•~
-
n
.........
.........
~
f
s
§
>
i
APPllCATION
-
•
USER
INTE~ACE
8Cl.VTION8
""''"
INTE~ACE
8Cl.VTION8
POST-AUDIT REVIEW
OPEAATIONAL &YSTE•
.
APPFICWEO
........
APPFICWEO
1£CHNOLOOIE$
TECHNOI.OOIU
..........
-
Cf'IC.IH.
........
...,..,.
S1rat&gle EnlerprlSe 1ntormat1on .._enno1ogy Arcnltecture
Fact-Finding Techniques for
Requirements Discovery
Chapter Preview and Objectives
Effective fact-finding techniques are crucial to the devebpment of systems p,tjects. In
this chapter you will learn alx>ut techniques to discover and analyze information system
requirements. You will learn how to use various fact-finding techniques to gather information alx>ut the systen1•s problems, opportunities, and directives. You will know that you
understand fact-finding techniques and requirements dis::overy when you can:
I Define system requirements and differentiate between functional and nonfunctional
re~uirements.
I Uoderstand the activity of problem analysis and be able to create an Ishikawa
(fohbone) diagram to aid in problem solving.
I Uoderstand the concept of requirements management
I ld!ntify seven fact-finding techniques and characterize the advantages and
disadvantages of each.
I Uoderstand six guidelines for doing effective listening.
I Uoderstand what body language and proxemics are aod why a systems analyst
should care.
I Oaracterize the typical participants in a JRP session and describe their roles.
I Complete the planning process for a JRP session, including selecting and equipping
the location, selecting the participants, and preparing an agenda to guide the JRP
session.
I De.scribe several benefits of using JRP as a fact-finding technique.
I De.scribe a fact-finding strategy that will make the most of your time with end users.
208
Part 1wo
Systoms Analysis Methods
Bob ,_lartloez has spent most of the week reading. He started with memos related to the
proposed Member Senices S)'stem to better understand the problem. He then re,iewed
SoWKIStage's procedures manual for any policies related to member senices and pro.
motions. He stud.Jed nearly l 00 member order forms seJected ar random, noth1g the
kinds of data recorded In each blank and whld1 blanks were always, sometime,, and
never used. He read the documentation for the present member senices system. Be reviewed data and process diagrams from the prior member •=ice systems development
projec~ noting things that would probably need to be changed In d,e new system. It
was gruellng work. But In ti,e end he really felt like he was beglnnlng to w1derstand the
system. He produced a report foc Sandra, hls boss, of the key Issues and questlo1u that
would need to be answered at the upcomlng Joint requlremetlls plannlng meeting.
An Introduction to Requirements Discovery
ln dt.'tptet' 3 we discussed se,,'en.l plt.'tses: of systems de"-elopment. E~ch ph~s:e is: i.m,.
requitemei.-.s disco,·ery
the process and techniques
used by systems analysts to
identify or extract system
problems and solution
requirements 1rom the user
community.
system requiremeot
something that the inbrmation
system must CO or a property
that it must ha'/e. Also called a
busin9SS f9QU.Y91Tl9nt.
ponant and necessary lo order to effectively design, construct, and t~tlmately lmplemet1t a ~·stem to meet the users' (stakeholders') needs. But to develop such a system,
we must: first be able to correctly idet1t:ify, analyze, and understand what the users' requirements are or what the usess want the system to do. The process and techniques
that a ~·stems analyst uses to idet1t:ify, analyze, and w1derstand system requirements
are referred to as req11lrements discovery. As suggested by the chapter's home
page, reqttfremet1ts disco,--ery primarily invoJ,-es systems analysts working with
system users and owners during the earlier system developmet1t pl1ases ro ob1aln a
detailed tmderstandtng of the bush1ess requirements of an information ~·stem.
What are system requirements? S)''Stem requirements specify wt1.1r the infor.
matlon system must do or wt1.1t property or quality the system must have. System requlremetlls that specify what tbe Information systetn must do are frequet1tly referred
to as functlon.-.J requirements. System requlremetlls that specify a property or qua~
ity the system must have are frequently referred to as 001UU1xtloo...'ll req11irements.
The PIECES framework (Table 6.1), Introduced lo Chapter 3, pro,ides an exceUent
tool for dasslfylng system requirements. The benefit of classifying the various types of
reqttlremetlls Is the ability to group reqttlrements for reporting, tracking, and validation
purposes. Plus doing so alds h1 klet1tifyh,g posslble overlooked requlrements.
Es~ult.llly, llut pw..,o:,;t:' uf 1·~uireuu::ut:,; ul~uvt:'ry aud t11.u1agt:'uu::u t i:,; tu c..v..-
fuoctiooal requiremeot
something the information
system must co.
oo-o.f'u.nctioa.al requiremeot a property or quality
the system mLst he/9. Exam.
pies include security, ease.of.
use, performance.etc.
rectly idet1t:ify the KNOWLEDGE, PROCESS, and COM."1UNJCATION requirements for the users
of a new system. Failure to conectJy Identify ~·stem reqltfrements may result In one
or more of the following:
The systetn may cost more tl1ao projected.
The systetn may be deliveied later than promised.
The system may not meet the users expectations, and tl1.1t di~atlsfact:Jon may
cause tl1em 11ot ro use it
Once In production, the costs of maintaining and enhancing the systetn may
be excessively hlgb.
The system may be wvelL1ble and p rone to errors and downtime.
The reptttation of the IT staff on the team is tamlshed because any fallwe,
regardless of who is at fault, will be perceived as a mistake by tl1e team.
11,e lmpact In terms of cost can be staggering. Toke, for example,Tuble 6.2, by B.'lft)' W.
Boelun, a noted expert h1 h1formatlon technology economics. 1 He studied several
tootuLld C.Gii.u,c 11t1d GduJd M. Weitibttg, E.rplon.,fl R~t1in11w#ts: Q,u,1#)' ~fan Dtstjn(New YOJ.'t: Oot'Jtt lk\.l!JIC'
Publisbitig.1989), pp. 17- 18.
Fact-Finding Tochnlquos f« Roq<lromonn Discovery
d,aptw Six
209
,. TABLE 6-1 PIECES Classification of System Requirements
Nonfunctional
Requirement Type
Peoormanai
'
Explanation
Performance requirement$ repl'9sent the performance the system is required b exhibil to meet
lhe neods of u,en.
• What is lhe acaipioble lhrooghp<i rai<>J
• What is lhe acaipioble response timef
lnfoonation
Information requirernenb repre>ent the information that is pertinent lo the users in terms of
content, timeliness, accuracy, and format.
• What are the nea>'5ary inplll, and 001put,J When m"'1 ihey happenf
• What is lhe required data lo be slored'?
• How a..irrent must the information bef
• What are the interfaces to external systamsJ
ro>l10r11)'
Economy requiremenb repre,ent the need for lhe ,y,Jom lo reduce 0001' or increase profib.
•
•
•
•
Control (and security)
What are the areo, ol lhe sy,lom where cx,.1, m"'1 be reduaid'?
How much ,hoold 0001' be nduced or profit, be increowd'?
What are the budgelory limibf
What is lhe timetable for del'Olopmon~
Control requirements representtle en\llronment in which the system must operate, as well
a, the type ond degree ol ,ecurity lhat mu,1 be provided.
• Must acceu lo lhe ,y,19m orinfonnation beoonirol edf
• What are the privacy requirO'llOrllsf
• Doe, the criticality of lhe dat, nea>'5ilate lhe need k>r special handling (backup,, off-silo
,torage, e1t.Jol the darof
Efficiency
Efficiency requiremont, represent the ,y,Jom'• ability lo produce 001put, with minimal W<ISio.
• Are there duplicate straps in the process that must be eliminatadf
• Are there 'MJYS lo Rlduce ~ste in the way the system uses it resourcest
Service
\..
Service requirement, repre,enlneeds in order for the ,y,Jom lo be reliable, flexible, and
expandable.
• Who will use the ,y,tem, ond where an, lhey locatedf
• Wil there be differenl lypoo of u,enf
• What are the approprialo human facloBf
• Whd training devices and training materials are to be included in the systemt
• What training device, ond lroining malarial, are lo be developed ond mainloined ,eparaioly
from lhe ,y>tem, such a, ,ta rd-alone oomputer-b°'ed lraining (CBT)
program$ or databasest
• What are the reliabilily/ CMliabilily requiremenbf
• How "1oul d lh e •Y' l9m be packaged ond di ,tributed'?
• What documentation is requ:redf
,
210
Part 1wo
Systoms Analysis Methods
'
TA a LE 6 - 2 Relative Coasts of Fixing an Errar
Phase in which
Error Discovered
Requirement$
Do,ign
Coding
Development Tooting
Accepronco Tooting
Operation
Cost Ratio
1
3-6
10
15-40
30-70
40-1 ,000
software development projects to detennlne the costs of errors in requirements that
Weretl' t discovered until later in the deveJopm ent proces.,.
B.1Sed on Boehm's findlngs, an erroneous requirement dut goes tmdetected and unfixed until the opention ph.'l.Se nuy C06t t ,000 times m o re than Jt wou ld if ir wete de
tected and fixed In the requlrements phase.Therefore, h1 defining >)'Siem requirements,
it Is critical that they meet the following criterL1:
requlreme11ts are 11ot conf Uctlng or ambiguous.
Complete- T he reqttlrements describe all possible system Inputs and
Co·11sf.ste1it- 1l1e
responses.
Feasible- The requlremen1s can be satisfied based on the a"-ailable resources
and constraints (feaslbillry analysis Is covered In a,apter 11).
Required- TI, e requirements are truly needed an d fulfill the p urpose of the
system.
Accu.rate- T he requirements are Slated correctly.
Traceable- Toe requirements dhectly map to the functions and features of
the system.
Verifiable- Toe requirements are defined so that they can be demonstr.ued
d uring testing.
Tills can be a tlme-consumlng, dlfflct~t, and frustrating process that ofte11 leads org.1n izatlons and lndl:viduals ro tal:e sh or tcuts to save time and money. But tllls !hortslgbtedness often leads to the problems mentioned before. Now that we understand
our goal, lets look at che ptOCe.$.
The Process of Requirements Discovery
111e process of requlremenrs discovery consists of the following acthities:
Problem discovery and analysis.
Req,t!rements discovery.
Documenth1g and analyzlo;! requirements.
Requirements management
Let's now ex.amine each one of these actlvitles In detail.
>
Problem Discovery and Analysis
As prevJousJy stated, requirements solve problems. For systems analysts to be successM, they must be skilled h1 the actl,ity of problem analysis. To fully under,tand
problem ai1..1lysls, let•s use the fcllowlng example: A mother takes her yow1g daltylter
to the doctor because the chlld Is ill.T he first thing the doctor tries to do Is Identify
Fact-Finding Tochnlquos f« Roq<lromonn Discovery
d,aptw Six
211
the problem.111e child h.as an earache, a fever, and a runny nose. Are these the prob.
lems? TI1e mother has been giving the chJld pain medJcine to ease the pain, but
the chUd h.as not gotten better. It turns out the mother is treating the ~·mptoms and
11ot the real problem. Forttmately, the doctor ls trained to analyze further. After examlolng the dilld, the doctor has concluded that the chlld has an ear Infection,
whld1 is the root cause of the dlild's symptoms. J\ow that the problem l1as been
identified and analyzed, ft ls time for the doctor to recommend a cure (solu tion).
NormaUy, an antibiotic ls prescribed to cttre an ear lofectlon, but in order to do that,
the doctor first needs to determine lf there are any constraints on the medicine that
he can prescribe. How old ls the chlld, and how much does she weigh? Is the dilld
allergic to any medJcatlons? Can she swallow pills? Once these constraints are
known, a prescription can be generated. Systems analysts use the same problemsol\oiog process as a doctor uses, but instead of diagnosing medical problems they
diagnose system problems.
One of the most common mistakes inexperienced $)'stems analysts make when
trying to analyze problems is Identifying a symptom as a problem. As a res,dt, they
may design and Implement a solution that more than likely doesn't solve the real
p roblem or that may cause new problems. A popuL1r tool used by development teams
to identify, :inalyze, :ind solve p roblems is an Ishikawa. d.l..1.~.m. The fish.bone.
1Sblk3wa diagram a
shaped diagram is the bralnchlld of Kaoru Ishikawa, who pioneered quality manage- graphical tool used to identify,
ment processes In the Kawasaki shJpyards of Japan and, In the process, became one explore, and depict problems
and the causes and e~cts of
of the founding fathers of modem management
1hose problems. It is often reDrawing the flshbone diagram begins with the name of d,e problem of Interest et~ ferred to as a C8IJS9.Mld-ct
tered at the right of the diagram (or the fish~ head).The possible causes of d,e problem dagam or a f#!ono diagam
are lhen drawn as bo1,es off the 111ain backbo·,w, each on an arrow pointing to the (because it resenbles the
bacl:bone.1)•plcall)', these "bones· are labeled as fotu basic categories: materials, ma- skeleton of a fish).
dili1es, manpower, and methods (the four ,_Is) . Other names can be used to suit the
problem at hand. Alternative or additional categories lnclude places, procedures, policies, md people (the four Ps) or sum,undlogs, suppUer,, systems, and skills (the four Ss).
The key is to have three to six main categories that encompass all possible areas of causes. Bn.lnstormlng techniques (defined farer In the chapter) are commonly
performed to add causes to the main bones. Whett the braJnstonnJng is complete,
the flshbone depicts a complete picture of all the posslbllltles about what could be
the root cause for the desJgnated p roblem. TI1e devtlopmet1t team can then use the
diagram to decide and agree 0 11 wh.at the most likely causes of the problem are and
how they shOldd be acted on. Figure 6-1 is an example of a fishbone diagram
_
-Mernoer unriapp1ness •
~Fnane1a1 _
N04JJIOmaDc
oe1a11t eo1uaon
~
_ _ 1n, ume1ent
proo1erns
B'lroroement
IOOCOSlly
, . No rern1naere
w.arn1ng customers
~
~ N o progress _ _
tract<ll'lg
lnoentlVM
Laekot
-B'lroroernent ~
- - PollCle.s
1naaequate
~
C- ·- - - - - - - - - F I G U R E 6 • 1 Sample Fishbone Diagram
)
212
Part 1wo
Systoms Analysis Methods
depicting the SoundStage problem of members defaulting on contracts. In the diagram, notice tliat the problem to be solved is in the box at the far right. The five
areas thar have been ldentlfled as categories of causes (People-?ttembers, r.tethods,
Contracts, ,_laterials, and Policies) are listed In boxes above and below the
fish's skeleton and connected by arrows (bones) poh1tlng to the fish's backbon e.111e
actual causes of the problem for each cat egory are depicted as arrows pointing to
the category arrow (bone).
>
fact-flnd.it1g the formal
process of using research,
meetings, inte'Views, questionnaires, sampling, and
other techniques to collect
information about system
proo1ems, requirements, ana
preferences. It is also called
inbrmation gath9ring or data
coH9c1m.
Requirements Discovery
Gtven an understanding of problems, the systems analyst cut start to define requirements. For today's systems analysts to be successful In defitl.ing system requirements,
they must be skilled in effectl..-e metl1ods for gathering informatlon- fact-tlndlng.
Fact-fhtdiug Is a tedmlque that Is used across the enthe developmetll cyde, but it is
extremely critical h1 the requlrements analysis pbase. Once fact-finding h.as been completed, tools such as use cases, data models, process models, and object models wlU
be used to document facts, and condusJons wUJ be draw11 from the facts. You will
learn about these tools and ho\\· to dOCltment requirements dert,--ed from fact.finding
u1 subsequent chapters of th.ls textbook.
Facts are in the domain of the business application and its end users.Thertfore,
the analyst must collect those &cts In order to effectively apply the documentation
tools and technlques. During Sj'stems analysis pbases, the analyst learns abo<K the
,"'OC:lbutary, problems, opportunities, constraints, requfremet1ts, an d priorities of a
business an d a system.
What types of facts must be coUected? It wot~d certainly be benetlcL1l If we had
a framework to help us determine what facts need to be collected, no matter what
project we are working 011. Fomm.ateJy, we have such a f.ramewodc As It turns out, the
facts that describe any information system also correspond nlcely with the building
blocks hlghlighted on the chapter home page. Notice tl1at fact.finding tedmlques are
used In the early systems development phases to Identify h1formation, functional, and
communlcatlon scopes and visions, as well as to identify business knowledge prcce.s.,,
and communlcatlon requ.frements for the system .
>
Documenting and Analyzing Requirements
When the systems analyst Is pe,forming fact.finding activities, It is Important tltat the
.1.n.'llyst assemble or dOClunenr the g2dtered lnfonn:ltion (or
war
draft ,.oqulwn1q11/$) In ,n
organized, understandable, and meaningful
These initial documents wlU provide
direction for the modeling techniques the systems analyst wlU use to analyze the requirements and determine the correct requirements for the project. Once those have
been ldentltled, the systems analyst formalizes the requlremetlls by presenth1g them
in a docttment tl1..1t will be re"iewed and approved by the users.
Documenting the Draft Requirements Systems analysts use various roots ro document thelr initial findings In cltaft form. They write use cases to describe the system
functions from tl1e external users' perspective and in a manner and terminology tl1e
users w1derstand. Declsf.011 tables are used to dOCltment an organlzatio11's complex
business policies and dedsion-making rules, and requ.lretnents tables are used ro document each specific requirement Each of tl1ese roots is examined in more detail L1ter
h1 the chapter.
Anatyzing Requirements More often than not, fact-tlndh1g activities produce
requirements that are lo conflict witl1 one another.1bls Is because requirements are
solicited from many different sources and ead1 person has bis or her own oplnloos
Fact-Finding Tochnlquos f« Roq<lromonn Discovery
d,aptw Six
213
and desires for the functionality and features of the new system. The goal of the
requirements analysis activity ls to discover and re.solve the problems with the
requirements and reach agreement on any modifications to satisfy the stakeholders.
The proces., ls concerned with the .. lnltial" requirements gathered from the stakehoJders.These requirements are usually Incomplete and documented in an informal
way in instruments such as use cases, tables, and reports. The fOCllS at dlis stage ls on
reachJog agreement on the stakeholder's needs~In other words, the ai1..1lysis should
aOS\'let the question, '1)o we ha,--e the right system requirements for the project.?•
Inevitably, the draft reqttlrements contain many problems, such as:
blissing requirements
Conflicting reqtdrements
Infeasible requirements
o,--erlapplng requ.frements
Ambiguous requirements
The.se types of requirements problems are very common in many of the requirement
documents written today. If left unresolved, they can be extremely costly to fix later
In the development cycle.
It w:is pre"iot1sly mentioned that stakeholders should agree on the resulting &)'S
tern requirements-thus there is an Inevitable negotiation process that ex.1sts among
staktholders during analysis. If m,dtlple stakeholders subndt reqturements that are In
conflict with each other or lf the proposed requirements are roo ambitious, the stakel10Jders must negotiate, oftet1 under the guidance of the ~tem.s analyst, ro agree on
any modifications or simplifications ro the system requ.Irements. They also must agree
on the crftlcallty and prlorfry of the requirements. 111.is is crucial ro ensure the success
of the development effort.
Toe fact-finding and reqtdremet1ts analysis acthities are very closely assocL11ed
with each other and ln fact: are often interwoven. If reqttlrements discovered during
tl1e fact-finding process are found to be problematic, tl1e analyst may go ahead and
perfonn analysis actl'\oitles on the select Items it1 order to resolve the problems before
continuing ro eUdr addJtlonal ~tern needs and desires.
This chapter foctrses primarily on tl,e business side of requlremet1ts, or, In other
words, the logical reqttlrements, bur Jr is important to 11ote rhar addltlonal technical
requirements exist that are physical In nature. Examples of technical requlrements h,
clude specifying a req,ured software package or hardware platform. These types of
requirements wUI be discussed In depth In Chapter 11.
Pormallzlng Requirements syscem reqturemencs ue usually docttruenced In a formal way to communicate d1e requiremet1ts ro the key stakeholders of the system.1b.ls
document serves as the contract between the system owners and the development ream on whar Is goh1g ro be pro"ided it1 renns of a new ~·stem. Thus, ft may go
through many revisions and re'\oiews before everyone agrees and authorizes Its conret1ts.
There is 110 standard name or format for tllls document In fact, mai1y organ.izatlons
use dlfferenr names such as requirements statement, requirements spec.Jflcation,
requirements defhlitlon, fw1ctlonal speciflcatlon, and the like, and the fonnat Is usually tailored ro d1e organization's needs. Companies that pro"ide Information systems
and software ro the U.S. government must use tl1e format and naming conventions
specified h1 tl,e governmet1t's published standards dccwnent MIWTD498.' Many orgatl.i1atlons have created tl1eir own standards adapted from ,_UlrS1D-498 because of
Its thoroughness and because rnany people are already familiar with It. In this book
we wUJ use the term requirements defio.ltion document, and Agure 6-2 pro"ides
a sample outline of one. Please note that this documet1t will be consolidated with
11\LIL.SrJ)..(98 #11 llCLlld.:i:td that tndpJ OODSrD-2167A iLlld 00J).Sfl).793SA to dc£1t1c- 11 lid.of!lelivitio 11t1d docu.ll)C'.~
talion -.iitable for- the ~loptndll d both '111'.-i:1.J)OA ~il..lld 11u!Olnlkd ibfottnllliob ~ctn,.
requiremeot! defitlitioo
documeot a formal document that comrrunicates the
requirements of a proposed
system to key S1akeholders
and serves as a contract
for the systems project. Synonyms include r.iqu irements
S1atement, requ rements
specification, and functional
specification.
2 14
Part 1wo
Systoms Analysis Methods
FIGURE 6 - 2
REQUREMENTS OEflNITION DOCUMENT
1. Introduction
Sample Requirements Definition
Outline
1.1. Pupose
1.2. Backgto(lld
1.3. Scope
1.4. Definitions, Acronyms, ard.A.bbreviations
1.5. References
2. General ~oject Description
2.1. Functional Requirements
3. Requirements and Constraints
3.1. Functional Requirements
3.2. Nom.nctional Requirements
4. Con:lusion
4.1. OUtstarding Issues
f.ppendix(optional)
other project lnforlillltlon to form the reqttlremenrs statement, wbid1 is the firul deliverable of the requirements analysis phase. A requirements definition document
should consist of the following:
The ftmctlons and services the ~·stem should provide.
Nonfunctional requlremen1s, induding the ~·stem's features, d1..1rncterlstlcs,
and attributes.
The constraints, wbid1 restrict the development of the system or lmder
whlch the system must operate.
Information about other systems wfth wll.ich the system must interface.
Who will read the requlremenrs definldon document? 1bls document ls probably
the most widely read and referenced document of all the project documet1tatlon.
Systetn owners and users use It 10 specify their requlrements and any changes that may
arise. ,_lai1..1gers use it ro prepare project pt.uu and estimates, and developers use it to
understand what is required and to de,'dop tests to validate the system. With this In
mind, it ls important to note that requirements are read more often than they are written. Therefore, taking the time to write thetn correctly, concisely, and dearly no, only
will sa,--e time in tenns of the schedule but ls also more cost-efficient and reducts the
risk of costly requirements errors. Perfonnlng requirements validation, therefore, is a
necessary step toward acble,,ing that goal . Requlrements validation ls perfonned on a tlnal draft of the requlrements definition document after all Input has been solicited from
the system owners and users.The purpose of this actfvJty is for the systems analyst to
ensure the reqttlremet1ts are written correctly. Examples of errors the systems aaalyst
mlg)lt find are:
System models tl1at contain errors.
Typographlcal or grammatical errors.
Conflicting requlretllents.
Ambiguous or poorly worded req,tlremenrs.
L,ck of conformance to quality standards req,t!red for the document
>
Requirements Management
Over the lifetime of the projec1 ft ls very common for new requirements to emerge
and existing requfremet1ts to cb.ange after a requirements definition document has
beet1 approved. Some stud.Jes have shown that over the life of a project as much as
Fact-Finding Tochnlquos f« Roq<lromonn Discovery
50 percet1t or more of the requirements will dw1ge before the system ls put Into prod uction. Obviously, this can be a major headache for the development team. To help
alleviate the many problems associated with changing requlremet1ts, ft ls necessary to
perform requlremeitts m.1Jugerueut. Reqttlrements management encompasses the
policies, procedures, and processes that govern how a change to a requfremet1t ls
handled. In other words, it specifies how a change request should be submitted, how
it ls analyzed for Impact to scope, schedt~e, and cost, how It is approved or rejected,
and bow the change ls implemented If approved.
( Fact-Finding Techniques
In this section we present seven common fact-flndtng teduliques:
Sampling of existing documetllation, forms, and databases.
Research and site visits.
Observation of the work en'\oironment.
Questionnaires.
lnteniews.
rrototyptng.
Joint requlremetlls planning.
Alt analyst usually applies several of these techniques d uring a single systems project.To be able to select the most sultable technique for use lo any given sltuatlon,
systems analysts need to learn the advantages and disad,-antages of each of the fact.
finding techniques.
fact-Finding Ethics During fact-flndtng, systems analysts often come acros., or analyze lnformation that ls set1SJttve in nature. It could be a file of an aerospace compatlf'S prlcing structure for a contract bld or e,--en employee profiles, induding
salaries, performance history, medical history, and career pL1ns. A11..1lysts must take
greai care to protect the security and privacy of"'"! facts or daia with whldt they
have been etttrusted. Matty people and org,1nlzations in this hlgbly competitive atmosphere are looking for an .. edge" to get ahead. Careless $)'stem analysts who leave
sensltlve documei1ts in pL1in view on their desks, or publicly discuss sensJtive data
could cause great harm to the organization or to lndtvJduals. If such data should fall
into the wrong people's bands, dte systems analyst m,y Jose the respect, crediblUty, or
confidence of users and management. In some cases, dte ailalyst '\\"'Ould be responsible
for the Invasion of a per30n's p.riva.cy and could be liable.
btost corporations make every effort to ensure they conduct business In ai1 ethical
manner because the L1ws may reqttlre them to. There have been many cases where corporadons have lttctUred heavy fines for not conducting business properly. To this end,
many corporatio11S reqttlre that their employees attend annual training seminars on
company ethics, and they reinforce the leamlng by displaying banners or signs titat
conttln the company's code of conduct and ethics statemei1ts throughout the workplace In hlghl)' visible locations. The company's ethlcs policies may be ht a hard.copy
format that ls distributed to all employees, or titey may be on dte company's Web
pages, making them easily accesslble to employees no matter where they are currently
located. Ethics policies document expected and required behavior. Violations of these
policies could lead to dlsclpllttary action or even termination. Ethlcs play a crucial role
in fact.finding.
Sampling of Existing Documentation, Forms, and Files
When studying :u1 existing system, systems analysts revelop a pretty good feel for the
system by studying existing documentation, forms, and flies. A good analyst always
knows to get facts first from ex.lstlng documentation rather thatt from people.
d,aptor Six
21S
requiremeot!
maoagemeot the process
of managing change to the
requirements.
216
Part 1wo
Systoms Analysis Methods
Collecting facts from Existing Documentation What kind of documents can
teach you about a ~tem?The fi rst document the analyst may wish to seek our is the
organizatio11 chart. Alt organ.ization chart serves to Identify key individual owners and
users for a project and their reporting relationships. The analyst may also want ro
trace the hlstory tl1at Jed to the project. To accomplish thls, the analyst shot~d collect
and review documet1ts that descrlbe the problem .These indude:
Interoffice memoranda, studies, minutes, suggestion box 11otes, customer complaints, and reports that document the problem area.
Accotmtlng records, perfonnance reviews, work measurement rel-iews, and
other schedt~ed operating reports.
Information systems project requests-past and present.
In addition ro documents that descrlbe the problem, there are usually documents thar
descrlbe the business function being stud.Jed or desJgned. These documents may
indude:
The company's mission statement and strategic plat1.
Formal objectives for the organlzatlon subunits belng studied.
Policy manuals t11at may place constraints on any proposed system.
:standard operattog proced1.1res (.!SUt'S), Job outltoes, or task tnstrucuons for
spedflc day~o-day operations.
Completed fonns that represent actual transactions at '\o-:trlous points In the
processing cyde.
Samples of manual and computerized databases.
Samples of manual an d computerized scteetlS and reports.
Also, analysts often check for documentation of previous system studies and designs performed by Conner systems analysts and consultants. 'This documentation may lndude:
Various types of flowcharts and diagrams.
Project dJctlonarles or reposltorles
DesJgn dOCltmentation, such as lnputs, outp uts, and databases.
Program docttmentatlon .
Computer operations manu.als and training manuals.
All documet1tatlon collected should be analyzed to determine whether or not the loformation is nurenr. Outdated d0Cltmentatio11 should not be cllscatded~ l1owe,--er, analysts should keep in mlnd that additional fact-finding wlU be needed to verify or
update the facts collected. W11.-. Is tl,e analyst looking for In all this material? Things
that can be e:leaned from these dOCltments lndude:
The symptoms and (possibly) causes of the problem .
What persons in the organization h.ave an understanding of the problem.
The business functio11S that support the present system.
The type of data that needs to be collected and reported by the system.
Things ln the documentation that the analyst: does 11ot w1derstand and so
need to be covered in interviews.
sampllilg th• process of
collecting a representative
sample of dooJments, forms,
and records.
Document and File Sampling Techniques Because it would be impractical to srudy
every occurrence of every form or record in a file or database, system analysts norm.ally
use sampllog techniques to get a large-enough cros., section to determine what can
happen In the system. The systems analyst should seek to sample enough forms to represent d,e full nature and complexity of the data. Experienced analysts avoid the pJtfaJJs
of sampling blank fonns-blanl< forms tell little about how the form Is actually used,
when it ls 11ot used, or how it ls often misused. Whet1 srudylng docttments or records
from a database table, analysts shot~d Sl\ldy enough samples to identify all tl,e possible
processing condJtlo11S and exceptions. Statistical sampling technlques can be used to
determine lf d1e sample sJze is L't!'ge enough to be representative of the total population
of records or doctunents.
Fact-Finding Tochnlquos f« Roq<lromonn Discovery
r
d,aptor Six
217
TA II LE 6 • 3 Partial Table of Certainty Factors
Desired Certainty
Certainty factor
95%
1.960
1.645
1.281
90
80
There are many sampling issues and factors, and tllis is a good reason for taking
an introductory Slatistlcs course. One simple and reUable formula for determitling
sample size ls
Sample size
=0.25 X (Certainty factor/Acceptable error)'
Toe certainty factor is a value that can simply be looked up In statlstlcal tables
based on the deslred certainty that the sample selected will be represetllatlve of the
total popufatlon. See T.,ble 6-3 for a partial example.
suppose an analyst wants to be 90-percenr certatn that a sample of mvotces Will
conttln no unsampled variations. TI1e sample size, S~ is calculated as follows:
SS = 0.25(1.645/0.10)2 = 68
Toe analyst will need to sample 68 Invoices to get the deslred accuracy. If a higher
level of certainty ls desired, a L1rger number of invoices are needed.
If the analyst knows from experience that I In e;uy 10 Invoices varies from the
norm, then he or she can replace the heuristic 0.25 with p(l - p) where p Is the proportion of it1v0Jces with variances:
SS = p(l - PX!.645/0. 10)2
By ush1g this form,tla, the analyst can reduce the number of samples requlred to
get the desired accuracy:
SS = 0.10(1 - O.IOXt.645/0. 10)2
= 25
How are the 25 lnvolces chosen? Two commonfy• used sampling techniques are
randomization and stratificatio11. Randomization inToJ,-es randomly, or without concen1, selecting sample data.Therefore, we Just randomly choose 25 lnvolces based on
tl1e sample size calcttlated above. Stratification is a thoughtful and systematic approach aimed at reduch1g the "-arlance of the sample data. For computerJzed files,
stratlflcatlon sampling can be executed by wrlting t simple program. For lnstance,
suppose our invoices are In a database that has a volume of approximately 250,000
invoices. Recall that our sample sJze needs to include 25 in,-oJces. \X'e wJU simply
write a program tl1at prints every I O,OOOth record ( = 250,000/25). For manual files
and documents, we couJd exea1te a sJmllar sd1eme.
>
Research and Site Visits
A second fact.finding technique Is thoroughly researdling the problem domain. Most
problems are not completely wllque. Other people have solved tl,em before us. Many
times organJzations contact or perform site '\oisJts with comparties they know have
previously experienced sirulLu problems. If these companies are •willing to share;
valuable Information can be obtained tl1.1t may save tremendous time and cost in the
development process.
Computer trade joun1.1Js and reference books are a good source of information.
They can provide lnfonnation on how others have solved shn.lL1r problems. With
recent ad'\o"3J.lces h1 cyberspace, analysts rarely have to leave tl1eir desks to do reseateh.
raodomizatioo a sampling
technique characterized by
having no predetermined
pottem or pion br 3electing
sample data.
stratification a systematic
sampling techni~ue that
attempts to redLce the variance of estimates b'f spreading out the samplin~for
example, choosng documents
or records b'f brmul~and
by c!/Oiding very high or very
low estimates.
2 18
Part 1wo
Systoms Analysis Methods
Exploring the Internet and intra.net via personal computer can provJde lmmeasurable
amow1ts of informatlo11.
A slmlL1r type of research iovolves >isltlng other companies or departments that
have addressed similar problems. ~tembershlps In professJonal societies such as the
Association for Information Technology Professionals (AlTP) or AssodatJon for J.n..
fonnatlon Systems (AIS), among others, can provide a network of useful contacts.
>
Observation of the Work Environment
Observation ls one of the most effective data<ollectlon techniques for learning abottt
obsenatioo a fact.finding
a ~·stem. Observation involves the systems analyst becoming an observer of people
technique wh,rein the eystems analyst Either partici·
and actlvitles In order to lean1 ibout the ~·stem. Th.ls technique ls oftet1 used when
the validJty of data coUected tluough other methods ls ht question or when the complexity of certain aspects of the system prevei1ts a clear explanation by the end users.
pates in or wa-.c.hes a person
perform ac.tivites to learn
about the syst~m.
Collecting Facts by Observing People at Work Even with a well-concclved
observation plan, tl,e systems analyst ls not assured tl1at fact.tlndlng wlll be successful.
11,e following story, wlllch appears In a book by Gerald M. Weltme,g called Ret/1'11klng Sys-tP'ttl.<' An.aly.«s and T>P.<':IJn, ei\o-P~c. 1Lc. :in P.ntP.tta inine }'Pt PTrP.IIP.nr PT:1mplP nf
some of the pitfalls of observao,n. 3
The Railroad Paradox
About thlrry miles from Go,ham aty Jay the commuter commwllty of Suburban.
town. Ead1 momlng, thousands of Sutburbanltes t ook the Central Railroad
to work In Gotham Oty. Ea.ch evening, Central Railroad returned them to thelr
waiting spouses, children, and dogs.
Suburbantown was a '\\'ealthy subwb, and many of the spouses liked to leave
the children and dogs and spend an evening in Gotham aty wlth thelr mates. They
preferred to precede their evenit1g of dinner and theater wJth browsing among
Gotham City's lush markets. But there was a problem. To allow time for proper
shopph,g, a Subwbanlte wotdd have to depart for Gotham Oty at 2:30 or 3:00 in
the afren.1oon. At that hour, no Central Railroad traitt stopped it1 Suburbantown.
Some Suburbartites 11oted that a Central train dkl pass through their Slatlon at
2:30, but dld not stop.11,ey decided to petltlon the railroad, asking that the train
be scheduled to stop at Subutbantown. They readily found supporters In thelr
door-to-door canvas.,. When the petition was malled, Jt contained 253 sJgna1ures.
About three weeks later, the petltio11 commlttee received the following tener
from thP. C'.t>ntf":11 R:tllrn!trl:
Dear Committee
Thank you for your continuing interest In Central Railroad operations. \X'e tal::e seriously our commitment to providing responsfve senice to all the people lfving
among our routes, and greatly appreciate feedback on all aspects of our busi.1es.,.
In response to your petition, our ctistomer service representative \oisJted the Suburba11tow11 Slation on tltree separate days, each time at 2:30 In tlte afrernoo11.
Although he obser,--ed with great care, on none of the three occasfons u-ere there
any passeugers 11.:oatt11,gfor a so·uthbou.,ut train.
We can only condude that there Is no real demand for a southhotmd stop at
2:30, and must therefore regretfully decline your petltlon.
Yours sit1cerely,
CttStomer Service Agent
Central Railroad
~ M. ~tib(tg.Rtlbinltins Sy1*'11UA1ulyd, and Dfstin., pp. 23-24. C.Opyri(tlt 4.'I 1988, 1982 byGdllli M.
~betg. llc-ptiru:ed t,' p(ttnsionof0olw1Rou,( PubJi$hills,353 W. 121h St.,N,:w·Yotk,NY 1001.i at2-62040:53/
800.J>M.J300KS,,..,..,.·.dohtthouSl'.~tn.). All tighu te.s(~ .
Fact-Finding Tochnlquos f« Roq<lromonn Discovery
What are the lessons Jeamed form the story abo,-e? For one,it ls necessary rouse the
appropriate fact-finding technique for the problem a1hand. Observation, In thJs case,
was an Incorrect d1oice. Why would anyone be walling for a 2:30 train when all the
town's peopJe knew the train doesn't stop? A second lesson to be Jeamed ls to verlfy
fact.findh1g results wJth users. Based on the user feecback, you may discover that you
need to try other fact-finding tedmlques to gather addltlonal Information. Neve, Jump
to cet1dusJons.
Observation Advantages ancl Disadvantages Observation can be a very useful
and beneflcL1l fact-finding technique provided tl1at you have tl,e ability to obsen-e all
aspects of the work being performed by the users and tl1at tl,e work Is being performed In the usual matu1er. You should become aware of the pros and cons of the
tedll'Uque of observation. Ad-vantages and disad"-antages indude:
Advantages
Dita gathered based on observation
c:in be very reJJable. Sometimes,
observations are conducted to
Disadvai1tages
Because people usuallr feel uncomfortable when being watched, tl,ey
may unwittingly perform dlfferently
check the "-:illdlty of d.:it:1 obt:tlned
when being observed.
directly from indl>iduals.
The systems analyst Is able to see
exactly wbat Is being done. Complex
Toe work being obsen-ed may not
lnvolw the level of dlftlctdty or vo~
ume normally experienced during
tlut time period.
tasks are sometimes difficu.lt to
dearly explaln In words. Through
observation, the ~tem.s analyst can
idl'1ltify tasks that have been missed
or Inaccurately described by otl1er
fact-finding techniques. Also, tl,e
analyst can obtain data describing
the physical emironmetll of the
task (e.g., physical layout, traftlc,
lighting, noise level).
Some systems activities m.1)' take
place ac odd times, causing a sdJedullng incon,--enlence for the systems
anal)st.
Toe usks being ooserved are subject
to '\<'ariOltS types of lnterruptlons.
Some tasks may not always be per-
Observation is relatively inexpetlSJve
formed In the manner In whld,
they are obsen-ed by the systems
analyst. For example, tl,e systems
compared with other fact-finding
analyst mlght ha,--e obser,--ed l1ow a
teduliques. Other cechnlques usu-
company fllled several customer
ally require substantL1lly more
employee release time and copying
orders. However, the procedures
expenses.
Observation allows the ~terns
have been d1e seeps used co fill a
analyst to do work measurements.
Guicleline1 for Observation
the s~'Stems ai1..1lyst observed may
numl:<'r of regular customer orders.
If any of those orders had been
specul orders (e.g., an order for
good, not normally kept in stock),
the s~'Stems ai1..1lyst woldd have
obseived a different set of procedures being executed.
If people have beetl performing
tasks ht a manner that vioL1ces
stan<brd operating procedures,
they may temporarily perform
their jobs correctly while you are
observing tl1em. In other words,
people may let you see what they
want you to see.
How does the ~·stems ai1alyst obtain facts through
observatlo11? Does one simply arrive at the observation site and begin recording
d,aptw Six
219
220
Part 1wo
Systoms Analysis Methods
everything that's viewed? No. 1,fud1 preparation should take place in advance. TI1e
analyst must determ.Jne l1ow data will actually be captured. Will ft be necessary
to have special forms on which to qulckly record data? Will the lndMduals being
observed be bothered by h.avlng someone watd1 and record their actions? When
are the low, normal, and peak periods of operatio ns for the task to be observed?
work samplog a fact·
finding technicue that
irrvotves a larg9 number of
observations t:1.ken at random
intervals.
T he systems analyst must Identify the ideal time to o bserve a partlcttlar asp,ct of
the system.
An analyst should plan to o bserve a slte when there ls a typical workload. Once a
typical workload has been obs<rved, observations can be made d uring peak periods
to gather information for measuring the effects caused by the increased volume. As
part of the analyst's observation, he or she sl1ouJd obtain sampJes of dOCltmeuts or
forms used by those being observed.
T he sampJing techniques discussed earlier are also useful for observation . In tllis
case, the technique is called work sampllog, wherein a large number of o rnervations may be condu cted at random intervals.11lis technique ls Jess threatening to tl1e
people being observed because the obsen-atlon period is not continuous. When using
work sampling, an analyst needs to predefine the operations of the Job to be observed. A sample size t11ei1 needs ro be calculated as was done for document and file
sampling. The analyst sho ldd m:ike m.-1ny r.mdom ob6er~tio ns, belng cireful to o b
serve act:l\oitles at differet1t tlme.s of the day. By cow1th1g the number of occurrences of
ead1 operation during the observations, the analyst will get a feel for how employees
spend thelr days.
T he following guldellnes are key to honlng observation skills:
Determine the who, what, where, when, why, and how of the obsen-ation.
Obtain permission to observe from appropriate supenisors or managers.
Inform those who wUI be obser.-ed of the purpose of the obser.-atlon.
Keep a low profile.
Take 11otes during or Immediately following tl1e obsen-ation .
Review observation 11otes with appropriate individuals.
Don't Interrupt indJvJduals at work.
Don't focus h eavily on tri,ial activities.
Don't make assumptions.
Living the System In this type of observation tl,e systems analyst actl.-ely performs
the roJe of the user for a st1ort: period of time. 11lis is one of tl1e most effective ways
to team about problems and requlrements of the system. By filling the user's•stoes;
2 systems an.tlyst qulcldy gains: :Ul 2t)precl2tlo n for what the user experience$ 20d
what she or h e has to do to perform the Job. This type of role playing gives the sys.
terns analyst a Brst11..1nd edu cation in the business processes and functions, as '\\'ell as
the problems and challenges associated with them.
>
questioooaire a document
that allows the analyst to
collect inforrn&ion and
opinions from respondents.
Questionnaires
Anotl1er fact-findi ng technique ls cond ucting surveys through questio 111uires. 111e
document can be mass-produced and distributed to respondet1ts, who can then complete the questionnaire on their own tlme. Questionnaires allow tl1e analyst to collect
facts from a large number of people while maintaining uniform responses. When dealing with a large audience, no other fact-finding teclmlque can rabuL1te the same facts
as effidet1tly.
Collecting facts by Using Questionnaires Systems analysts l1..1ve often c:rltklzed
the use of questionnaires. ,_lany systems ai1..1lysts claim that the responses lack reliable
and useful lnformatlon. Nevertheless, questioru1..1lres can be an effective means of fact
gathering, and many of these critldsms can be anrlbuted to the inappropriate or
Fact-Finding Tochnlquos f« Roq<lromonn Discovery
d,aptor Six
221
ineffectlve use of the questionnaires. Before using questJonnafres, an analyst should
unckrSland the pros and cons associated wlth their use:
Adv.lntages
,_lost questionnaires can be answered
qulcld)•. People can complete and
retltn1 que.stioru1..1lres at their
con,--enlence.
Q.lestionnalres are a rehtively
inexpetlSh-. means of gathering
data from a large number of Individuals.
Que.stio1u1..1lres allow indJ'\oiduals to
maintain anonymity. Therefore,
lndhiduals are more likely to prc»ide
the real facts, rather than telling you
what they think their boss would
wint them to.
Responses can be tahufated and
analyzed quicld)•.
Oisadva11tages
The number of respondents is
often low.
There's no guarantee that an incli,ich.tal will answer or expand on
all of the questions.
Quest!onnalres tend to be lnflexJ.
ble. There's no opportunlty for the
sy,tems analyst to obtain voluotl!)' lnfonnation from lndhiduals
or to reword questions that may
h..1Ye beett misinterpreted.
It'! not possible for the ~·stems
antlyst to observe and analyze
the respondes1t's body language.
There is no Immediate opportunity to darlfy a "-ague or incomplete answer to any question.
Good questionnaires are diftkult
to prepare.
Types of Questionnaires There are two formats for questionnaires: free fonnar and
fixed format Free-format questionnaires are des~ned ro allow the users to exercise more freedom or latitude In their answers to eadl. question.
Here are two exampJes of free-format questions:
W11ar reports do you curret1tly recetve and how are tJ1ey used?
Are there any problems with these reports (e.g., are they lnacnuare, Is there
lnsutlldent Information, or are they diftkult to read and/or use)? If so, please
explaln.
free-format
questioo.oai.tt a ques.
tionnaire desig1"'19d to offer the
respondent greiter latitude in
the answer. A question is
asked,andtherespondent
records the answer in the
space provided after the
question.
Ob,iously, responses to such questions may be dlftkult to tahufate. It is also possible thar d1e respondents•answers may nor match the questions asked. In order ro ensure useful responses in free-formar questionnaires, the analyst should phrase the
questions In simple sentences and 11ot use words- 5\lch as good- that can be interpreted diffes-.ntly by differetll respondeslls. Toe analj>t sho,dd also ask questions ti1.11
c:in be answered with three or fewer sentences. Otherwise, the questionnaire may
take up more time than the respondent is wUllng to sacrifice.
The second type of questionnaire is fixed-format.Fb:ed-format questionnaires
are more rigid, requiring that the user select an answer from a predefined set of possible answers. Gtven any question, the respondent mu.st d1oose from the available answers. This makes the results much easier to tabldare. On the other hand, the
respondent cuu1ot pro"ide addJtlonal lnformatlon thtt might prove valuable.
There are tivee types of fixed.format questions:
J. For 1uultrple-cboice quesffons, the respondent is givet1 se,-eral answers from
'\\tl.ich ro choose. The respondent should be told if more than one answer can
be selected. Some mtdtiple-d1oice questions allow for very brief free-fonnat
responses when none of the standard answers apply. Examples of m,dtiple-choice
fix:ed-formar questions are:
Do you feel that backorders occur too frequently?
OYES
ONO
Is the current accotlllts receh--able report thar you receive useful?
OYES
ONO
If no, please expL11n.
6.'"ed-for-mat
questioo.oai.tt a question.
naire containing questions
that require selecting an
answer from predefined
available resporses.
222
Part 1wo
Systoms Analysis Methods
2. For mt111g questions, the respondent is given a statement and asked ro use
supplied responses to stare an opinion. To pre,--enr bu.flt.in bias, there should be
an equal number of positive and negati,-. rntlngs.11,e following Is an example of
a rating fixed-fonnat question:
111e Implementation of quantity discotmts would cause an increase In customer
orders.
Cl Strongly agree
Cl Agree
Cl No opinion
Cl Disagree
Cl Strongly disagree
3, For m11klng qu.esttons, the respondent ls gtven se,--eral possible ai1SWers, wbid1
are robe ranked in order of preference or experiet1ce. An ex.ample of a ranking
ftxed-formar que.stio11 ls:
Rank the followlng trailSactloos according to the amount of time you spend
processing them:
_ _ _ _ new customer orders
order cancellations
_ _ _ _ order m od1.flcatlons
_ _ _ _ payments
Developing a Questionnaire Good questionnaires can be dJfflcult to develop. 111e
following procedure can prove helpful In developing an effective questionnaire:
I. Determine what facts and opinions must be collected and from whom you sl»<dd
get tl1em. If the number of people Is L,rge, consider using a smaller, randomly
selected group of respondents.
2. Based on the facts and opinions sought, determine whether free- or flxedformat questJ011s will produce the best answers. A combination format tl1at
permits optional free-format clarlflcation of fixed-fonnat responses ls often
used.
3, Write the questions. Examine tl1em for construction errors and possible mlsJnterpretatlons. lttake sure tl1at the questions don't reveal your personal bias or
opinlons. Edit the questions.
4. Test the questions on a small sample of respondents. If your respondents had
problems wJt11 them or lf the answers were not useful, edJt the questions.
5, Duplicate and dlstrtbuce thequesctonnaJ..re.
>
interview a fact.finding
technique whEreby the S'iS·
terns analyst collects informa.
tion from indiv duals through
face.to.face interaction.
Interviews
The personal Interview ls gei1erally recognized as the most important and most
often used fact-flndlng technique. Personal interviews ln\--olve soliciting requirements tluough direct, face-to-face interactio11. Interviewing can be used to ach.leve
any or all of the following goals: find facts, verify facts, cfarify facts, generate eotl1uslasm, get the end user 1t1,·o[ved, Identify requJrements, and solicit Ideas and
opinions. There are two roles assumed in an inter\-iew. The systems analyst Is the
111..tervleu,-er, responsible for organizing and conductlng the lntervJew. The system
user or $)'Stem owner is the l11.tervie1vee, wl10 ls asked to respond to a series of
questlons.
There may be one or more interviewers ancVor inteniewees. In other words, lnteniews may be conducted one-0n-0ne or many-t:o-many. Unfortw1ately, many systems
analysts are poor interviewers. In this section you wUJ Jearn how to conduct proper
intervJews.
Fact-Finding Tochnlquos f« Roq<lromonn Discovery
d,aptw Six
223
Collecting Facts by Interviewing Users People are the most important element
of an Information system. r.tore t11an anythJng else, people wanr to be in on tilings.
No other fact-finding technique places as much emphasis on people as interviews. But people have different values, priorities, opinions, motl:vatlons, and
personalities. TI1erefore, to use the Interviewing technique, a systems analyst must
possess good human relations skills for deaUng effectively with different types of
people. As with other fact-findlng tedmlques, inter>iewlng Isn't the best method
for all situations. Interviewing has its advantages and disadvantages, which should
be weighed against ti1ose of other fact.finding techniques for every fact.finding
siruatlo11:
Adv.lotages
Interviews give the analyst an
opporrunlry ro motivate the
interviewee to respond freely and
opetlly to questions. By estabUshlng
rapport, the systems analyst Is able
to give the inteniewee a feeling of
acuveJy contnbuung to the systems
pto)ect.
Interviews allow the ~·stems analyst
to probe for more feedback from
die Interviewee.
Interviews permit the systems analyst to adapt or reword questions
for ead1 Individual.
Interviews give the analyst an
opportunity to observe the Interviewee's 11011vetbal communlcatlon. A good systems analyst may
be able to obtain Information by
obsen-ing the interviewee's body
movements and facial expressions
as well as by listening to verbal
repUes to questlo11s.
Disadvai1tages
lnterTlewlng Is a very tlmeconsumlng, and therefore a costly,
fact-finding approach.
Succ.-ss of hllerviews ls hlgllly
dependent on the systems analyst's
human relations skills.
1nten1eW1ng may be tmpracucal
due t •) the location of inten-iewees.
wistructuted interview
an interview that is conducted
with only a gen, ral goal or
subject in mind and 'Mth few,
if any, specific qJestions.
The interviewer counts on the
interviewee to pw ide a
framework and direct the
conversation.
lntetvlew Types and Techniques ntere are rwo types of Interviews, wtstrucrured
and structured. U1tstn1ctured interviews are characterized as Involving general
questions tl1..1t allow the interviewee to direct the conversation .11lis type of lnteniew
frequently gets off track, and the analyst must be prepared to redirect tl,e hllervlew structured interview an
back to tl1e main goal or subject. For this reason, unstructured interviews don't usu- interview in 'M'lich the interhas a specific set of
ally work well for ~·stems analysis and deslgit. Structured interviews ln,"'Olve the in- viewer
questions to asl: of the
ten-iewer asking speciflc questions designed to elicit speciflc lnfonnatlon from the interviewee.
interviewee. Depending on the lnterviewee•s responses, the lnterviewer will direct
addJtlonal questions to obtain clarification or amplification. Some of these questions
may be plaJ.u1ed and others spontaneous.
opeo.eoded question a
Unstructured lntervJews tend to involve asking open-ended questions. Such question that all~s the interquestions give the lnteniewees slgoiflcant latitude in tl1eir answers. Alt ex.ample of an viewee to respo1d in any WS!f
open-<,nded question is "Why are you dissatisfied with ti,e report of uncollectable that seems app1opriate.
accounts?" StrlK'tured inteniews tettd to tn,-otve asking more closed-ended questions
t11..1t are desJgned to elicit sl1on, direct: responses from t11e interviewee. Examples of cJosed.('oded question a
such questions are ..Are you recei"ing the report of uncollectable accow1ts on time?• question that restricts answers
and "Does the report of tmcollectable accow1ts conraln accurate lnformatlon?" Real- to either specific choices or
short, direct res,)onses.
istlcally, most questions fall between the two extremes.
224
Part 1wo
Systoms Analysis Method s
> How to Conduct an Interview
A systems analyst's success Is at least partially dependent 0 11 the abillty to hllerview.
A successful Interview wUJ imolve selecting appropriate Individuals to Interview,
preparing extensively for the Interview, conducting the hller>iew properly, aml fo~
lowing up on the interview. Here we examine each of these steps In more detail. Let's
assume that the analyst has ldutilled the need for an hllerview and has determined
exactly what kinds of facts and opinions are needed.
Select Interviewees The systems analyst should lnteniew the end users of the loformation system being studied. A forma l organlzatlon chart wUJ help identify d,ese
indJviduals and their responsibilities. The analyst sholdd attempt to learn as m ud1 as
possible about each indJ'\oidual prior to the Interview, such as the person's st.rengtlu,
fears, biases, an d motl'\o-atlons. The inteniew can then be geared to take the characterlstlcs of the lodtvJdual Into accotmr.
The analyst should make an appointment with the Interviewee and never Just
drop h1.The appointment should be llruited to somewhere between a half hour and
an hour.The higher the mai1..1gement level of the Interviewee, the less time should be
r.rhpciufpc1. If thp i n tP.tViPWPP ii;. :t rlPf'ir::tl, ~ i r P, nr h htP4'011!l f' WOf'l.Pf', thp :tn:dy.i.r
must get the supervisor's permission before scheduling the inteniew. It is also imponant to ensure that the location for the interview will be a"-aUable during the time
Jt is scheduled. Interviews should never be conducted ln the preset1ce of the analyst's
officemates or the interviewee's peers.
Preparatio11 ls the key to a successful inteniew. An Interviewee cu1 easily detect: when atl inteniewer ls unprepared ai1d may resent the
L1cl:: of preparation because ft wastes '\o-:tluable time. When the appolntmetlt ls made,
the lnteniewee should be 11otified about the subject of the lnteniew. To etlSltre tlut
all pertinent asp«ts of the subje.._"t are covered, the analyst: should prepare an l1itervleu1
gu.r.de. 111e Interview guide is a checklist of specific questions the int eniewer
will ask the lntervJewee. The Interview guide may also contain follow-up que.stlons
that will be asked only if the answers to otl1er questJons warrai1t tl1e additional answers. A sample hllerview gulde is presented In Figure 6-3. Notice that the agenda is
careMly lald out with the specillc time a llocated to ead1 question. Time should also
be reserved for ask.log follow-up questions and redfrectlng tl1e inteniew. Que.S-lons
should be carefully chosen and phrased. Most questions begin with the stan dard who,
what, when, where, why, and now much type of wordlng. The following types of
q 11P.«-lnns. s.hn111c1 hf, avoltwl:
Prepare for the Interview
Waded quesff-011s, such as "Do we ha,--e to have both of tl1e.se colunulS etl
tl1e report.?• 111e question conveys the inteniewee's personal opitlion on the
issue.
l.eading quesff-01JS, such as "You're nor going ro use this OPF.RATOR CODE,
are you?• The question leads the intervJewee to respond, .. No, of course nor,"
regardless of actual opinion.
Biased questions, sud1 as ~How many codes do we need for FOOD ClASSIFICATION In the INVENTORY FILE? I think 20 ought to cover It." These types
of biased questions wUJ lnrluence an lnteniewee.
Interviewers shotdd always avoid tbreatetli.ng or crftlcal questions. The purpose
of the Interview is to lnvestfgate, not to evaluate or crftldze. Additional guldellnes for
questions Include:
Use dear and concise langtiage.
Don't Include your opinion as part of the questio11.
Avoid long or complex questions.
Avoid threatening questions.
Don't use ..you• whei.1 you mean a group of people.
Fact-Finding Tochnlquos f« Roq<lromonn Discovery
lntervieNeei
Janua,y 19, 2003
Tirrei
Place
Subject1
1 13:>P,M,
Time
1 to 2min,
22S
Jeff Bentle,,, Accounts Receivable Manager
Datt,
Allocated
d,aptw Six
Room 223, Admin. Bldg.
Clll'e'1t Credlt-Checijng Policy
Interviewer
Question or Objectlw
Interviewee
Resl)Onse
Ob)«tlve
Open the inteiview1
• Introduce ourset...'es.
• Thank Mr. Bentley for his valuable time.
• State the purpose o f the inteivie.v - to obtain an uiderstanding o f the
existing credit-checking policies,
Smin,
aue,-tion 1
What cond itions determine whether a rusto11er's order is cl)pr0ted for credit?
Follow-up
Smin,
aue,-tion t
What are the possib le decisions or actions that might be taken once these
conditions have been evaluated?
Follow-up
3 min,
aue,-tion 3
How a-e customers notified Yilhen credit is not cl)pr0ted for their order?
Follow-up
1 min,
1 min,
aue,-tion 4
A fter a new order is apprcwed fer credit and placed in the file containing ordeis
that ca, be filled, a rustomer might reQJest that a modificatio n be made to the
order. Would the order hove to go through credit cPP(OVal again if the rteW total
order cost e:xc«ds the original cost?
Follow-up
aue,-tion s
Who are the indt.'iduals who perform the credit checks?
Follow-up
1 to3 min,
aue,-tion 6
Milf I have permission to talk to those indivi,juals to lea-n specificalty hON they
cary out the credit<hecking process?
Follow-up
If soi When would be an appropriate time to meet w ith each o f them?
1 min,
Ob)«tlve
Conclude the intervie;,.vi
• Thank Mr, Bentley for his cooperation aid assure him that he \Mii be
recet.'ing a copy o f w hat transpired juring the intervie;,.v,
21 11inutes
Time allotted for questions and objectives
9 minutes
Time allotted for follo..v-up questions and redirection
30 11inutes
Time allotted for interview (1i30 p,m, - 2100 p,m,)
General Convncnts and Note,:
( F I G U RE 6 • 3
1;;ample Interview <.;uide
)
226
Part 1wo
Systoms Analysis Method s
Conduct the Interview Respect your inteniewee and bis or her time. Drtss to
match the lntervJewee. That generally means tl1at you will dress differently to interview managers tl1..1n you wUJ to lnterview workers on the loading dock. If the interview wlU be held In a meeting room other tl1an the inteniewee•s office, arrive early
to make sure lt Is set up appropriately.
Open the inteniew by thanking the Interviewee In ach--ance. State the purpose
and let1gth of the lnteniew and how the gathered data will be used.111et1 monitor the
time so you will keep your promise.
Ask follow-up questions. Probe untll you understand the system requirements.
Ask especially about exception conditions. As what-If questions, such as "What if tl,e
check doesn't clew.• or "What happens If a product Is not In stock?"
Listen d oseJy, observe the inteniewee, and take notes concerning both ,-erbal
and nonverbal responses from the inteniewee. Ir's ,--ery lmportant to keep the Interview on track; tllls meaJ.15 anticipating the need to adapt the lntervJew, lf necessary.
Questions can often be bypassed lf they have been answered earlier or they can be
deleted if detennlned to be irrelevant, based on pre"ious answers.
Here is a set of r ules tl1at an Interviewer sholdd follow:
Do
Dress appropriately.
Be courteous.
Ustet1 carefully.
tttaintain control of the Interview.
Probe.
Observe m:umerisms an d nonverbal
communication.
Be patient.
Keep the lnteniewee at ease.
tttaintain self-control.
Finish on time.
Avoid
Assuming an aJ.lSWer ls fl.nlshed or
leading nowhere.
Revealing verbal and 11on,--etbal
d ues.
Using jargon.
Revealing your personal biases.
Talking Instead of listening.
Assuming anything about the topic
or tl1e Interviewee.
Tape recording- a sign of poor
Ustenlng skills.
Conclude the lnteniew by expressing appreciation and p ro,i ding answers t•>any
questions posed by the lnteniewee.The conclusion is very important for maintaining
rapport and trust with the intecvlewee.
Follow Up on the Interview To help maintain good rapport an d trust with Interviewees, the inteniewer should send them a memo tl1at Slunmarizes the lnterview.
This memo shot~d renllnd the Interviewees of their contributions to the systems pro~
ect and a uow them the opporn1n 1ty to ctarlfy any nus1nterpretauoos that the inter·
viewer may have dertved during the lnteniew. ln acklltlon, the lnteniewees sl1ould be
given the opportunity to offer additional Information they may have faUed to bring
out during the interview.
Listening When most people talk about communication skills, they think of speaking and wrltlng. The skill of listening is rarely mentioned, but it may be the most imporcant skill during the lnter,·lewlng process. ln order to conduct a successful
interview, the lnteniewer must make a distinction between hearing and listenin.g:*To
hear ls to recognize tl1at someone is speaking, to listen ls to w1derstand what tl1e
speaker wants to communicate."'
\X'e have actually been conditioned most of our lives not to listen.Take, for example, how we can ignore our quarreUng brothers and sisters while we enjoy our
favorite CO or, as students, how we learn to study by blocking out distractions socb as
noisy roommates. \X'e have learned not to listen, but we can also learn how to listen
effectively and productively.
Fact-Finding Tochnlquos f« Roq<lromonn Discovery
d,aptw Six
227
When working wJth users trying to soJ,-e thelr problems, analysts may find tl1..1t
getting the users to commwllcate can be difficult. The following guldellnes can help
open the lines of communlcatlon:
Approach the session wr.tb a positive attitude. The lnteniewer sho,dd make
the best of any situation, and look at lt as a fun, pleasurable experience.
Set the other perso1i at ease. Preset1tlng a 11.ice, cheerful attitude can heJp
the person reLu. 111e interviewer st1ouJd scart by talking about the perso11's
Interests or hobbles. Showing an Interest in the lnteniewee's personal life
sometimes can serve as an icebreaker and put the person more at ease.
Let the other perso11 know you are llste1il11g. 111e intervJewer should always
maintain eye contact when listening and use a response such as a head nod
or an ..uh-huh" to acknowledge what the person ls saylng. Good posture and
leaning forward wUI tell the speaker that the Interviewer Is really hllerested
In what the person Is saying.
Ask quesff.0·1,s. The inteniewer should ask questions to make sure he or she
dearly understands what the person Is saying or to clarify a point. 1bls wUI
show that the lnteniewer ls llstesllng; It wUI also gh-. the other person the
opportunity to expand on the answer.
Do11 't assu.n1e a11ytbt11g. One of the worst things an loteniewer can do is to
act as if he or she ls lo a hurry. For example, ll an loteniewer a~umes what
the other person ls going to say and cuts lo aOO fhlishes the sentence, he or
she will possibly miss what the person Intended to say and Irritate tl,e
speaker. Or If the speaker Is Interrupted becau,e the lnteniewer has already
beard the Information and belleves It Is not applicable to tl,e topic of the
lnteniew, a valuable piece of information may be missed. Don't assume anyth.lng! TV l1ost Art: UnkJener lean1ed this lesson on Ills popuL1r television
,how, Kids S~ the Darnedest Tbl11gs, whes, he asked a chUd a phllosoplllcal
questio11:
On my sl1ow I once had a child tell me he wanted to be ai1 alrllne pilot. I asked
blm what he'd do If all the engines stopped out over the Pacific Ocean. He said
"First I would tell everyone to fasten thelr seatbelts, and thes1 I'd find my parachute and Jump our.•
Wh.Jle the audience rocked wlth laughter, I kept my attention on the yotmg
rnai1 to see lf he was being a smart alee. The tears that sprang Into h.1s eyes alerted
me to hlsdiagrln more than anytlllng he could have sald,so I asked him why he'd
do sud1 a thing. His answer revealed the sound logic of a dilld: .. rm going for
gas, .. rm coming back!tts
Take tiotes. The process of taking notes serves two purposes. First, by jotting
down brief notes while the other person Is speaking, you give the person
the impression that what he or she h..,s to say is important enough to be
written down. Second, the notes help the lnteniewer remember the major
points of the meeting later.
Body Language and Proxemics What Is body hnguage, and why should a systems analyst care about It d uring the Interviewing po:>eess? Body language Is all the
1100-Yerbal lnfonnatlon being communicated by an lndlvidual. Body L,nguage ls a form
of 11onvetbal commwlicatio11 that we all use ai1d of whid1 we are usually w1..1ware.
Studles have determh,ed a startling fact: Of a person's total feellngs, only 7 percent
are rommun.lcated verbally (h1 words), whereas 38 J)(tcent are communicated by the
tone of voice used and 55 percesll are communicated by facial and body expressions.
If you only listen to someone's words, you are missing most of wh.at the person l1..1s
to sar
body language the
nonverbal information we
communicate.
228
Part 1wo
Systoms Analysis Methods
For dlls discussion, we will focus on just three aspects of body language: farul disclosure, eye contact, and posture. Paa.al dlsdosure means you can sometimes understand how a person feels by watchJog the expressions on bis or her face. ~lany
commo n emotio ns have easily recogil.izable facial expressJons associated witl1 them.
However, the face is one of the most controlled parts of the body. Some people who
are aware that their expressions often reveal wh.at they are thinking are very good at
disguising these expre~Jons.
Another fonn of non,-erbal communlcation is e)~ co11tact. Eye contact ls the least
controlled aspect of facial expressio11. Have you ever spoken to someone who will not
look directly at you? How did It make you feel? A continual lack of eye contact m1y Indicate uncertainty. A 11orm.1l gbnce ls usually from three to five seconds in Jengtli;
ho wever, direct-eye-contact time sho uJd Increase with distance. Analysts need to be
carefu.l nor to use excesst,--e eye contact: with users who seem tlveatened so that tl1ey
won't further Intimidate them. Direct eye contact: can cause strong feelings, tither
posltive or negative, ht otl1er people.
Posture ls the least controlled aspect of the body. As such, body posture holds a
wealth of lnformatlon for the astute analyst. t.tembers of a group who are In agreement tend to display the same posture. A good analyst: wUJ watch the audience for
changes In posture that could lndlcare ;uudety, dis:igreemenr, o r boredo m. An an:llyst
proxemics 1he relationship
between peope and the
space around them.
sho,dd normally maintain an •open· body position, signaling approachab!Uty, aocep,
tance, and receptlvenes.,. In spedal drcumscances, the analyst may choose to use a
confrontation angle of head-on or at a 90-degree angle to anotl1er person In order to
establish control and dominance.
In addition to the lnform1tlon communlcated by body L,nguage, lndlvldua!s also
commwt.icate via proxemics. Proxemics, the re.latlonshJp between people and tl1e
space arow1d tltem, is a factor In communications that can be controlled by the
knowledgeable analyst.
People still tend to be very terrltorlal about their space. Observe where your
classmates slr In one of your cotuses t11..1r does not ha,-e assigned seats. Or the next
time you are tn,-olved In a convtrsation wlth someone, dellberately move mudt d oser
or farther away from the person and see what happens. A good ai1..1lyst is aware of
four spatial zones:
lntlniate 20ne- doser than 1.5 feet
Person.a l zo·, ie- from 1.5 feet to 4 feet.
Social zone- from 4 feet ro 12 feet.
Public 2011e- beyond 12 feet.
Certain types of communications take place only ht some of these zones. For example, an analyst: conducts m~t httervJews with system users ht the personal rone.
But the ai1..1lyst: may need ro mo,·e back ro tlte soc.L1l zone if the user dispL1ys any signs
(body language) of being w1corufortable. Sometimes Increasing eye contact can make
up for a long distance that can't be changed. Many people use the fringes of the social
zone as a .. respect" distance.
\X'e l1..1ve examined some of tl1e htformal ways that people communicate tl1elr
feelings aitd reactions. A good analyst will use aU tlte h1fonnatlon available, not just the
wrltten or verbal commwt.icatietts of others.
>
Discovery Prototyping
Anotl1er type of fact-finding teclmlque ls prototyping. Prototyping was Introduced In
Chapter 3 for use In rapid appllcation development (RAD). As you shot~d recaD, tlte
concept behind prototyping ls bulldlng a small woddng model of the users' requirements or a proposed design for ,11 Informatlon system.1bls type of prototyping Is ust•
ally a design tedmlque, but the approad1 can be applied earlier In the system
Fact-Finding Tochnlquos f« Roq<lromonn Discovery
development life cycle to perfonn fact.flndlng and requlrements analysis.11,e process
of buildlng a prototype for the purpose of ldet1tlfylng requlremei1ts Is referred to as
dl.scovery prototyping.
Dlsco,.. f)' prototyping is frequently applied to systems development projects, especially In cases whet-e tl,e developmet1t team Is having probletnS dellnlng the system
requirements. 111e philosophy ls that the users wUJ recognJze their requirements
when they see thet11. It ls Important that the prototype be developed qulddy so tl1at
lt can be ,tsed during tl,e developmet1t process. Usually, only the areas whet-e the requlrements are not dearly understood are prototyped. Tols means that a lot of desired
functionality may be left out and quality assurance may be Jgnored. Also, nonfunctional requirements such as performance and rellalility may be less stringent than
they would be for the final product. Tecbnologles other than the ones used for the
final software are frequently ,tsed to b,uld the dlscovery prototypes. 111 these cases,
tl1e prototypes are most likely dlscarded when the system is llnlshed. Thls "throwawa}~ approad1 ls primarily ,tsed to gatl1er l11formatlon and develop Ideas for tl,e system concept. ,_lany areas of a proposed system may not be dearly understood, or
some features may be a technlcal dl..11lenge for the developers. Creating discovery
prototypes etl..1bles the developers as well as the users to better understand and refine
d,aptw Six
229
discove,y prot0typitlg
the act of building a smallscale representative or
working model of the users'
requirements in order to
discover or verify those
requirements.
the lss\les ln'\--o(ved wlth deveJoplng the system.11l..ls techniqu e helps ru.lni..ru1ze the
risk of delivering a system tl1..1t doesn't meet tl1e user's needs or that can't fulfill the
tedll'Ucal requ.lrements.
Discovery prototyping has its advantages and disadvantages, which should
be weighed agalnst tl1ose of other fact.findlng techniques for every fact.finding
sJtuatlon:
Adv:ant..1ges
Allows users and developers to
experiment wlth the software and
develop an understanding of how
tl,e system ought work.
Alds in determining tl,e feasibility
and trsefulness of tl,e system before
high development costs are
incurred.
Serves as a training mechanism for
u..~rs.
Alds in b,uldlng system test plans
and scenarios to be ,tsed List in the
system testing proces.,.
May mlrdmlze the time spent on
fact-flndlng and help define more
stible and reliable requirements.
>
Disadvai1tages
Developers may need to be trained
In du prototyping approad1.
Users may develop unrealistic
expectations based on the performance, reliability, and features of
the prototype. Prototypes can only
slmu.lite system fw1ctlonaUty and
are incomplete In nature. Care must
be taket1 to educate tl1e users about
this ftct and not to mis.lead t11em.
Doing prototyping may extend the
de,-el)pment schedule and Increase
the development costs.
Joint Requirements Planning
,_I.any org.ul.izations are using the group work session as a substitute for numerous and
separate lnterv.iews. One ex.ample of the group " 'ork session approach is joint
requirements pfanoiog QRP), wherein hlghly structured group meetings are co,~
d ucted for the purpose of Identifying and analy7ing problems and defining systet11 requirements. Th.ls and slmJL1r techniques generally require extensive training to work
as lntended. Howe,--er, they can s.ignlfkantly decrease the time spent on fact-finding In
one or more phases of t11e life cyde.JRP ls becoming lncreasfr1gly common in systems
planning and systems analysis to obtain group consensus on probletnS, ob)ectl,..s, and
requirements. In this section, you wUJ lean1 about the participants of a JRP session
joint requiremeots
plaruliflg QRP) a process
whereby highly structured
group meetings are conducted
for the purpose :)f analyzing
problems and de fining
requirements.
230
Part 1wo
Systoms Analysis Methods
and their roles. \X'e wUJ also dlsctiss how to go about plannlng and conducth1g 1 JRP
session, the tools and techniques that are used during a JRP session, and the benefits
to be achieved through JRP.
JRP Participants Joint requirements planning sessions lndude a wide varltty of
participants and roles. Each participant is expected to attend and actively partldpate
for the entire JRP session. Let's examine ti,e dllferent types of Individuals hwolw,d In
a typical JRP session and their roles:
Spo11sor- A11y
successful JRP session reqttlres a single person, called the
sponsor, to serve as its champion. This person is normally an lndJ'\oidu.al
who is In top management (tJ.ot rr or IS management) and who has
authority that spans the different departments and users who are to be
Involved In the systems project. TI,e sponsor gives fld l support to the systems project by encouraging designated users to willingly and actively
participate In the JRP session. Recalling the • creeping commitment'
approad1 to systems development, ft is the sponsor (system owner) who
usually makes final dedsJons regarding the go or no-go direction of the
project.
The sponsor plays a ""klble role during a ]RP session by kicking off the
meeting by introducing the participants. Often, the sponsor will also make
dosh1g remarks for ti,e session. The sponsor also works dosely with the JRP
leader to plan the session by helph1g idet1tlf)• Individuals from the user rommwllty who shot~d attend and detennhllng ti,e time and location for the JRP
sessJon.
Facfiltator- JRP sessions involve a single indJ'\oidual who plays the role of the
leader or facilitator. The ]RP facilitator Is usu.Uy responsible for leading aU
sessJons that are heJd for a systems project. 11lis lndJvidual ls someone who
h ..,s excellent commwlicatio11 skills, posse~es the ability to negotiate and
resolve group conflicts, has a good knowledge of the b,tsiness, h.as strong
orga,llzational skills, is Impartial to decisions ti1at will be addressed, and does
not report to any of the ]RP session participants.
It is sometimes dlfflct~t to find an indMdual wlthh1 th.e company who
possesses all these traits. n1us, companies often must pro"ide extensJve JRP
trainlng or hire an expert irom outside the organization to fill tllis role. Many
systems ai1..1lysts are trained to become ]RP fadUtators.
The role of the JRP facilitator is to plan the JRP session, conduct the
sessJon, and follow through on the results. Durlng the session, the facilllator
ts responsible for leading the dlscusston, encouraging the auendees co
actively participate, resolving issue conflJcts t11..1t may arise, and ensuring t11..1t
ti,e goals and objectives of the meeting are fldfilled. It Is ti,e JRP facili tator's
responsibUlty to establish. the grow1d rules that will be followed durh1g t~e
meeting and ensure that the participants abJde by tl1ese rldes.
Users and 111a11.agers- JoiI:it requirements pL'Ul01ng Includes a number of
participants from the user and management sectors of an organization who
are gh-.n release time from their day~o-day jobs to devote ti,emselves to
active ln,"'Otvement In the JRP sessions. These participants are normaUy chosen by tl1e project sponsor, who must be careful to ensure that ead1 person
l1..1S tl1e business knowledW! to contribute during the fact-finding session!.
The project sponsor must exercise autl1orlty and encouragement to ensure
ti1at ti,ese h1dlvlduals wUJ be committed to actlvely participath1g.
A typical JRP session may Involve anywhere from a relatively small
number of user/mat1..1gement people to a dozen or more. The role of the
users during a JRP session is to effectively communicate business rules and
requirements, review design prototypes, and make acceptance dedsJons.
The role of the managers during a JRP sessJon is to approve project: objectives, establish project: priorities, approve schedules and costs, and approve
Fact-Finding Tochnlquos f« Roq<lromonn Discovery
klentlfled trainJng needs and Implementation pL1ns. Overall, both users and
managers are relied on to ei1su.re tl1at their cdtlcal success factors are
being addressed.
Scrlbe(s)- A JRP sessJon also lndudes one or more scribes, who are
responsible for keeping records pertaining to everything discussed h1 the
meeting. These records are published and dissem.Jnated to the attendees
bnmediately following the meetfrlg In order to maJntaitt the momentum
that has been established by the JRP session and Its members. The need to
quickly publish the records ls reflected by the fact that scribes are Increasingly using CASE tools to capture many facts (documented using data and
process models) thar are commwlicated during a JRP sessJon. Thus, ft is
advantageous for scribes to possess strong kt10wledge of systems analysis
and design and be skilled with using CASE tools. Systems analysts
Crequently play this role.
rr staff- A ]RP session may also lndude a number of IT personnel who
primarily listen and take notes regarding Issues and requirements volced by
the users and managers. Normally, IT personntl do not speak up unless
Invited to do so. Rather, any questions or concerns they have are usually
dJrected ro the JRP f:1.clUr:iror immediately after or before the JRP sessl01t. It
Is the ]RP fadlitator who lnltiates and facllitatts disa1sslon of issues by users
and managers.
11,e IT staff In the JRP session usually consists of members of the pro~
ect team. These members may work closely with the scrlbe to develop
models and other doaunentatlon related to facts commwlicated during the
meeting. Specialists may also be called on to gain information regardJng
special technical issues and concerns that may arise. W11en the situation
warrants, the JRP facilitator may prompt an rr professional to address the
technical issue.
,_lost JRP sessions span three to five days and occasionally last up to two weeks. The success of any ]RP session depends on properly
planning and effectively carryh1g out the plan. Some preparation ls necessary well before the JRP session can be performed. Before pL,nning a ]RP session, tl1e analyst must
wort closely with the executive sponsor to determine the scope of tl1e project tl1at Is
to be addressed through JRP sessions. It ls also Important that tl,e hlgl1-Je>-.l requirements and expectations of ead1 JRP session be determlned.11lls normally involves interviewin,a selected lndi'\oiduals who are responsible for departments or ftmctlons tl1..1t
are to be addressed by the systems project. Fh1ally, before planning the JRP session,
the analyst must ensure that the executive sponsor ls willing to commit people, time,
and other resources to the session.
PlaJ.uling for a JRP se~ion tn,-olves three steps: selecting a location for the ]RP
session, selecth1g JRP partldpants, and preparh1g ao agenda to be followed during
tl1e JRP session. Let's examine ead1 of these pL1nnln@ steps In detail:
How to Plan JRP Sessions
I. s,tect111g a locatton for ]RP sesslo11s- When possible, ]RP sessions should be
conducted away from the company workpL1ce. tttost local hotels or unl:versitles have facllltles designed to host group meeth1gs. By holding the JRP session at an off-site location, the attendees can concentrate on the Issues and
ad:i"ities related to the JRP session and a,-oid interruptions and distractions
that would occur at their regular workplace. Regardless of tl,e location of tl1e
]RP session, all attendees should be required to attend and be prohibited
from returnh1g to their regular wortplaces.
A JRP session typically requires several rooms. A conference room is
required h1 which the entire group can meet to 1ddress JRP issues. Also, If the
]RP session Includes many people, se,-eraJ small breakout rooms may be needed
far separate groups of people to meet and focus disalSslon on specific issues.
d,aptw Six
231
232
Part 1wo
Systoms Analysis Methods
4 1' • o·
Food & Refreahment&
IT Profe.ssionals & Other Cb!ervers
Sc,be
~
W:>rbtation
(for CASE tool)
i
Scribe
+-
""'"
and
Manager&
Smartboan:t
Overhead Projector
Corrputer
Projection
Device
a
D
b
JAP
Facilitator
"
(')
t
Whiteboard
Workstation
(for prolotyping tool)
IT Prole881onale & Other Observers
Sc,be
C---------~
F I GU R E 6 • 4
Typical Room Layout for )RP Session
)
..____
The conference or maJn meeting room should comfortably hold all the
accendees. n1e room shoul<I be fttlly eqUlpped wtth cables, chairs, and ocher
items that meet the needs of all attendees. Figure 6-4 depicts a typical ,oom
layout for a JRP session. 1)pical visual aids for a JRP room should include a
wh.iteboard, smartboard, or blackboard~ one or more fUpcharts; and one or
more p rojectors.
The room sholdd also lndude computer eqttlpmenr needed by scrlbes ro
record facts and Issues communicated during the session. 111e computer itself
sho,dd include software packages to support the various types of records or
documetllatlon to be captured and later published by the scribes. Such software may include CASE tool, word processing, spreadsheet, presentation package, p rototyping software, printer, copier (or qulck access), and computes
projection capability. As a guldeline, computer equlpment (except that used
for prototyping) should be located at the rear of the room so that it doe!n't
interfere or become a distraction for the JRP participants. Personal lnteractlon
of the participants, not technology, sho,dd be tl,e focus of the session.
Finally, the room should be equlpped for teleconferencing so tl1.1t usess at
distant locations can participate. The room sl1ould include notepads and pend.ls for users, managers, and other attendees. Attet1dees should also be provided with nametags, place cards, snacks, and drinks so that they will be as
Fact-Finding Tochnlquos f« Roq<lromonn Discovery
d,aptw Six
233
comfortable as possible. Creature comforts are very Important sh1ce JRP sessions are , -ef)' intet1SJve and often run the entire day.
2. s,tecting ]RP part!.ctpants- As mentioned earUer, participants selected lndude
the JRP facilitator, scrlbe(s), and representat1,..s from the user community. The
u,ers should be key lndMduals who are knowledgeable about thelr bush1ess
atea. Unfortw1ately, mai1..1gers are often very dependent on these indJ'\oiduals to
run their business areas and are often hesJtant to release them from their
duties. Thus, the analyst must ensure that m.1~ment is committed to the
}RP project and wUUng to not only permit but also require ti,ese key h1dlvkluah to participate.
Various IT professionals may also be selected to be hwolved In the JRP
session. Usually all IT lndl,iduals assigned to ti,e project team are Involved h1
the JRP session. Other IT spedaUsrs may also be assigned to address specllk
technlcal Issues pertahllng to the project.
3, Preparl11g a ]RP sess/011 agenda- Preparation is the key to a successful JRP
session. The JRP faclll tator must prepare documentation to brief ti,e partlclptnts about the scope and objectives of the ses5loos. In addltlon, an agenda
for each JRP session sho,dd be prepared and dlstrlbmed before each session.
1
The agend:i dictates issues ro be discussed during the session :ind the amount
ol time allotted to each Item.
The agenda sl1ould contain three parts: the opening, bod)', and condusion.
The opening ls intended to communicate the expectations of the session, to
communicate the groWld rules, and ro influence or motivate the attendees ro
ptrtldpate. The body is hllended to detail d,e topics or Issues to be addressed
ln the JRP session. Flnally, the conclusion represents the tlme set aside to summarize d1e day's session and ro remind the attendees of unresolved Issues
(t,, be carried forward).
How to Conduct a JRP Session The JRP session begins with opening remarts, h~
troductloos, and a brJef overview of the agenda and objectlves for the session. The
JRP facilitator will direct the session by following the prepared script. To successfully
conduct the se~Jon, the facilitator should follow these guidelines:
Do not unreasonably deviate from the agenda.
Stay on sd,eduJe (agenda topics are allotted specillc times).
Ensure thar the scribe is able to rake notes (th.is may mean having the users
and m.u1..1gers restate their points more slowly or dearly).
1i.vold the use of tedul.lcal Jargon.
Apply confUct resolution skills.
Allow for ample breaks.
Encourage group conset1Sus.
Encourage user and managemet1t participation without aUowing indl\oiduals ro
dominate the se~io11.
btake sure tl1..1t attendees abide by the established ground rules for the
session.
One of the goals of a JRP session ls ro genera.re possible ideas to solve a problem. One approach ls bra.lnstormlng. Brah1Stormi11g io\--o[ves encouraging participants to generate as many ideas as possible, without analyzing the valldJry of the
Ideas.
Brainstorming Is a formal tedmlque tl1at requires dlsdpllne. The following guldellnes should be trsed to ensure effect1,.. brainstorming:
I. lsoL11e the appropriate people h1 a place that will be free from distractions
and interruptions.
2. lttake sure that everyone understands tl1e purpose of tl1e meeting (to get1erate
Ideas to solve ti,e problem) and focuses on the problem(s).
bta.itlstor-mi.og a technique
for generating ic'eas by en.
couraging participants to offer
as many ideas u possible in
a short period of time 'Mthout
any analysis un1il all the ideas
have been exhausted.
234
Part 1wo
Systoms Analysis Methods
3. Appoint one person to record Ideas. Tills person should use a fllpchart, chalkboard, or overhead projectoc that can be viewed by the et1tlre group.
4. Remind everyone of the brainstorming ntles:
a. Be spontaneous. Call our ideas as fast as they ocntr.
b. Absolutely no criticism, analysis, or e>-.Juatlon of any ldnd Is pennltted
while the Ideas are being generated. Any idea may be usef,tl, if only to
spark ai1other idea.
c. The goal Is quantity of Ideas, not necessarily quality.
5. Within a specUled time period, team members call out their ideas as qultlly
as they can think of them.
6. After the group has run out of Ideas and all Ideas have been recorded, then
and only tim1 should the Ideas be analyzed and evaluated.
7. Refine, combine, and enhance the ideas thar were generated earlier.
With a little practice and attention ro these rldes, brainstorming can be a very effective technique for generating Ideas ro solve problems.
As met1tloned earlier, the success of a )RP session Is highly dependent on planning and ti,e skills of ti,e JRP facil itator and scribes. These skills Improve through
proper tralnlng and experiet1ce.Therefore,)RP sessions are usually concluded with an
evaluation questio1u1..1lre for the participants to complete. The responses wUJ help
ensure the likelU1ood of furure JRP successes.
The etld product of a JRP session is typically a formal written document. This
document is usually created by the JRP faclliraror and scribes. It is essential for
confirming the speclflcatlons agreed on during the session by all participants. TI1e
content and organization of the speci.flcatlons are obviously dependent ou the
objectives of the JRP session. The analyst may provide a clifferetll set of spec!Jkations to different participants based on their role- for example, a manager mty receive more of a summary versJon of the document provJded to the user participants
(especially ln cases In whld1 the ~·st:em owners had minimal actual involvement in
the JRP session).
Benefits of JRP Joint requlrements plarullng offers many benefits as an alteroatl,..
fact.finding and development approach. More and more companies are beginning to
realize its advantages and are Incorporating JRP Into their existing methodologies. An
effectively conductedJRP ses.<;ion offers the following benefits:
JRP actlveJy lnvotves users and management in the development project
(encour.uclna them to take ..ownership" ln the project).
JRP reduces the amount ol time requlred to develop systems. This is achleved
by replacing uadJtlona~ time-consuming one-on-one lnteniewing of each user
and manager wlth group meeth1g.1. The group meetlng.1 allow for more eJSil)'
obtaining consensus among the users and m.u1..1gers, as well as resolving conflicting Information and requlrements.
When ]RP incorporates prototyping as a means for confirming requirements
and obtalning design approvals, the benefits of prototyping are reallzed.
Acbie'\oiog a successful ]RP session depends on the JRP facilitator and his or her
ahUity to plan and facili tate the )RP session.
~~~A~ F_a_ct_-F_i_n_d_in_g~ S_tr_a_te_g_y~ ~~~~~~~~~~~~~~~~)
An at1..1lyst needs an organized method for collecting facts. Inexperienced analysts
will frequently Jump right into lnteniews. They believe, "Go to ti1e people. That's
where the real facts are!,. Wrong! This approach fails to recognize an Important
fact of life: People must complete their day-to.day Jobs. You may be thlnklng, "But
Fact-Finding Tochnlquos f« Roq<lromonn Discovery
d,aptw Six
23S
I thought you've been saying that the system is for people and that direct end.
user Involvement In systems development ls essential. Aren't you contradicting
yourselves?"
Not at all.11me ls money. To waste end users• tine is to waste their company's
money. To make the most of the time spetll with etld usets, analysts should not Jump
right Into Interviews. Analysts should first collect all the facts they can by using othet
methods. Consider the following step-by-step strategy:
1. Learn from existing docttments, forms, reports, and flies. Analysts cut leant a
lot without any people contact.
2 . If approprL1te, observe the system in action.
3. Gl,-.n all the facts already collected, design and distribute questionnaires to
ckw up things that aren't fully w1<lerstood.
4. C)nduct inteniews (or group work sessions). Because most of the pertinent
facts have already been collected by Jow-tLSer-contact metl1ods, Interviews cut
be used to
and clarify the most difficult l,sues and problems. (Altetnatr;ely, consJder usfr1g JRP techniques to replace or complement lnteniews.)
,-.rifj·
5. (Optional). Build dlscovety prototypes for any functional requlremet1ts that are
not understood or fo r requirements th:tr need ro be "-:iUd.ared.
6. Follow up. Use appropriate fact-finding techniques to vetlfy facts (usually Interviews or observation).
The strategy Is not sacred. Although a fact.finding strategy should be developed
for every pertinent phase of systems development, every project is unique. Sometimes obsetvatlon and questionnaires may be Inappropriate. But the Idea shot~d
always be to collect as many facts as possible before using interviews.
,-CD
/
0
This chapter Introduced you ro a wide range of tochtliques for discovering Infor-
mation system requirements. tttost systems deve.lopment methodologies require
some level of documentation and analysis of system reqttlrements. Accordingly, the
remaining chapters In thls part present a number of systems documentation tools
and 1echnlques that can be used during the analysis phase of systems development.
Most of you wUl proceed directly to a,aptet 7, "Modeling System Requirements with
Use Cases." Use-case models serve as a foundation for the deve.lopment of subse-
quent models for modeling additional systems requirements and are presented In
Chaptets 8 through 11.
"""'""
::J
::J
co
:::::0
0
0
Q_
3
0
--0
236
Part 1wo
Systoms Analysis Methods
Summary ~
l. The process and techniques that a systems ai1..1lyst
uses to Identify, analyze, and understand system
requirements are referred to as requirements
dlscoverr
2. System requlrements specify what the infonnation
system must do, or what property or quality the
system must have.
3, The process of requirements discovery consists of
the following activities:
a.
b.
c.
d.
Problem discovery and analysis.
Requlrements discovery.
Documenting and analyzing reqttlrements.
Requirements m:u1..1gement.
4. Fact-fincli11g ls a technique that ls used across the
entire d€velopmet1t cycle, but It is extremely critical in the requlrements analysis phase.
5. A popt~u tool used by development teams to
Identify, analyze, and solve p roblems ls an Ishikawa
diagram.
6. Conductlng busloess ln an etll.icaJ manner is a
required practice, and :u1..1lysts need to be more
aware of the Implications of not being etillcal.
7. There are sevett common fact-flndlng teduliques:
a. The s,mpling of existing documents and files
can provide many facts and details with little
or no dlrect personal communication being
neces,ary. The analyst sho,M collect hlstorical
dOClunents, business operations manuals and
fonns, and lnformatlon systems documents.
b. Research Is an often-overlooked technique
based on the study of other similar applications.
It now h ..,s become more con,--enlent wfth the
lute1:uC'l .u.KI Worh.1 Whk WC"U (WWW), Site' vi:,.
its are a special form of research.
c. Obsetvation Is a fact-finding technique In wlllch
the analyst studies people doing their jobs.
d. Queslio1uulres are used to collect similar facts
from a large nunlber of Individuals.
e. lnter,·Jews are the most popular but the most
tlme<onsuming fact-finding teclullque. When
inteniewlng, the analyst meets Individually
with people to gather informatlo11.
i) When most people talk about communication skllls, they tlllnk of speaklng and
writing. The skill of listening hardly gets
mentioned at all, but ft may be the most
important, especially during the Interviewing process.
il) Researd1 stud.Jes h.ave determined a startliJlg fact: Of a person's total feelings, only
7 percent are commwllcated verbally (ill
words), whereas 38 percent are communicated by the tone of voice used and 55 percent are communicated by fadal and body
expressions. If you only listen to someone's
words, you are missing most of what the
person has to say. Experlenced systems analysts pay close attention to body L,nguage
and proxemics.
f. Discovery prototyping Is frequet1tly applied to
systems developmet1t projects, especially In
cases where the development team ls having
problen,s defining tJ,e S)'Sten> requirements.
The philosophy Is that the users will recognize
thelr requirements when they see them. It is
Important that the prototype be developed
qulckly so tl1a1 it can be used during the d<velopment process.
g. Many analysts find fL,ws with lnterviewlngseparate interviews oftet1 lead to conflicting
facts, oplnJons, and priorltles. The end result ls
numerous follow-up lnterviews and/or group
meetings. For this reason, many organizations
are usfr1g a group work session known as the
joint requirements planning session as a s,i>stitute for interviews.
i) Joint requlremet1ts plamllng sessions In,
elude a wide ,,irlety of participants and
roles. Eacl1 participant Is expected to attend
and actlw,~· participate for the entire duration of the ]RP sesslon.
Ii) An effective JRP session Involves extensive
plannl1~. Plannlna for a JRP session ln,'=>lves
three steps: selecting a location for the JRP
session, selectlng]RP participants, and
preparing an agenda to be followed dwing
the ]RP session.
& To help allevL11e tJ,e many problems associated
with changing reqttlrements, it is necessary to perform requirements m:u1.1gemet1t.. Requlremet1ts
management encompasses the policies, procedures, and processes that govern how a change to
a reqttlrement is handled.
9. Because • tJme is money; ii ls wise and practletl for
the systems analyst to use a fact-finding strategy to
maxlroize the value of time spet1t with the et1d
users.
a. Learn from existing documents, forms, reports,
and files. Analysts can learn a lot without any
people contact.
Fact-Finding Tochnlquos f« Roqclromonn Discovery
b. If appropriate, observe the system h1 actlon.
c. Givei1 all the facts already collected, design and
distribute questionnaires to dear up tllings that
aren't fully understood.
d. Conduct h1tervJews(or group work sessions).
Because most of the pertinent facts h.ave already beett collected by low-user-contact methods, Interviews can be used to verify and clarify•
the most dltlktdt issues and problems. (Altern,-
d,aptw Six
237
th1'1)', consider using JRP technlques to replace
or compJeruent intervJews.)
e. (Optional.) Build discovery prototypes for any
ftmctlonal requirements that are 11ot tmderstood
or for requirements that need to be validated.
f. Follow up. Use approprL1te fact-tlnding techniques to verify facts (usually Interviews or
observatlo11).
\ ';::: ;:s Review Questions
l. What ls the lmponance of conducth1g the requirements discovery process?
2. What are the possible consequei1ces If you fail
10 identify system requhemetlls correctly and
oomplctcly?
3. What are some of the criteria deemed to be criti,
cal lo defining system requirements?
4. The requirements dJsco,lery process consists of
wll..1t
"'
9. What are some of the drawbacks of c0Uecth1g
facts by observing employees In ti1elr worl< environment? How can systems analysts deal with
these drawbacks?
10. What arc the types of survey qucstionnalrcs that
11.
actlvitles?
5. Briefly describe the purpose and componetll
parts of ait lshlkawa d11gram.
6. What technlque Is commonly used In the reqtth1'ments disco,..,ri· phase? Why is It hnportant?
7. Why Is analyzing reqtdrements essential?
8. When collecting facts from existing documentation, what kind of documents sho,tld system
analysts review?
l. \'ou are manaaitw. a project that was postponed
1wJce because lts funding was diverted to hfghetpriority projects.111e $)'stem owners do not want
that to happett agaln, so they are very anxious to
get the new system started and built as quickly as
possible. They are putting a great deal of pressure
on you to spend no more than a couple of days
on requhements discovery. If anything is ndssed,
tl,ey tell you, It can be fixed later on. You really
want to make them happy, but a Uttle voice of
caution is going off. What are the potentlaJ consequences and costs of rushfrlg through the requirements discovery process?
2. \'ou have leanted the lmportance of making sure
tl1at requh1'metlls are correctly idei1t!Jled. But
how do you know when you ha,-e a correct
requirement-that ls, wh.at criteria must each
requirement meet in order to be considered
correct?
12.
13.
14.
15.
systems analysts can use to collect infonnation
and oplnlons?
What are some of the ways that you can ltSe to heJp
open dte lines of commwtlcatlon ln an lntervlew?
What is joint req,urements planning ORI')?
Why has }RP become pop,dar?
Why Is the fadUtator lnJRP so Important?
What ls the main concen1 ln seJectlnga location
for JRP sessions?
@:
Problems and Exercises
3. What common error does a new systems :u1..1tyst
often make when :u1..1tyzing a problem? W11..1t are
the potential consequences of th.ls error? W11..1t
tool can be used to help avoid tills problem?
4. System developers use fact.findh1g techniques h1
every project phase. Is fact.finding more Important during the requhernents analysis phase than
for other phases? Why or wh.y not?
5. What ethical issues ought arise during the
fact.finding process, and how sho,tld they be
handled?
6. What are some of the common tools and technJques a systems analyst can use to document the
h'dtial findings? Should ti,e systems :uulyst expect
the requlrements to be complete and correct at
this polnt? If not, what are the common problems? What should be the focus of the project
team at this polnt?
238
Part 1wo
Systoms Analysis Methods
7. Wh.at ls the deliverable that ls created once re.qttlrements analysis ls completed? Why ls this
deU,-.rable needed, and what does It lndude?
Who are the audience and/or users of tills deliverable, aod for what reasons?
8. )'ou are a systems analyst ln a software development company that has been hired to do the reqttlremmts analysis phase for a large organlzatlon.
What are three categories of existing documentation tl1.11 you should collect d uring requirement
discovery? What are some examples of ead1 of
these three types of documet1tatlon? W11at should
the systems analyst watch out for In collecting
gather facts. What are some of the ad"-:i.ntages and
disadvantages of questionnaires? When might you
choose free-format que.stioru1..1lres over fixed
format questionnaires? W11..1t is one method of
determlnh1g the effectiveness of a questlonndre?
11. What are some of the reasons to use joint req,tlrements planning ORP) as a fact-finding technique? What sho,tld be the basis for selecting
whld1 ,rsers and mai,agers will participate In
the ]RP se~Jon, and who generally selects them?
What skills should the facllltator and scribe possess? What Is the role of IT staff d urlngJRP
sessions? What ls the typlcal d u.ration of the
documentatlo11?
9. Suppose that you are a ~·stems :u1..1lyst on a
project that Involves modlfyh1g the sales order
process. Slnce your company receJ,--es ln d1e neighborhood of 2,500 sales orders per day, how 01.1ny
do you need to ~mple Jf you ~nt 95 percent
certainty that you have covered aU '\o-atL1tlons?
What lfthe number of sales orders per day was
25,000 orders?
Projects and Research
10. Surveys and questlonnah-.s are frequently used to
JRP sessions?
12. ProvJde at least five of the crJtical success factors
for JRP sessions.
13. What one tiling should an analyst 1101 do when
begituli.ng the f:ict finding portion of require
met1ts discovery, no matter how tempting?
1b
I. Systems ai1.1lysts must h»-. expertise h1 problem
ai1..1lysls. When systems analysts are starting out,
they often find It dlfflcttlt to differentiate symptoms from problems, and to Identify the actual
causes or' the problem. One tool that can help
a,1.1lysts learn to do thls ls ti,e lsWkawa, or
tlshbone, diagram.
a. Find and select a problem that your organization. school or other oraanli.atlon is currently
attempting to resolve. Describe this problem.
b. Follow the process described In this d1.1pter
and create an Ishikawa diagram.
c. Which categories did you start with h1 the dlagrain,and wWch categories did you add during
the process?
d. Did this diagram help In findh1g the actual
cause(s) of the problem? Did the cause(s) tum
out to be wt1..1t you originally thought, or somethh1gdifferent?
2. Observing the work environment ls a technlque
that predates the lnformation age, but that cut still
be hlghly effective. Although not appUcable for
every sltuatlon, observlng wh.at people actually do
and how they do ft ca11 be ht some cases much
more accurate tha11 asking them! Select a
system- whether hypothetical or real- and do
the following:
a. Provide an o,-ervJew of d1e system and what you
are trying to learn about the system for a project.
b. Develop a w ork observation plan ush1g the
guldeUnes In tills diapter.11,e format Is up to
you, but It generally sho,tld not need more tlw1
1-2 pages.
c. Develop a work-samplln.e: plan. an d descrlbe
the sampllng procedures you will use.
d. What are your tl1oughts about th.ls metl1od
compared to otl1er fact-tlndJng methods?
3. You are a systems ai1..1lyst working on a project to
develop an Intranet for a large organ.ization with
several thousand employees working In offices
iliroughout the United States.11lls will be the
organization's first h1tranet, ai1d executive management wants ft to help increase employee effidet1q•
ai1d commlt.ment to tl1e organizatio11. As part of
fact-finding, Information needs to be g.1thered from
employees of tl1e organization regarding lntnaet
content ai1d functionality. Due to the size ai1d geographic distribution of tl1e organization, as well as
project time constraints, there ls Insufficient time
Fact-Finding Tochnlquos for Roqclromonn Discovery
aad resoltreeS for personal interviews, so you have
decided that a questionnaire is needed.
a. W11at facts and ophlions do you need to collect?
b. Sho,~d all employees In the org,1nlzation be surveyed? Why or why not? If not all employees
sl1ould be surveyed, how would you select the
employees to be surveyed?
c. What format do you thlnk wo,~d work best for
tills survey questionnaire? If fixed format, what
type(s) of fixed-format questions st,o,~d be used?
d. How long should the survey questionnaire be ill
order to get the necessary information without
discounglng employees from fllling lt out?
e. Create the sur,--ey questlonnalre, using the
questlon-wrltlng guldeUnes given In this d1apter.
4. B1Sed upon the responses to your Intranet survey,
you feel that It wo,~d be helpful to Interview
someone in !ulother org.•ulizatl0tl wlto h.as h.'ld ex
perlence h1 developing and/or malntalnhlg company lntranets.
a. What type of lnteniew do you think would be
most appropriate In this sltuatlon-WlStrucrure:J
or structured? Why?
b. Make an appointment with the h1tranet admlni;.
trator ln your organization or ai1other organization or school to discuss her or his experiences
in developing an<Vor maintaining an intranet.
Describe the organizatio11 and its lntranet.
c. Prepare an interview guide using the format of
FJgure 6-3 as an example, ensuring that questions are free of the problems disct~ed in
tills chapter.
d. Conduct d1e h1terv:iew, and record the responses.
e. Wll..1t do you feeJ worked well In the Interview,
and what would you do dlfferently next cime?
5. Bod)' language ts an extreme!)• Important pan of
communlcatlon, as descrlbed ln the textbook.
Analysts need to be aware of not only what is heh11
communicated ci,rougl> the body language of the
intervJewee but also the impact tll..1t their own
body L,nguage may h»-. upon the Interview
process. Make an appointment with several
d,aptw Six
239
co-worl.:ers or fellow students to intervJew regarding
the features they would Uke to see ln an lnuanet; lf
possible, select intervJewees you know well and
those that you don't. Prepare for the ln1emews fo~
lowlng the same steps as ln the prior question.
a. Oescrlbe tl1e lntervJewees you selected and the
questions you asked.
b. During each Interview, observe the racial expressions of the h1tervJewee. What did you observe? Were the facial expressions always
consistent with the responses?
c. Ou.ring ead1 lntervJew, observe the eye contact.
How long dld It fast? Observe and describe what
happened when you made eye conttct for more
than three to ft,--e seconds wJth d1e interviewee.
d. Try changh1g your spatial zone during the Interview. Did the Interviewee show any sgns of beh1g uncomfortable? At what point dkl dut OCClui'
e. Old you note any dlfferences h1 body L1nguage
between tl1ose you knew well and those you
dldn't.?
f. What dld you do that was the most succe55ft~
and the least successful h1 elldtlng informatlo11?
6. Analysts typically have access to confidential or
sensitive data during the requirements discovery
phase of a project, partlct~arly during bet.finding.
Analysts need to be aware of situations where
there may be a breach of professional etlllcs,
whether by acts of comml~Jon or omi.ssJon, and
the possible consequet1ces. Search on the Web
and/or In business perlodlcals h1 your sd1ool (I.
brary for artlcles on Incidents Involving breaches
of professional ethics.
a.
b.
c.
d.
What artldes did you find?
What was tl1e nature of each of tl1ese lncideots?
What were tl1e consequet1ces?
What was the analyst's personal responslbUlty
In each incident?
e. What could have been done at tl1e org..1nlzatlonaJ and/or individual level to pre,•et1t the
lnddet1t or to reduce its severity?
240
Part 1wo
Minicases
Systoms Analysis Method s
O
I. In Chapter 5, you developed feasibility studies for
a project. Economic feasJbllJ ty assessments are lmpacted slgnlJlcantly by Intangibles, whose value Is
obtained lo part by intervJews and questionnaires.
Develop interview questions to determine the
value to emp loyees of telecommu ting.
a. Begin wlth wutrucrured questions posed to one
group of employees to determfr1e what matters
to the employees and how they vJew telecommuting.
b . Once you know what issues surround employee
perceptions of telecommuting and why they
mlgl11 like/dislike it, create open-,,mled, b ut structured, questions on d1ose Wues, and interview a
second set of employees. Why are we lL'Sing two
different groups of emplO)'ees for this process?
2 Develop a questionnaire for rnass employee distribution based on your findings from the previous
Interviews. Why are we com pleting the analysis
wlth an anonymous survey?
3. You are In d1arge of de,-eloplng a n ew 01illne class
registration system for your sd.1001. Develop a set
of Interview questions to determfr1e Issues and
needs of stude11ts, registration staff, and facul ty for
an 01illne registration system.
4. Discuss the Impact that biased or leading que~
tions may have 011 an analysis. Create one no11·
biased lntervlew question and one blased or
leadlng question. Pose each of those question! to
five people. What kind of responses did you get?
WCf'C they what yo u expected?
Team and Individual Exercises
I. Create a bL1Sed, leading, or loaded set of interview
questions. Pose them to another student ht the
class.T he other student, Instead of answering the
questions, should tell you how you are bL1Sed and
what response you are looking for.
2 . Oass exercise: Create as tmblased a set of lntervJew questions as you can on a particular toplc.
Pose the questions to the class. However, wear a
shlrt, pins, and so on, tl1at Jead the class to respond
Suggested Readings
In a particular way. Have fun, and experiment with
visual alds, props, and the lli(e.
3. It has been found h1 past research s tudies that em.
ployees who are allowed to telecommute actually
work approximately three extra unpaid hours a
week. But teJecom.mutlng is ofte.1.1 used as a negotiating tool by an employer- in order to telecommute, employees must accept a lower salary,
typically JO percent. What do you thJnk aboutthls?
[3]]
Andrcu,s, 0 . C., and N. S. l.c\•c nthal. Fuston Jntegmttng IE,
CASE and)AD: A Hauabooll for Reengtneertng tbe S)'S·
r.e,ns orga11tratfo11. Englewood Cliffs, NJ: PrcntkC' Hall,
1993.
Jkrdic, Douglas R., andJolU\ E Anderson. Qtl<!Stto1111afres: Desfgn and Use. l'itctuchen., NJ: Scarccrou• Pttss, 1974. A
practical guide to the construction of (fuC'Sl:ionnaircs. Particularly tiSC'ful because o f its short length and i.Uustrative
examples.
OJ.vis, Wi.lliam S. sysr.e,ns A11al)1sts and [}(!Sfgn. Reading, l\otA:
Addison-Wesley, 1983. Provides useful pointers for preparing and conducting intc,r,'lcu<s.
DtjoiC', Ro }; Gc-orgc Fowler;and 0.'l.vid. Paradk.'C'. Etbl.Cal ISStl<!S
tn Infortnat«>n sysre1ns, Boston, l'itA: Boyd and FraSC',r,
1991. Focuses on the impact o f compute r technology on
cthkal decision making i.n today's business organi.'13.tions.
Rtzgcrald..Jerry; Ardra E Fitzgc,ra.Jd:; and Wartt'Jl 0 . Stallings, Jr.
Fundmnentals of S)'SlettlS A11atyS1s, 2nd ed. Neu• Yolk:
Jo hn Wiley & Sons, 198 1. A useful sut,'C'}' text for the
syste,ms anal)'Sl:. Chapter 6, •unck,rstandi.ng the Existing
System/ docs a good job of pltSC'tlti.ng fact·fUldin@tech ·
nkfuC'S in the study phase.
Fact-Finding Tochnlquos f« Roqclromonn Discovery
Gtutc:, c. Raptd sysre1ns Develop11ie11t. Neu• York: Rapid S}stclllS Dc\•clopblcnt, lnc., 1987. This book provides a good
discussion on how to lead a group mcctingtintcni.cu:
Gause, Donald C., and Gerald ~1. Weinberg. EXplortng .Requtre1ne11ts: Quattty before Desfgn. New York: Dors:-t
Housc Publishing. 1989. An cxccUcnt book describing the
techniques of rt-q_ttitcrnc:nts discO \'t't):
Gilckts!CC'\-e, Thom.."U R. successful Data Processt11g S)1st.ern
A1f0~1SIS, Eng)C\\•ood Cliffs, NJ: Prentice Hall, 1978. Cltaptcr 4, •Jntc,r,'lcwi.ng i.n Systc.ms Wod,:: provides a coblplc'hc:nsivc look at intc,r·viewing sJ)<'ci.ficall}' for the systems
atw)•st. A thorough sample intc,r·vicw is scripted arid
atulykd in this chaptc.r.
LonO,n, Keith R. The People Side of S)1st.e1ns. Ne\\• Yori::
McGrav.•-Hill, 1976. Chapter 5, •tn,-c-stigation ,-crsus ln({Ui·
sition," pro,'ldcs a ,try good people-oriented look at fact·
fir.ding. with consickl'.\ble emphasis on inteJ,'lC\\•iJlg.
Lord, Kenniston W., Jr., and JaJncS 8. Steiner. CDP RevfetlJ
AfiltJ.Hal: A Data Processf11g Handbooll, 2nd ed. New
Yc rk: Van Nostt'.Uld Reinhold, 1978. Chapter 8, •systems
Analysis and Design,• provides a comprehensht cornpari·
son o f the merits and demerits of each fact·finding tech·
niguc. This matctial is intended to plt'patt data processors
for the Ccrti.ftcate in OJ.ta Processing examinations, one of
vvhich covers systems analysis and design.
Mille~ In~d.n, and John E Fft'und. Probabfttty a11<1 srartsttcsfar
E11g111eers. f.ngleu'Ood aiffs, NJ: Pttntice Hall, 1965. Jn.
ttoductory college textbook on probability and statistics.
Mitchell, Jan; No rman Parrington; Pete.r Dutute; and John
Moses. •Practical Prototyping. Part One," Object Clll'IT!IIIS,
d,aptw Six
241
r,,tay 1996. First of a three-part series of artic·lcs that
cxplotts protocypiJlg and how you can benefit horn it.
Prototyping is an integral part o f }RP.
Robertson, Su:zatute, and James Robertson. Ala.s!errng the Requtren1e11ts Process, Reading. MA: ACM Press/Addi.son·
Wesley, 1999. This book contains an in-depth co,tragc of
ste~by--step procedures for lt'quitt-.ments di.sco,'t't):
Sa.htnd)·, G., ed. Ha11t1booll of 111<1ustrfal E11gt.1wertng. New
York:John Wile)' & Sons, 1974. A comprcbc.nsh't' hand·
book for industrial engineers; syste.ms analysts att-, in a
way, a type of industrial enginccr. Excellent coverage on
Sl.mpling and wod,: measuremcnt.
Stcu,art, Charles )., and William 8. Cash, Jr. h1lervtet1Jtng:
Prt1JC(pfes a11d Pmcltces, 2nd ed. DttbuqtlC', IA: Brou'tl,
1978. Popular college textbook that provides broad expo·
sure to inte.n •icwing techniques, tnatl)' of u •hich arc
applicable to syste.ms analysis and design.
Walton, Donald. Are }'?)fl Cbtntnuntcartng? Jou. can't ,wan.
age. uJl.tbout JI, New York: r,,tcGt'.tw·Hill, 1989. This book is
an casy-t~tlSC guidebook on the process or" cornmunica·
tions and a must tor anyone utio rnust wott with people
and influence thern.
Weinberg, Gerald M. Retbtnklng sysre111s A11atySfs and De·
stgn, Boston: Little, Brown and Company, l982. A book
cft'ated to stimulate a ncu• '"'al' o f thinking.
Wood,Janc, and Denise: Sil·ver.}Otnt AfJpltcatto11 Desfgn, New
York:John Wiley & Sons, 1989. This book provides a com·
plt'hcnshtc: m•en•icu• of mr,,t's joint application design
technique.
Slrahgl: 1n1:1rmat1on s,rtems Pian
Slrategle Enterprise Pian
.....
.............
"''"
rnpo,o a..i,_
"''"
i~eusrw.u
PACC.....
l(NOWlEOGE
COMWUNICAnONS
JI
811.TEMEN'f OFWOFI(
PFI08LEM STKEWENT ~~ N Plce.s ...,._.,,,
INFORMATION
•COP<
FUNCTION.t.L
SOOPE
00Wt.lJNICR10NS
SCO,E
VISION
VU$10 N
""°"
•
•
•
SYSTEM IWPAOVE~N'f Oe..ECTIV€8 ~1'9 N PECES ...,._.,,,
8USIIESS FEOU FIEt.ENTS $1;UE~N'f
.
...
.B
'
,
:
"' Jl~
J.
'
~m
'
'. .
..
"'
I
AFICH TECTVIW. t.C<IEL
OE & IGN PR O TOT \ 'PE 8
PHY61CAL
""""
'""'"
8 PECFICR10 NS
~FIEDESIG~
SPECIFICATIONS
FUNCTION A L 8 Y & TEM
• R A INING •ATERI A L 8
-
~
.........
"°'"'°"
PHYSICM.
USEA A SYSTEM
INTERFACE
OESGN
61'EOFIOOIONS
...
...........
~
f
s
§
>
-· i .
-·
OPER A TION A L & YS TE •
. . ..
..........
Cl'ICIH.
INTE~ACE
SOI.UTION8
.....,
CUS10W~ ILT
APPI.ICIJION
-
~-
•
INTE~ACE
SOI.UTION8
PO& T. A UOIT RE V IEW
........
.........
APPFIOYEO
TECHNOLOGIES
Ccrlt1111ntAPPAOVEON~NOLOOIE$
S1rategl c Enter pri se 1ntormat1on Tecnno1ogy Arcnltecture
g
!1
!~
§
u,
~
I
~
I
I
m
I
"' n::!
~
'
'
'
6l
•i
~
~
$
,
I
•I•
1
• '
>
,
6U611ES8 PAOCU8
OE.slON
!
-
i
!{
smew PFIOPOSM. (or FEOJESTFOASYSTEW PFIOPOSM.8)
-
ii
•
'.
p
''
••
I
•
w Iz f
J,!
1
n,
I -
.
- -
Modeling System
Requirements with
Use Cases
Chapter Preview and Objectives
In this chapter you will learn about the tools and techniques necessary to pe,form u.secase mcxieling to document system requirements. Capturing and documenting system
requiren1ents have proved to be critical factors in the ouloome of a successful information
systems development project. Documenting the requirements from the perspective of the
users in a manner that they can understand promotes user involvement, which greatly enhances the probability for the success of the project. You will know that you understand
requiren1ents use-case modeling when you can:
I Describe the benefits of use-case modeling.
I Define actors and use cases and be able to identify th?m from context diagrams and
other sources.
I Describe the four types of actors.
I De.scribe the relationships that can appear on a use-case model diagram..
I Describe the steps for preparing a use-case model.
I De.scribe how to construct a we-case n1odel diagram..
I De.scribe the various sections of a use-case narrative and be able to prepare one.
I Define the purpose of the use-case ranking and priority matrix and the use-case
dependency diagram.
244
Part 1wo
Systoms Analysis Method s
Following the Joint requlremetl1s planning ORP) meeting that was held as one t,.sk of
the requirements analysis pha,e, the SoundStage Member Senices systet11 p rojec t
team has built a list of use cases that specify all the required fw,ctionality of ti,e systet11. At first ead1 use case was Just a simple verb phrase (sud, as "Place New Order")
that described something one or more users wanted to do with the system. Next,
each use case was documented wlth a narrative describing In detail the desired Inter-
action between the user and the ~·stem. Then Bob ,_lartlnez and other systems analysts held a series of interviews with users to verify those use-case narratl,-es. Finally
they are analyzing whld1 ltse cases are the hlghest priority to the system. Bob's boss,
Sandra, says that will identlfy for them what functlonaUty has to be Included ill ti,e
first build cycle of the system. The plan is to take those highest-priority use cases Into
the logical design and later phases and lruplet11et1t a woddng version l. 0 of the systet11
on schedule and within budget.
1
~~~-A_n~ l_
n_tro
~ d_u_c_t_io
~n_t_o~U_s_e_-_c_a_s_e~Nl_o_d~e_li_n_g~~~~~~~~~~~____,)
One of the primary d1allenges of vital Importance to any lnformatlon systems developmet1t team, and especL1lly the systems analyst, is ti,e ability to ellclt the correct and
necessary system requirements from the stakeholders and specify them in a manner
that ls understandable ro the stakel10Jders in order for those requirements to be verified and validated. In fact, this has been the case for many years, as the distinguished
autltor Fred Brooks wrote ht h.Js famous 1987 artlde:
The hardest single part of buildlng a software systet11 is decldlng precisely what
to bldld. No other part of the conceptual work is as diflktdt as establishing ti,e
detaUed technlcal requlrements, Including all ti,e Interfaces to people, to madtlnes, and to other software systems. No other work so crlpples the resulting
system lf done wrong. No other part is more diffintlr to rectify L1rer.
The information tec hnology commwllty has always had p roblems trying to
specify requirements, espedaliy fllllctlonal requirements, to users. In the past we
have used tools such as data models, process models, prototypes, and re(Jltlrements
speclflcatlons that we w1derstood and were comfortable with, but they were ltard
to understand for any user who wasn't educated ln software de,--etopment practices.
Because of cbts, many development projeets were and srtU are pL1gued wtcb scope
creep, cost overruns, and schedule creep p roblems. Very often systems are deveJoped and deployed ti1at really don't satisfy ti1e user·s needs. Some are shelved and
not used at all, and a large percentage are canceled even before the development
effort is complete. A very weU known research firm, the Standish Group, studJed
23,000 IT appllcatlons in 1994, 1996, and 1998. 1 As shown In Figure 7-1, the 1998
study folllld that only a little more than a quarter of the p rojects In 1998 were successful (on budget, on tlme, and included all features). ,_lore titan a quarter of them
failed (canc eled before completion). A little less than half were what Stan dlsh consJdered challenged- the project was complete and operational, bur ft was completed either over budget, o,·er the time estimate, or wJthout all tl1e features
speclfled by the users. The good news reflected In these srudles and otl1ers is that
the ways and means we are U!ing to develop ittformatlon systems are improving.
The software development lnWstry l1as learn ed that in order to successfully pL1n,
llb,:- !illlldi:lb Group lbtettPtiorial. lbC._,·av.os: A hdpe for- Succas''(tkrtlttik veftiOll), 1999, Rctric-vtd O«ernbet 5,
~ 02, 0otn www. ptn2go~o.1n/SJ..1Dplt h'!lmh'.hk
ptilnt.ry tc1't'll.ldl lllld ll.llldy,i$ of the' IT indutty.
hws199fl·Ddf, The StiuldWl Group ;, be.._ kbO'fl'h for i~ in.dc,pellddl.t
Modoling Systtm Roq<lromonn with Uso Caso,
Project Success Rate
1JO%
-
11111'
l0%
fl()%
SI%
21'!1,
83'K.
--48%
<0%
20%
3 1~;
40%
28~;
0%
1994
1996
1998
--
chaptor S..von
24 S
, FIGURE 7 - 1 '
D Succeeded
D Challenged
O Failed
Project Success
Rates As Reported
by the Standish
\. Group
~Kt: 'Ibo Su,ndii:I Croup h:tttnatioMl. l~,. "'Ch-:A Recipe lot
S'lx«-'"(tlectf011ic,~n:io11). 1999.
www.p m2Ro.oom/f(IQple__t-.i,rtb/
duo•l998.pdf.
v...
analyze, desJgn, construct, and deploy an Information system, the ~·stem.s analyst
first must tmderscand the needs of the stakeholders and the reasons why the system
should be developed- a concept called user-centered development. By focusing
011 the users of the system, the analyst can concentrate 011 l1ow the system will be
used and not how ft will be constructed. Use-case modellog is an approach that
facilitates usage-centered development.
Use<ase modeling has its roots in object-orJented modeUng, and you will learn
more about how to apply use-case modeling In the ~ect-orlented analysis and design
diapters, but It has gained popularity In nonobject developmetll environmetlls. You
will learn throughout the remaining diapters of this book how tLSe-Clse modeling
complemet1ts tradJtlonal systems analysis and design tools such as data modelit1g and
process modeling as weU as provides a basis for architectural decisions and user
Interface design dedslons.
Use<ase modeling was originally conceived by Dr. Ivar Jacobson In 1986 and
gained pop,tlarity after he published hls book, Object.Oriented Software E11gl11eeri11g, in 1992. Dr. Jacobson used use-case modeling as the framework for hJs objectory
methodology, which he successfully used for developing object-Oriented Information
systems. Use<ase modeling has pro,-ed ro be a valuable aid in meeting the challenges
of dttermlnlng what a system is requlred to do from a user and stakeholder perspective. It is now widely recognlzed as a best practice for the defining, documenting, and
unckrsrandfng of an informatio11 ~tern's functional requirements.
Usfr1g use-case modeling fadlitales and encourages user invotvemet1t, wbid1 ls
one of the primary crltlcaJ success factors for et1Surina project success. In addition.
use.case modeling provides ti,e following benefits:
Pro,ides a rool for capturing fw1ctlonal requ.lrements.
Assists In decomposing system scope lnro more manageable pieces.
Pro,ides a means of communicath1g with users and other srakeholders concerning S)'stem ftUlctlonallty. Use cases presetll a common language that ls
easily understood by various stakel1olders.
Provides a means of identifying, assigning, tracking, controUlng, and managing
>)'Siem de,-.Jopment actMties, espedally Incremental and iterative developmet1t.
Pro,ides an aid In estimating project scope, effort, and schedule.
Pro,ides a baseline for testing In terms of dellnlng test plans and test cases.
Pro,ides a baseline for user help ~tem.s and manuals as well as ~tern
development documet1tatlon.
Pro,ides a tool for requirements tmceabUlty.
Pro,ides a starting point for the ldentUlcation of data objects or et1tlties.
Pro,ides functional specUkations for designing user and system Interfaces.
Pro,ides a means of defining database access requlremet1ts lo tenns of adds,
changes, deletes, and reads.
Pro,ides a framework for drhing the system developmetll project.
user<eoteted
developmeot a process of
~y.sl!:1111~ d1:M:1lo p1111:111l b1;1~ecJ
on unders1B.Jlding the needs
of the stakeholc»rs and the
reasons why the system
should be devebped.
use-case modeling the
process of modeling a sys.
tern's functions h terms of
business events, who initiated
the events, and how the eystem responds tc those events.
246
Part 1wo
Systoms Analysis Methods
System Concepts for Use-Case Modeling
use-case d.iagtam. a dia.
gram that depicts the inter.
aciions betwe&n the system
and external systems and
users.In other words, it
graphically describes who
'Mii use the sy31em and in
'M'lat WS!fS theuser expects to
interact with tte system.
fuoctiooal
decomposition the act of
breaking a syEtem into
subcomponents.
use-case oatratt'\•e a
111ere are two primary artifacts Involved when performing use<ase modellng.111e
first Is the use-case dlagram, wbld1 graphically depicts the system as a collection of
use cases, actors (users), and their relationsbips.11lis dL1gram commwlicates at a high
JeveJ the scope of the business events tl1at must be processed by the $)'stem. An example of a use-case diagram is shown in Figure 7-2. It shows each system function, or
business event (in the eUipses). and the actors, or system users, who interact with
those fw1ctlons. As you can see ln Ffgure 7-2, actors can be pL1ced on either side of
the set of use-case figures and can interact witl1 one or more use cases. The us<-<ase
diagram Is extremely simple. Bot It begins an Important process called functional
de,compositio.-1, the act of bre1king a system apart Into its subcomponents. It is impossible to understand the entire ~tern at once, but it Is posslble to w1derstand and
specify each part of the system.
The second artifact, called the tise-case ua.n-ative, fills in tl1e details of ead1 business e,-ei.1t and specifies how the users interact wlth the $)'stem durlog that event.The
use-case narrative will be discmsed in detaU later ln the d1apter.
> Use Cases
textual descriJ:tion of the
business evert and how
the user will irteract with the
system to accomplish the
task.
use case a b; havioralty
related sequence of steps
(a scenario), both automated
and manual, for the purpose
of completing 1 single
business task.
~
~
Use<ase modeling ldentllles and describes the system functions by ush1g a tool called
use cases. Use cases descrlbe d1e system ftmctlons from the perspecth,--e of external
users and ht a manner and tennhology they understand. To accurately and thoroughly
accomplish this demands a high level of user ln,--olvement and a subject-matter expert
who is knowledgeable about the business process or event
Use cases are represented gr.tphlcally by a horizontal ellipse wltl1 tlte name of tlte
use case appearing above, below, or Inside the ellipse. A use case represents a single
goal of the system and describes a sequence of activities and user Interactions Ill try·
ing to accomplish the goal. TI1e creation of use cases h ..,s proved to be an excellent
technique to better understand and document system requlremenrs. A use case itself
is 11ot considered a function.al requirement, but the story (scenario) the use case tells
consists of one or more requirements.
Use cases are lnltially detlaed during the reqttlrements stages of tl1e life cycle
and will be addltlonally refined throughout the llfe cycle. During requirements
__
System
r FIGURE 7 - 2 '
Sample Use-Case
Model Diagram
,,
Actor 1
Actor S
Actor 2
Modoling Systtm Roq<lromonn with Uso Caso,
chaptor Sown
247
discovery, use cases are used to capture the essence of the business problems and
to model (at a high level) the functionality of the proposed system. Additionally,
they are the starting point for identifying the data entities (covered in Chapter 8)
or objects of the system (covered in Chapter 11). During requlreme11ts analysis the
use cases are refined to model usage of the system In more detail. In other words,
they are updated to specify what the users are trying to accompUsl1 and why.111e.se
use cases aid In the definition of any prototypes ot user Interfaces. During design
the use cases are refined to model how the users will actually use the system
with regard to any Interface and ~·stem const:raJnts(covered in Chapter 18). TI1ese
types of use cases aid In identifying object or system behavior and in designing interface and code speci.flcatlons, as well as serve as the plan for testing the $)'stem .
ln construction, use cases aid developers in progr.imming and testing. These use
cases also serve as the baseline for preparing any user and system documentatJon,
plus they serve as tools for user trainJng. And, because use cases contain an et1ormous amount of system flIDctlonaUty detail, they will be a constant resource for
validating the system .
> Ai:tors
Use cases are ln.itiated or triggered by external users called actors. An actor Initiates system activity, a use case, for the purpose of completing some business task
that produces something of measurable value . Let's use the example of a college
student enrolling for the fall semester's courses. The actor would be the st1,de1it,
and 1he buslness evet1t, or use case, would be /!:nrolll11g in Co,,rse. An actor represents a role fulfilled by a user lnteractJng wJth the system and ls not meant to portray t single individual or job tltJe. In fact, an actor doesn't have to be human. It can
be an organization, another information system, an external device such as a heat
sensor, or evet1 the concept of time (which will be discussed a little later). An act or is represented graphically as a stick figure Libeled with the name of the role the
actor plays.
It ls important to 11ote tl1..1t there are primarily foltr types of actors:
Prt111ary b ·ust11ess aaor- the stakeholder that primarily benefits from the
execution of the use case by receiving something of measurable or obser,lable value. The primary business actor may or may 11ot lnltL1te the business
event. For example, ln tl1e business e,-ent of an employee rece.ivlng a paycheck (something of measurable value) from the payroll system each Friday,
the employee does not lnltlate the event but is the primary redplenc of the
something ohalue .
Prl111ary systettJ. actor- tl1e stakeholder that directly interfaces witJ1 the ~ tem to ln.itiate or trigger tl1e business or system event. Primary system actors
may Interact wlth prlmary business actors for the purpose of usfr1g tl1e actual
system. They facilitate ti,e event through the di'ect use of the system for the
benefit of the primary business actor. Examples include a grocery store
clerk who scans the Items for the n1stomer buying groceries, a telephone
operator who gives directory assistance to a customer, and a bank teUer who
processes a banking transaction. The primary business actor and primary
~·stem actor may be the same person for e,-ents where the business actor
Interfaces with the system directly- for example, a person resening a rental
car ,ia a Web slte.
E.."<ternal server actor- tl1e stakeholder that respon ds to a request from the
u.se case (e.g., a cred.Jt bureau authorizing the charging by a cred.Jt card).
E.."<ternal receiver actor- the stakeholder that ls not the primary actor but
receives something of measurable or observable value (output) from tl1e use
case (e.g., a warehouse rece.i,ing a packing order to prepare a sh.ipment after
a customer has pL1ced an order).
actor anything that needs
to interact 'Mth tie syS1em to
exchange information.
\
Aclor Symbol
248
Part 1wo
Systoms Analysis Methods
In many information systems there are busfr1ess events trfggered by the calendar
or the time on a dock. ConsJdet the following examples:
The billing system for a credlt card company automatically generates its bills
on the 5th day of tl,e month (billing date).
A bank reconciles Its check transactions every day at 5 P.M.
O n a nlgbtly basis a reporl is automatically generated llstlng whlcb courses
have been dosed to enrollment (no open seats available) and wh.lch courses
are stl U opet1.
tem poral e,ieot a system
These events are examples of te mporal events. Who would be the actor? All of
event that is trggered by time.
the events listed above were performed (or triggered) automatically- when ft
became a certain date or time. Because of that we say the actor of a temporal event
ls time.
>
Relationships
A reL1tlonshlp Is depleted as a Une between two symbols on the tase<ase diagram. The
meaning of the relationshJps may differ depend.fog on how the Unes are drawu and
what types of symbols tl,ey cetmect. In the following sections we will define tl1e
dlfferent relatlonshJps fow1d on a use-case diagram .
Associations A relatlonsl:l.ip between an actor and a use case exists whene,--er the
use case descrlbes an Interaction betweet1 them. This relatlooshJp is referred to as an
assocl..1.tlo11. As lndicated lo Figure 7-3, an as.,odatlon is modeled as a solid line connecting the actor and the use case. An association that contaitlS an arrowhead on the
end touching the use case (0) indicates the use case was Imitated by the actor on the
other etl d of the line. Assodatloos without arrowheads (0) Indicate an interaction between the use case and an exremal server or recetver actor. Whetl any actor is associated wlth a use case, we say the actor co1u1uu.11tcates witl1 the use case. Associations
may be bidirectional or wlldirectlonal.
associatioo a relationship
between an attar and a use
case in which an interaction
occurs between them.
exteosioo use case a use
case consistin.:J of S1eDS extracted from a more complex
use case in oder to simplify
the original case and thus
extend its functionality. The
extension use case 9Xtends
the functionati}' of the original
use case.
,
\.
FIGURE 7 - 3
Extends A use case may contlin complex functionality consisting of several steps
making tl1e use-case logic difflcttlt to llllderstand. For the purpose of simplifying
the use case and making it more easily llllderstood, we can extract the more complex steps Int o their own use case. TI1e resultJng use case is called an e xteosiou
u SE" a1s:e in th.it ft extends: the flmct1on11ir:y of the original use c:ise. The rel:ttion.
ship between the ex.tension use case and tl1e use case it ls extending is called an
e:'(te11ds relatlo11shlp. A use case may have many ex.tends relationships, but an extension use case can be h1.,...-oked only by the use case it is extending. As depicted
in Flgttre 7-4, tl1e extends relationship is represented as an arrowheaded Une
(either soUd or dashed) beginning at the extension use case and pointing to the
use case ft ls ex.tending. Ead1 extends relatlo11ship line is labeled "<<extends>>."
Get1erally exte11Slon use cases are not identified in the requirements phase but in
the analysis phase.
'
0
Exam p le of an
Association
Relationship
Club Member
Distribution Center
Modollng systom Roq<Aromonn with Use Cases
chaptor S..von
249
FIGURE 7-4
Example ofan
Extends
Relationship
Uses (or Includes) Very commonly, you may discover two or more use cases tl1..1t
perform steps of Identical functionality. It ls best 10 extract these common steps
into their own separate use case called an abstract \1se case. An abstract use case
represents a form of ..reuse" and is an excellet1t rooJ for reducing redw1dancy among
use cases. An abstract use case ls available for referencing (or use) by any other use
case that t'0qui.re6 its functlonaUty. The t'el:ttionship ~tween the nbstt:tct use case and
t11e use case that uses ft is called a uses relatlonshJp (some use<ase modeling tools refer to lt as an tncludes relatlonshlp). The uses relationship as presented in Figure 7-5
is depicted as an arrowheaded line (elther solid or dished) beginning at the original
use case and pointing to the use case it ls uslng. Each uses relationship line ls L1beled
.. <<USes>>:' Generally abstract use cases are not Jde1xified ln the requirements ph.a se
but ln the analysis phase.
Dep•nds On As the project manager or lead developer, lt is very helpful to know
wh.ich use cases have a dependency on other use cases in order to determine the sequence in wllich use cases need to be deve.loped. Us.Ing the banking business as an
example, the use case lttake a Withdrawal cannot be performed until the use case
Make a Deposit has been executed, and that use case cannot execute until the use
case Establlsh Bank Accotult has occurred. Because cf these dependencies the deve~
opment team wlll most likely choose to deveJop the use case F.stabllsh Bank Accotmt
first, the ~take a Deposit use case second, and the !\take a Withdrawal use case tllird
for usability and testing purposes. A use-case d11gram modellug the system's use<ase
depende11des using the. depends 011 reL1tlonshlp pto\'ides a n1odel that is an excellent tool for pL1nning and sd,edullng purposes. Toe depends on relatlonshlp as
Abstract
Use Case
<<u~es>>
<<u~es>>
I
abst:tact use <ase a use
case that reduces redundancy
among two or rrore other use
cases by combining the com.
mon steps rounCI 1n tnose
cases. Another use case use,s
or includss the abstract use
case.
depe-ods o-o a. relationship
between use cases indicating
that one use case cannot be
performed until another use
case has been performed.
/
"
FIGURE 7-S
'
Example of a Uses
Relationship
,
250
Partlwo
Systoms Anclysls Methods
FIGURE 7-6
Example of a
Depends On
Relationship
<<depends on>>
I•••~
<<depends on>>
presented h1 Figure 7-6 Is depleted as an arrowheaded line (either solid or dashed) beginning at one use case and polntlng to a use case ft ls dependent 0 11. The depettds on
relationship line Is Libeled "<<depends on>>.'
Inheritance When two or more actors share common behavior- in other "i'Otds,
they can lnltiate the same use case- lt ls best to extrapolate this comn1011 beha"ior
and assign ft to a new abstract actor lo order to reduce redw1dant commwlicatlon
wJth the ~tern. For example, a library parro,, is a card-carrying member who ls a u-
ialteritaoce in use cases,
a relationship Oetween actors
created to simolify the drawing
¥itlen an abstract actor inherits the role of multi pie real
actors.
thorized to "Search library hwentory" as well as "Check out books" from the library.
Since many Ubrarles are public Institutions, they we.lcome visitors to use th eir
services onsJte such as ..Search Jlbrary Jnventory; but the '\oisJtors are not allowed the
extended services (such as "Check out books") tli.1r are reser,--ed for the patrons . By
creating an abstract actor caUed a1sto1ner, from wllid 1 patro11 and visitor w UJ JnherJt,
we have to modeJ only once the relationship loJt.iating d1e use case Search Library
Inventory. In the use-case diagram the Inhe ritan ce relationshlp is depicted by the
type of arrow shown in the ..Afrer" section of Ffgu re 7-7.
FIGURE 7-7
Example of an
lnheritarce
Relationship
Vis itor
Patron
Patron
Before
Viet tot
After
Modoling Systtm Roq<lromonn with Uso Caso,
The Process of Requirements Use-Case Modeling
The objective of constructing the requirements use<tse model Is to elicit and analyze
enough requirements information to prepare a mockl t11ar communicates what is requlred from a ,rser perspective but Is free of speclfk details about how the system
will be b,ult and Implemented. Following this approach will Liter produce a design
tl1at is more robust and less Ukely to be impacted by change. Bur ro effectively estimate and sd1edule the project, the model may need to lndude prelimlnary«system
Implementation assumptions· to aid In those activities. It Is critical that tl1e analyst
does not slip Into a state of analysis paralysis when preparing this model. Speed Is
the tey. Not all of tl1e facts wiU be learned during this phase of the life cyde, bttt
by utilizing iterative and Incremental development, the methodology allows the In-
troduction of new requirements later In the project without seriously Impacting
the deployment of the final solutlon.111e steps requlred to produce this model are the
following:
1. Identify bush1ess actors.
2. Identify busU.tess reqttlrements: use c:ues.
3, C)11Struct use-case model dtagram.
4. Ooa1ment busfr1ess requirements use<ase narratives.
>
Step I : Identify Business Actors
Why identify actors first? By foalSfng on the actors, you can concentrate on how the
system will be used and not how It will be built. Foct1Slng on the actors helps to refine and further define the scope and boundaries of the system. Actors also determine
the completeness of the system requlrements:2 A benefit of Identifying actors first ls
tl1at doing so Identifies candidates we can later inten-iew and observe to complete
tl1e use<ase modeling effort. Plus, tl1ose same lndJvk:luals can be used to verlfy and
validite the use cases when they are finished.
Where do you look for potential actors? The followlng references are excellent
sources:
A context dtagram that ldentlfles the scope and bowlClaries of the system.
Existing system documentation and user manuds.
6Unmes of project meetings and workshops.
Existing requirements documents, project charter, or statement of work.
When looking for actors, ask tl1e following questions:
W110 or wh.at provides Inputs to the ~tern.?
W110 or what receives otnputs from the system?
Are lntetfaces required to other ~·stems?
Are there any events that are automatically trJggered at a predetennlned
time?
W110 wUI maintain information In the system?
Actors should be named with a noun or 11otm phrase.
W11en you Identify an actor, create a textual deflnltion of that actor according to
the users' perspective and ush,g their terms. Figure 7-8 Is a template of an actor glossary tl1at can be used to doalOlent actors. 111is example contains a partial listing of the
SotmdStage ,_lember ServJces System's actors.
chaptor S..von
25 1
252
Partlwo
Systoms Analysis Methods
Actor Glossary
FIGURE 7 - 8
Term
Partial List of
SoundStage
Member Servires
System's Actors
Synonym
An individual o r corporatio n that submits a slbscription
order in order to join ihe ell.A:>,
1, Potential
member
2. Clubmember
Description
Member
An individual or corporation that has joined the club ·1ia
a, agreement.
3. Past member
lnactWe
member
4, Marketing
A type cl member that has fulfilled the ag-eement
obligation but has not placed an order w ithin the last
six months but is still in good standing.
Oganization responsible for creating promo tion and
slbscription programs and generating sales for the
compalT'/,
Oganization responsible for prCMding point o f c onta:t
5. N'£mber
for SouidStage Entertainment customers in terms o f
agreements and orders,
setVic es
6. Distributio n
center
>
business requiremeots
use case a use case created
during require11ents analysis
to capture the interaciions be·
tween a user ,111d the system
free oftechnobgy and imple-
mentauon aetans aiso ca11ea
an essential use case.
Warehoose
Entity that houses aid maintains SoundStage
Entertainment product inventory and processes
c ustoma shipments .:ind rctums,
7. Accouits
receivable
Oganization responsible for processing customer
payments and billing as well as maintaining custo mer
account information.
8. lime
Actor concept responsible for triggering temporal events.
Step 2: Identify Business Requirements Use Cases
A typical lnformatio11 $)'stem may consist of dozens of use cases. During requirements a nalysis we strlve to Jdentify and document only the most critJcal, complex,
and important ones, often referred t o as esse11tial use cases because of time and
cost considerations. A business requiremeit ts tise case captures the Interactions
wJth the user in a manner that is free of technology and lmplementatJon details.
Since a use case describes ltow a real-world actor Interacts wJth the system, an
excellent technique for finding business requJrements use cases ls to examine
actors and how they will use the system. When look.Ing for use cases, asl: the
following quesrJons:
What are the mait1 tasks of dte actor?
What infonnatlon does the actor need from the system?
What infonnatlon does the actor provide to the system?
Does the system need to lnform the actor of any changes or e,--ents tl1..1t have
occurred?
Does the actor need to lnform the system of any changes or e,--ents tl1..1t have
occurred?
Agait1, a context dL1gram l! an excelle nt source for finding potential use cases.
Context diagrams were discussed in 01apter 5. They come from traditional process
modeling (Chapter 9) but are useful <>1'11 for projects that take an object-0rletl1Ed ap,
proach. Let's examitte the SoundStage ~tember Services System's context diagram in
Agure 7-9. We can ldentlf)• potential use cases by Jooklng at the dlagnm and ldentlf)•ing the prlmary Inputs and outputs of tl1e system and the exten1..1l parties that submit
and receive them. T he p rimarJ' inp uts that trigger business e,-ents (for example,
Sub1nlt ,lletnber Order) wJtl)ln the organization are considered use cases, and tl1e
external p arties that pro,ide those Inputs are considered actors (for example, aub
,lfe»iber). It Is important to note t11..1t inputs that are the result of system requests do
Modoling Systtm Roq<lromonn with Uso Caso,
Chaptor S..von
Member Services Context
Diagram
Marketing
CIUl) Mem.11er
- - - - S u t m l Memllef ClfGer----,
-
su11n1t Promoaon 1ntormaaon -
1nqure AOCCUnt (oraer & payment ntsto'Y)
SLOrrfl SU!l&Cllptlon - - -
Program
Generate va11ous
Generate nq1Jry Responses - -
__
SUll&Cll~bn Reportl
ecnc:11 nomottonOtrOI" - - - -
Poterltl81 CIUD
MemDel'
t
•
-----
- - - Ccnoldo V41'1ouo _ __,
Promotion Reports
Generate YallOU$
- - - - - - S~86Aeports
suDmn SL09Crlptlonoroer~
(app~ t:ir memDer&lllP)
~
P~utMemDe,
Sena SU!ltcrlptlon Offer
'
I ,..,_
J
..,.
St.0mn SUOto!"'cn
"'"'''"
>---Rasutl6Cll~IOn - - - - - '
°""
suomn Memoer
CredtSlab.Js - - - - - '
He:sponse
Ol8tr1Dut1on
Center
(Warenou,e)
Gnrate Va,IOus
Menllef Reports
•
Merrt:ler 5el'Ylcee
F IG U R E 7 •9
SoundStage Member Services System Context Diagram
11ot fndicate a separate use case- such as a credit card company responding to an
authorization request or, as presented in Ffgure 7-9, the Acco,,nts Receivable actor
responding witl1 Afe,nber Credf.t Status /11for111atlo11.
Use cases are named with a verb phrase specifying the goal of the actor, such
as Su.btuit Subscrlptio·n Order. Use cases thar are temporal events are usually
253
254
Partlwo
Systoms Analysis Methods
identified as a result of analyzing the key outp uts of the system. For example, any
output that ls generated 0 11 the basis of time or a dat e, such as monthly or annual
reports, ls considered a use case, and the actor, as you recall, ls time. In Figttre 7-9
Jet's assume that one of the Yarious reports that ~tember Services receives is a
/0-30-60-day default agreement report that is automatically gei1ernted on a dally
basis. Since the generation of the report ls triggered by time, a use case is requ.Jred
to process the event, and we would name it Generate Dally /0-30-60-Day D•fault
Agree,ne11t Report. It ls important to note that many times indJ'\oiduaJ reports are not
listed on a context diagram be::ause they are too numerous and would clutter the
diagram and make it hard to read. It is the system analyst's responsibility to research
with the ap propriate stakeholders the type of outp uts tl1ey receive and thelr dtaracterlstJcs, in tenns of volume, frequency, and triggering mechanism, In order to
identify "h idden use cases.·
FJgttre 7-1O is a template of a use-case glossary tl1..1t can be used to document use
cases. 1bls exampJe contains a partL1l listing of the SoundStage ~tember Services
System's use cases and actors identified from the context dL1gram as weU as from
other sources.
>
Step 3: Construct Use-Case Model Diagram
Once the use cases and actors have been identified, a use<:ase model diagram can
be used to graphica lly depict the systetn scope and boundaries. The use-case
r FIGURE 7 - 1 0
Partial List of SoundStage Member Services System's Use Cases
~
Use-Case Glouary
Use-Case Name
Use-Case Description
Participating Actors and Roles
Submit Submiption
Order
Thi$ use case de$cribes the event of a
potential member roque,ting lo join ih• dub
by ,ubscribing. ("Tokoany 12 CD, for one
penny and agree lo buy A more at regular
prices within two years:")
• Pok>ntia I member (primary bu ,iness)
• Oi$tribution Center (aicternal receiver)
Submit Submiption
RenCJW<J I Order
This use case describes the event of a past
mombor roquostiOQ lo rejoin tho dub by
,ub,cribing. ("Tako any 12 CD, for one
penny and agree lo buy A more at regular
prices within two years:")
• Past member (primary bu,iness)
Submit Manbor
Profile O,onge,
Thi, u,e ca,e de,crib.. lhe "'9111 of a dub
mombor ,ubmitling change, b hi, or her
profile for such lhing, a, postal address,
e-mail oddres$, privacy code$, and order
preference$,
• Club member (primary bu,iness)
Plaai NowOrder
Thi$ use case de$cribes the event of a
dub member submitting an order for
SoundStoge producn.
• Club member (primary bu,ine")
• Oi$tribution Center (aicternal receiver)
• Acrounb Payoole/ Receivable (9""'rnal ,er,..r)
Revise Order
Thi, u,e ca,e de,crib.. lhe "'9111 of a dub
member revis.ing an order previously
plaaid. (Order must not hCM> shipped.)
• Club member (primary bu,ine")
• Oi$tribution Center (aicternal receiver)
• Acrounb Payoole/ Receivable (9""'rnal ,er,..r)
l
• Distribution Contor ('11Xh:1rnol rocoivor)
,
Modoling Systtm Roq<lromonn with Uso Caso,
chaptor S..von
2SS
F I G U R E 7 - 1 0 Concluded
Cenco! Order
This use case describes the event of a dub
member oonailing an order
placed. (Order m,nt nol haw ,hippo .)
• Club member (primary bu,ine6')
• Distribution Center (e,ternal receiwr)
• Accaunb Payable/Receivable (ex!Qnal sOM>r)
Maka Product Inquiry
This use case describes the event of a dub
mom bar viewing product, for J:XlO•ible
purcho,e. (DriV911 by Web aro>'5
• Club member (primary bu,ine6')
previoul
requirement.)
This use case describes the event of a dub
member viewing her or hi, purchasing
hislory. (1hree-}'90r time limit.)
• Club member (primary bu,ine6')
Est.ibli,h New Momber
Sub,cripoon Prog rom
This use case describes the event of the
marketing depar1ment eotobli,ling a new
membeBhip wbscription plan b entice new
members
• Marketing (primary busine'5)
Subm ii Subscription
Program Changeo
This use case describes the event of the
marketing depar1ment chonging a
subscription plan for dub members (e.g.,
extonding the fulfillment period!.
• Marketing (primary busine'5)
fabbli,h Past Member
R..ub,criplion
Program
This use case describes the event of the
marketing depar1ment eotobli,ling a
r..ubmiption pion lo lure bad k>nner
members.
• Marketing (primary busine'5)
Submit Member
Prolile Changeo
This use case describes the event of the
marketing depar1ment eotobli,ling a new
promotion plan to entice active and inactive
membOB lo order the product. (Noto: A
promotion leature, ,pacific ti~ ... usually
"""'· that the company is trying b ,oll at a
special pric:e, These promotion! a re
• Marketing (primary busine'5)
Mo lea Pu rcha,e
Hiitory Inquiry
integrated into o catalog
$9111 (or
communiooted) lo all membenJ
Revise Promotion
This use case describes the event of the
marketing depar1ment revising a promotion.
• Marketing (primary busine'5)
G<nerate Doily
1(). 30-60-Doy Defoult
~reernentReport
This use case describes the event of a report
that i, generated on a doily bo1i, to list the
membOB who have nol fulfilled their
ogreernent by purcho,ing the required
number of product, oufoed when they
subscribed. Thi, report i, sorted by
membOB who are 10 day, pa~ due, 30
day, past due, and 60 day, po,t due.
• Time (initioong actor)
• Member Service, (primary"-'"rnal
receiver)
256
Partlwo
Systoms Anclysls Methods
Order Sut,eyetem
Subtcription S ub•yatem
Potential Mtmber
1nrua1ee
Club Member
~
rnaias
1n111a1es
1nt11atee
Paet Member
1nn1a1ee
Operation• Subeyetem
1n111ates
Prcmotion Su:bayetem
~
~
~
Ti,111:t
1nrua1ee
FIGURE 7 · 1 1
SoundStage Member Services Sy>tem' s Use-Case Model Diagram
dlagram for the ltSe cases listed In FJgure 7-10 ls shown in Figure 7-11. It was created using Popkin Software's Syste111 Architect and represents the relationships between the actors and the use cases. In addltion, the use cases l1ave been grouped
into business sub,ystems. The sub,ystems (UML's package symbol) represent logical functional areas of business processes. The portjonJng of system behavior into
subsystems is very important In w1derstandlng the system architecture and is a key
to defln..lng your development strategy- whld1 use cases will be developed first
and by whom. We have labeled the associations between the actors and the use.
cases .. Initiat es" because tl1e tool did not support lines wlth arrowheads at the
time. We also didn't include the external server and recelver actors because of
space Umltatlons. To model all the use cases of a particular >)'stem may requlre the
creation of several use<ase mode! diagrams- as you recall, a system may contain
dozens of use cases. J.n tl1at event you may want to create a separate use-case
model diagram for ead1 subsystem.
>
Step 4: Document Business Requirements
Use-Case Narratives
When you are preparlog the nlrratlves, it ls wise to first document them at a high
level to qulckly obtain an w1detstand.Jng of the events and ma.gnltude of the system.
111en return to ead1 use case and expand lt to a fully docume11ted buslness requirement narrative. Figure 7-12 represents a re(Jltlrements use-case narrative for tl1e
chaptor Sow n
Modoling Systtm Roq<lromonn with Uso Caso,
257
Member services System
Author (s),
- --=o=---- -
Date,
E)
Version,
Use.case Hemet
Use.case ID,
Priority,
Soll'cc,
PrtmsyB..,ncn
Place Nev,., Order
Peitlclpatlng
Actors,
Otl>cr
Interested
St*choldcrs1
Ocscrlptlon1
'9
Use--Cas.e Type
MSS-BUC002.00
0
High
REQ.Jirement - MSS-R1 .00
e
CIIJ:> member
Actor,
Otl>cr
0
•
•
Business Requirements:
0
0
0
Warehouse(e:xtemal recet.'ef)
Accounts ReceWable (external server)
~
•
Mneting - Interested in sales acti'IAty in order to pla, ne.v promotions .
Prorurement - Interested in sales actWity in order to replenish inventory.
• Msiagement- Interested in order acti'IAty in order to evaluate compaly' performance and
customer ( member) satisfaction,
This use case describes the event of cell.A:> member submittinq a new order for SoundSta:Qe products.
The member's demographic inforrnaton as well as his or her account standing is validated, O'lce the
products « e verified as being in stoc<, a pa::king order is sent to the warehouse for it to prep9re the
shipment !=or iS'o/ product not in stod<, a back order is created, On completion, the member w ill be sent
an order confilmation.
CD .
F I G U R E 7 • 1 2 High-Level Version o f Place Ne w Order US<H:ase Narrative
,_leni>er Services System's Place New Order use case. Notice tl1..1r Jr tersely descrlbes
the event, whlch lndudes the following Items:
O Au.thor- The
GI
names of the Individuals who contributed to the writing of the
use case and who pro'\oide a polnr of contact for anyone requlrlng additional
Jnformatio11 abour the use case.
0 Date- T he dare tl1e use case was last modtfled
O Ver.rf.o·n - T he current version of the use case (e.g., 1.0).
O use-case 1ui1ne- llle use-case name should represent the goal that the use
case Is trying to accomplish. T he rwne should begin with a verb (e.g., Enter
New Member Order).
0 Use-mse type- It, perfonnlng use-case modeling, business requlrements use
cases, wltich focus on d1e strategic "islon and goals of the Yarlous stakeholders,
are constructed first:.This type of use case ls blr:iness-orlenred and reflects a
hlgh-level >iew of the desired behavior of the system. It Is free from technlcal
details and may lndude manual actMties as weU as the acthities that will be
automated. Business requirements use cases pro,ide a general lUldersranding of
the problem domaln and scope bur don't indude d1e necessary detail ro communicate to developers what d1e system sho,dd do.
O Use-case ID- An ldentlller that uniquely Identifies the use case.
O Priority- Toe priority communicates the importance of the use case In terms
of hlgh, medium, or low.
O Sou.rce- T he source defines tl1e entity thar triggered tl1e creation of the use
case. 11lls could be a requirement, a sped.tlc document, or a stakeholder.
O Prl1nary busl1iess actor- The primary business actor is the stakeltolder tl1..1t
primarily benefits from tl1e execution of tl1e use case by receiving sometlling
of measurable or observable value.
258
Part lwo
Systoms Analysis Method s
C?:) Other participating actor.s- Od1er actors tl1..1t participate in the use case to
accomplish lts goal lndude lnltiatlng actors, facilitating actors, server/receJver
actors, and secondary actors. Always include the m:uu1er ln wtlich the actor
partldpates.
'D Interested stakebolder(s)- A stakeholder is anybody who has a stake in the
development and operation of the software system. An interested stakel10Jder
ls a person (other than an actor) who has a vested lnterest In the goal of
the use case.
cP) Descrtption.- A short summary description that consists of a couple of
sentences outllnlng the p urpose of the use case and its activities.
Documenting the Ute·Case Course of Events For each high-level use case Identified, we must now expan d It to indude the use case's typical course of events and
its alternate courses. A use case's typlcal course of events is a step-by-step description
starting with the actor lnitiath1gthe use case and continuing until the end of the business event. In tl1is section we include only the major steps that ocntr the majority of
the time (its typical course). The alternate coltrse documet1ts the exceptions or tl1e
conditional brandling of the use case. Figure 7-13 represents a requirements us<-<ase
narratl,-e for the ,_lember Servlces System's Place New Order use case. Notice that it
indudes the following additional items:
O Prec.ondlt/011- A precondition
is a const.ralnt on the state of the system
before tl1e use case cut be executed. Typically this refers to another use case
that must be prel-iously executed.
& Trtgger- T he trigger ls tl1e evet1t that initiated the execu tion of tlte use
case. Tilis ofte11 is a physkal action, such as a n1stomer walking up to a
sales counter or a check uriving In tlte mall . Time can also trigger use
cases.
0 'lyptcal cou.rse of events- Toe typical course of events is the normal
sequence of actMties performed by the actor(s) an d the system in order to
satisfy the goal of the use case. These lndude tlte interactions between the
system and tl1e actor and the actfvities performed by tlte syst:em In response
to tlte interactions. Note that the actions of the actor are recorded ln t11e Jeft
hand column while the actions of the systems are recorded in ti,e right hand
column.
O Alternate co,,rses- Alternate coltrses document tlte behaviors of the use
case if an exception or vulatio11 to tlte typical course occurs. This can
happen when a dectston point occurs wtthln cbe use case or an excepuon
occurs that requires addidonal steps outside the scope of the typical
course.
0 Co11dusto11- 1l1e conduslon spedBes whet1 the use case succ~fully ends- in
oth er '\1/"'0rds, when the primary actor receives sometlth1g of measurable value.
O Postcondition- A postcondition is a constraint 011 the state of the ~tern
after the use case has been successfttlly executed. This could be data
recorded ht a database or a receipt deU,--ered to a customer.
O Business rules- Business n~es specify policies and procedures of ti,e
business that ti,e new system must abide by. 1bis could lndude the calcufatlon of shlpping d1arges or rules for granting credit terms.
0 /111plenie11tatlo11 constrai,zts and spectflcatto1,s- lmplemet1tatfon constr.1ints
and spedllcations specify any nonfunctional requirements diat may Impact
the reaUzation of the use case and may be helpful In any archltectural
pL'Ullling an d scoping. Items that may be lnduded are security spedBcatlons,
Interface requirements, and so on .
C:) Ass1,n1.prto11s- AJ.ry assumptions that were made by the creator wbett do..."Umet1th1g tl1e use case.
'1:) Ope1i Issues- Any questions or i~ues that need to be resoJ,-ed or ln,--esti
gated before the use case can be finalized.
Modoling Systtm Roq<lromonn with Uso Caso,
chaptor S..von
259
Member Services System
o.rte,
Author (s), - - - - - -
version,
u,c--CaH Memc1
u,c--CaH 101
MSS-BUC002.00
Priority,
High
Place New Order
Use--Casc Type
Buslneu Rcq<irements, lllJ
Source,
Requirement- MSS-R1 .00
Prmery Buslncn
Club member
Acton
Ofter
Pertlclpatlng
Actors,
•
•
Warehouse(extemal receiver)
Ofter
lntcrated
Stikeholden,
•
•
•
Ma'keting - Interested in sales activity in order to plan reN promotions,
Dac,..,.k>n1
Accounts Receivable(extel'ra se!Vtt)
Procurement-
Interested in sales activity in crder to replenish irwentoiy.
Msiagement - Interested in :irder activity in order to evaluate comparry perlorrrwice and
rustomer ( merrt>er) satisfaction.
lhis use case describes the event o f a club member slbmitting a ne.v order for SoundStage prod.Jets.
lhe member's demogr~ic informa1ion as well as his or her a:count standing is valid ated. Cnce the
products are verified as being in stod<, a packing order is sent to the warehouse for it to pre,:are the
shipment. !=o r arrt p roduct not in stcx:k, a back o rder is created. 01 completion, the memberwill be
sent an order cc:nfirrnation.
Prccondltlon1 •1 lhe party( individ..Jal or compal'/) slbmitting the order must be a member.
Trl19cr,
lhis use case is initiated w hen a new o rder is submitted.
0
lyplcel Course
ofEvcnt1-1
E)
Actor Actlon
Step 1, Thecllb member
provides his or her demographic
informatio n as well as order and
payment information.
System Rt:cpons,e
Step 2: The system responds by verifying that all required
iiformatio n has been p r0tided.
Step 3: The system verifies the club member's demograohic
iiformatio n against what has been pre-v;ously recorded.
Step 4: ~or each product o rdered, the system valid ates the
product identity.
Step 5: ~or each product o rdered, the system verifies tte pioduct
availability,
Step 6: ~or each available product, the system deterrnires the
price to be ctwged to the club member,
Step 7: 0,ce all o rdered products are processed, the ~em
determines the total cost of the order,
Step 8: The system checks the status o f the club member's account
Step 9: The system valid ates the club member's payment if
provided.
Step 10: The s1stem records the order informatio n and !hen
releases the order to the appropriate distribution center
(warehouse) to be filled.
Step 11: O nce the order is processed, the system geneates a,
order confirmatio n and sends it to the club member.
FIGURE 7 - 1 3 ExpandedVersionofPlaceNewOrderU~aseNarrative
Btisfness requirements use cases are excellent tools in t11at they desc:rlbe the
events the organization must process and respond to, but tl1ey lack information regarding the interfaces and the acthities tl1..1t are targeted to be automated by infonnatlon technology. Later, in Chapter 11, you wUJ learn how to evolve the use case to
Include technlcal and Implementation details.
260
Part 1wo
Alternate
Coursa:
0
Systoms Analysis Methods
Att·Step 2: The club member has not provided all the information necessay to process the order. The
club merrt>er is notified o f thediscrepa,cy and prompted to resubmit
Att·Step 3: If the club member information prCMded is different from vvhat w as previously recordec,
verify w hat w as recorded is cLrrent, then upc.ate the ell.A:> member information accordingly,
Conclulloni ~
Postcondllon, O
Att·Step 4: If the prod.Jct information thecll.b member provided does not match arry o f SoundStage's
products, notify the club member o ftt,e disc1?Pancy and request clarification.
Att·Step 5: If the quantify ordered o f the preduct is not available, a back order is created.
Att·Step 8: If the status o f thec llJ:> member's account is not in good standing, record the order
information aid place it in hold sta1us, Notify the club member o f the account status aid the reason the
order isbeing held. Terminate use case.
Att·Step 9: If the payment the club member provided (credit card) cannot be validated, notify the club
member aid request a, alternative means o f payment, If the club member cainot provide ai alternate
meais, cancel the order and terminate ihe use case.
This use case concludes vvhen thec llJ:> member receives a confilmation o f the order.
lhe order has been recorded aid it the ordered products were available, they were released, !=or iS'fy
product not available a back order has been created.
Buslnc11 Rula1
•
0
•
•
•
lq>lcmcmetlon
Cons traints end
Spcclflcetlons, G
AIM.nptlonl1
Open l11uni
0
CD
lhe club merrt>er responding to a promotion or a merrt>er using credits rneJt affect the price of
each ordered item.
(ash cr checks w ill not be accepted with ihe orders. If provided, tl"lef w ill be retuned to ihe
club member,
lhe club merrt>er is billed tor produc:s only vvhen they are shipped,
GUI to be provided tor Member Services associate, aid Web screen to be provided for club
member.
Procurement w ill be notified o f back ordeis ty a daily report (separate use case).
Need to determine how distribution ctnters are assigned.
,.
( FIGURE 7 - 13 Conclued
)
----------
-·
~~~-U_s_e_C
_a_s_e_s~a_n_d~P_ro~ie_c_t_Nl
~a_n_a_g_e_in
~ e-"_'~~~~~~~~~~~---)
As you recall, one of the benetltsof ltSe<ase modeling ls that the use<ase model c,1n be
used to drtvc the entire S)'Stcm de,--clopmcnt d'fon. Once the business t'C<Jltlremcnts usccase model ls complete, the project manager or systems analyst: uses the business re-
qulremetlls use coses to plan ( estilllltte and schedl~e) the build cycles of the project.1llls
is especWI)' crucial when applying the lterath.. and incremetllal approach to software
de,'dopment . A build cycle, whlch consists of the system analysis, design, and construction actlvldes, is scoped on the basis of the Importance of d,e use case and the tine it
takes to implement the use case. In other '\\"'Ords, one or more use cases wlUbe developed in ead1 build cycle. For a u;e case that is too brge or complex to be comple1ed In
one build cycle, a slmplltled version wlll be lmplemetlted hlltlally, followed by d,e full
verslon In the next build cycle.To detennlne tl,e lruportance of the use cases, the project
nw.u.ger or ~ems analyst wlll complete a use-case raiuing and e\o-aluatlon matrix: and
construct a use.case dependency diagram with h1put from the stakeholders and the de,--elopment team. You will Jean1 bow to use these tools in the following sections.
>
use-case ranking aod
priority matti.'\'. a tool used
to evaluate use cases and
determine thei' priority.
Ranking and Evaluating Use Cases
In most software de,--etopment projects the most Important use cases are developed
first:. In order to determine the prJorJty of the use cases, the project: manager uses a
tool called the use.case ranklog and priority matrb:. 11lls matrix is completed
Modoling Systtm Roq<lromonn with Uso Caso,
Use-Case Mame
SUbmlt Sub1atptlon Order
Piece New Order
- c Product Inquiry
Establlsh New Member
SUl>lc._,.lon Prognm
Ga,crotc Delly 1Cl-30-60-Dey
Ddeult .-.cement R - '
Rc-lllcOnler
FIG U RE 7 • 1 4
1
5
Ranklng ~
3
5
5
4
5
a, 1 to 5
1
1
5
5
!2
4
4
2
2
3
chaptor Sow n
26 1
4
s
6
4
4
5
5
5
5
29
27
High
High
2
1
1
1
6
Lo,v
3
3
5
5
27
High
6
Lo,v
3
18
W£d um
2
3
4
4
1
Partial Use-Case Ranking a nd Prio rity Matrix
with input from the stakel10Jders and the development ream. Tilis matrtx, adapted
from Craig Lannan's work,3 evaluates use cases on a scale of l to 5 agaitut six crlterla.
T hey are as follows:
I. Slgnlficant Impact on the archltectural design .
2.
3.
4.
5.
Easy to Implement bltl contains slgnlllcant functionality.
Jndudes rlsl·y, time-critical, or complex ftmctions.
Involves sJgnlflcanr research or new or rlsl')' tedlllology.
Jndudes primary bush1ess functions.
6. WiU Increase r evenue or decrease costs.
Once each category has been scored, the individual scores are tallied, resulting in the
use case's final score. The use cases wJth the high est scores are assigned the h.ighest
priotlty and sho,dd be developed first.
Figure 7- 14 Is a partial use-case ranking and JYlorlty matrix for the Member
Services System. Based on d1e results of the analysis, the use case Submit Subscription
Ordtr sl1ould be developed first. But we can't be sure tmtll we aJ.talyze the use<ase
depende11des.
>
Identifying Use-Case Dependencies
Some use cases may be dependent on other use cases, with one use case lea'\oing the
system ln a state that is a precondition for another use case. For example, a precondition of sending a dub promotion ls tl1at tl1e promotion must first be created. We use
a diagram called the use-case dependency diagram to model such depet1det1des.
T he use-case dependetlC)' diagram pro,ides the following be11ellts:
The graph ical depiction of the system's events and thelr states enhances the
understanding of system fun ctionality.
It helps to Identify missing use cases. A use case with a p recondition ti1at Is
oot satisfied by the execution of any otl1er use case may indicate a mi~ing
u.se case.
It helps facll ltate project manageme11t by deplcth1g which use cases are more
critical (have the most dependet1des) and thus need to ha>-. a high er priority.
Figure 7-15 is the use-case dependency diagram for the use cases listed In Figure 7-14.111e use cases that are dependent on each other are connected with a dashed
use-case depeodeocy
djagram a graphical depiction of the dependencies
among use cases.
262
Part 1wo
Systoms Anclysls Method s
FIGURE 7-IS
Sam ple Use-Case
Dependency
Diagram
Depends on
•
'
.
.
line labeled "Depends on." In Flgure 7-15, the use case Submlt Subscription Ordtr has
a dependency (precondltion) on the use case Establish New Member Subscription
Program. Because of thls dependency the use case Establish New Member SUl>lcrlption Program should be developed first even though Submlt Subscription Order had
a hfgl,er score as reflected ln Figure 7-14.
'
Q_
0
E
v
0
0
CY'.
0)
c
c
1.-
0
11lis chapter provkled an introd.Jctlon to use cases and how they can be used to document functional requirements. Also, you have lean1ed that use<ase modeling based
on object-oriented concepts ls an excellent complementary tool for tradltlonal systems analysis and design tools 9.lch as process modeling and data modeling. Mmy of
you will proceed directly to Oupter 8, • oata Modeling and Analysis." All Information
systems lndude databases, and data modelh1g ls an essential skill for database deve~
opment. Also, It ls easier to ')'nchronlze early data models with later process m>dels
than vice versa. YO\ll' Instructor may prefer that you first study Chapter 9, "Process
Modeling.• Process modeling ls an effective way to analyze and document f,mctlonal
system requirements. Courses that want to follow an object-0rle11ted approach may
elect to jump straight to Chapter 10,•Qbject-Orlented Analysls and Modelk1g Uslng
the UML," whlch teaches emerging object-modeling technlques using the unlfied
modelh1g language.
(])
__J
Summary
rm;
1. The.re are two primary artifacts involved when performh1g use.ease modeling. The first is the use-case
dlagram, which graphlcally depicts tl1e ')'stem as a
collection of use cases, actors (users), and their re.latlonshlps. OetaJls of each business event an d
how the users interact with the $)'Stem are descrlbed ln the second artifact, called the use-case
narrative, which ls the texmal description of the
business event and how the user wUJ lnteract witl1
the system to accompllsh the msk.
2 Use-case mode.ling utilizes two constructs: actors
and use cases. Alt actor represents anytlling tMt
needs to Interact with the system to exchange in formation. An actor is a user, a role, which could
be an extenu.l system as well as a person. A use
case ls a beha\oiorally related sequence of steps (a
Modoling Systtm Roqclromonn with Uso Casos
scenario), both automated and manual, for the purpose of completing a single business task.
3. There are primarily four types of actors:
of measurable or observable '\o-alue (output)
from the use case.
6. TI,e steps requlred to produce a requirements usecase model are the following:
a. Idet1tify bush1ess actors.
b. Idetttify bush1ess requlrements use cases.
4. Temporal events are business events that are perfcf'me-d (or triggered) 3.Utom.'ltlc:illy
c. Cot.lSU'uct use case mode) dhgr.un,
wbe1t lt be
comes a certaln date or time. Because of that, we
sa.y the actor of a temporal event is time.
5. A relationship Is depicted as a line betweei1 two
symbols on the use<ase diagram.
263
b. The relatlonsllip between the extetlSJon use
case and the use case .it ls extendln@ ls called an
extetlCls relationship.
c. The relatlonsJ.lip between the abstract use case
and the use case tl1..1t uses it ls called a uses
reL1tloruhlp.
d. The inheritance reL1tlonshlp occurs whet1 an
actor lnherlts tl1e ability to hlitlate a use case
from anotl1er.
e. Toe depet1ds-on reL1tlonshlp lndlcales a dependet1q• between use cases. ltt otl1er words, the
precondltlon of one use case is dependent on
the postcond.itlon of a11other use case.
a. Prlnlflry busl1iess actor- The scakeholder that
primarily benefits from the execution of the
use case by receiving something of measurable
or observable '\o"alue.
b, Prlnlflry S)Ste,n actor- The stakeJ10Jder that
directly Interfaces with d1e system to inltlate or
trigger the buslness or system evet1t..
c. £'!(ter11al server actor- The stakeholder that
responds to a request from the use case.
d. £'!(ter11al receiver actor- The stakeholder that
ls not the primary actor but receives somethit1g
Chaptor Sovon
d. Oocumei1t bush1ess reqttlrements ltSe<ase
narratt,--es.
7. Tite use<ase ranking and priority matrix and tl1e
use-ease dependei1q• diagram are tools used by
project managers for prioritizing and scheduling
use.ease deveJopment.
a. An association ls a relationsh.ip between an actor and a use case.
\-;·::~s Review Questions
l. What ls user<entered developmet1t and why is tt
crJtlcaJ to the success of the ~'Stem developmet'Jt
process?
2. How ls use<ase modeling related to user-centered
c:-8. What are the different types of relatiooshlps employed in a use<ase diagram, and wh,11 is their
purpose?
9. What Is the objective of constructing the requlre-
rlP\--Plopmpnti
3, h1 addition to encouraging user ln\--oJvement, usecase modeling provides numerous other benefits.
list the benefits tl1at use-case modeling p rovides
4. Use.case modeling uses two primary artlfactsthe use.< ase diagram and the use-case narrative.
How are tl1e.se two artifacts used and what are
their differences?
5, Use case diagrams consist of three components.
What are these tlvee componet1ts, and wl1..1t is
tl1elr putpose?
6. How are use cases used througl.1out tlte entire
,ystem development life cycle?
7. Of the four primary categories of actors, who ls
tl,e primary system actorY
10.
11.
12.
13.
14.
15.
mpntt- 11'-P4':U:P m orlPI :tnrl wh:lt .i.fpp.,:; :u·p to hf>
followed?
Why Is idet1tlfying the actors the first step In usecase modeling?
What should we be aware of when we are looking for business requirements use cases?
What ls a use case's typlcal course of events?
Why Is ranking and evaluating of use cases
essentL1l?
What are the six crfterla In the use.<a.se ranking
and priority matrix?
What Is the use.case dependency diagram, and
why do we use Jt?
264
Part Two
Systoms Analysis Methods
Problems and Exercises
~
1. Accord.log to author Fred Brooks, what is the sh1-
gle most dtftlcult thing to do in systems development? How does use.< ase modelh1g help lo this
area?
2. In use case modeling, wl1at two maln artifacts
does the systems analyst use? Describe each of
these artifacts and explain thelr purpose.
3. Wllat shottld a systems analyst always keep In
mind In identifyh1g and developing use cases reg,1rdh1g their purpose? Since req,tlrements fact.
finding llas been completed previously, is It reall)'
necessary to spend much time with users at this
poh1t? Just what should a use case represet1t? Is a
use case the same as a functional requirement?
4. During what part of the developmetll life cyde
are use cases first defined? When are they used
during the development life cycle, and for what
purpose?
5. Matcll the following stakel1olders and external
users wlth the correct actor. What ls a temporal
event? 'Who or wt1..1t is considered to be the actor
ht a temporal event, and wl1y?
United States Postal
Service
Coavuterized door
lock with key pad
Renral car agent
Sales manager generating regional sales
report
Sale.s manager receJ,~-
actor created spec!Jlcall)' to mlnintlze duplica-
tive system commwlicatio11.
The relationship betwee.n the use case «calcttlate GPA" and the lengthy use case • ereate
Transcript."
The relationship betwee.n the use case ..ShJp
Order" and the
<tse
case "Suhntlt Order.·
7. Y8\J Cookbooks is a fictional small business
owned and operated by a retired couple. Up to
this time, Y8\l Cookbooks has sold Its books by
mall order only. The owners now want to develop
an onllne system to sell rare and out-of-prh1t
cookbooks over the Internet. VisJtors will be able
to browse a variety of cookbooks, but they '"'lll
ha,-e to create a customer accow1t before being
able to make a purcllase. Payments will be ac-
cepted only 011.Jlne wlth a major cred.Jt card, and
the credit card will be verified before the order
can be approved. Based upo11 th.ls lnformatlon,
Identify tile main business actors.
8. In use-case modeling, once you Identify the bus•
ness actors, what perspective and L1nguage
Stakeholders and
exteroa.J users
system to see lf an item is h1 stock, and an
Actor
Primary business
actor
Prlmary system actor
Exten1al server actor
Exten1al receiver
actor
Time
should you use In defining tilem? Use that P"'·
spect:Jve and language to construct ai1 actor glossary using Agure 7-8 as an example.
9. A context diagram can llelp tremet1dously In idet1tify!ng different use cases. Prepare a higll~evel
context diagram for the Y8\l Cookbooks Web site,
using Figure 7-9 as an example.
10. TI1e next step ln requlrements use.< ase modeling
ls to identify the business requirements use cases.
What sl1ould each use case capture? What efJec-
iug 1~iv1.00. :,ale:,;
llv~ l~duti\ju~ 1-.~.u, you u~ lo iUaitify u~ 1-.~.u~:,;?
report
Wllat questions ntlgllt you ask In order to ida1tlfy
use cases? What is tl1e dtfference betweet1 a use
AUtomatlc lawn
sprinkler system
Driver purcllash1g
gasolhle with ATM
card
Bank loan authorizatio11 service
6. Wllat Is the type of relationship for ead1 of tile
following examples?
111e relationship between the use case .. Prh1t
Form,. and se,--er.il other use cases t11at
hwolve printing different types of forms.
111e relationship between a motorcyde offi..
cer and a hand.held citation writing device.
111e relationship between a cttStomer and a
sales derk who can each query the lnventory
case ai1d an essential use case?
11. TI1e third step lo use-case modeling ls to coo.
struct the use-case model diagrams. Based upon
the Y8\l Cookbooks actor glossary and conten
diagram, create a higll~evel use-case model dia-
gram, showlng tl1e lnteractions between tl1e
shopper/customer actor and the system, lndudlng searching and browsing for books, purclus-
lng, and m:u1..1ging the customer account. ,_lake
sure to st1ow tl1e relationships betweet1 the actor
and each of these use cases.
12. TI1e next step ls creatlng use-case narratives 10
document the buslness require.met1ts. Why is
preparatio11 of the narratives generally done In a
two-step process, ai1d wt1..1t are d1e.se two steps?
Based upon the preceding lllgh-Jevel use-case
Modoling Systtm RoqlAromonn with u .. ea...
model diagram, create an expanded narrative, us
ing Figure 7- 13 as an example.
13. What Is the relationship of use<ase modellng to
project management.? Why is this Important? Wl1y
are use cases ranked, and what tool is used to
taken from an artlde by Frederick P. Brooks Jr.,
who is generally considered to be one of the lead,
ing authors and contributors to the field of project
m.'103.gement and software development. Search
the Web for this artlde and for other artldes by
aad/or about Fred Brooks.
a. ln conducting your search, how many references to the author dJd you find?
b, Based upon d1e Information presented In the
prevlous d1apters, explain Brooks's statement
that "the hardest single part of building a software system is deciding precise~· what to
build."
c. W11..1t was the name of the artlde lo whid1
Brooks made the preceding statement, and
what was the artlde's mah1 theme?
d. What is Brooks's best known hook that is still in
print and widely read decades after its original
publication? What was the main theme of this
hook?
e. W11..1t do you consJder to be Brooks's greatest
contribution to date? Why?
2. The Standish Group, which was met1tloned in
Chapter 7. is an independet1t research eroup
that stud.Jes changes and trends in Information
t<ehnology. In 1994, the Standish Group p ublished
its groundbreaking CHAOS Report, which "expose[d] the overwhelming failure of rr application
de1i--elopmet1t projects lo today's ~fIS environment"
Since that time, the Standish Group has published
pe,iodlc updates to ti1elr original report. Go to
their Web sJte at ll!Wlt1.standlsbgroup.con1., and
fellow the links to their public access area, where
you can find a summary of ti1elr latest CHAOS
research report, as well as the original 1994
report Itself.
a. W11..1t crlterL1 does the Standish Group use to
detennlne whether a project succeeded, was
challenged, or fulled?
b, Based upo11 dte latest research report, wl1..1t
percentage of projects succeeded, were challenged, or failed?
26S
rank them? Who provides the input for ranking
them? W11..1t crJterL1 are used for ranking? Explain
why use.case dependencies need to he ldent!Jled,
and provlde an example. W11..1t tool is used to
identify dependencies?
@
I. At the beginning of a,apter 7, there is a quote
Chaptor Sovon
Projects and Research
c. How do these latest rates compare to the project success, d1..1llenge, and failure rates shown
In Figure 7-1 of the textbook? How wo,~d you
describe the overall trends, if any?
d. Based upon your reading and experience, wl1..1t
do you beUe,-e to be the reason(s) for the
changes in project success, challenge, and failure rates?
e. Do you thU.1k that ctln'ent project management
and system deveJopment metltodologles will remain essentially the same but contluue to be re.fined, or do you foresee the emergence of
dramatically different methodologies for managing projects and developing systems over the
next decade?
3. Select an information system used In your organli.atlon or In your scltool. IntervJew a systems analyst or designer who Is farnllL,r with ti1e system.
Based upon the h1formation provided, do the
following:
a. De.scribe the infonnatlon system and orgart.ization you selected.
b. Create a context diagram of the system.
c. Idet1tify the business actors.
d. Create an actor e.lossary.
e. Idet1tify the business requJrements essentL1l use
cases.
f. Create a use case glossary.
4. Based upon the h1formation provided regarding
the system you selected In ti1e precediog question:
a. Construct a use-case modeJ diagram that Includes all major subsystems.
b. Prepare expanded use.< ase narratives for three
of the essential use cases.
c. Prepare a use-case ranking and priority matrix,
then use It to rank and evaluate the use cases.
d. Identify use case dependencies.
e. Prepare a use-case dependency diagram.
266
Part Two
Systoms Analysis Methods
5. Search the Web or professional Journals in your
school library for research artlcles on new and
emergh1g developments in use-case modeJ.i.ng.
Select two artlcles, then do the following:
a. Provide a bibliography for each article. (Use the
format used by your school.)
b. Create an abstract in your own words for each
artlde.
c. Compare and contrast the methodologies de-
scrib<d In each article. Describe which one
you feel is more viable and/or slgnlfkant, and
explain why.
6. Conduct intervJews wJd1 several developers
regarding their views on use.case modeling. If
possible,IC)' to find developers from different organlzations and/or wld1 different lengdu of experience,
as well as clllferent types of experience (i.e., a deve~
oper who h:as experlenoe m06t.ly as a f>)'Stems an:i
lyst, one mostly as a designer, and one as a builder).
a. Desctlbe the developers that you Interviewed
ln terms of their experlence. For example, l1ow
long bave they worked In 11; what Is their area
of expertise, and how familiar are they are with
use.-0.se modeling?
Minicases
b. What Is the nature of their org.,nlzation(s)?
c. What questions dJd you ask?
d. What are the viewpoints of each developet regarding the importance and value of lise<:ase
modeling?
e. Do these developers actually en,ploy use-ase
modeling it1 their current orgart.izatlon? Why or
why llOt?
f. If they were aos of their organization for a
day, would they change their organlzation's rr
architecture regarding use-case modeUng! If
so, how?
g. Using the capability mamtity model, how
wo,~d you rate the maturity level of their organlzation? Why?
h. What conclusions, lf any, can you draw from the
interviews regarding the practical application
of use-case modeling?
i. \Vh:tt were yo\.tt views ttgarding the lmpot
tance and "-a.lue of use.~ ase modelit1g before the
interviews? OJd your views change any as a re.suit of the Interviews? If so, how dld they
dtange and why?
't"j
l. In a mincase for 01..1pter 6, you intervJewed stakeholders for an 01illne class reglst.ratlon system. In
that exercise, you were to develop an w1derstandlng of any issues and needs those stakeholders had
In regards to the systen,. Review your findings
from those lntervlews.
a. VisJt other school registration systems. Is there
any functionality or ease of use differences?
Are there any features that you tllink tl1e stakehold,rs wo,~d particularly Jil(e/dlsllke? Make
notes and create screen dump examples of
otl1er systems.
Team and Individual Exercises
I. Roundtable discussion: Do you thlnk people are always ab..<olutelj• truthful In their responses to lnter-
vJew questions?
2. Watch a silent movJe. Roundtable dlsct~Jo11: What
communication is taklng place other than words?
3, Roundtable discu~Jo11: When you determine reC(ltlrements for a $)'stem througl.1 a method sud1 as
b. Create a follow-up intervJew wlth tl1ose stakeholders you previously spoke to and determine
speclfk functionality and ease-of.use requirements for your school.
2 Create a use-case descrJptlon for at least one of
the fllllctlonallt:y requirements you found in the
previous problem. Follow tl1e example shown lo
Figure 7-10.
3. Identify all of the actors for the school registr.ition
$)'stem. Wllich uses cases wUJ ead1 lnltL1te?
4. Using your answer 10 tl,e previous problem, draw a
use<a.se diagram of the school registration sys1em.
rn
an lntervlew, you assume that the person you are
lntervJewing and collecting Information from
U,'(l1Jts the system to be successful Is th.ls always
the case? How can you handle requirements
gathering if It ls not?
Modoling Systtm Roq<lromonn with Uso Caso,
Chaptor Sown
267
~ Suggested Readings
Amblrt; Scott W. The. Object Pr1111er. New York: Cambridge
Uni,trsity Pttss, 2001. Very good information about doc·
urncnting use cases and their use.
Armout; Frank, and Gran,'lllc Miller. Atlt,.rince. use. case Atoaett11g. Boston: Addi.son·Wcslcy, 200 L This book pttscJXS
C¥cdlcnt co,tragc of the use-case modeling process.
Brooks, Jr., EP., 1987. • No Sih'dilulk-t - F.sscncc and Attidc:tts
of Software Engineering." 0>1np111.er 20(4), April, 10-19.
proc. IFIP Congress, Dublin, I~land 1986
Jacobson, J-,,ar; l\otagnus O\ristcrson; Patrik Jons90n; and Gun·
nar O\trgaard. Object-Ortenled Softtt'tlre. E11gt1Jeerf11gA use. case. Drl.ven Af)proadJ. Woddnghi.m, England:
Addison--~slC)', 1992. This book pttscnts er.tailed co,-cragc of how to idc:nti.f)• and document u.sc cases.
Lannan, Craig. AJ)J)lytng UAIL and Patterns, Upper Saddle
River, NJ: Prentice Hall, 1998. This book providc:s a cobl·
prchcnsh-c- o,tn•tC'u• of a use-case modelin@ process.
Strategio Enterpri se Plan
~
-
-
Strategi c tifonnation S,stems Plan
M l'Nt
f'flOCESSES
STATEMENT OF WORK
P R0 8t.E II S TATEIIENT
-~
.....
.....•
<••••• ••• Pl EC ES h • • •wo, a )
SYSTEII I IIPRO\IEIIENT 08JECTI VES ( • •l• t
~
E
~
II
'•=
1
I
I
t
~
ii
•
)
r
I
!
I
~
-
---....
........ ••
.........
,....,.....,.
..........
_..
......
..
.........
1111•
.,,.........
8USDl£881;8VSTEII
( Of
......
.,,...........
REQ U EST FOR SYSTEM PROP08A t. S )
...........
..,,........
.....
..
•
US&t I; SYSTEM
sa:TWAIIE OEaaM
Sf'IECIFO.'KlfS
F U NCTI ONAt. SYSTEM
SwmcN
•
I
r
.I
I
,
I
I
I
Ii
..
,
A
l •
ii •
I
I
I a.
;
I
lh I
I !
"
Sf'IECIFCATM:lfS
I
i•
I
-
!
~
ii•
TRAI NI NG MATERI A L S
:
~
I
r
OESI ON f'ROlOTYf'ES
l!IOSIIESB MX:€88
I
•
•
~
I
---
~
RECA.lfl:IIENTS
......
; ................
..........
.......
..
......
.......
.
........
'
- .............
..........
..........
........
;
I ...........
'
•
A
APf' t.l CATI ON ARC HITECT U RE
5
I
PI ECES ,, • • • • o , a )
..........
,....,...
SYSTEM PROP08At.
~
CClilM'I.MCATION!I
O U O IM COO ftCG Ul tlCMC H TO OTATCMC H T
' I
•
•
.....
.....•
....
CT]
WOMIATION
A
I
I
.............,
CUST'Clit8A T
~
Of'E RAT I ONA t. SYSTEII
..,.......
.......
......,,.,..
.......
..,.
.......
......,,.,..
f'OS T · A U OI T REVI EW
Strate"c Enterpri se tlfonnation Teeflnology AJdli tecklre
"
I
!
ii
A
I •I
~
1U
-
Data Modeling
and Analysis
Chapter Preview and Objectives
In this chapter you will learn how to use a popular data-modeling tool, entity relationship
diag,ams, to document the data that n1ust be captured at1d stored by a system, independently of showing how that data is or will be nsed- that is, independently of specific
inpu5, outputs, and processing. You will also learn about a data analysis technique called
nomJOliwtion that is used to ensure that a data model is a "good" data model. You will
knO\\' data modeling and data analysis as systems analysis tools and techniques when
you can:
I Define systems modeling and differentiate between logical and physical system
mxlels.
I Define data modeling and explain its benefits.
I Recognize and understand the basic concepts and constructs of a data mcxiel .
I Read and interpret an entity relationship data model.
I Explain when data models are constructed during a p<tject and where the models are
stored.
I CX.scovereotities and relationships.
I Construct an entity relationship context diagram..
I CX.scover or invent keys for entities and construct a key-based diagram .
I Construct a fully attributed entity relationship diagram and describe all data structures
and attrib.ltes to the repository or encyclopedia
I Normalize a logical data model to remove impurities that can make a database
unstable, inflexible, and nonscalable.
I De.scribe a useful tool for mapping data requirements to b.lsiness operating locations.
270
Part 1wo
Systoms Anclysls Methods
As the SoundStage ,_,ember Ser,Jces system project moves from requirements analysis Into logical design, the first ttsk according to their methodology is to analyze the
data requlrements for the new system. Bob ,_lartlnez remembers a favorite professor
h1 college who always sald, •Get the data right and the system will he able to ele11,,ntly
support all your present requJren1ents and evett requirements users don't yet envision~ get the data wrong and it wUI be a paJn lo the neck to meet requirements roday,
tomottow, and forever."
Bob enjoyed his database classes In college and always dld well In them. Of
course, the member servlces system is larger and more detailed than any data project
he did In school. Fortunately, he has the database from the pre>ious version of the sys.
tern to start wfth, plus forms and reports ftonl the pre\oiOllS system, plus notes from
user lntervJews, plus use-case narratives created durlng the requirements aru.lysis
phase. Sandra has asked Bob to take the first shot at p,tlllng It all together Into a logical data model. He's determined to impress her.
~~~\N
~ h_a_t_ls__
D_a_ta~ M
_o_d_e_l_in_g_?~~~~~~~~~~~~~~~~)
daoa modeling a techrique
fa- orgaiilirg M d document·
i'lg a system's data. Some·
tines caled d-ataba.se
modeling.
Systems models pfay an Important role In systems development. 11lis d1aptet wlll
present data modelliig as a tech.nlque for defining busines., requirements for a database. Data modeling is sometimes called database 1nodeling because a data model is
eventually implemented as a database.
Figure 8-1 Is an example of a simple data model called an entity relatlonsbrp
df.agran1, or ERD. This diagram makes the following business assertions:
\X'e need to store. data about
CUSTOMERS, ORDllS,
and
INVENTORY PRODUCTS.
The value of cuSTOMEt NUMBm uniguelv ldentlfles one and only one CUSTO!dER..
The value of ORDER NUMBER unique.Iv identifies one and only one ORDER, The.
value of PRODUCT NUMBllt unlquelv ldentifles one and only one INVENTORY
PRooucr.
Fo r a CUSTOMER '\\'e need to know the CUSTOMER. NAME, stUPPlNG ADDR..E'SS, BCUJNG
ADDRESS, and BAL\NCE DlfE. for an ORDER we need to know ORDER DATE and
ORDER TOTAL COST.
For an
PRODUCT UNIT Of MEASURE,
FIGURE 8 - 1
An Entity
Relationship Data
Model
INVENTORY PRODUCT
CN','E'(J'()RY PRODUCJ'
and
we need to know
PRODUCJ' UNJT PIUCE.
PRODUCT NAME,
Data Modollng and Analysis
dlaptw Eight
271
has placed zero, one, or more ctirrenr or recent ORDERS.
Alt ORDf.R is pL1ced by exactly one CUSTOMER. The value of cusTOMm NUMBf.R (as
A CUSTOMER
recorded In ORDER) Jdet1tifies that CUSTOMER.
sold one or more ORDf.RED PRODUCTS. Thus, an
Alt ORDf.R
least one
ORDf.R
must contaitt at
ORDER.fl) PRODUCT.
Alt CN\'E'ltl"ORY PRooucr may have been sold as zero, one, or more OllDERfD
PRODUCTS,
All ORDfllED PRODUCT idet1tifies a sfr1gle INVENTOR'( PRODUCT on a single ORDf.R.
The
(for an ORDfllED PRODUC'J') ldentltles the ORDER, and the
(for an ORDfllED PRODUCT) ldentlfles the INVENTORY PRODUCT.
Together, they identify one and only one ORDf.R!D PRODUCT.
ORDER NUMBER
PROD-
UCT NUMBf.R
for eadt
ORDfllED PRODUCT
we need to know
QG\NTITY ORDER.fl)
and UNfT PRICE
JJ TIME Of O RDER.
After you study this chapter, you will be able to read data models and construct them.
( System Concepts for Data Modeling
'fhere are several notauons for data modelu1g. 'the acntal model ts frequently called an
entlly relatlonsWp diagram (ERD) because It de('lcts data In terms of the entitles
and relatlonsh.ips descrlbed by the data. There are several notations for F.RDs. lttost are
named after their invetllor (e.g., am1, Martlll, Bachman, Merlse) or after a published
standard (e.g., IDEFJX). These data modeUng•tanguages• generally support the same
funclunental concepts and constructs. We have adopted the ,_lartfn Qnformatlon
engineering) notatio11 because of its widespread use and CASE tool support.
let's explore some basJc concepts that underlie ill data models.
entity relatiotlsb..ip
diagram ( EIW) a dala
modeluti2fngseveral nolab'ls
t> depict dala i"I terms of
the entities aid relationsh.,s
desaibed by !hat data.
> Entities
All Sj'stems contain data- usually lots of data! Data describes "things." Consider a
school ~·stem. A school system indudes data t11..1t dtscribes things such as snromrs,
TEACHERS,COURSES, and CLASSROOMS. For any of d1ese thlng.1, lt is not diffiC'ltlt to imagine
some of the data tl1..1t descrlbes any gtven Instance of the thing. For ex.ample, the data
tl1..1t describes a pardctdar student might lndude NA...t,IE,ADDR.ESS, PHONE NU\.iBER, DATE Of
BtR'Jli, GENDER, RACE, MAJOR, and GR.A.DE POINT AVERAGE, to name a few.
We need a concept to abstractly represent all htstances of a group of slmJlar
thin~. We call this concept an entlry. An entity Is somethin,a about which the business needs to store data. In system modeling, we find ft useful to assign each abstract concept to a shape. In this book, an entlry will be drawn as a rectangle with
rounded corners (see margin). Tilis shape represents all instances of tl1e 11amed
entlt)'. For example, the entity STUDENT represents all students In the system. TI1us,
an entity identlfles spedJlc classes of entitles and Is distinguishable from the other
entitles.
Categories of et1tltles (and examples) Include:
Persons:
AGENCY, CONTRACTOR,CUSTOMER,OEPAR'fME'llr, DMSION, EMPLOYEE,
INSTRucroR,snro~ SUPPUER. Notice d1..1t a person entity class can
represent ind.JvJduals, groups, or org.ut.izatlons.
Places:
Objects:
entity a dass of persons.
i:,aoes, objeC"S, evens, a
ocnceptsabout M'lic:h we
need t> caplJre aid stcre
data.
SALES REGION, BUILDING, ROOM, BRANCH Of'FICE, CAMPUS,
BOOK, MACHINE, PART, PRODUC'I;, RAW MAt'aUA.1., S0fTW,\R£ LICllllSE, SOFTWARE
PACKAGE,TOOL, VDilCI.£ MODEL, VEHICLE.•\n object entity can represent
actual objects (sud, as a speciflc software license) or spedllcatlons
for a type of object (sud, as specllkatlons for dlfferent software
packages).
Events:
APPUCATION,AWARD, CANCEU.ATION, CLASS, PLIGHT, INVOICE, ORDER,
Concepts:
ACCOUN'J;. BLOCK OflTIME, BOND, COURSE, fUND, QUAUfllCATION, STOCK.
REGISTRATION, RENEWAL, REQUISITION, R&RVATION, SA.I.£,TRJP.
An E.nllty
272
Part 1wo
Systoms Analysis Methods
It ls important to distingti sh between an entity and Its inSlances. An etttlty
entity i.osta.OCe a s.'gle
occurence of an entity.
b1Staoce is a single occurret1ce of an et1tlty. For example, the entity STUDENT may ba,-e
multiple Instances: Mary, Joe, ~brk, Susan, Chery~ and so forti1. In data modeling, we
do not concent ourselves with lndtvidual students because we recognize that each
student Is described by slmllar pieces of data.
>
attribute a atsat,iw
property a c:h.wacteristie of
an entity. Syncnyms i'd.Jde
olomM! propiNfY, and fold.
Attributes
If an entity ls something about wtlich we want to store data, then we need to Identify
what specific pieces of dam we want to store about ead1 instance of a gtven entity. We
call these pieces of data attributes. As noted at the beglnnlng of tills section, each to.
stance of the entity STUDENT might be described by the following attributes: NA.'°',
ADDRESS, PHONE NU-.mER, DATE Ofl Jm'Jli, GIN)~. RJ£E, MAJOR, GR.A.DE POINT AVflV.GE, and others.
\X'e can now extend our graphical abstraction of the entity to lndude attributes by
recording those attributes Inside the et1tity shape along with the name (see margin).
Some attributes can be logically grouped Into superattrlbutes called compo,utd
attributes. For ex.ampJe, a student's NA...\ffi ls actually a compound attrlbure that consists of LAST NA...\iE, flCRST NA...\iE, and MIDDLE INtTlAL. In the margin, we demonstrate one
po:s:si!Jlt' uulatiuu fur c.:u1upvunU att.riliutc-.:,, Nolh.:~ l11al <l pt'riOU b pl;u:t'O <ll llu~
beginning of each prlmltlve attribute that Is lnduded In the composite attribute.
Domains When analyzing a S,'Stem, we sholdd define those values for an attribute
thar are Jegltimate or thar make business sense.The "-alues for each attribute are de-
Atult1Jte8 and
Compound AnrlbUtea
compouod 2.ttribute
fined In terms of three properties: data type, domain, and defa,dt.
The data type for an attribute defines what type of data can be stored In tllat attrlbute. Data typing should be iamlllar ro those of you who have wrlttetl computer
programs; dedarlng types for variables is commo11 ro most programming languages.
For purposes of systems ai1..1lysJ:s and busfr1ess requirements definition, ft ls useful ro
declare logical (nontedmlcal) data types for business attributes. For the sake of argt•
met1t, we will use the logical data types shown In Table S. I.
An attrlbure's data type con.,-uains its domain.111e domalo of an attribute defines
what values the attribute can Jegltim.ateJy take 011. Eventually, system designers must
use tedmoJogy to enforce the business domains of all anrlbures. T.'lble 8-2 demonstrates how logical domains mlght be expressed for each data type.
M
allribule that consists of other
allribules. Syncnyms i"I ciffer·
TA a LE
ent data modeing languages
are nl.fflerous: concat9f'lat9d
atribus, compos#e attibut9,
and CMta stuctur9.
Logicol Data Type
a· 1
Nl.MBER
lEJ(T
data type a properiy of an
allribule that identifies What
type of data ca, be stored i"I
MEMO
the attribute.
l);.JE
domain a prq:,erty of M
allribule that oefines What
values the attribute can
legiimatety late en.
TI/,E
>ES/NO
VALUE SET
Representgtive 1.ogicgl Ogtg Types for Attributes
Logical lu1ines1 Meaning
Any l'll.lfflber, real or integer.
A string of characters, inclu$ive of nlN'l'lbers. When number$ are
indudocl in a lEJ(T attribulo, it moans wt> do nol o,q,ect lo peri:,m,
arithmttic or comparisons with tho$e numbers.
SOO'le as 1EXT but of an indeterminate $ize. Some busine$S
n,quiro lho ability to attach p-.tially lengthy nolos o
a given dalabaw rooord.
Arry 0018 in any format.
Arry timo in any format.
An attribul<> that can aswmo only ono ol lho,o two Y<Jlu...
A finito sol ol valuo,. In mo,t ooso,, a cooing sch.mo would be
ostobli,hed (o.g., FR = fr.. lvnan, so = ,ophomore, JR = junior,
SR = senior, etc.),
Any pi:ture or image.
,ystom,
Data Modollng and Analysis
dlaptw Eight
273
,. TABLE 8 - 2 Representative logical Domains for Logical
Data Types
O..ta Type
N""'WI
Domain
For integers, ,pecily the range:
Examples
{10-99}
{minimoo,-maximum}
For real numbers, specily the range and proci~on: {1.000- 799.999}
{miniml.NT'l.preci$1on-moximl.N'n,preci$1on}
1EXT
1EXT (maximum ~ze of attribu19)
Actllal valuo, ore uwolfy irlinil&; how..vo,; "" "'
may specify catoin narrative restriction,.
TEXT (30)
MfJNO
Not opplicobls. Th9reon, no logical n,stri..-ion,
on siz e or comrnt.
Not applicable.
Variation on the 1'NAOOY'YYY form at, To
MMOOYl'YY
O..TE
oc:commodote the yeor
abbrevial<> }'90 r lo VY.
TIME
2000, do not
Formatting charac19r, are rarely slored;
there/ore, do nol include hyphen, or sloshes.
MMYl'YY
\'YYY
For IWI/ FM time,:
or
For military time$:
HHMMT
HHMMT
HHMM
HHMM
>ES/ NO
{YES, NO}
{YES, NO} {ON, Off}
\:ALUE SET
{value#l, value#2, ... value#n}
or
{toble of codes and meanings}
{FRESHMAN, sa>HOMORE, JUNIOR, SENIOR}
{FR = FRESHMAN
SO = SOPHC\l,OORE
.R = JUNIOR
SR = SENOlt}
....a
Not opplicobls; how..vo,; any known
choroctaislic, of the images will eventoolly
prove useful lo doot,119rs.
Not applicable.
"
Finally, every anrlbure should have a logical d efault value thar represents the
value of an attribute If its value ls not specified by the user.T.,ble S.3 shows possible
default "-alues for an anrlbure. Notice thar NOT NUU ls a way ro specify that each
inSlance of the anrlbure must haE. a "-alue, wh.lle NtLL ls a way ro spedfy that some
instances of the attrlbure may be optional, or not have a value .
Identification An entity h ..,s many lnstanc es, perhaps thousands or millions. There
exists a need to uniquely identify ead1 lnstance based on the data value of one or
more attrlbutes.111us, every entity must ha,--e a key. for example, each it1Stance of the
e ntity sruoENr might be uniquely lde11tlfled by the key sruoENr NUMBER attrlbme . No
two students can have the same sruol:NT NU\.iBER.
Sometimes more than one anrlbute ls required to uniquely identify an lnstance of
an entity. A key consisting of a group of attributes ls called a concatenated key. For
example, ead1 DVD entity instance In a >ideo store might be uniquely ldentlfted by the
default value the wlle that
~ be reocrdedif a value is
notspeciSed by the user.
key M altib.Jte, o r a grol.l)
of attributes, that assunes a
uiique valJe tu each entity
i'lstance. ft is sanetmes
caled an id9rtif:9r.
coocateo.ated key a gol.l)
of attibutes that u,~ety ttentiSesan i'lstaice of an entity.
Synonyms inclJde compost•
lrsyand rxmpoondkr,y.
274
Part 1wo
Systoms Analysis Methods
TA a LE 8 - 3 Permissible Default Values for Attributes
Default Value
Interpretation
voos
For an instanoa of the attribute, if
he user does not specify a value,
hen use thi1 value.
For an instanoa of the attribute, if
he user does not specify a value,
hen IOCM1 it blank.
For an instanoa of the attribute,
"'quires lhat ,tu, user enter a legal
volue from the domain. [This is used
when no value in the domain is
common enough lo boa delault
but some "'1iue must bo enl9red.)
from ,tu,
domcrin (m d..aibed
A lsgal
obovs/
NONE or NUll
REQUIRED or NOT NUll
concarenauon of
Trrt.£ NUMBf.R plus COPY NUMBf.R. ' I'm.£ NUMBf.R by
Examples
0
1.00
FR
NOI-E
NlA.L
REQUIRE:)
NOT NJ!
ttself would be tnad-
equate because the store may own many copies of a single title. Copy NUMBER by itself
would also be h1adequate since we presumably have a copy # I for every tlde we ow11.
We need both piec es of data to ide11tlfy a spec lflc tape (e.g., copy #7 of Star Wars:
Reve11ge of the Sith). In this book, we will give a name to the group as weU as tl1e
fr1dl:vidual attrlbutes. For example, the concatenated key for ovo would be recorded as
follows:
°"" ID
.nTLENUMBF.».
.COPY NUMBER
Frequent.I)•, an entity may ha,1! more tlun one key. For ex.ample, the entity E.\IIPLOYEE
may be uniquely Identified by !OC!AL Sf.ClllUTY NU'1llDI, or company4.ssigned
NU\IIBf.R, or &MAIL ADDRESS. Each of these attributes is called a c.a11dtdate ~ A caodld..1.te
key Is a •candldate to become the primary key" of instances of an ei1tlty. It ls sometimes
called a ca1ulfdate fde11..tlft.er. (A candklate key may be a single attrlbute or a concatenated key.) A prim.-u-y key Is that candidate key that will most commonly be used to
uniquely identify a single entity Instance. The defat~t for a primary ker is always Nor
NUU because lf the key has no "-ih1e, it cannot serve lts p urpose to Identify an l.n.&ance
of an entity. Any candidate key that Is not selected to become the primary key Is called
an alternate key. A common eynonym ls secondary key. ln the margh1, we demonstrate our notation for primary and alternate keys. All candidate keys must be either
primary or alternate~therefore, we do not use a separate notation for candidate keys. All
attributes that are not part of the primary key are called nonkey attributes.
Sometimes, it is also necessuy to identify a subset of an entity's lnstances as opposed to a single Instance. For example, we may require a simple way to identify all male
students and all female srudents.Asubsetthig criteria is an attribute (or concatenated
attrlbute) whose flnlte values dJ1iide all entity lnstances loto useful subsets. This ls !ometlmes referred to as an In.v ersion e,1-try In our STUDENT entity, the attrlbute G&l'Df.».
dh-ides the h1Stances of sruomr into two subsets: male srudet1ts and female studenrs.
In general, subsettlng criteria are useful only when an attrlbute has a B..nite (meullng
..lhnitedj number of legitimate mlues. For ex.ample, GRADE POCNT AV'flV.GEwould not be a
good subsetting criteria because there are 999 possible values between 0.00 and 4.00
for that attrlbute. The margin art demonstrates a notation for subsettlog crfterla.
1
caodidate key one of a
nLmber of lt:tys that may
serve as the pli'nary key of an
entity. Also called canddate
identifier.
ptima,y key a CMcldale
key that WI rmstcommorfy
be used to uri=l!Jety ideni fy a
s.'l~e entity irstaice.
alter-oate key a cancidate
key that is not selected to
become !he pm,ary key. A
syncn)ffl is S9COflda.ry kQf.
su bsettiog criteria
M
allribule(s) W'lose irite values
dMde entity irstaices i'lt>
subses. Scmetmes ca.led
in~rsion ertry.
>
=•
Relationships
Conceptually, entitles and attrlbutes do nor exist in isoL1tio11. The things they represent interact with and impact one another to support the business mission. TI1us, we
Data Modollng and Analysis
dlaptw Eight
27S
introduce the concept of a relatlonshJp. A relationship is a natural business association that ex.lsts between one or more entitles. The reL'ltlonshJp may represent an e,--enr
t11..1r links the entities or merely a logical a.fflnlty thar exists between the entitles. ConsJder. for example, the entitles STUDENT and CURRlCUUl\.l. We can make the following
business assertions that link students and courses:
• A
•
current snromr ,s FNJOI JFD IN one or more
A CUllRlCULUM IS BECNG STUDIID BY
CURRJCUL\.
zero, one, or more
STUDENTS.
The underlined verb phrases define bush1ess relationships tl1at exist between the
two entities.
We can graph.ically illustrate tllls assodatlon between STUDENT and cuarucUWM as
shown In Figure 8-2. The connecting line represents a relatlonshJp. Vetb phrases describe tl1e refatlonshlp. Notice that all relationships are lmpllcltly bidirectional, mea,~
Ing they can be Interpreted In both directions (as suggested by the above business
assertions). Data modeling methods may dllfer in their namlng of reL1tlonshlps- some
Include botl1 verb phrases, and otl,ers include a single verb phrase.
Cardinality Agure S.2 also shows the complexity or degree of eacll relationship. For
example, if we know how to read it, Figure 8-2 cnn answer the followlng questions;
?.lust there ex.1st an lnstance of STUDENT for each it1Stance of cuarucUWM? Nol
blust there ex.1st an lnstance of CUJlRlCULU\.t for each lnstance of STUOEN'J'? Yes!
How many instances of CUR.RICUUl\.t can exist for each hmance of sruomt? ,_lany!
How many Instances of STUDENT can exist for etch lnstance of OJRRJCUUl\.t.?
Many!
We call this concept card/11.alf.ty. Carclloallty defines the mJnlmum and maximum
number of occurrences of one entity t11at may be related to a single occurrence of
the other entity. Because all relatlonsh..lps are bJd..lrectlonal, cardinality must be defined h1 both dlrectlons for every relationship. A pop,tlar graphical notatlon for cardinality is shown in Figure 8-3. Sample cardinality symbols were demonstrated In
Figure S.2.
Conceptually, cardinality tells us the following rules about the data e11tities shown
In Figure S.2:
Ke.,. and 9J baet.11 ng
Crltetfa
relationship a natural b.Jsiness association between one
a
more entities.
cardinality tte minim.Jm
M d maXim.Jm rumber of
occurrences of c:ne entity that
may be related IO a M~e
occurrence of tie otler enity.
When we insert a STUDENT instance In the database, we must Unk (associate)
th.at sruol:NT to at least one instance of cuwcmUM. In business terms, «a student cannot be admitted without declaring a major.· (Most scl1ools wottld
Include an inslance of CUllRlCULUM called "tmdeclded" or «undeclared.")
A sruoENT can study more tl1..1n one CURRJCULUM, and we must be able to store
data that indicates all CURJUCULA for a gtven snma,,rr.
We musr insert a cuwcutUM before we can litll: (associate) sruol:NTS to that
CURRJCUWM. TI1..1t is why a CURJUCUWM can h.ave zero students- no students
have yet been admitted to tl1..1t CURJUCUWM.
Once a CURRJCULUM h.as been inserted Into tl1e database, we cut link (associate) many sruomrs with that CUJlRJCULUM.
Degree Another measure of the complexlty of a data relationship is Its degree. Toe
degree of a reL1tlonshlp is the number of entitles !11.11 partlclpate In the relationship.
All the relationshlps we·ve explored so far are binary (degree
2). In other words,
two differe11t entitles participated In the relatlonslllp.
=
degree the nunber of
entities that p.w~ate i'I a
relationsh.,.
r FIGURE 8-2 '
A Relationship
'- (Many-to-Many)
276
Part 1wo
Systoms Analysis Methods
FIGURE 8 - 3
Cardinality
Notations
CARDINALITY
INTERPRET ATIOt
.........
INSTANCES
IIA,a-
GRAPMC
lNSTANCES
Nor Ano.
Ex.acuy one
(one and o,uy one)
-« -
0
21:!roorone
many(>1)
One or more
21:!ro,one,,ormcre
More than one
0
many(>1)
>1
>1
1_1
1
i'lstMcesof tM sane entity.
Relationshlps may also exist between dllferent Instances of d,e same entit)'. ~e call
thls a recursive relatlonsWp (degree I). For example, In your school a course may
be a prerequisite for other cotmes. Slm1L1rly, a course may have se,. eraJ
.
other courses
as Its prerequlslte. Figure 84 demonstr.1tes thls many-to.many recursive relationshlp.
RelatlonshJps can also exisl between more than two different entitles. The.se are
sometimes called N-ary relationships. An example of a J-ar)~ or ter,,ary: relatto·RSbf.p
associative tntity
is shown In Agure 8-5. An 1V-.1ry relationship ls IUustrated wJth a new entity conru-uct
called an associative eutit)i An associative entity is an entity that Inherits its
primary key from more ti1an one other et1tity (called parents). Each part of tha1 coo-
recursiVe reJatiooship a
relatm~., tlat e>fst:s b:ttMen
M
enity
that irtlerils il! ptmary key
from more than one other
enlily.
=
carenated key points to one and only one itutance of each of the connecting entitles.
In Figure 8-5 the as.,odatlve entity ASSIGNMENT (notice the wlique shape) matches
an EMPLOYEE, a J.OCAnoN, and a PROJ-f.CT. For ead1 inSlance of ASstGN.~ the key
' FIGURE 8 - 4 '
.
..
A Recursive
'-
18 a prere(J.lla.lte tor
Relationship
h as as a prerequla.lte
Data Modollng and Analysts
...
277
Chaptor Eight
FIGURE 8·5
--
A Ternary
Relationship
requires
la given
offers
indkates wbidt E.\.'IPLOYEE co, which LOCATION NU\.tBER, and whlcb PROJOCT NU\.tBER are
combined to form tl1.1t assignment.
Also as shown ln Ftgure 8-5, an associative entJty can be described by Its own
nonkey attributes. In addition to the primary key, an ASSIGNMENT Is described by the
attributes BEGIN DATE and END DATE. If you thlnk about it, none of these attributes
describes an EMPLOYEE, LOCATION, or PROJOCT- they descrjbe a single lnstance of the
relationshJp between an instance of each of those entitles.
foreign Keys A relationship Implies that instanc es of one et1tlty are related to Instances of another entity. lX'e should be able to identify those instances for any gt,--en
entity. 11,e ability to identlfy specilk refated entity instances hwolves establishing
forelgu keys. A foreign key Is a primary key of one entity that is contributed to
(duplicated In) another entity to ldentlfy instances of a relationshlp. A foreign key
(alw,ys In a child entity) always matd,es the primuy key (hl a parent entity). In
fjgure 8-6(.a), we demonstrate the concept of foreign keys with our simple data
model. Notice that the maximum cardJ.nallt:y for DD'ARf?JE\IT is"one," whereas the maximum cardinality for CUJUUCUWM is "many." In tllis case, DEPARTMENT ls called the parent
entity and CURRJCUWM Is the child entity. The primary key Is always contributed by the
parent to the child as a foreign key. Thus, an Instance of CURRICUWM now has a forefgn
key DEPAR.TME'tl' NA...>,.iE whose 1t"'alue polnts to the lnsta11ce of DEPAR'l'ME'n' that offers that
currk.."ulum. (ForeJgit keys are never contributed from child to parent.)
foreign key a prmary key
of a, M i ty that is used rl
mother entity t> identify
rlstancesof a relationship.
child e-otity a dala m i ty
that derives one or rroe attributes from aiother entity,
c.aled the pa-art. In a one·tomany relationshi) the c:hld is
the entity on Ile "many" side.
pareot eotiry a data entity
lhatcontributesone a more
attributes to another entity,
c.aledlhe d'll d.ln a one-kl·
many relationshi) the parent
is the entity on he "one" side.
278
Part 1wo
Systoms Analysis Methods
(a)
PARENT
ENTITY
t
( MAXlMUMCAAOINAU1Y • 1)
(MA»MUM CAAOtNAUTY • MANY)
CHILD
ENTITY
"!"'!........
..------,~,1~i
"1 li i i i::~·• a,
1111• cl I I•·
(b)
contaJna
••
...
IOC8ted
In
G
GURE 8 - 6
ForeignKeys
nooidemiJ\,tilg
relationshiJi a refationsh.,
i'I wtich each p.w~tirg
entity has is <1N1l i"ldependent
prim.wykey.
------~)
In our example, the relationship between CUJlRICUWM and DEPARTMfNT is referred
to as a nonldentl.fytng relationship. Nonldeutlfylug relatlousWp.s are tha,e In
wbid1 each of the partldpatlt11 entitles has its own lodepe11de11t primary key. In
other words, none of the prlmary-key attributes is shared. The entitles CU1lRICULU'1 and
DEPARTMEW are also referred to as stro11g or Independent entitles because neither depends 011 any other etttlty for Its identlllcatlon. Sometimes, however, a forelgn key may
partldpate as part of the primary key of the child et1tlty. For example,ln Figure 86(b)
the parent entity BUILDCNG contrlbures its key to the entity ROOM. Thus, BUILDCNG NAME
serves as a foreign key ro reL1t e a ROOM and BUILDING and in conjtmctlon with RO:>M co
Data Modollng and Analysis
AEU110HSHIP
279
STRONG
STRONG
ENTITY
ENTITY
, FIGURE 8 · 7 '
FLIGHT
No tations for Weak
Entity and
No nidentiiying
,_ Relationship
PASSENGER
P•Nf'191J'IO CPm.ry Key)
PMNf'l9(r-Narne
(odw lll.. lbut• of PASSEWGER)
NON II! NnFYING
dlaptw Eight
rlght-~W(PM'llry Key)
right· Dflle·Of·Oe perture
~ett'lbut• of FLIGHT)
ID!NnFYING
1
AEUTlOHSttP
.....
.. •
I
l ....
i
WEAK
ENTITY
to unlquely Identify a given Instance of ROOM. In tho,e situations ti1e relationship between the parent entity and the dilld entity ls referred to as an lde11..tlfyl11g relatto1~
ship. Ide ntifying refatlonsWps are those In whlch the parent entity contributes Its
prltmry key to becom e part of ti1e primary key of the child et1tlty.The dilld entity of
any Identifying relationship is frequently referred to as a weak e11tr.ty because lts ldet~
tificati.011 ls dependent on the parent entity's ex.lstence.
btost popular CASE tools and data modeling methods use different notations to
distinguish between ldentlfylng and nonldet1t!fying relationships and between strong
and weak e ntitles. In Figure 8-7, we use a dashed lt11e notation to represent the non-
identifyuig rdat ionsllip
a relaioosl,.:, i'I W'lich the
parent entity's key is also part
of the prinwy Illy o f tie c:hld
entity.
identJfying relationship between PAS ~f.R and s&.T A$1GN.\.W'llr. Because part of the prJ..
mary k ey of SEAT ASSIGNMENT is the foreign key FUGHr NUMBf.R from the parent e n rtty
ruGHr, the relationship is an ldet1tlfylng relationshlp an d Is represented using a solid
lt11e. Finally, sear assignment ls a weak enrJty because It receJ,--es the primary key of
flight to compose Its own primary key. A weak entity Is represented using a symbol
composed of a rou.,ided rectangle t1Jltbl11 a rou.,uk?<} rectangle.
NOTE: To reinforce the above concepts of Identifying and nonldet1tifying relatlonshJps an d stro11g versus weak entitles and to be consistent with most popular
data modeling methods and most widely used CASE tools, the authors use the
abo,--e modeling notations on all subsequent dau modeling examples presented
In the book.
W11at lf you cannot differentiate between pare11t an d child? For exampJe, In
FJgure 8-S(a) on page 280 we see that a CURRICULUM enrolls zero, one,or more sruofNTS.
Ar the same time, we see thar a sruomr is enrolled in one or more CURRICULA. The maximum cardinality on both sides Is •many.• So, which Is the parent an d whld1 is the child?
You can't tell! 11lis Is called a 11011specijlc re/aN011ship. A n on specific relaUonshlp
(or many-1~111a11y relaff-01,sbtp) ls one lo which many Instances of one entity are
associated with many Instances of another entity. Such relationshlps are sultable only
for preliminary data models and should be resolved as quickly as possible.
o oospecific relatioosbip
a relaioo~ W'lere mr.'tj
i'ls1ancesof M entity .we
associated 'Mth mcW'ly i'I·
stMces of Mother entity.
Nso called tn817f-lo.many
rolationship.
280
Part 1wo
Systoms Anclysls Methods
(a)
Many..to..Many Relationship
........................
.... ........ .... .. ... .-··
.-·..... ......... .
-··
~
,,...·
,..'
,,
,,
,'
'' ,
!'
re placed by
''
''
.
.:''.
..'.
.'
•.
.•
I
(b)
'
declared
......
...
...
.'.
'\
...
replaced by
..
..
..
.....
.•.•
\
~
'
haa
"
FIGURE 8 • 8
•
t .• .
Resolving Nonspecific Relationships with an Associative Entity
Many nonspeclJk relationshlps can be resolved Into a pair of one-to-many relat!onshlps. As Illustrated !11 Figure 8-S(b), each entity becomes a parent. A new, assoc!"'
tlve e11t11y ts Introduced as the dilld of each parent. In Figure 8-S(b), each Instance of
MAJOR represents one STUDENT'S enrollment ln one CUliUUCUlll\.t.. If a student is pursuing
two majors, that student wUJ h..1,;e two lnst:ances of the entity MAJOR.
Stt1dy Figure 8-B(b) carefltl~f. For associative et1tit!es, t!1e card!nalJty from d1ild to
parent ls always one and o nlv one. That makes sense because an instance of MAJOR.
must correspond to one and only one sruomr and one and only one CUR.RICULU\t. The
card!nallty from parent to child depends 011 t!1e business rule. In our example, a
STUDENT must dedare o ne or more MAJORS. Conversely, a CURRlOIWM Is being studied by
zero, one, or more MAJOR.5- perllaps it is new and no one has been admJtted to it yet.
An associative entity can also be described by lts own nonkey attributes (such as DATE
a,,moJLEO and CUR.RENT CANOIDAn FOR DEGREE?). Finally, associative entitles inherit the
prlmary keys of the parents; thus, all assoc.L1tt,--e entitles are weak entitles.
Not all noospec-lflc relatlonshlps can and should be automatically resolved as
described above. Occasionally nonspeclJk relat!onshlps res,tlt from the failure of the
analyst to identify the existence of other entities. For example, exantlne the relationship between cusroMER and ••ooucr In Figure 8-9(a). Recognlze that the relationship
Data Modollng and Analysts
(a)
281
Chaptor Eight
Many-lo-Many Relationshi p
....
-.
~
··===!)
:!i:ii!::il:!l•
1:10- - - - -ordera- - - -<
''
relationshi> oometimes suggests other entities. In this
The wro or wro pl,rase of a many-to-many
exarrl)le the many-to-many is resolved by recognizing
that the verb "orders" adually suggests anwont •ntity
cafledORDER that relates CUSTOMERs to
PRODUCTS. Notice that the new many-to-many
relationshi> between ORDER and PRODUCT would
need to be reoolved.
(b)
•
..
p1a...
..
•
• I
• .
(c)
•
j•
• • •
contains
• -
1·
Gan be reso4wd with an associatiw entity.
paces
•-
.........
F I G U RE 8 • 9
I
Resolving Nonspecific Relationships by Recognizing a Fundamental
Business Entity
j•
·•
282
Part 1wo
Systoms Analysis Methods
(a)
Many-to-Many Relationship
BANK ACCOUNT
-
....,,,,., ID (Pm,e,y Key)
etc.
While the above relationship is a many-to-many, the many
on the BANK ACCOUNT ~ide is a knoYAl maximum of
'2". This suggests that Iha relationship may ac:tually
represent multiple relalionshi>s ... in this case l\'oO
$epttrate r8Jation:;~& .
..
.
(b)
t
from
BANK ACCOUNT
Acoold NLwnbet 10 (PITl'lfllY Key)
ts
de
e<c.
to
F I GU R E 8 • 1 0
Resolving Nonspecific Relationships by Recognizing Separate Relationships
Morders~ between CUSTOMER and PRODUCT suggescs an event abouc wtl.ld1 a user mlghc
want to store data.1bat evenr represents an event entity called ORDER depicted in FJg.
u.re 8-9(b). In reality, cusroMn aod PRODUCT do 11o t have a naturaJ and direct rehtlonship as was depicted h1 Figure 8-9(a). Rather, they are related Indirectly, by way of an
oRD,:a. Thus, our many«>-maoy relationship was replaced by separate relationships between CUSTOMER, ORDER, and PRODUCT. Notice that the reL1tlonshlp between ORDfJl and
PRODUCT ls a many-to-many reladonsllip. 111..1t relationship would need to be re.solved
by replacing it with an assodatlve entity and two one-to -m.my reL1tio11sbips, as is
illustrated In Figure 8-9(c).
Finally, some nonspecific relationships can be resolved by lntroduch1g sepante relationships. Notice the many-to-many reL1tlonsllip between TRANSFER and BANK ACCOUNT
show11 in Figure 8-lO(a) . Wh.lle it is true that a TRANSFER transaction ln,--ol"-es many BANK
ACCOUNTS and a BANK ACCOUNT may be lnvoJved in many TRANSf!Ell transactions, we must
be careful! Data modeling notations can sometimes mlsJead us. Technlcally, a single
'fRANSFEll
transaction lnvoJves two
BANK ACCOUNTS.
When we know the sped.fie maxi-
mum number of occurrences of a many-to-many reL1tlonsllip,lt oftett suggests tlut our
original relationship is weak or coo l!l'neral. Notice In Figure 8-JO(b) tbat our rel,tiooshlp "ln,--olves• was replaced b)• two separate one-to-many relationships that more
accurately describe the business reL1tlonsh.ips between a TRANSFER. and BANK ACCOUNTS.
Data Modollng and Analysis
Generali::tation ~tost people as.,odate the concept of generaUz.ation with modern
object-oriented techniques. In reality, the concepts hive been applied by data mode~
ers for m.u1y years. Generalization is an approad1 tbir seeks ro discover and exploit
the commonalitfes between entities. Genera.Uzation is a technlque whereht the
attrlbutes thar are common to several types of an entity are grouped lnro thelr own
enti~·. Consider, for example, a typical school. A school eivolls SWDENl'S and employs
EMPLOYEES (in a universJty, a person could be botl1).111ere are several attrlbures d1ar are
commo11 ro both entitles~for example, NA...\ffi, GENDm, tACE, MARITAL STAl'US, and posslbly
e,-en a key based on SOCIAL sr.cuarrv NUMBER. \X'e could coosoUdate these common attributes Into an ei1tlty supeitype called PERSON. An entity supertype Is an entity
whose instances store attributes thar are common ro one or more et1tlty subtypes.
The entity superrype will have one or more 01:e-to-01ie relationships to entity
su.btjpes. These relatlonshJps are sometimes called ..is a,. relationsh.ips (or "Was a," or
.. could be a") because each lnslance of the supertype "ls alS2 an,. Instance of one or
more subtypes. An et1tlty subtype is an entity whose instances lnherlt some common
attrlbutes from an entity supertype and thet1 add other anrlbutes tl1at are wlique to
an instance of the subtype. In our example, "a PERSON Is an employee, or a student, or
both~11,e top half of Figure S.J i lllustrates this generJUzation O as a hleiarchy. Notice
tlmr dlc subtypes S'l'UOCN'l' and
C.'lil>'L OYOZ
have lohcrltcd attributes f.rom
PCR30N,
as well
as adding their own.
Extending the metaphor, we see that an entity can be both a superrype and a subtype. Retunling to Figure 8-11, we see that a sruomr (which was a subtype of Pms<>N)
b ..,s its own subtypes. In the dL1gram, we see that a STUDENT ls O either a PROSPECT, w: a
ClfRRi!NT snroa,,rr, m: a FOR..\U:ll sruomr (ha"ing left for any reason other than graduation), and O a sruoENr cot~d be an ALUMNUS. These addltlonal subtypes Inherit all the
attrlbutes from STUOl:NT as well as those from PERSON. Finally, notice that all subtypes
are weak entitles.
Through lnherJtance, the concept of get1eraliz.ation in dam models perm.its us to
reduce the number of attrlbutes througl1 the careful sharing of common attributes.
The subtypes not only Inherit the attributes but also the data types, domains, and
defaults of those attributes.111is can greatly enhance the consistet1C)' wlth wtlich we
treat att:rlbutes that apply to many different entities (e.g., dates, names, addresses,
curttnC')', etc.).
In addition to lnhetltlng attributes, subtypes al,o lnhetlt relationships to othet
entities. For it1Stance, all E.\IIPLOYEES and STUDENTS inherit the relationship O between
PERSCN and ADDRESS. But only EMPLOYEES Inherit the relationship 0 with OONTRACrS. And
only an ALUMNUS can be related to O an AWA.llDED DEGREE.
( The Process of Logical Data Modeling
Now that you w1derstaod the bas.le concepts of data models, we can ex.amine the
process of data modeling. When do you do It? How many data models may be drawn?
What technology exists to support the process?
Data modeling may be performed during various types of projects and In multiple
phases of projects. Dara models are progressive~there is no such thing as tl1e .. flnal,.
data model for a business or application. Instead, a dira model should be considered
a Uving document that will change in response to a changing business. Dara models
shot~d Ideally be stored In a repository so that they can be retrieved, expanded,
and edtt:ed over time. Let's ex.am.Joe how data modeUng may come into play during
systems planning and analysis.
>
Strategic Data Modeling
,_lany organizatio11S select application development projects based on strategic h1formation systems plans. Strategic platmlng ls a separate project.11lls project produces
dlaptw Eight
283
geoeralllatioo a ocncept
Wherei"I the attributes that ae
common t> se'll«al types of
M eni ty are grooped i"lto
their OW'I eni ty.
snpenype an enily
""°"'
i"lstancesstore attibutes that
.we common kl one or more
entity subtypes.
subtype an ertity Whose i"I·
stMces may i"lt'erit common
attri butes from its eni ty
~«type.
284
Systoms Anclysls Methods
Part 1wo
·,;
.
.....
CC!UB cted at
ADDRESS
(attribut11s omt8d)
0
0
....... ......... oy·-,0.
...
0
1---<• •
CURRENT STl.DENT
1 - - -laa
could De a
FORMER STUDENT
' - - -la•- -
al attnbutl!s from PERSON Uld STUDENTplua
Ree:aon fo, Wlltch.war
Plan& to Return?
• 11:i•••
CF I GU R E 8 • l l
AGene ralizatio n Hierarchy
)
~~~~~~~~~~~~~~~~~~~~~---
an infonnation $)'stems strategy pL1n that defines an overall "islon and ardlitecrure for
frlformatlon systems. Almost always, this architecture includes an et1.terprlse data
mode£ Information engineering is a methodology that embnces thls approad1.
An enterprise data model tj'plcally ldentlfies only the most fundame ntal of e ntf.
ties.T he e ntitles are typically defined (as In a dictionary), but they are not described
Data Modollng and Analysis
dlaptw Eight
28S
in terms of keys or attrlbutes. The enterprise data model may or may not Include rela-
tionships (depending on the planning methodology's standards and the level of detail
desired by executive mai1..1gement). If relationships tre lnduded, many of them will
be nonspeclflc (a concept introduced earlier in the chapter).
How does an enterprise data model affect subsequent appUcatlons development?
Part of the information strategy plan identifies application development projects and
prioritizes them accord.fog to wl1atever criteria mai1,1gement deems approprL1te. As
those projects are started, the appropriate subsets of the lnfonnatlon systems archltecture, lndudfng a subset of the enterprise data model, are provided to the applications development team as a point of departure.
The enterprise data model ls usually stored in a corporate repository. When the
app!Jcatlon de,.. lopment project is started, the subset of d,e etllerprlse data model (as
well as the other models) is exported from the corporate repository into a project
reposJtory. Once the project team compJetes systems analysis and de.sign, the
expanded and refined data models are Imported bad into the corporate repository.
>
Data Modeling during Systems Analysis
In Sj>leros analysis and In this chapter, we will focus on /ogf.ca/ data modeling as a
part of systems analysis. The data model for a single information $)'stem ls usually
caUe:I an applicatio11 dat..1 model.
Data models are rarely constructed durlng the scope defitl.itlon phase of systems
analysis. The short duration of that phase makes them Impractical. If an enterprise
data model exists, the subset of that model that is applicable to the project might be
retrleved and rel-iewed as part of the phase requirement to establish context.. Alternatlwly, the project ream co,dd identify a simple list of entitles, the things about
whlch team members think the system wiU ha,.. to capture and store data.
Unfortunately, data modellog is rarely assocL11ed with the problem analysis phase
of sy,teros analysis. Some analysts prefer to draw process models (Chapter 9) to document the curret1t ~tern, but many analysts report that data models are far superior
for the following reasons:
application data model
a data model tu a co~ete,
M~ infcrmaic:n system.
Data models help analysts to qulckly identify business vocabulary more com,
pletely than process models.
Data models are almost always built more q<tlcidy than process models.
A complete data model can fit on a slngle sheet of paper. Process models
often require dozens of sheets of paper.
Process modelers frequently and too easily get hung up on unnecessary
detail.
Data models for ex.lstlog and proposed ~tem.s are far more similar than
process models for existing and proposed systems. Consequently, there ls less
work to throw away as you move into later pb1ses.
We agree! A problem analysis phase model includes only etltltles and refatlonshlps,
but no attributes- it is called a context d..1t..1 model 111e lnrent ls to refine our
unckrSlanding of scope, not to get into details about the entitles and business rules.
Many relationships may be nonspeclflc.
Many automated tools provide the ability to read existing system flies and data,
bases and translate them Into •physical" data models. These physical data models can
ti,en be transformed Into their equlvalent • logical" data model. This translation capability benefits both tl,e probletn analysis and the requlremetlls analysis phases.
Toe requlrements analysis results in a logical data model that ls developed in
stages as follows:
I. \Xe begin by constructing the context data model to establish the project
scope. If a context data model was already developed during problem analysis,
tlt.1t
model may be revised to reflect new reqttlrements and project scope.
context data model a
data model tlat i'lc:lJdes
entities and relaliooslips but
no attributes.
286
Part 1wo
key-based data model a
data model that ird.Jdes eni ·
tiesand relati:nsh'36 'Mth
predse c.wcinalities resd\lW'g
noo..specifie rtlationsh.,s into
associatil.e enlitias, aid also
i'lclJdirg prm&,y aid alternate
keys.
fuJJy a ttribu:ed data
m odel a dala model tlat
i'lclJdesal ertitias, attributes,
relai oost..,s, wbselli"lg criteria, M d predse cacinalities.
Systoms Analysis Methods
2 . Next, a key-based dat.1 model wUI be dtawn.11lls model will eliminate mnspedflc reL1tloosh.ips, add :usoclati,. e. entitles, an d lndude prlmary and alternate
keys. Toe key.based model will also Include precise cardlnaJltles and any generaUzatlon hierardlles.
3. Next, a fully attributed data mod el wlU be constructed. 11,e fully attributed
model includes all remainm;! descriptive attributes and subsettlng criteria. Ead1
attribute ls defined h1 the repository with data types, domains, and defaults (hl
what is sometimes caUed a fr,lly desert/Jed data model).
4. 11,e completed data model is analyzed for adaptability and flexibUi ty through
a process called 11ort11a/t.zatf.0·11. The final analyzed model ls referred to as a
11.or,naltzed data niodeL
11lls dara reqttfrements model requires a ream effort thar lncludes systems analysts,
users and managers, and data analysts. A data administrator often sets standards for
and approves all data models.
Ultimate ly, durh1g ti1e decision analysis phase, the data model will be used to
make implementation decisions- the best way to Implement the requirements with
database tedu1ology. In practice, this dedsJon may ha,-e already been standardized as
part of a database ardlltecture. For example, SoundStage has already standardized on
two database m:u1..1gement sys1ems: ~flcrosoft Access for personal and work-@roup
databases, an d ~Ucrosoft SQL Server for et1terprlse databases.
Finally, data models cuutot be constructed without appropriate facts and information as supplied by the user community. These facts can be collected through a
number of techniques such as sun piing of ex.lstlog fonns and flies, research of simlL1r
systems, surveys of users and management, and Interviews of users and m.u1..1gement.
111e fastest method of collecting facts and Information and simultaneously co1utructh1g and verifying ti,e data modtls is joint requhements plamllng. )RP uses a carefully
faclU tated group meeting to coUect the facts, bulld the models, and ,-er lfy the modelsusually In one or two fldl-day sessions. Fact-finding and lnformatlon-gathering techniques were fully explored In Chapter 6. Tobie 84 summarizes some questions
that may be useful for fact-finding and infonnation gathering as It pertains to data
modelh1g.
>
Looking Ahead to Systems Design
During system design, ti1e logical data mo del will be transformed into a physical
data model (called a database scben1a) for the chosen database managemeru: system. This model will reflect the rec hnlcal c:ip:ibilltl es :md limir:itlo ns o f that d:ir:i
base t echnology, as well as the performance tuning requirements suggested b)• the
database administrator. Any fu rrher disctisslon of database design is deferred wttll
Chapter 14.
>
m etadata d2La a bout data.
Automated Tools for Data Modeling
Data models are stored ht a rep) sitory. ht a sense, the data model Is met.ad..1.ta - that
ls, data about the business's data. Computer-alded systems engineering (CASE) tecl,.
nology, introduced in Chapter ; , pro,-ides the repository for storh1g the data model
and its detailed descriptions. Most CASE products suppor t computer-assisted data
modeling and database design. Some CASE p roducts (sud, as Logic Works' ERw/11)
only support data modeling and database design . CASE takes the drudgery out of
dr1lwlng and malntahllng these models and thelr underlying detaUs.
Using a CASE product, you can easily create professional, readable data models
without the use of paper, pend.I, erasers, and templates. The models cu1 be easily
modllled to reflect corrections and changes suggested by end users- you don't have
to start o,-erl Also, most CASE prod ucts pro,-ide powerful analytical tools that can
check your models for mechanical errors, completeness, and consisten(.')'. Some CASE
Data Modollng and Analysis
r TA II LE 8 • 4
JRP and Interview Questions for Data Modeling
Purpose
Ditcover the sy$lem entitie$
Di,covor entity wbselling
ai'Wia
Di'"""' attributoo and
do,T10ins
Ditcover sectN'ity and rontrol
need,
Di,CXMII' data timing needs
Di,"""" generalization
hi,rarchies
Ditcover relationMlips and
deiJ .....
Ditcover cardinalities
Candidate Questions
What are the wbjects olthe bu,ine55f In olher words,
what types ol person,, o,ganizaliOM, argonizotional
unit$, Places, things, rnatarials, or events are used in or
inl<>rad with this sy,19m about which data must be
capured or rnaintoinedf How many in,tanais ol each
subject exi,t!
What ooique charaderisfic (or charac:taristics)
di'1ingui"1"' an in,tanai ol each subject from olher
instanc"' of the ,ome subjd Are there any plans b
change this identifiootian .theme in the futuref
Are there any characl<>risic, ol a subject that divide
all in,tanai, of the ,ubject into u,elul wbseM Are there
any subset, of the above wbject, for which you haw no
convenient way to group instoncesf
What characl<>risfics de!O'ibe each subjd Far each
ol the,e charactwi'1ics, (I) what type of data i, storedf
(2) who is r"'pomible for defining legifimal<> value, for
the dataf (3) what are the legijima1" value, for the dataf
(4) is a value requiredf end (5) i, there any defoult value
that should beaHigned fyou dan' hpecifyolherwisef
Are there orry restrictions on who can see or use the
datof Who is allowed to crea1" the dataf Who is allOW9d
b upda1" the datof Whc is allowl,d to delete the dataf
How ahen doe, the data changef Over what period ol
time i, the dato of value io the bu,i """f Haw bng "1ould
w,i kaep the datof Do ya, need historicx,I dato or trend,f
fa charactwisfic chang<s, must you know the k>nner
value,f
Me all inslonais ol each wbjecl the samef That is,
are there ,pecial types al each subject that are described
or handled diflorentlyf Can any of the dato be
consolidated for sharing!
What avenb occur that imply aHociation, betwl>en
subjed$f What business activities or transactions involve
hcv,clino or chnnoino dotn obout ~OlfQrnl diff.:i.rant
subjed$ of the ,ome or a different typef
Is each busine,, activity or event handed the ,ome way,
or are there special circummncesJ Can an event occur
w~ only some ol the a"ocia1"d subjecb, or must all the
subjed$ be invalvedf
,
prod.1cts can e,--en heJp you analyze the data modeJ for consistency, compJeteness,
and flexlbillty. The potet1tlal time and quality savings are substantial.
As mentioned earlier, some CASE tools support reverse engineering of existing
file and database structures Into dara models. The resulting data models represent
• ph)>lcal" data models that can be revised and reengineered Into a new Ille or
database, or they may be translated Into their equJvalent• [ogical" model. The logical
data model co,dd then be edited and forward et1glneered Into a revised physical data
model, and subsequently a file or database Implementation.
CASE roots do l1ave their limltatlons. Nor all dara modeling conventions are
supported by all CASE products. And different CASE tools adopt slightly different
dlaptw Eight
287
288
Part 1wo
Systoms Anclysls Methods
O et tot "' ffr¥ ~,..;
_,.:flll jjj ~ i'I>@•
to:ilJ
~V>l'V
s,,t-ou YL't><I"" tt!b
li:.l lH!IM .::rJI ~j e,e,
:t r ~ ~ ! O A CJoli3
11
·-
O-···~·······t
.
........
"
........,, ·--
·-
o.i.-nou
''
....'
".,
~
f7
"..
[i
.,. .."' "..' ..
... , ..... ,._.,
St-AroS'o•"
SIU - ~
$1, 0 , ~
$ t o;!I"~
'Jtco'9"1>·~
~
'
11Ei
Si a~~"" Ii GI
$,.....51,....
.:J .:J
,,
"' '
o ~ "I"' "
a " ""''
o....-...-,w..
r,
"
n i::!
I]
~ n
~
n
m,l!oic
di~~ Ill.I)
OI- 1400
di..,,;~ txtl
-- ~,;
Ol111$C'=< ll'I
~ ..
---:-----,
;ii
i
i
i
'
I
I
I
I
I
I
I
I
F I GU R E 8 • 1 2 Screen Capture of Sy.stem Architect CASE Tool
notations for the same data-modeling methods. Therefore, It Is very likely that any
given CASE product may force a company to adapt Its methodology's data-modellng
symbols or approach so that It ls workable within the limitations of tl,e CASE tool.
All the SoundStage cbta models: in tl1e next section of this: ch.1.pter were c-re.1.ted
wjth Popkin ~·stems and Soft\\•are's CASE tool, Systetn Arcbf.tea 2001. For the case.
study, we provide you with the prlntouts exactly as they came off our prlnters. ~ dld
not add color. 1be only modifkatlons by t11e artist were the bullets that call your
attention to speclflc ltems of interest on the printouts. All of the entitles, attrjbutes,
and relatlonshlps on the Sotu1dStage data models were automatically cataloged into
System Arcbltecfs p roject repository (whld1 It calls an encydopedla). Figure 8-12
illustrates some of S:,,•ste111 Arcbftec.t's screens as used for data modeling.
~~~-H_o_vt
~ t_o_C
_o~n_s_tr_u_c_t_D_a_t_a~Nl_o_d_e_l_s~~~~~~~~~~~~~~~)
)'ou now know e11ough about data models to read and interpret them. But as a systems analyst or knowledgeable end user, you must learn how to construct them. We
will use the SoundStage Entertainment Club p roject to teach you how to construct
data models.
NOTE:111ls example teaches you to draw the data model from scratch. In reallty,
you shottld always look for an existing data model. If such models exist, the data
managen-1ent or data administration group usually maintains them. Alter natively,
you could reverse engineer a data model from an existing database.
Data Modollng and Analysis
>
Entity Discovery
The rlrst task h1 data modeling Is relatively easy. You need to discover tl1e fundametl·
tal entitles h1 the system that are or might be described by data. You shot~d not restrict your thJnklng to entitles about which the end users kt1ow they want to store
data.111ere are several techniques that m.1)' be used t •) identify et1tltfes:
During intervJews or JRP sessions wlth ~·stem owners and users, pay attention to key words in their discussion. For example, during an inteniew with
a11 lndtvidual discussing SoundStage's business en'\oironment and activities, a
u.ser may state, "We have to keep track of all our members and their botmd
agree.m e.n ts." Notice that the key words in this statement are MEMB~s and
AGREEMENTS. Both are entitles!
During interviews or JRP sessions, specl.tlcally ask system owners and users
10 identify thlogs abollt wbid1 they would like to capture, store, and produce
Information. Those things often represent et1tites tl1at should be depicted on
1he data model.
Another tedu,Jque for idet1tifying e ntitles Is to study existing forms, Illes, and
reports. Some fonns identify event entitles. Examples indude ORDERS, R.EQUISI·
TIONs, PAYMENTS, oEPOsrrs, and so forth. But most of these same forms also
contain data t11..1t describes other entities. Consider a registration form used
In your school's course enrollment system. A RIGIS'fRATION is ltself an event
entity. Btn tl1e a,-erage registration form also ca.1talns data that descrlbes
other entities, such as snromr (a person), COURSES (which are concepts),
1NSTRucroRS (other persons), ADVISOR (yet anot11« perso11), 01V1S10Ns (another
concept), and so forth. Studying the computerized registration system's computer fl ies, databases, or outputs could also discover these same entitles.
If use-case narratives ha>.. been written duting the reqt~ments analysis phase,
they can be a source of cbta arulbutes and entitles. Scan each use-case narrath,--e
for nolUlS. Every notut ls a potential data attribute or entity. You wlll 11..1,-e to
massage the resltlting list of 110W1S because not ill of dtem will be attributes or
entities. Some wlll be references to users or other information ~ems. Some
will be references to things that are part of dte user lntetface, not data. Some
wlll be synonyms for od1er attributes or entities elsewhere on the list, and you
wo,dd not want to duplicate tl1em. Otapter IO explalns how to do this, taking
an object-oriented approach to buJJd a list of ob;,cts and tl1elr attributes. You
can use a very slmilar approach to discover data entitles an d their arulbutes.
TecbnolOI!)' may also help you Identify entitles. Some CASE tools can re,-erse
engineer existlng Illes and databases Into p hysical data models. The analyst
must usually dean up the rest~tlng model by repL1dng physical names,
codes, and comments witl1 their logical, business.friendly equlvalents.
While these techniques may prove useful in lden~ing entitles, they occasionally
play tricks on you. A simple, quJck quality check can eliminate false entitles. Ask your
user to spedfy the number of hutances of each entity. A true entity has m ultiple
instances- do zens, htmdreds, tl1ousa11ds, or more! If not, the entity does not ex.1st.
As et1titles are discovered, give tltem simple, meaningful, business-oriented
11..1mes. Entities should be 11..1med wlth nowu that dtscribe the person, event, place,
object, or tlling about wh.ich we want to store data. Try not to abbre"iate or use
acronyms. Names should be singular so as to distingttlsh the logical concept of the etttity from the actual Instances of tl1e entity. Names
indude approprL1te adjectives
or clauses to better describe the entity- for lnstance, an externally generated
CUSTOMER ORDER must be distinguished from an Internally generated STOCK ORDER.
For each entity, define It in business terms. Don't define the entity in technical
terms, and don't define it as•data abom .. . "Try thls:Use an English dictionary to create a draft definition, and tl1et1 customJze it for the bush1ess at l1..1nd.Your entity 11..1mes
and deflnltlons sho,dd establish an lnltlal glossary oi business terminology that will
serve both yo u and future ai1..1lysts ai1d users for yean.
mar
dlaptor Eight
289
290
Part 1wo
Systoms Analysis Methods
TA a LE 8 - S Fundamental Entities for the SoundStage Project
Entity Nome
ACRIEMENT
MEMBER
MEMBER ORDER
PRODUCT
PRCW.OTION
'
Business Definition
A contract whereby a momber agrees to purchaw a airtain
number of product, wilhin a certoin time. Aftw fulfilling that
agreement, lhe momber becomeo eligible for bonus credit, that
are redeomable for free or discounted product,.
An adiv< momber of one or more dubs.
Noto: A brg<>t sy,tom objectiw is lo reenroll inadiw members os
oppo,ed lo deleting them.
An ordergeneratod fora member a, part of a monlhly
promotioo, or an order initiated by a member.
Noto: The current •}"fern only wpports orders genera1"d from
promotioos; howEWer, customer-initiated orders have been given a
high pria'ity as an added option in lhe proposed sy,tom.
A busine,s ""'nt lo which Iha Member SO!Viais System must
, ..pond.
An inven'oried product avoilable for promotion and xale to
members.
Noto: Syrtern impro,,,mMt objectiws indude (1) oompab'bility
with new bar oode •}"fern being developed "' the warehou,e,
ond (2) cdaprobilily lo a rapidy changing mix of producn.
A monlhly or quarterly c,,ent whereby special product offerings
are rnadt a,ailable lo members.
Our So,mdStage management and users Initially ident!Jled the e ntitles listed In
Tobie S.5. Notice how the definitions contribute to establishing the vocabl~at)' of tl,e
system.
>
The Context Data Model
111e next task ln data mode Ung is to construct the context data model. The context
data model should lndude the fw1damet1tal business e ntltJes that were previously
discovered as well as their natural relatlonsllips.
RP.1:arloni;hlpr. r.ho11lrl hP. n:tmM with vP.m phr:alioP.... that, whP.n rom hlnt>ci with thp
entity names, form simple business sentences or assertions. Some CASE tools, such as
System Arcbitec~ let you name the rebtlonshlps in both directions. Otherwise, always
name the rebtlonshlp from parent to dilld.
We have completed this ta<k in Figure S.13. This figure represents a data model
created ln Syste111 Architect Once we begin mapping attributes, new entities and reL1tlonshlps may surface.Toe numbers below refere11ce the same numbers in Figure S.13.
111e ERO communicates the following:
O
e
O
O
An AGREE.\ UNT binds one ot more MJ:MBERS. While relationships may be named
in only one clirectlon (pare11t to cbUd), the otl1er clirectlon is lmpllclt. For
example, ft ls lmplid t that a MEMBf.R is botmd ro one and only one AGREE.',!J:NT.
A ME.\'IBER bas Co0dl1<1fd Zt'tO, one, or more TRANSACTIONS, Imp licitly, a given
nANSACTION was rnod11<1ed l;ij• one and only one ME.\'IBER.
A MfMBf.R ORDf.R is a TRANSACJ'ION. tn fact, a given MfMBf.R ORDER may correspond
to many nANSACTIONS (for exampJe, a new member order, a canceled member
order, a changed member order, etc.), But a given TRANSACTION may or m.1y not
represent a MEMBf.R O RDER.
A PRO MOTION features one or more PRODUCTS. Implicitly, a PRODUCT is featured
In zero, one, or more PROMOTIONS. For exampJe, a CO that appeals to both
--
,.,.
e
..1EMBER ORDER
II
-
6
-- --- --- ------
6
responcts lO
..
:l'N00UCT
•• e
••'"' 0
l
lr ~eER
II
II
ZS
.·o{RANSACTION
)
sz
geoc:r.i..-«
e .
.
""
~;
Oinds
0
C)
0
0
-
~
"''''""'
I G UR E 8 - 1 3
--
IPROMOTI0r4
The Sol.lI1dStage Context Data Model
rGREEMEITT
]
)
292
Part 1wo
Systoms Analysis Method s
country/western and light~ock audle11ces might be featured in the promotion
for both. Since products greatly outnumber promotions, most products are
oe,w featured in a promotion.
0
A PRO MOTION generates many ME.\.UlER ORDERS, Implicitly, a ME.\IIB£R ORDER !!
O
unerated foe zero or one PROMOTION. Why zero? ln the new system, a member will be able to lnltL1re h.Js or her own order.
It is pennlssible for more than one rebtlonshlp to exist betwee11 tbe same
two entities if the separate relationships communicate different business
events or associations. Thus, a MENBER responds ro zero, one, or more MENBER
ORDflt5, 11lis relationsh.ip supports the promotlon.get1erated orders. A MEM3f.R
places zero, one, or more )1£.\.ffiER ORDfltS, This relationship supports mem.>erln.itiated orders. In both cases, a ME.\IIB£R ORDER Is placed by Qs responded ro
m:) exactly one """""'·
Although we didn't need it for this double relationship, some CASE rools
(lncludltlg System Arcbf.te<i) provide a symbol for recording Boolean relationshlps (such as AND, OR). Thus, for any two relationshlps, a Boolean symbol
cotdd be used to establish that lnstances of the relationships must be mutually exclusive(= OR) or mutually contingent ( = AND).
O
A ME.'IIBDl on.oEn sells o n e or more rnooucrs. lmpUcltly, a r nooucr is E:Old on
zero, one, or more MENBm. ORD ERS. Note that this is a nonspecific relatloruh.ip,
whlch w UI bter be resolved.
If you read each of tbe precedltlg items careMly, you probably leamed a great
deal about the SotmdStage system. Data models have become lncreasfogly popular as
a tool for describing tbe business context for system projects.
>
The Key-Based Data Model
11,e next task is to idet1tif)• the keys of each entity. The following gttldelines are suggested for keys: 1
I. 11,e value of a key should oot change over ti,e lifetime of each entity instrnce.
For ex.ample,
NAME
wotdd be a poor key since a person's L1St name could
change by marrL1ge or dJ\--orce.
2. 111e value of a key cannot be null .
3. Controls must be Installed to ensure tbat tbe value of a key Is valid. This can
be accomplished by preclsE!y defining the domain and ush,g the database
m.'UUgemenr system's ""l.Ud:ttion controls: to enforce th.it dom.tln.
iotelligeo t l!ey a business
code 'M'IOse stuctne COR'ITAJ·
nicates data at1out an entity
i"lstaice.
4. Some experts (Bruce) suggest you avoid lnteUJgent keys. An hllelllgetll key is
a business code whose strl"--"ture communicates data abottt an et1tlty it1Staace
(such as its classllkation, size, or other properties). A code is a group of characters and/or dlgiis tbat identifies and describes something in the busines.<
system. Some experts argue that because those cbaracterlstlcs can change, it
vioL1tes rule l above.
\X'e disagree. Business o:>des can return '\<'a lue to the organization because
they can be quJckJy proces!ed by humans witl1out the asslsrance of a
comp uter.
a. There are several types of codes. 111ey can be combined to form effecth,--e
rueailS for entity it1Stance identl.flcatlo11.
(1) Serial codes assign sequentially generated numbers to entity lllSlances.
~tany database management systems can generate and constrain serial
codes to a bush1es.,'s requirements.
IAdaptt d ftoll:I Thoma, A lltlict. Dc,igning Q,utlity D t t ~ ttilb lDEFlX /11fon11ttrion ,~odtk C,oprtight O 1992
byTliolni$ A. Bn.c:e llc-ptiru:ed by pt ttn.sior.ofDolwt Rou:ll' PubJbhi..ns. 353 W. 121h St. , N,:w· Yotlt, NY 10014
(212.62040;5Yt .SOO.OM..DOOKS/'11-ww.dorsnho....,~O!D). AU tigats h ' ~.
Data Modollng and Analysis
(2) Block codes are similar to serial codes except that block numbers are
dtvJded into groups tl1ar have some business meaning. For lnslance, a
satellite television provider mlght assign 100- 199 as PAY PER VIEW channels,
200-299 as CABLE channels, 300-399 as SPCRT channels, 400-499 as ADUCT
PROGR.A..\t~G channels, 500- 599 as MUSIC-Om.¥ channels, 600-699 as
tNTI.Jt.t.CnVE GA...\UNG dwu1els, 700-799 as CNTERNET channels, 800-899 as
PRE.WUM CABLE channels, and 900-999 as PRi!MlUM MOVIE AND EVllltr d1annels.
(3) Alphabetic codes use finite combinations of letters (and possibly numbets)
to de.scribe entity lnslances. For exampJe, each STATE has a unique two-
character alphabetic code. Alph.abetlc codes must usuallj• be combined
with serial or block codes to uniquely ldetltlfy Instances of most entitles.
(4) In stg1tlfica11t position codes, each dlglt or group of dlglts describes a
measurable or ldentltlable characterlstlc of the entity Instance. Signlfkanr
digit codes are frequet1tly used to code 1n,·enrory ftems. The codes you
see on tires and lightbulbs are examples of sJgrlificant position codes.
They tell us about cbaracterlstlcs such as dre sJze and wattage,
respectlvelj'.
(5) Hferarcblcal codes provide a top-<lown Interpretation for an entity
itlStanoe. Every item coded is &ctored into groups, subgrouP6, and so
fortl1. For lnstance, we could code employee positions as follows:
-
First dlglt ldentlftes classllkatlon (clerical, factdty, etc.).
Second and third dlgits lndlcate level within dasslJkatlon.
Fourth and fifth dlglts indlcate calendar of employment.
b. 111e followlng gttldeUnes are suggested when creating a busines., codlng
scheme:
(I) Codes sbould be expandable to accommodate growth.
(2) The full code must res,dt h1 a unique value for each etltlty Instance.
(3) Codes should be mge enougl1 to describe !he dlsth1guJshlng characteristics
but small ei,o,tgh to be hllerpreted by people wf.rhout a compu.ter.
(4) Codes sbould be convenient. A new instance should be easy to create.
5, C)11SJder 1n,-entlng a surrogate key h1Stead to substitute for L1rge concatenated
keys of Independent entitles. Th.is suggestion ls not practical for associative
eatltles because each part of the concatet1.1ted key ls a foreign key that must
predselj• match Its paretll entity's primary key.
Figure 8-14 Is the key-based data model for the 3oundStage project. Notice tl1at
tl,e primary key ls speclfled for each et1tlty.
O Many etltltles have a simple, single-attribute primary key.
O W'e resolved the nonspecltlc relationship between MJ:MBER ORDf.R and
PRODUCT
by lntroduch1g the assoc.L1tfve entity ME.\.UlER OROfllED PRODUCT. Ead1 as.,odatfve
e11tity h1Stance represents one product: on one member order. The parent
e11titles contributed their own primary keys ro comprise the assodatt,--e
e11tity•s concatet1.1ted key. Systen1 Architect places a "PKl,. next to ORDER
NUMBf.R to lndkate tl1.1t Jt is ..pan: one" of the concatenated primary key and
a '1>K2,. besJde PRODUCT NUMBf.R to lndlcate that Jr is ..parr two" of the concate-
nated key. Also notice th.at ead1 attribute in th.ti concatet1.1ted key, by Itself,
Js a foreJgn key tl1.1r polnts bad:: to the correct parent et1tity h1Stance.
Likewise, the 11onspecific relatlonsllip bem·ee.1.1 PRODUCT and PROMOTION
was re.soJved using an assoc.L1tt,--e entity, nTLE PROMOTION, that also h1herits the
l::eys of the parent et1tlties.
When developing this model, Jook out for a couple of things. If you cannot define
keys for an et1tlty, It may be th.at tl,e entity doesn't really exist- th.at ls, m,dtlple
occurrei,ces of tl,e SO<alled et1tlty do not exist. Thus, assigning keys Is a good quality
d,eck before f,dly attributing tl,e data model. Also, If two or more entitles have
Identical keys, they are h1 all llkelll1ood the same etltlty.
dlaptw Eight
293
~
0
EJJBER ORDER
....
I
II t""•><rKey
nn;.-.Numbe<
isa
0
resoond5
.....
e
. -'
1·11 ········ ------·· .
[PKI)
IO
.
"""'""'""
MEMBER
II-.Prim,,y ""'
. ___ . II· Member·Nl.l'lltler
11
lPK1)
...
$Old 85
0
ROOOCT
Prim•!)' Ker----- - - 1
~
generate&
0A
bind$
"I<
0
RANSACTtON
Pnm•ry
Key- - - - -- - - -- -'
-Nt.rnbef (PKI)
y, _._l.('111--~.,.,iu:-N~
[P KI I
0
7'GREEMENT
i$ fe.wturcd a&
PM\&~Key--- - - - i
Al)(~nl·Nvmbcr 1PK1)
0
...............
,.,., fPK1) fFK] ~ I
c
oo
r.RC\tOTION
Pl'imary Key
leistures
II
·--N,....., fPK 1)
FIG U R E 8 • 1 4 The SoundStage Key-Based Data Model
--)
Data Modollng and Analysis
>
Generalized Hierarchies
At this time, it would be useful to Identify any ge11eralizatlon hierarchies In the business domain. The SoundStage project at the beginning of this dtapter identlfled at
least one supertype/subtype structure. Subsequent discussJons dJd tmcover a generalization hierarchy. Thus, our key-based model was revised as shown In Agu.re 8-15.
'\X'e had to lay out the model somewhat differently because of the hierarchy; l1owe,--er,
tl1e relationships and keys that were previously defined have been retained. We call
your attention to the following:
O
O
O
>
11,e Sow1dStage CASE tool amomatlcally draws a dashed box around a generalization hierarchy.
The subtypes Inherit the keys of the supertypes.
W'e disconnected PROMOTION from PRODUCT as ft was shown earlier and reconnected ft to the subtype 11Tl.£. 1b.ls was done to acctuateJy assert the business
t u.le that MEllCHANDISE is ne,--er featured on a PROMOTION- only TITLES.
The Fully Attributed Data Model
It ma.y seem like a tri'\oial task to identify the remaining data attributes~ however, analysts not famlllar with data modeling frequently e11counter problems. To accomplish
tllis 1ask, you must have a thorough understand.fog c,f the data attributes for the system. TI1ese facts can be disco,. ered
.
using top-down approaches (such as brainstorming) or bottom~•p approaches (sud, as form and Ille sampling). If an enterprise data
model exists, some (perhaps many) of the attributes may have already been ldentltled
and recorded lo a reposJtory.
The following guidelines are offered for attribution:
btany organJz.atlons have naming standards and approved abbre'\oiatlons. The
data admlnlstrator usually maintains such standards.
Choose attribute names carefully. ~tany attrlbutes share common base names
sud1 as NAME,ADDRESS, DATE. Unless the attributes can be generalfzed into a
supertype, ft ls best to give each variation a unlque name such as:
ORDER DATE
CUSTOMER NAME
CUSTOMER ADDRESS
SUPPU£R NAME
SUPPUER ADDRESS
CN\OICE DATE
t.\'IPI.OYEE NA...\iE
E.\'IPLOYEEADDRESS
FUGHTDATE
Also, remember t11..1t a project does not U,--e lo isolation from otl1er projects,
past or future. Names must be distlnguisl1..1ble acros., projects.
Some organJz.atlons maintain reusable, glob1I templates for t11ese common
base attributes. 11lis promotes consistent data types, domalns, and defaults
across all applications.
Physical attribute names on existing forms and reports are frequet1tly abbrevi-
ated to save space. Logical attribute names should be dearer- for example,
translate the order form's anrlbute coD into lts loglcal equJYalent, AMOUNT To
COUEcr ON DELJV£RY, translate QTY Into QUANTITY ORDfllED; and so forth.
btany attrlbutes take on only YES or NO Yalues. Try 11..1ming these attributes as
questions. For example, the attribute name CANDIDATE FOR A DEGREE? suggests
the values are YES and NO.
Each attrlbttte should be mapped to only one entity. If an attrlbttte truly
describes different entitles, it is prohab~· several different attrlbtttes. Give
ead1 a unique 11..1me.
Foreign keys are the exception to the nonredundancy rule- they Identify
associated h1Stances of related et1tltfes.
dlaptor Eight
29S
i
....
.
,,..,.,.")'~
jMl'MBER OROl;R
I
Oto,tt.NuMI* fl)KII
p
l'""'l!MUER •
0
T
~·"
~
l'PIQI
t.<mbo!W !PK1)
P
·-ti«
'
(
.....
-
'
'
'
-- -- -- - -·
1..-ROOUCl
Pri'n~Ktf
'
--- -
"
'
P ~Numb91" IPIOJ
.1
...
MER.CMANOIS.E
-Pl'N')'i<ey
PJ'Od~t,ljj( (PKII IFKI
'
T
,m.,
•a
.
j
f)
P~\.1Ct.ffl.ombo:r lf'K1! "'KJ
;,,
-•
-
-
M
[t'R()MOTl()N
---
- 01
,.
Pl-ffl.-yKer
PI-Qrl!Oli:;n-Hi.,moo, IPK 1)
itfiNtl.loec:1-,
·Pr.mary
GAME mu
-P,ffl,ry
Produo:t,,H- 1PK1J (flQ
P fOOuCl,NutYtW {PK II (Fl(J
P r ~ b O r [PK1J
......
f'ROMOTI
~
... l
VlOE;OllTLE
-Pfine,yK
e
.. - . . .. -
-Ptm.wyl<oy
e
l ..
AUOIOTITLE
-.. -
I
~~~ ,~
p
.
tlOt (l'!QI
I
ll"'JC)
I
'
FIG U R E 8 - 1 S The SoundStage Key-Base:! Data Model with a Generalizatioo Hieran:hy
ie111v<e,
dlaptw Eight
Data Modollng and Analysis
_,...,1
_....,_.,
~
-·-·-- _______
297
e-...c.
I()
--··-·-----!
~·~-----~
-··-----. ---Oo----~----<·-~.
.,_ _ l"" 'I
....-c,,..
II .,.,....,...
__
--~c..t,..
--·"·,_
..........
-"""'__
........._
_....·.._
_
--
__
--.:i.,0-P,.._ _
,_,
·-·-C.•
-·-.. ,,.~
-<·w::-11..
K",_........._
_
--··-.... c;_ll>',,..._
<M
...o,T)t<
.,,._ f'CI
,
... (;,....-«,.....
- -·•"'!'IQ
'"
·= ------11
··-··
..__
_,_
·------·
-·
·~-- ,.._.._.,,,...,.
...-~·-----·II
..
...,,__,"""
..··
.- I l e ! :
, . _ . _ Jl'IU) ltllf
..._._u., r-;11 itq
.........,_
e,--·
--~...,-----11
--··------11
..:::.~ , =------11
N.00fl11.(
YOlOM\.f
..._......,..,C""'!l(Jl(I
·-·---~-·--,...,.
.......
_.
-·-....
-
.... ,l>A.....,
_,.,_,._,..
~•-
•<oo,
c..~
_..
.......
c:-.,o.....,._
'-"''"'
...._....._._ l"l!IUII!
~
.(,_
....
11:1.<,...:--
- -·,-- ·-
..-_
--·
o.·--- -.. O,lt.<l(l!l\f:
.......... "-· - -- --n
·--"
.._..
~ W !N ') f'\<I
e.--··11~
......__A,,-
""'-W•C:-
~~-
"""''"~
F I G U R E 8 - 1 6 The SoundStage Fully Attributed Data Model
Alt attribute 's domain st1ould not be based on logic . For ex.ample, in the
SoundStage case we learned tl1..1t the values of MmJA were dependent on the
cy•pe of product. If the product type Is a >ideo, the media co,dd be VHS tape,
8mm tape, Liserdlsc, or DVD. If the product type Is audio, the media cotdd
be cassette tape, CD, or ~ID. 111e besr solution would be to assign separate
attrlbutes to ead1 domain: AUDIO MEDIA and VlDEO MEDIA.
Figure 8-16 provides the mapping of data attributes to etltltles for the deflnltloo
phase of our SotmdStage systems project. While tl1e fully attributed model ldet1tltles all
~QI
=.:_ )01(11
--··-~
_,H,.
--
.,...,1
298
Part 1wo
Systoms Analysis Methods
the attributes to be captured and stored In ottr future database, the descriptions for
those attributes are Incomplete; they require domains. Most CASE tools provide
exte11sive faclllties for describing the data types, domal11s, and defatdts for all attributes
to the repository. Additionally, each attribute sho,dd be defi11ed for future reference.
~~~A_n_a_ly
~zi_n_g_t_h_e_D
~a_ta~M_o_d_e_l~~~~~~~~~~~~~~~)
Willie a data model effectt,--ely communicates database requirements, it does not necessarily represent a good database design. It may contain structural d1arocterlstlcs mat reduce flexibility and expansion or create unnecessary redundancy. Therefore, we must
prepare our fully attributed data model for database design and implementation.
Thls section wlU discuss d,e d,arocteristlcs of a qua/r.ty data model- one that wlU
allow us to develop an ideal database strucrure. We'll also pre.sent the process used to
analyze data model quality and make necessary modlficatlons before database design.
>
What Is a Good Data Model?
Wh.at makes a d.:it:i model go odl We suggest the following crJteri.'l:
A good data model Is stmple. As a gei1eral nde, the data attributes that
describe any given entity should describe only that entity. Consider, for example, the following entity dellnltlon:
COURSE REGISTRATION
=
COURSE 11.EGISTR.ATION NUMBm (PRIMA.llY Kff)
+
COURSE 11.EGISTR.ATION DATE +
STUDENT CO NU\.IBER (A fOREGN KEY)
+
+
STUDENT MAJOR +
STUDENT NAME
One or more COURSE NUMBERS
Do snromr NAME and sruoENT MAJOR really de.scribe an it1Stance of course registratio11? Or do they describe a dJfferent entity, say, STUDENT? TI1e same argument cotdd be applied to :mromT JD NUWlfR, but on further Inspection, that
anrlbute is needed to ..point" to the corresponding lnslance of the snro~rr
etltlty. Another aspect of simplicity Is stated as follows: Each attribute of
an entity instance can have only one '\o-:tlue. Looking again at the previous
ex.ample, we see tl1.1t COURSE NUMBER can 11.1,--e as many '\o-:tlues for one COURSE
REGISTRATION as the student elects.
A good data niodel Is esse11..tlalty 11-0·11redu11dant. This means that each data
anrlbute, other than foreign keys, descrlbes at most one entity. In tl1e prior
ex.ample, it is not difficult to imagine that sruoa,,rr NAME and STUDENT MAJOl
might also describe a STUD""T entity. We sho,dd choose. Based on the pwrlous bullet, the logical d1olre would be the STUDmT entity. There may also
ex.1st subtle redundancies in a data model. For example, the same attribule
mlght be recorded more than once tmder different 11.1mes (synonyms).
A good data model shou.ld be jkxlble and adaptable to Jutu.re needs. In
t11e absence of tills criterion, we would rend to design databases to fulflli
only today's busines., requi'ements. 111en, when a new requirement becomes
known, we can't easily change the databases witl1ou t rewriting many or ill of
tl1e programs tl1.1t used those databases. WhUe we can't change tl1e reality
tl1.1t most projects are applicatloo-drivei.1, we can make our data models as
appllcacion-independei1t as possible to encourage database structures tha1 can
be extended or modified witl1our lmpact to cttrrenr programs.
So how do we adlleve the above goals? How can you design a database tl1at
can adapt to future requirements that you cannot predict? TI1e answer lies In data
analysis.
Data Modollng and Analysis
>
299
Data Analysis
The tedmlque used to Improve a data model In preparation for database design Is
caUOO data analysts. Data a1ulysis ls a process thar prepares a data model for lmplementatlon as a slmple, nonredtmdant, flexible, and adaptable database.The speclflc
tedln.ique is called 11ort11alt.zn.tf.0·11. Non:n..1.Uzatioo is a data analysis technlque tl1..1t
organizes data attributes such that they are grouped to form nonredundant, scable,
flexible, and adaptl,.. entitles. NonnaUzatlon Is a three-step tedmlque that places the
data model into first normal form, second nonnal form, and third normaJ form:2 Don't
get hung up on the terminology- it's easier than ft sounds. For now, Jet's establish an
inltlal understaodlng of these three formats:
Simply stated, an entity Is In first oonn.~J form (lNF) If tl1ere are no attributes that can have more than one value for a single it1Stance of the et1tlty.
Any attrlbutes tl1at can have multiple '\<-:th1es acrually describe a separate
entity, possibly an entity and relatlonshlp.
Alt entity ls in second normal form (2NF) If tr is already in I NF and if the
r.ilues of aU non-primary-key attributes are depende11t on the fuU primary
tey- not just part of It. Any nonkey attributes that are dependetll on only
part of the primary key sl1otdd be moved to any entity where that partial key
Is actually tl,e full key. This may require creatlt11 a new entity and relatlooshJp on the model.
All entity Is In third normal form (3NF) If It Is alreadv In 2NF and If the
Talues of its non-primary-key attributes are not dependent on any other nonprlmary-key attrlbures. Any nonkey attributes that are dependent on other
oonkey attrlbures must be moved or deleted. Agait1, new entitles and relatloo,hlps may llave to be added to the data model.
>
dlaptw Eight
Normalization Example
There are numerotis approaches to normalizatlo11. We have chosen to present a nontheoretlcal and 11onmathematlcal approach. '\X'e'll leave the theory, relational algebra,
and detailed Implications to the database cotuses and textbooks.
As usual, we'll use the SoundStage case study to demonstrate the steps. Let's
begin by referring to the ftdly attributed data model that was developed earlier (see
Figure 8-16). Is lt a normalized data model? No . let's Identify the problems and
walk through the steps of nonnalizing our data model
First Normal Form The first step In data analysis Is to place each entity Into INF. In
Flgtue 8-16, which etltltles are not In INF?
You should find two- ME.\.UlER ORDf.R and PROMOTION. Each contains a repeating
gro·up, that is, a group of attributes d1at can ha,-e multiple values for a single instance
of the ei1tlty {denoted by the brackets/. These attrtbutes repeat mmy tlmes •as a
group ." Consider, for example, the entity MENBf.R oRDm. A sfngle ME.\iBER ORDER may
contain many products; therefore, the artrlbutes OFDERm PRODUCT NUWlER, 011.0m.m
PROOT
JCT DESOUPTION, ORDER.fl> PRODUCT Tm.£, QUANTITY ORDER.ED, QUANTITY SHJPPED, QUANTITY
BACKORDER.FD, PURCHASED UNIT PRICE, and o.'TI.NDm PR.ICE may (and probably do) repeat for
each instance of ME.\1BER ORDER.
SlmlL1rly, since a PROMOTION may feature more than one PROoucrnTLE, the PRODUCT
NUMBf.R and TITLE OF WORK anrlbures may repeat.. How do we fix these anomaUes ln our
model?
Figures 8-17 and 8-18 demonstrate how ro place these two entitles into JNF. The
original entity Is depicted on the left side of the page.The INF entitles are on the right
to..latuc a-pen, bi"' identif,ed ildditiobLI tiottn.d fottn,. Thi.Jd nor-tnLI bnn ~ tDOSt cbt11L110tnaliC'11. w·c- Je:,"' 11.
di$c..-ion oflld'r.lbocd nor-tnLI fbr-n. to dattl»llc- ttttboob arid oour--.
data aaal}'Sis a tec:hrique
used to inp-ow a data model
br ~lement.ati>n as a
database.
oor-malizatioo a dala
Maly§s tech'liQ.Je that orga.
rims dala i'lto ~rol.l)s to fcrm
nor'l'edu"ldant, ,1atM, ne,-tM,
M d adaptive ertmes.
first normal lorm ('INF)
eni ty W'lose attributes
haw no mae ttan one value
bra M~e i"lst.ance of tlat
M
antity.
secood ooNml form
(2NF) an enlil)' 1'11clS<>
non.p-ma,y-ke)' altibutes .we
dependent on tte ft.I pmuwy
ksy
tbi.td normal form
(3NF) an e~· Whose non·
i:rma,y."9y attib.Jtes .we not
dependent on arr; other non·
i:rma,y."9y attib.Jtes.
300
Part 1wo
Systoms Anclysls Methods
MEMBER ORDER (1NF)
0-de< .... mbe< (Prma,y Key)
Oder-0-eation-Oate
Order·AulOl'1'\.91c-F•·Oate
Member--Nl.l'llber (Fori91gnKey)
Member--Nl.l'llber·2 ~ore9l Key)
Member--Narne
Member·Ad:i'ess
&IIR)ng·Adctess
~ n g lns-trucllC>ns
Promobon-Nl.l'llber (Fore9l Key)
Order.SUb·Total-Cos-t
Oder.S-S-Tax
Ship.Via-Method
sn,,png Charge
Order.sta1us
Prepaicf.Amomt
Prepaic:J.tAethod
a ells
.....
••
PRODUCT (1NF)
Product-N""""' (Pm,a,y Key)
Urwet'Sa-Produci-Code (Aftemate Key)
Ouanltty-1'\-St>ck
Product-Type
Suggeslecf.Relai-Pnce
Oe1al.At·Uut.Pnce
CL1Tent-Spectaf-Untt.Pnc,e
Cooent ,IJonth-Unlts--Sold
CLITent·Year-UMs·Sold
TOlaH.lfe11 me -Uuts-Sokt
( FIGURE 8 • l 7 First Normal Form (INF)
)
Data Modollng and Analysts
Chaptor Eight
301
PROMCITIO" (1NF)
generated for
genera&
~G U R E
8-18
First Normal Form (JNF)
_ _ _ _ _)
side of the page. Each figure shows how normallzatk>n changed the data model and
attrlbute assJgnments. For your convetlience, the attrlbutes that are affected are In
boldface type and In small capital letters.
In Ffgure 8-17, we B.rst removed the attributes tlut can h.ave more than one value
for an instance of the MD.lBf.R O RDER entity.n1.at alone places MEMB f.R O RDf.R ht t NF. But
wl1..1l do we do with the remove.d attrlbutes? We can't remove them entireJy from the
model- they are part of the business requirements! Therefore, we moved the entire
group of attrlbutes to a new e11tlty, MEMBER O RDER.ED PRDDUCJ'. Each instance of these attributes describes one PRooucr on a single ME.\.fB£R ORDER, Thus, lf a specific order contains five PR.o oucrs, there will be flve Instances of the MEMBf.R ORDER.fl> PRODUCT entlry.
Ead1 entity instance has only one value for eadt attribute~ therefore, the new e ntity ls
also in firs t normal form.
302
Part 1wo
Systoms Analysis Method s
Another example of INF Is shown In Agure 8-18 for the PROMOTION e ntity. As
before, we moved the repeating attributes to a different entity, TITLE PRO MOTION.
All other entitles are already in t NF because they do not contain any repeating
groups.
Second Normal Form TI1e next step of data analysis ls to pL1ce the e ntities into
2NE Recall that it is required that you have already placed all e ntities Into INF Also
recall that 2NF looks for an atttibute whose value is determined by only part of the
primary key- not the entire concatenated key. Accordfngly, entitles that l11ve a
single-attribute primary key are already In 2NF. That takes care of PRODUCT (and its
subtypes). Mfl\lBf.R O RDER, MENBf.R, PRO MOTION,AGREfMENT, and nANSACl10N. Thus. we need
to d1eck only those entitles tl1..1t h.ave a concatenated key- MENBm. OllDER.fD PRODUCT
and TITLE PRO MOTION,
First, let's check the
MEMBm. OJI.Of.RED PRO D UCT
entity. ,_lost of the attributes are
dependent on the ful l primary key. For example, QUANTITY ORDERED makes 110 set1Se
unless you have both an o aof.R NUMBEll and a PRooucr NUMBER. Tilink about it! By itself, ORDER NUMBf.R ls inadequate sinc e the order could have as many quantities ordered as there are products on the order. SlmJlarJy, by ltself, PRODUCT NUMJIEll is
inadequ:ite since the same product co uld appear o n many orders. Thus, qu.-._,rnn
ORDERED requires both parts of the key and is depet1dent on the fltll key. The same
could be said of QUANTrTY SHIPPED, QUANTrTY BACKORDEJlED, PURCHASE UNIT PRICE, and
EXTE'IDED PRICE,
But wt1..1t about ORDER.ED PRODUCJ' DESCJUPn ONand OllDERfD PRODUCTnTJ.£? Do we really need ORDf.R NUMBf.R to detennlne a value for either? Nol Instead, the values of these
attributes are dependet1t only on the value of PRODUCT NUMBEll. Thus, the attributes are
1101 dependent on the full key; "" have tmcovered a partial depe1ule11cy anomaly that
must be fixed. How do we Bx this type of normalization error?
Refer to Agure 8-19 on the next page. To fix the problem, we simply move the
nonkey attrlbutes, ORDfllED PRODUCJ' DESCRJP'J'ION and ORDERED PRODUCT11Tl.J:, to an e11tity
that has only PRODUCT NUMBER as its key. If necessary, we woldd ha,-e to create tlll.s entity, but the PRooucr entity with that key already exists. But we have to be careful because PRooucr ls a supertype. Upon inspection of the subtypes, we discover tltat th e
anrlbutes are already in the MaCHANDISE and nTLE entitles, albeit tmder a sy11onym.
111us, we didn't actually l1..1ve to move tl1e attrlbutes from the MENBf.R ORDER.fl> PRODUCT
entity; we just deleted th em as redtmdant attrlbutes.
Next, let's examine the TITLE PROMOTION entity. The concatenated key is the combination of PROMOTION NU-.mER and PRODUCT NUMBf.R. Tm.£ OflWOR.K ls dependent on tl1e
PRODUCT NUMBER portJon of the concatenaced key. lbus, Tm.£ OP WORK lS removed from
m1.< PROMOTION (see Agure 8-20). Notice that TITLE OP WORK already existed in tl1e
entity rrrt.E, wlllch has a product number as its primary key.
derived attribu te an
allribule WhoM value can be
cab.fated Iran otler attribules a derived frcm the
vafuesofother attributes.
Third Normal Form We can further simplify our etltlties by placing them Into 3NF.
Entltles are required to be in 2NF before beginning ,NF analvsls.Third nonnal fonn
analysis looks for two types of problems, derf.v ed data and tmnsltf.ve depe,ufellCies.
In botl1 cases, t11e ftmdamental error ls that 11oru::ey attrlbutes are dependent on other
nonkey attrlbutes.
T he first type of 3NF analysis Is easy- examine each entity for derived anributes.
Derived attributes are those whose values can be either calculated from otl1er attribu tes or derived through logic from the values of other attributes. If you thlnk
about lt, storing a derJved attribute makes Utt.le sense. First, it wastes disk storage
space. Secon d, it complicates what should be simple updates. Why? Every time you
change the base attrlbutes, you must remember to reperform the calculation and also
change Its result.
For ex.ampJe, look at tl1e ME.\'IBm ORDERED PROOUCJ' et1tiry in Figure 8-21 . T he attrlbute O.'TJN)ED PRICEls calctdated by mldtlp.lying Qlll.NTITY ORDER.fl> by PURCHASED UNfT
PRICE. Thus, o.'TJN)m PJUCE (a 11ankey anrlbute) ls 11ot dependent on d1e primary key
Data Modollng and Analysts
( F IG U R E 8 • 1 9
Second Normal Form (2NF)
Chaptor Eight
303
)
----------
..._.
as much as it is de.pendent on the nonkey anrlbutes,Qw.NnTY oaomm and PURCHASED
UNJT ?RICE. Thus,
we correct the entity by deleth1g EX'TE'mED PRICE.
Sounds simple, right? ~'el~ not always! There ls disagreement on how far you take
this rule. Some experts argue tl1at tl,e rule sho,tld be applied only wlthln a single entlty.111us, these experts would not delete a derJved attribute lf the attributes required
for the dertvatlon '\\"'ere assigned to different entitles. We agree based on the argt.101ent
tl1at 1 derived attribute that involves multiple entitles presents a greater danger for
304
Part 1wo
Systoms Anclysls Method s
ge nerates
_________
CF I GU R E 8 • 2 0
----
t:rausiti\•e depeocleocy
'Mien Ile value of a nonkey
allribule is dependent on
the wlle of a-otler ncnkey
allributo othorthan ty
derivation.
_ . ,)
Second Normal Form (2NF)
data lnconslste11q• caused by updarJng an attrlbute in one entity and forgettlag to
subsequently update the derived attribute in another entity.
Another form of 3NF analysis checks for transitive dependencies. A transit ive
dependency exists when a nonkey attrJbute is dependent on another nonkey attribute (other than by dertvation).Th.ls error llSltally indicates that an u ndiscoTered
entity is still embedded within the problem entity. Such a condition, lf no, corrected, can cause future flexibility and adaptabUity problems lf a new requirement
eventually requires that we lmplement tl1at lUldiscovered entity as a separate database table .
..
S
\....__
t, ..._,U
RE 8_
• 2 1 Third
_
Normal
_
Fo rm (3NF)
_
_ _ _ __ . ,)
Data Modollng and Analysis
!
p .._
!
MEMBER ORDER (2NF)
°'"""""""
dlaptw Eight
30S
!
f'91pollcil t o
!
MEM3ER ORDER (~F)
(Pm,a,y Key)
Order.Creedon-Oaie
Order-F•-Oate
Member NLmber (Foreql Key)
Member--Ni.mber-2 (foreql Key)
MDIDm.NAM(
MDIDm.AODA!eSI
~g-Adci'ess
~ g IR!:11UC1ons
-~,ge
Promodon N""be< (Rl<eq, Key)
Order-Sub-Tow.Cost
0rder-S8'es·Tex
~-VMl-Method
()-,1,:,,r ,q,_.. IA.
Prepaid-Amount
Prepaid-Method
( F I G U R E 8 • 2 2 Third Normal Form (3NF)
TransJtive analysis ls performed only on entitles that do nor ba,-e a concatenated
key. h1 Ot tr ex.ample , tllis indu des PRODUCl', ME.\.UlER OR.Df.R, PROMO'OON,AG Rf.E.>,.{E'll(, MEMBf.R,
and TR.ANSACno N. For the entity PRo oucr, all the noru:ey attributes are dependent on
the primary key and only the primary key.11,us, ••ooucr is already h1 third normal
fonn. A sim1L1r ai1..1lysls of PROMOTION, AGREEMENT, and i'RANSACTION reveals tl1..1r they are
also in third 11ormal for m .
Btn look at the enrJty ME.\ IIBm ORDf.R lo Figure S.22. ln particular, examine the attributes ME.\.IBER NAME and MENBf.R ADD RESS. Are these attributes dependent 0 11 the primary key, ORDf.R NU\.iBER.? No1111e prlmary key ORDER NUMBER ln no way detennlnes the
value of ME.\IIBf.R NA...\ffi and ME.\IIBf.R ADDRESS, On the oth et han d, the values of MENBF.». NA...\ffi
)
306
Part 1wo
Systoms Analysis Method s
and MENBf.R ADDRESS are dependent on the value of another no11-prt111ary key lo the
entity, MENBf.R NU\.iBER.
How do we fix this problem? ftlEMa f.R NAME and MENBER ADDRESS need to be moved
from the MEMB>ll ooom entity to an etltity whose primary key Is just MEMBER"""""· If
necessary, we would create tl1..1r entity, bur in our case we already have a MENBF.». entity
wlth the required primary key. As ft turns ou t, we don't need to really move the prob-
Jem attributes because they are already assigned ro the ME.\IIBER entity. We dJd, 110\\·ever,
notice thar MEMBER ADDRESS was a synonym for ME.\.UlER sTR.EET ADDRESS. We elected ro
keep the latter term ln MfMBER.
Several nonnal forms beyond 3NF exist.. Each successive normal form makts the
data model simpler, less redw1dant, and more flexible. However, systen,s analysts(and
most database experts) rarely tlke data models beyond 3NF. Consequently, we w JU
Jeave further discussion of normalization to dambase textbooks .
The first few times you normalize a data model, the process will appear slow and
tedious. Howe,--er, with time and practice, ir becomes quJck and routine. ,_lany experienced modelers signlJlcantly reduce the modeling time and effort by doing normalization during anrlbution (they are able to do normalization at the time they
are developing the fully attribuled data model). It may help to always rememb<r the
following dJtty (sou.roe unknown), whlch nlceJy stunmarlzes first, second, and third
nonnal forms:
An e ntity is said to be In third normal form ff every non-primary-key attribute
is depet1detll on the primary key, tl1e whole primary key, and notlllng but tl1e
primary key.
Simplification by Inspection Normalization is a fairly medl..1nlcal process. But it is
dependent on naming consistencies in the original data model (before normalization).
When several analysts work on a. common application, It is not w1usltal to create probJems that won't be taken care of by 11ormalizatlon. These problems are best solved
througl1 slmpliJlcatlon by Inspection, a process wherein a data entity In 3NF Is ftrther
slmpliJled by such efforts as addressing subtle data redundancy.
The final, nonnaUzed data model ls presetlled In Figure 8-23 on the next page.
CASE Support for Normalization ~tany CASE tools claim to support norimUzatlon concepts. They read the data model and attempt to Isolate posslble nonnallntlon
errors. On dose examination, most CASE tools can normalize only to first normal
form.They accomplish this In one of two ways.They look for many4o-many rebtlooshlps and resolve those reL1tlooshlps lnto assodatlve entitles. Or they look for attrlbtttes spec!Jlcally described as ha,,ing m ultiple values for a sh,gle entity instance. (One
could argue that the analyst sholdd have recognJzed tl1at as a 1 NF error and nor
described the attributes as such.)
It ls exceedingly dlfflctdt for a CASE tool to Identify second and third normal form
errors.111ar would require that the CASE tool h.ave the intelligence to recognize par·
tial and transitive dependencies. In reality, such dependencies can be dlsco,-.red only
through less-tl1an-routlne ex.amhatio11 by the systems analysts or database experts.
Mapping Data Requirements to Locations
Whlle a logical data model ls effective for describing what data Is to be stored for
a new system, lt does nor corumwlicate the requirements on a business operating
location basis. We need to identify what data and access rights are needed at which
locations. Spec!Jlcally, we mlght ask tl,e followh1g business questions:
Which subsets of the entities and attrlbutes are needed to perform the "·ork
ar each locatio11?
What level of access Is required?
...
..
~--••+++•
?
•+M•+++
!
c-
!
!iihl
t(ill
[
l
...
...
.
.
!..
..
,.
...
I' .
:
l .:
.
..
...
..
.
;
...
'' :
t·
f
• 1
01
H!jfl!
!!
Q j , , - t ..
'' 'I
a;
e
-..
.£
ll
!. '
~
z
""
·"
I=
.$
1
•
j
~ I f lis
~·
uli •l•ll• •
HHHhlli
••
;
'
I:.
Ij
rHii
•
ti
ii
I
z
!1 1
i
!ii !};11
f til
HHUiHHli I
I l
I ....
I "§0
I .5·.;,
I ..~
"~
I
I "'"~
I "'
I <»•
I ...a,:
I 0
I ...
N
•;;"
•1
fI
uh J.!f' 11•f
HHillhl
·-··
-
.
::)
307
308
Part 1wo
Systoms Analysis Methods
c:
..
_g
~
~
NOV
•
RU
RU
x
•
...,
...,
...,
ALL
NOV
•
•
•
ALL
•
• ALL
ALL
•
•
•
•
CRJI)
ALL
CRJI)
CRJI)
CRJI)
RU
CRJI)
CRJI)
l:~t
•
•
ALL
•
CRJI)
ALL
CRJI)
SS
CRJI)
SLI)
CRJI)
•
•
CRJI)
SLI)
CRJI)
SS
CRJI)
NOY
•
•
•
•
•x
ALL
•
•
•
~=-~!ALL: t -
••
•
•
RU
ALL
•
•
•
SS
CRJI)
CRJI)
CRJI)
•
•
RU
RU
SS
•
•
•
ALL
•
ALL •
•
•
•
•
•
•
CRJI)
CRJI)
CRJI)
CRJI)
CRJI)
CRJI)
SS
CRJI)
CRJI)
CRJI)
CRJI)
ALL
•
•
•
•
•
•
::; !:::+ I
SS
SS
•
•
•
SS
•
•
•
CALI)
CALI)
CALI)
•
•
SS
SS
•
•
•
SS
SS
•
•
•
CALI)
CALI)
CALI)
SS
SS
CALI)
CALI)
ALL
ALL
ALL
•
•
•
•
•
•
•
•
•
•
•
RU
•
•
•
•
•
RU
! I I I
)
( FIGURE 8 - 24 Data-to-Location~RUD Matrix
Can the
Can the
Can the
Can the
location create inslances of the entity?
location read lnsttnces of the entity?
location delete instances of the entity?
location ·update e:dstlng lnstances of the entity?
Systems analysts h.ave found it useful to define these logical requirements in
d:lt:i-to-locadoo.CRUD
the form of 2 dnto .to.Jocntlon.CRUD ,nntrl."t'.
m at rix amalrix thatisused
to map data rEQliremen~ to
a table In which the rows Indicate e ntitles (and possible attributes); the columns
in dicate locations; and the cells (the intersection of rows and columns) document
Jevel of access w here C create, R read, U update or modify, and D delete
or deactivate. Figure 8-24 illustrates a typical data-to-location-CRUD matrix. 111e
decision to indude or not include attributes is based on whether locations need to
be restricted as to which attributes they can access. Figure S.24 also demonstrates the
abUity to document that a location requires access only to a subset (designated SS) of
entity instances. For example, ead1 sales office might need access only to those
customers In Its region.
In some methodologies and CASE tools, you can define views of the data model
for each location. A view lndure.5 only the et1tltfes and attrlbutes to be accessible for
a single location. If views are defined, tJ,ey must also be kept in sync with the master
data model. (Most CASE tools do this au tomatically.)
locations.
=
=
i\
d a t :1.t0-loettlo o..·CR UD aut rix is:
=
=
/
Mosl of you will proceed directly 10 Chapter 9, "Process Modeling.• Whereas data
modellng was coocerned with data independently from how that data is captured and
used ( data at rest), process modeling shows how the data will be captured and used
(data in motioo). To take an object-oriented approach, you may Jump to a,apter I 0,
•object-Oriented Analysis and Modeling with UML" Object modeUng has many para~
lels with data modeUng. An object lndudes attributes, but it also ind,ldes aU the
processes that can act on and use those methods.
If you want to immediately learn how to implemtot data models as databases, you
should skim or read Chapter 14, "Designing Databases.• In that chapter, the logical
data models are transformed into physical database schemas. With CASE tools, the
code for creating the database can be generated automatically.
~ Summary
I. Data modeling is a technique for organizing and
documenth1g a system's DATA. Data modeling is
sometimes called database modeling because a
data model Is usually Implemented as a database
2. There are several 11otatlons for data modeling. The
3.
4.
5,
acnta.l model is frequently called an enuty reta1ionship diagram (ERD) because 11 depicts data in
1erms of the entities and relationships described
by the data.
.\n etltity Is somethh1g about whid1 the bushless
needs to store data. Oasses of entitles lndude
persons, places, objects, events, and concepts.
.\n entity lnstance ls a slngJe occtttrence of an
<'tltity dass.
Pieces of data we want to store about each instance of a givet1 entity are called attributes. An
attribute ls a descrlptl,-e property or characterls1ic of the ei1tity. Some attributes can be logically
grouped Into superanrlbmes caUed compound
attributes.
When analyzing a sys1em, we should define those
values for an attribute that are legitimate or that
1
6.
make business sense .111e "-alues for each attribute
are defined in terms of three properties- data
type, domain, and defu,tlt:
a. The data type defines wl1..1t class of data can
be stored in the attrlbu1e.
b. The domaln of an attribute defines what '\<'alues an attribute can Jegltim.ateJy take on.
c. TI1e default "-a.Jue for an attribute is the value
tha1 wlll be recorded If not spedJled by the
user.
7. Every entity must have an idet1titler or key. A key
is an attribute, or a group of attributes, tl1..1t assumes a unique value for each entity instance.
a. A group of attrlbmes tha1 wllquely ldentllles
an lnstance of an entity ls called a concatena1ed ke)'.
b. A candidate key is a •candidate to become
the primary ldentlfler• of Instance, of an
entity.
309
310
Part 1wo
Systoms Analysis Methods
c . A primary key ls the candidate key that will
most commonly he used to uniquely ldentif)• a
slngte entity instance.
d. Any candidate key that ls nor selected to
become the primary key Is called an alternate key.
e. Sometimes, ft is also necessary to Jdentify a
subset of entity h1Stances as opposed to a single IDStance. A subsettlng criteria is an attribute (or concatenated attribute) whose
flnlte values dJvJde all entity lnstances into
useful subsets.
8. A relatlonshJp ls a natural business assoc.L1tlon
that eusts between one or more entitles. The reL1tlonshlp may represent an event that litlks the entitles or merely a loglcal affinity that exists
between tl,e entitles. All relatlonsblps are Implicitly bldlrectlonal, meaning tl,ey can he interpreted In both directions.
9. Cardinality defines the minimum and maximum
number of occurrences of one entity for a single
occurrroce of the related entity. Because all relatlonshlps are bldlrectlona~ cardlnallry must be de-
10.
11.
12.
13.
fined in both directions for every relatlonshlp.
111e degree of a relatlonshlp is the number of entity c!as,es that participate in the relatlonsblp.
Not all relationshlps are binary. Some reL1tionshlps may he recursive relationships, wherelt1 the
relatlonshlp exists between different instances of
the same entity. Relationships can also exist betwee.n more than two different entitles, as ln the
case of a 34rj•, or remary, relationshlp.
An associative entity ls an entity that Inherits l!s
primary key from more than one other et1ticy•
(parents). Each part of that concatenated key
poh1ts to one and only one h1Stance of each of
the connectin.e: et1titles.
A foreign key ls a primary key of one entity that is
contrlbmed 10 (duplicated in) anod1er entity 10
ldet1tlfy instances of a relatlonshlp. A foreign key
(always In a child entity) always matd,es the
primary key (ln a paretll entity).
Nonldentlfying refationshlps are those in whld1
each of the partlclpatlng entitles has lts own Independent primary key, of whlch none of the
primary-key attributes is shared. The entitles In a
nonldentlfying refationshlp are referred to as
stro11g or lndependent et1titles because neither
depet1ds on any other ei1tl1y for Its ldentlflcatlon.
ldentif)ing reL1tionshlps are those In whld1 the
paretll entity contrlbmes Its primary key 10
become part of the primary key of the chlld
entit)'. The dilld entity of any ldentlfying reL1tlonshlp ls referred to as a 11..ieak entity because lls
ldentiflcation is dependent on the existence of
the parent entity's ex..l.st:ence.
t 4. A nonspecUlc refationshlp ( or many-to-many relatlonshlp) is one lo whJch many instances of one
entity are assoc.L1ted wlth many instances of 10other entity. Such relatlonshlps are sttltable only
for preliminary data models and shot~d be re
solved as quickly as possible.
15. GeneraUzation is an approach that seeks to d.lscover and exploit the commonalJtles between
entltles. It is a technJque wherein the attributes
are grouped to form ei1ti1y supertypes and
subtypes.
a. An entity supertype is an entity whose ln·
stances store attributes tl1..1t are common to
one or more et1ticy• subtypes.
b. An entity subtype ls an entity whose Instances
lnherlt some common attributes from an entity supertype and then add otl,er attributes
that are unlque to an lnstance of the subtype.
16. A logical data model ls developed In the followlng stages:
a. Entitles are disco,--ered and defined.
b. A context data modeJ ls bullt. A context data
model contains only business entitles and relationships ldet1tllled by the system owners and
users.
c. A key-based data model ls built.The key-0,1sed
model ellmlnares nonspecUlc refationshlp,
and adds associative entities. All entitles in the
model are given keys.
d. A fully attrlbmed model is built. This model
shows all the attributes to be stored h1 the
system.
e. A fully described model ls built E.1d1 attribute ls
defined lt1 the dlctlonary and described In terms
of properties such as domain and security.
f. The completed data model ls then analyzed
for adaprablllty and flexlblllty through a
process called normaUzatio11. The final anllyzed model ls referred 10 as a thlrd normd
form data model.
17. A logical data model does not comm,u,lcate dita requirements on a business operating location basis.
S)'stems analysts hm, fow1d It useful to define
these requirements in the fonn of a data-to.locitionCRUD matrix.
Data Modollng and Analysis
dlaptw Eight
311
\';::?; Review Questions
c>
I. What Is the difference between logical and physi-
cal models?
2. Why ls it lmponant to create an implementatlonlndependetll model of a S)'Stetn?
3, Why ls it necessary to create an lmplementatlondepet1dent model of a systetn?
4. What Is an entity? What are entity instances?
5. A re/aH011sbtp Is a natural business association between entitles. W11at is the relationship between
student and teacher? Does ft depend ou how many
classes a student can take, or how O:Wl'/ classes a
teacher can teach?
6. What is cardlnallty? Gh-. an example.
@:
l. What ls a reasonable domaln for the data anribu1e
for a student's last name?
2. What def.nut value would you choose for a
student's last name?
3. What def.nut value would you choose for gender?
4. The student table you are working with contalns
the attrlbutes: sruomr m ,NAME, PHONE NUMBf.ll,and
NormaUze to 3NF.
MAJOR.
5, What attributes would you ha,--e in a table to
descrlbe a movie?
6 . .\ many4o-many reL1tionship (also called a nonspeclflc relatlonslllp) can and generally should he
re.solved into a pair of one.-to-many relatlonstl.ips
with an associative et1tlty. When is th.ls not the
case?
Problems and Exercises
7. Gfve an example of a many-to-many reL1tlonshJp.
Re.solve using an entity or an as.,odattve entity.
Which dld you use? Why?
8. Describe each of the first three normu forms.
Gfve an example of each.
9. A customer goes to a shoe store and purchases
several palts of shoes. Diagram this relationship.
10. Give an example each of ternary, ldent!fyh1g, and
nonidentlfylng reL1tionships.
11. On the surface, data modeling appears not to re.qtdre much creatlvtty. Why is this incorrect?
12. Can a well-desJgned database give a buslness a
strategic advantage? How?
~ Projects and Research
I. Go to the school library. Ask the librarian at the clr-
cuL1tlon desk to prlnt out a copy of the information they keep on you. What types of data are
belng stored? ls there anything that surprises you
or seems irrelevant to checking out books? If so,
ask why the lnformatlon ls collected.
2. Create a list of attributes for the srudet1t entity
from the h1fonnatlon you found h1 the prevloltS
problem. Normallze to third normal form.
3. Go to a grocery store and make a purdiase. What
type of data would a good Information system
maintain on a traosactlo11? What does a good h1foFmatlon system do for a business?
4. Compare your at1SWer from the above question
(grocery store) to tl1.1t of at least one other
student How were your at1SWers dtfferent?
5. What legal and privacy Issues are related to databases used by grocery stores? Go to http://www.
ff.ndla1v.co111 and research some recent court
cases on the topJc. Pre.sent your work in a short
(tlve-page) paper to your class.
6. How can databases, and the information kept In
databases, be used by businesses for a !trategi.c ad'\o-antage? In a small group, go to a b ush1es., of yolU'
choosing. Bralnst:onn to create a database that offers that company either a solution to an existing
problem, or exploits an exlstlng opponurtlty in
business. Reme.mbe.r to be creatt,--e.
312
Part 1wo
Minicases
Systoms Analysis Methods
{:]J
I. Consider a lktitlous 01illne grocery store called
Step 6.
Wow ,_funchJes.11lis ls a national frandlise,complete wllh marl<etlng, accounting, slllpplng, and
customer service departments. The CIO has decided to update the database correspondlng to the
Web stote so that lt collects pertinent transaction
and shopping information for the different departments. She ls undecided what software or hardware will support this database.
Step I.
Step 2.
How wlll you determlne what data ls
important to collect and malntaln in
the new database? Be specific.
Create surveys, questionnaires, and the
llke, and admJnlster them to approprl3.te personnel in the affected depnrt
Step 3.
Step 4.
Step 5.
ments. Review the fonns that each
department uses.
What kind of responses did you get?
Go to an 01illne grocery store, and see
what data ls belng collected by"rlval"
companles. Old you miss anything? Did
any of the responses you get requlre a
secondary meeting with department
personnel? If so, revise your sur,--e}'S
and questions and reh1tervJew.
Utilize the methods you outlined h1
the above question, and ascert.ai.n the
entitles and attributes you will need to
lndude in your data.
Draft the relationships and cardinality
between the e11tltles. What kind of data
model are you using? lmplemet1tatlon
specific or nonspeciJlc? Why?
Revise your data model so that t!,ere
are no many-to-many relatlonsh1ps,
and the model ls normalized to third
normal form.
Step 7.
Subntlt all questionnaires, surveys,
forms, and responses to your professor,
along with your final data model draft.
Include a short explanation as to how
you derfved your entitles and attributes
and the relationships and any assumptions or llmJtatlons your data model
may ha,--e.
2 Research a car rental agency and create a data
model for its database for car rentals. What departments are :affected by the ttntal of a Cl.t? Re
view any forms publiclj• available and create
surveys and interviews as necessary to help you
detennlne wl1..1t your database should contaln. Be
sure to normalize to third normal fonn and to resolve any many-to-many relationshlps. SUbmlt your
data model and all supporting documents to yottr
professor.
3. Consider t!,e Mafia. Assumh,g that organlzed crime
groups maintaln databases to e\o-ade capture and to
rw1 their businesses, what lnformatlon would they
keep?Why?
4. What legal, etlllcal, and privacy Issues are associated with databases used h1 crime fighting? Research and present a short paper {tett pages 01
less) to your clas.,.
Team and Individual Exercises
I. Project managemetll In a geographically and cui
rurally dispersed team is dlflkttlt. For each team
member, assJgn the member to a country wJth a
different time zone and dJfferent languages. Assume all members share one common language,
although that language will not be a first language
for all members. Ex.ample countries: USA, l11d11,
Israel, Chlna, Pakistan, Iran, France, Peru, and
Japan.
2 . lndlvldlltl exercise: It is sald that the bow1daries of
our own creativity are ourselves, and our experiences. That is, the very thlngs that make us wl10
we are also constrain. us. Wh.at does it mean to be
creative? How do you become creative and to
think freely?
3, lndtvJduaJ or team exercise: Reet1glneer a common life process. If the "sky was rhe limlt," how
would you dtange this process? Identify each of
the steps In the old process and then each step in
the new process (e.g., putting on makeup, deaning the h.ouse, going to the grocery store, golllg to
class) . Bring your notes to class for a row1dtabJe
dlscussJon.
Data Modollng and Analysis
dlaptw Eight
313
r) Suggested Readings
Bruce, Thomas A. [}(!Sfgntng Quattty Databases uJl.rb
/DEFIX ltifortnatton Alodefs. New York: Dorset Ho use
Publishjng, 1992. We actually USC' this book as a textbook
in our database analysis and design coul'SC'. IDEFlX is a
rich, standardi.'1.C'd syntax for data modeling (vvhich Bruce
caUs infonnation modeling). The gtl.phkal language looks
cUifc.1t:nt, but it cornmunkatcs the same system concepts
pn-scntcd in our book. The language is supported by a.t
lc,st tv.•o CASE tools: Logk Works' ERtlJIIJ and Popki.n's
S)1Sle11J Arc!Jtt.ecl. The book includes t\\'O case studies.
Hay, Da,'ld c Data Alo<lel Rltter11S: C0111,1tu1tto11s ofTbougl•t,
N~ York: Dorsct House Publishing, I 996. What a nm.'t':I
book! This boo k starts v.•ith the prcrnisc that blOSt busi·
llC$S data models arc ckth'llth-c-s of some bask, l'C'pcatablc
pattc.rns. CASE ,,:odors, how about induding these
pattcms in CASE tools as reusable templatcsl
Mw.1.i1i, fti.uK'.!>, a.uJ Cli ,·c fi.ulr.cblcih. J11for111arton E11g1ueer·
t1Jg. 3 ,o ls. New York: Sa,':Ult Institute, 198 1. Informat.ktl
cnginttri.n.g is a fo rma~ database, and fourth-gdlel'.ttktl
language-oriented methodology. The gtl.phic d data model·
ing language of info rmation engineering is ;•irtually idc:n·
tical to ours. OJ.ta modeling is co,'C'.tcd i.n Volumes I and D.
Reingrubc,; l'itichael, and William Gtcgoty. The Data Alodeltng
Hanaboo'1. New Yotk:JolU\ Wiley & Sons, 1994. This is an
cxcc:llcnt book on data modeling and is partini.larly heJpful
in ensuring the quality and accuracy of data models.
Schlae,; Sally, and Stephen). Mellor. Objec.t-Ortnlted sysre1ns
A11af)1ru· Atoaett11g tbe Wf.Jrld tn Data. Englewood Cliffs,
N):Yourdon Press, 1988. Forget the title! •obi«t-oricnted"
means soblC'thing different today than it did. in 1988, but
the book is still one o f the easiest-t~ ttad books on the
subj«t of data modeling.
Tcorey, Toby J. Database Alodeftng & Destg,,· Tbe F1111a~
11ie11tal P,•flu:..fples, 2nd ed. San fl'.Ulci.sco: .\fo rpn Kataf·
man Publishers, 1994. This book is somewhat more
-.:v lll.:OCJJUa.J ll~, l.11,c v l11c1·l> iu tJ.1c li:>1., Uul il vruviJc~
uscfti.l insights into the practice o f data modeling.
Slrablgle 1nn:inna11on S)'Stelr6 Plan
strategic £rterp11Se Pian
-
STR"EMENT OF WOFt<
-
PA081.EW SUJEt.EN'f (uf1'9UIP Pl:CESIIWII-")
.....
.....•
f.lFO,-.RlON
SCOPE
-
... )
2'°
•
V U$10N
w~
~w
>.
"0
..
"
..
....
.....•
FI.IICl'IOW.L
COMWl.tllCATlONS
SCOPE
SYSTEM 1...FIOiEMENT 08JEC11VES (ulrg O. PIECES IIWll-'C)
I!
8USf.lE:'SS FEOJIFIEt.ENTS ST.UEt.EN'f
>
c
z
c
-
•)
2
I!!
>
r
..
• ..
,
.. ..
..
....
8U61NESS
AEOUIFEWEHTS
EIJSINUS
8USIIES8 & 6't'STEM
"""°'"'
llftt:FFAOE
AEOUAEMENTS
........
'°"'...
'"""'°'
FEQJIFEIENTS
LOGICAL
u>GOC...
ORA
WOOELS
MOOEl.8
•ODEl.8
v
c
~
SY.S TE• PFIOPO& AL (or
w
2
w
~
tlJ
c
~
>
cz
2
~
"w
~
0
A FICHITECTUIJA L •OOEL
-
0
l?
ffi
",
0
•
!
s•
-
-
-
ti
H
H
.II ~
~
•
i!
-
~
REQUES T F <J R .SY.STE• PROPO SALS )
H
;
"~
OE&IGN PAOTOTY~E&
A
8USHas PFIOCE89
.........
"'""
""'80CM.
INTERFACE
DESIGN
PHY61CAL
80FTWNIE OESIOII
SPECFICATIOKS
"'""
SPECIFICATION$
FUNCTION AL .SY&TEM
w
I
•
0
'
OPER A TION A L 8Y8 TE•
6PECIFIOOIONS
•FIAIHIHG M ATERI A L S
so,,_.,
eot,MCfle.lH.
.........
.......°"
PHYSICM.
U6&1 & SYSTEM
"""
,-Q<AOES
•
0
0
SOWTIONS
CUSTOM.8un
APPUC.UION
I
m
SOWTIONS
so,,_.,
INTERFACE
SYSTEM
INTERFACE
POST- AUDIT RE V IEW
........
.........
APPFIOiEO
TECl+IOLOGfES
strategic eiterprtse 1nn:irma11on TectnclOgy AfChnecture
•
-
-
":D
em
;
0
i0
Q
~
,•"
~
0
"a
~
.m
..a
0
m
"'"'
I
•"'z
"•m
1
I
"'z
i
m
"
i
•
I
!
f
t
~
•la
I
I
I'
I
f
•
f
I
~! ! ••
L...:!_
A
i"":"&
~
IA
I~
I
J!_
u
i
-
-
Process Modeling
Chapter Preview and Objectives
In this chapter you will learn bow to draw data flow diagrams, a popular process model
that documents a system's processes and their data flows. You will know process
modeling as a systems analysis tool when you can:
I Define systems modeling and differentiate between logical and physical system
mxlels.
I Define process modeling and explain its benefits.
I Recognize and understand the basic concepts and constructs of a process model.
I Read and interpret a data flow diagram .
I Explain when to construct process models and where to store them .
I Construct a context diagram to illustrate a system•s interfaces with its environment
I Identify use cases and external and temporal busine.s~events for a system.
I
PiF,rfnrn, event p~rtitinnine :1nrl nrz~ni7e event~ in
:1
f11nctinn~I rlP.r:nn1pN.itinn rli~zr~m.
I Draw e\o'ellt diagrams and then merge those event diagrams into system diagrams.
I Draw primitive data flow diagrams and describe the elementary data flows and
processes in terms of data structures and procedural logic (Structured English and
decision tables), respectively.
I Document the distribution of processes to locations.
I Synchronii.e data and process models using a CRUD matrix..
316
Part 1wo
Systoms Analysis Method s
Bob ,_lartloez has beett working on the SoundStage ,_lember Sen-ices ~tern for several weeks. He w1derscands the system pretty wel~ but It is still easy to get confused
and to forget details.
•n,e problem; Bob said to his boss, Sandra Shepherd, •is that the system ls too
big to keep It all In your h ead ai one time.·
.. I'm glad you said tl1at," Sandra answered, ...because your next assignment is to
break the system down into parts that you can get your h ead arow1d. Each part ls
called a process, and you'll need to define the lnputs and outputs to tl1at process plus
who or what ead1 input and output comes from or goes to . And, by the way, ~·ou'U
need to specify the logic for the process.•
• 1 thought the use cases did all that; Bob replied.
..They aren't specific enol~h." Sandra stated. "Would you like to runt a project
over to a programmer located across the cotmtry wlth no more specifics than '\\11..1t a
use case has? Who kt1ows what you'd end up witlt? \X'elcome to the world of process
modeling, Bob. Get to work.'
~~~A_n~ln_t_ro_d~u_c_ti_o_n_t_o~P_ro_c_e_s_s~Nl_o_d_e_l_in_g~ ~~~~~~~~~~~~)
In Chapter 5 you were introduced to systems analysis activities that called for drawing system models. System models play an lmponant role In system development. As
m odel a picbrial represen.
tation of reality.
logica.J m odel a nontechni.
cal pictorial re.,resentation
that depicts what a system
is or does. Synonyms are
sssent aJ mo~~ conceplJaJ
mode~ and busin9SS model.
p h }'Sical model a technical
pictorial representation that
depicts what a system is or
does and how the system is
implemented. 3ynonyms are
impl9frt9ntatio.r, rnod91 and
techriC81 mod>I.
a systems analyst or user, you wlUconstantly deal wJth unstructured problems, One
way to structure such problems is to draw models. A m od e l is a representation of
reality. Just as a plcture ls worth a thousan d words, most ~·stem models are plctorlal
represetllations of reality. Models can be built for existing systems as a way to better
underSland tl1ose systems or for proposed $)'stems as a way to document business
requirements or technical desf@tlS. An important concept ls the distinctlon between
logical and physical models.
Logical models show wbat a system is or does. They are impJementatloo/ndependet1t; that Is, ti,ey depict ti,e system lndepet1dent of any tedmlcal lmpleme0,
tatlon. As such, logical models Illustrate the essence of the system. Popular synonyms
indude essential n1.odel, co11.ceptu.al tnode4 and b·ust11ess ,node£. Physical m odels
show not only tlJbat a system Is or does but also botlJ the system ls physlcaU-y and
techn.ically lmplemented.111ey are implementation-dependent because they ttflect
technology choices and the timltatlons of those technology choices. Synonyms
indude i111ple1ne11tatton n1.odel and teclnif.cal tnodeL
Systems analysts ha,--e Jong recognJzed the '\o-a.lue of separating business and technical concerns. 1bat is why they use logical system models to depict business requirements and physical system models to depict technlcal designs. Systems anllysis
activities tend to focus on the logical system models for the following reasons:
Logical models remove biases that are the res,dt of the way the current system is lmp lemetlled or the way that any one person thinks the system mlght
be lmplemented.111us, we overcome the "'\ve"ve always done It tl1at way"
syndrome. Consequently, logical models etlCOtll':tge creativity.
LoglcaJ models reduce the risk of missing business requirements because we
are too preoccupied with tedulical details. SUd1 errors can be costly to correct after the system is Implemented. By sepanting what the system must do
from l1ow the system will do it, we can better analyze the requirements for
comp leteness, accuracy, aOO consistency.
LoglcaJ models allow us to communicate with end users ln nontechnical or
Jess technical languages. T hus, we don't Jose requirements in the technlctl
jargon of the computing discipline.
Procoss Modollng
In this chapter we will focus exduslvely on logf.cal process modeling dnrlng systemsan~ysls. Process modeling Is a technlque for organizing and documenting the
structure and flow of data tlvough a ~·stem's PROCESSES and/or the logic, policies, and
procedures to be Implemented by a ~tern's PROCESSIS. ln the context of Information
system bttlldlng blocks (see the home page at the beginning of the chapter), logical
process models are used ro document an information system's PROCESS focus from the
system owners' and users• perspective (the intersection of the PROCESS column with
the system owner and system user rows). Also notice thar one special type of process
model, called a co1,te."l(t diagra·,n, illustrates the coMMUNla.nON focus from the system
owners• and users• perspective.
Process modeling originated in classical software engineering metl1ods~ therefore, you may have encountered various types of process models such as program
structure d1arts, logic flowd1arts, or decision tables in an application programmJng course. In this chapter, we'll focus on a systems analysis p rocess model, data
d,aptw N lno
317
process modeling a
technique used to organize
and document a system's
processes.
flow diagrams.
A data Oow dfagram (DFD) Is a tool that depicts the flow of data through a system ,nd the work or processing performed by that system. Synonyms Include bubble
chart, rra11sformatlo11graph, and process modeL We'll also introduce a DFD pL1ll1llng
tool cnlle-d dcco111podtio,1. dlagra,11&. Fln:illy, we'll 11.ro study
CO"lllA"<t
diagran,s, a
p rocessllke model t11at actually illustrates a system's Interfaces ro the business and
outskle world, induding other information ~·stems. 1
A simple data flow diagram Is Illustrated h1 Figure 9-1. In the design phase, some
of these business p rocesses might be implemented as computer software (either
built lo-hottSe or purchased from a software vendor). If you examine this dara flow
diagram, you should find Jr easy ro read, even before you complete this chapterthat has always been the advantage of DFOs. There are only three symbols and one
connection:
data Oow diagram (DFD)
a process mod~ used to
depict the flow cf data through
a system and th9 work or
processing perrormea riy tne
system. Synony.ns are bubb/9
chaf! tl1lf1Sb,-ion gap,,
and procoss mcdol.
The rotmded rectangles represent processes or work ro be done. Notice
th.at they are illustrared it1 the PROCESS color from your lnformatlon system
Cramework.
The squares represent extern.al age11.ts- the OOlmdary of the system. Notice
th.at they are illustrated it1 the INTERFACE color from your lnformatlon system
Cramework.
The opefl-(>nded boxes represent data stores, sometimes caUed files or databases. If you h.ave already read Chapter 8, these dara stores correspond ro all
Instances of a sh1gle entity ln a data model. Accordingly, they ltave been illus.
trared wJth the DATA color from yottr Information systems framework.
The arrows represent data flotlJS, or Inputs and ourpurs, ro and from the
processes.
There is sometimes a rendet1q• to confuse data flow dtagrams with flowcharts because program design frequently Involves tl1e use of flowd1arts. However, data flow
dL1giams are very different . Let's stunmarlze the differences.
Processes on a data flow dL1gram can operate In parallel. Thus, several
processes mlghr be executing or working simultaneously. This ls consistent
with the way businesses work. On tl1e other hand, processes on flowcharts
can execute only one ar a time.
Data flow diagrams show the flow of data tlvough tlte system. Their arrows
represent paths down whlch data can flow. Looping and branching are not
typically sJ1own. On the other hand, flowcharts !how d1e sequence of proc~es
or operations in an algorfthm or program, Their urows represent pointers ro
the next process or operation. This may h1dude looping and branching.
1lb c:bui.c structured il.llldy,i$,contut diliSfll--lnJIIN' ooblidd"l'd to bC' 11bothd-type ofptoc:e,ts tnodr.L But it! object.
oric:bt«I il..llll..tyu, they illu,ltllte ,oope ILlld in.tttf.aoes. lb tbi$ editiotl. • ·c: hll\~ ch:»ctl the btm dc:6bitiob.
Author's Note: there are
several competir1g symbol
sets for OFDs. Throughout
this chapter, theauthors have
ohooen to U3e the Cane and
Sarson notation because of
its wide popu larty.
318
Part 1wo
Systoms Analysis Methods
Monthly Account
stalffllenb
New or ~odified
Monthly Statement
Bank
.
Reconcile
Account
Balances
i
Bill
Credtor
'
Monthly
Statement
'
Pay
Payment
a
Bill
Transaction
I
Account
Balance
.
~
.
I
Prior Monttlly
Statement
Current
Balance
Account
Tran,actiots
Bat* Atcounts
..
Credit
Payment
..
Debit
••
.
Atcount
Tra11SaCtion s
-
-
Deposit
Withdraw
Funds hm
an Areoont
•
Withdraw or Transfer
Employer
Pay
OeposHFmds
into an
Account
Bat*
• Data store duplicated only to prevent crossing lines
Other
Income
Source
Reimbursement
C ---------F I GU R E 9 • 1 A Simple Data Flow Diagram
.._.
)
Procoss Modollng
d,aptor Nino
319
Data flow dL1grams can show processes thar Juve dramatically different timing. For example, a single DFD might indude processes that happen hourly,
daUy, weekly, yearly, and on demand. Tills doesn't happen In flowcharts.
Data flow dL1grams have been popuL1r for more d1an 20 years, bur the Interest In
DFDs has been recently renewed because of thelr applicablllry In busl11ess process
redesign (BPR). As businesses h.a,--e come ro realize thar most data processh1g systems
have merely auromared outdated, inefficient, and bureaucratic business processes,
there ls ret1ewed Interest in streamlining the business processes. Th.ls ls accomplished
by fust modeling the business processes for the purpose of analyzing, redesigning,
and/or improving tl1em. Subsequently, lnformation t<cbnology can be applied to the
improved busfr1ess processes In creath,--e ways that m.axlmfze the '\<'alue returned to the
business. We'll re\oisJt this trend at the end of the chapter.
( System Concepts for Process Modeling
>
External Agents
All information systems respond ro events and condJtlons in the $)'stem's ettvlronment. The en"ironmenr of an infonnatlon ~tern indudes extern.al agents that form
the l:otmdary of the system and define places where the system interfaces wJth its etlvironment An external agent defines a person, an org.ul.ization unit, another ~·stem,
or another orgail.izatlon thar Ues outsJde the scope of the project bur that interacts
with the system being studied. External agents provide the ner lnputs lnro a ~·stem
and receive ner outputs from a system. A common ~·nonym is extern.al e1J.ff.ty (not to
be confused witl1 data entity as introduced In Chapter 8).
The term external means ..external ro the system being analyzed or designed." In
practice, an external agenr may actually be outside of the business (sud1 as gover11men1agencies, customers. suppliers, and contractors). or It may be Inside the business
but outside the project and system scope (such as other departments, other business
functions, and other internal information systems). An external agent ls represented
by a square on the data flow diagram. The De.lttarco/'iOurdon equJ:valenr ls a rectangle
(see margin).
It ls Important to recognize thar work and acth·ities are occurrlng insJde the
extemaJ aget1t, but t11..1r work and t11ose activities are said ro be ..our of scope" and 11or
subject ro d1..1nge. Thus, t11e dara flows between your system and these bow1darles
should not cause substantive cban,ae to the work or actlvJUes performed by the
extemaJ agents.
The external agents of an information system are rarely fixed. As project scope
and goals change, dte scope of ai1 infonnatlon system can eid1er grow or shritlk. If the
system scope grows, it can consume some of the original exten1..1I agents- in other
words, what was once considered outsJde tlte system ls now considered inside the
system (as new processes).
SlmlL1rly, lf tJ,e system scope shrinks (because of l>udget or schedule constraints),
processes thar were once considered ro be ittsJde the system may become external
agents.
External agents on a logical data flow dlagram may lndude people, business uolts,
other Internal ~tems with which a system must interact, and external organJzatlons.
Their indusion on the loglc:tl DFD means that your system interacts with these
agents. They are almost always one of the following:
Alt office, departmet1t, di,ision, or ittdtvldual widt.itt your company rl1..1r pro'rldes net lnputs ro d1..1r system, receives net outputs from that system, or both.
Alt organization, agency, or lndtvidual t11..1r is outside your company bur t11..1r
provides net lnputs to, or receives net outputs from, yottr ~·stem. Examples
Include CUSTOMERS, SUPPLIERS, CONTRACTORS, BANKS, and GOVf.RNMf.NT AGENOES.
exter-oal ageot an outside
person, organization unit, SfStem, or organization that inter.
acts with a system. Also called
external Mt;fy.
External
Agent
G,ne and Sen~on • hape
External
Agent
OeM areo/You:rdon • hape
External Agent
Symbols
320
Part 1wo
Systoms Analysis Methods
Another business or infon:natlon ~·stem- posslbty, though not nece~arUy,
computer-based- tl1..1t is separate from your system but wlth which your
system must interface. It is becoming common to interface infonnatlon SJ'Stem.s with those of other businesses.
A ~tern's end users or minagers. ln this case, the user or manager ls either
a net soucce of data to be input to a ~tern ancVor a net destlnatlon of outputs to be produced by a system.
External agents should be named with descriptive, sfoguL1r nouns, such as R.F.GJS. or RNANCI.AL INflOR.-\tATION SYSTE."1.. External agents
represent fixed, physical systems; therefore, they can have physical names or
acronyms- even on a logical DFO. For exampJe, an external agent representing our
school's financial management Information system wot~d be called FNJS. If an external
TRAR, SUPPUER, M.ANUFACTUIUNG ~
agenr describes an indhidual, we recommend job titles or role names Instead of
proper names (for ex.ample, use ACCOUNT CLERK, not ,llaryJacobs).
To avoid crossing data flow Uoes on a DFD, It ls permissible to duplicate external
agents on DFOs. But as a general rule, external agents should be located on the
perimeters of the page, consistent with thelr dellnltlon as a system boundary.
,. Data Stores
data store s:ored data
intended for later use.
Synonyms are file and
dBi.abase.
,_lost information systems capture data for later use. TI1e data ls kept in a data store,
the last symbol on a data flow diagram. It ls represented by the open-et1d box (see
margin). A data store Is an •inventor)'" of data. Synonyms lndude file and database
(although those terms are too lmplemet1tatlon-oriented for essential process modeling). If data flows are data 111 ,notion, tllink of data stores as data at fr!St.
Ideally, essential data stores should describe • things· about whlch the business
wants to store data. These tlllngs indude:
Persons: AGENCY, CONTAACTOII., CUSTOMER, DEPART~ DMSION, fl\lPLOYEE, INSTRUC'i'OR,
omcE, STUOENT,sUPPum.. Notice that a person entity cut represent either
lodtvJduals, groups, or org.·ulfzatlons.
II
PL1ces:SALES REGION, BUILDING, ROOM,BRANCH OFFICE, CAMPUS,
Objects: BOOK, MJ.CKCNE, PAR~PRODUCT,
Data Store
Gane tnd s,reon • h•pe
R.AW MATERlA.L, SOPTWAR.E LICENSE, SOPTWAR.E
object entity can represent actual
objects (such as SOl'l'WARJe LICENSE) or speclflcatlons for a type of object (sud1
as SOFTWA.11.E PACKAGE),
Events: APPUO.nON, AWA.llD, Q.NCEU.ATION, CLASS, FLIGHT, IN\OICE, ORDER, REGISTR.ATJON,
PACKAGE,TOOL, VEHICLE MOD!L, VEHICLE. An
RE'IBWA.L, REQUISmON, R.ESER'IATION, SALE, 'JlUP.
Concepts: ACCOUNT, BLOCK Of TL>,.tE, BOND, COURSE, flllND, QU\UFla.noN, STOCK.
Data Store
NOTE: If the above list looks famUL,r, it should: A data store represents aU occu.rrences of a data et1tlty~fined In Chapter 8 as sometlling about which we want
OeMarco/Yo~don •Nipe
to store data. As such, tl1e data store represet1ts the $)'nchronlzatlon of a system's
process model with Its data model.
( Data Store Symbols)
If data modellng ls done before process modeling, ldentlllcatlon of most data
stores ls slmpllfled by the following rule:
There should be one data s:ore for each data entity on an entity relationsh.ip dL1gram. (We even lndude associative and weak entlt:y data stores on our models.)
If, on the other hand, process modeUog Is done before data modeling, data store
dlsco,-ery tet1cls to be more arbitrary. In that case, our best recommendation is to identify existing implementations of tlles or data stores (e.g., computer tlles and databases,
file cabinets, record books, catalogs) and tl,en rename them to reflect the logical
.. things• about wll.ich they store data. Consistent with Information engineering suategies, we recommet1d tl1at data models precede the process models.
Get1erally, data stores should be named as the pJural of t11e corresponding data
model entity. Thus, If the data model lndudes an entity named cusroMEt, the process
Procoss Modollng
d,aptor Nino
321
models will include a data store named CUSTOMERS. 11is makes sense because the data
store, by definition, stores all instances of ti1e entity. Avoid physical terms such asjlle,
datal:>ase,fl/e cablne~ JUe folder, and the like.
As was the case with boundarles, It ls perm.lsslble to duplicate data stores on a
DFD to avoid crossing data flow lines. Duplication sbotdd be mlnlmized.
>
Process Concepts
RecaU from Chapter 2 that a f<u1Clametllal bulldh,g block of infonnatlon >)'Siems is
PROCESSES. All lnformation systems indude processes-- uslally many of d1em. lnfonnation
system processes respond to business e,--ents and conditions and transfonn D.\TA (another
building block) Into useful lnfurmation. Modelh,g ptocesses helps us to understand
inten.ruons with the ~em·s environment, od1er systems, and other processes.
A System 11 a Process We have used the word S)~e,n throughout this book to describe almost any orderly arrangement of Jdeas or constructs. People speak of educational systems, computer systems, management ~·stems, business systems, and, of
course, information systems. In the oldest and simplest of all system models, a system
Process name
G,ne & Sarton •Npe;
used throughout
this book
Is <l ptVi.:~:,.
In systems analysis, models are used to view or pre.sent a system. As shown In
Figcue 9-2, the simplest process model of a system is based on Inputs, outputs, and the
system itself- viewed as a process. The process symbol defines the boundary of the
system.11,e system is Inside the bow1dary; the en,iroometll Is outside that boundary.
The system exchanges lnputs and otnpurs wJth its en"ironmenr. Because the en"i·
ronrnenr is always d1anging, well-designed ~tem.s have a feedback and control loop
to allow the ~·srem to adapt Jrself to changing con ditions.
Consider a business as a ~·stem. Ir operates wJthln an environment thar indudes
customers, suppliers, competlrors, other Industries, and the government. Jrs lnputs
include materials, sen-ices, new employees, new equipment, facilities, money, and
orders (to name but a few), Its outputs lndude products ancVor senices, wasre
r FIGURE 9 - 2 '
The Classic Process
Model of a System
The
System as
a Process
Feedback and
Control loop
The Syslem's Environment
(constantly changing)
322
Part 1wo
Systoms Analysis Methods
process wor:< performed
by a system in response to
incoming data flows or condi·
tions. A synonym is tan.dorm.
materials, retired equlpment, fonner employees, and mon ey (payments). It monitors
its en'\oironment to make nece.ssary changes ro its product Une, services, operatfrlg
procedures, competitors, and the economy.
A rounded rectangle (the Gane and Sarson nomtlon) ls used tbrougl1our tllis clupter ro represent a process (see margin). A process ls work performed on, or in response to, incoming data flo"''S or condJtlons. A synonym ls tra11sfort11. Dlfferent
process modeling notations use a circle (the Oe,.larco/Yourdon n o tatio11) or a ttctangle (the SSADM/IDEFO notation). The d1oice is often dependent on your metl1odology
and CASE tool features.
Although processes can be performed by people, departments, robots, machh1es,
or computers, we once again want to focus on t1Jbat work or action ls being performed (the logical process), not on who or what ls doing tl1at worl< or activity (tl1e
pbysrca/ process). For instance, in Figure 9-1 we included the logical process WITHDRAW FUNDS FROM AN ACCOUNT. \X'e did not indJcate how dlis would be don e. lntuiti,-ely,
we can tbitlk of several physkal Implementations sud1 as using an AT~t, uslng a
bank's drive.through senice, or actually going Inside the bank.
Process Decomposition A complex system ls usually too difficult to fully underst:ind when "i ewed as a who le ( mean.Ing as a d,iglo proc<!$$), 11,erefore, in s~tems
decomposition the act of
breaking a syEtem into sub·
components.
,,
analysis we separate a system into lts component sub~tems, which are decomposed
into smaller subsystems, until we have Identified manageable subsets of the overall
system (see Figure 9-3). We call this technlque decomposition. Decompositio n ls tl1e
act of breaking a system Into Its component su~ ·stems, proce~es, and subprocesses.
Each level of abstraction reveals more or less detail (as desired) about the overall system or a subset of that system. )'ou have already applied decomposJtion In various
ways. ,_lost of you ha,--e outll1iet:' a term paper- this ls a form of decomposition. )lany
of you have partition ed a medium- to larguJze computer program Into subprograms
that cot~d be developed and tested Independently before they are h1tegrated.This is
also decomposition.
ht ~·stems analysis, decomposition allows you to partltio11 a ~·stem lnto lc,glcal
subsystems of processes for Improved communication, analysis, and de.sign, A diagram similar to Figure 9-3 can be a little difficult to construct when dealing with all
~
0
FIGURE 9 - 3
A System Consis ts
o t Many
S ubsystetnS and
Processes
The System
/
,,
1.1
[
[
\.
) [
Taak1.1.1
Taak1.1.2
Tuk t ,f .S
-
I
)
'
1.2
Ad vity ol lte f11co11
',,
'
1
A Fmctton of the ~e11
Activily ol Utt Fmction
Taak 1,2,f
)
)
\.
I
Taak 1.2 .2
)
2
Another Fm dfon ol the ~lem
'
2.1
Aclivily ol U.. floctiln
[
Taak2..1.1
)[
Task t ,f .2.
)
(
Tuk 2 .t ,S
)
[
Taak1.1.•
)
I
~
'
2.2
-
Activity ol ttis F11clion
r , •2..2.,
I
)
[
Tuk 2 .2,S
Taak 2..2.2
)
)
Procoss Modollng
d,aptw Nlno
323
0
The System
I
I
I
1
A Functloo
2
Another
Funcaon
I
I
1.1
ACIIYIIY or the
Function
1.2
Another Aet1¥1IY
of the Function
Task 1.1.1
-
Task 1.2.1
-
-
Task 1.1.3
-
22
Another AcUwlly
of This Function
Task 2.1.1
-
Task 1.2.2
Task 1.1.2
-
2.1
ACIIYlty Of This
Function
Task 2.2.1
Task 2.1.2
-
Task 2.2.2
-
Task 2.1.3
-
Task 2.2.3
-
Task 2.1.4
-
C _ _ _ _ _ _ _ _ ______,
F I GU RE 9 • 4
~·
A Decomposition Diagram (fo r Figure 9-3)
but the smallest of systems. Figure 9-4 demonstrates an alternatfve layout that ls
supi:orted by many CASE tools and developmen1 methodologies. It is called a
deco1npositio11 diagratn. We'll use ft extensively In this d1apter. A d ecompositio 11
diagram , also called a hierarchy chart, shows the top-down ftu1ctlo11al dec omposJtion and structure of a system. A decomposition d.agram is essentially a planning
)
derom J>ositioo diagram
a tool used to depict the
decomposition of a system.
Also called hiorarctff cm.rt.
324
Part 1wo
Systoms Analysis Methods
tool for more detailed p rocess models, namely, data flow diagrams. The following
ntles apply:
Ead1 process ht a decomposition diagram is either a pare11..t process, a cbl.ld
process ( of a parent), or both.
A parent tnust have two or more cbUdren- a single child does not make
setlSe because that would nor reveal any addJtional detail about the ~tem.
In most decomposition diagramming standards, a child may
ha,-. ortly one
parent
Flnally, a child of one parent may be the parent of Its own children.
The upper and lower halves of the decomposition diagram In Figure 94 demoostrare two styles for L1ylng out the processes and connections. You may use either or
both as nec essary ro present an uncluttered model Some models may require multiple pages for maximum clarity.
The connections on a decomposltio11 diagram do 11ot contain arrowheads be-
cause d1e diagram ls meanr ro show srruct1,re, not flotl.J. Also, the connections are nor
named. Implicitly they aU have the same name-cONsISTS OF- since the sum of the
chlld p rocesses for a parent process equals the parent process.
Logical Processes and Conventions Logical processes are work or actions that
must be performed no matter how you implement the system. Each l ogical process
is ( or will be) Implemented as one or more physJcal processes that may include
work performed by people, work performed by robots or madllnes, or work performed by computer software. It doesn't matter which Implementation ls nsed,
however, because logical processes should only indJcate that there is w ork that
must be done.
Namit1g convet1tions for logical proce.s.,es depend on where the process ls in the
decomposltlon diagram/data flow diagram and the type of p rocess depleted. There
fuoctioo a set of related
and ongoing a::tivities of a
business.
eveot a 1og1cru unit or work
that must by completed as a
'M'lole. Sometines called a
transac1m.
are tlvee types of logical processes: functions, even.ts, and elenientary processe;.
A fu11ctioo is a set of reL1ted and ongoing activities of the business. A function
has no start or et1d; Jt just continuously perfonns Jts work as needed. For example, a
manufacturing system may include the following functions (subsystems) : PRooucr10N
PLANNING, PRODUCTION SCHEDUUNG, MATERlAlS MANAGEMENT, PRODUCTION CONTI.OL, QU,UJTY
MANAGE.>,.{E'II(, and CN\'E'ltl"ORY CONlROL Each of these ftmctlons may consist of doza15 or
htmdreds of more discrete processes to support spedflc activities and tasks. Ftmctlon
names are nouns that descrlbe the entire function. Additional examples are ORDER
ENTRY, ORD£R MANAGE.>,.{E'II(, SA.LES REPORTCNG, CUSTOMER REI.A'OONS, and R£1'URNS AND REFUNDS.
An event iS a logical untr otwork tbac muse be completed as a whole. An event is
triggered by a discrete Input and is completed when the process has responded with
appropriate outputs. Evet1ts are sometimes called tra1JSacttons. Fttnctlons consist of
proces.,es that respond to events. For example, the M.ATERlAts MANAGE.\U.NT fw1ctlon m.1)'
respond co tl1e following events: TEST MATIJUAL QUWTY, STOCK NEW MATIJU.Ats, DISPOSE Ofl
DAMAGED MATERJ.Ats, DISPOSE Ofl SPOILED M.ATERlAlS, REQUISITION M.ATERlAlS FOR PRODUCTION,
RETURN UNUSED MATilUAJ.S PROM PRODUCTION, ORD[R NEW MATERI.Ats, and SO on. Ead1 of these
events has a trigger and response that can be defined by lts Inputs and outputs.
Using ,nodern structured ai1..1lysis techniques such as those advocated by
McMe11amln, Palmer, Yourdon, and tl,e Robertsons (see the suggested Readings at tl,e
end of tl1e chapter), analysts decompose system ft1nctions into business events. Each
business e,--ent ls represented by a single process that will respond to that evet1t.
Event process names tet1d to be very general. We wlU adopt tl1e convention of naming event p rocesses as follows: PROCESS
, RESPOND To
, or
GEN'f.RATE
• where the blank would be the name of the event (or lts corresponding Input). Sample event process names are PROCESS CUSTOMER ORD£R, PRXESS
CUSTOMER ORDER CHANGE, PROCESS CUSTOMER CHANGE Of ADDRESS, RESPOND TO CUSTOMER
c o ~ RESPOND TO ORDER CNQUtllY, RESPOND TO PRODUCT PRICE CHB:K, G~E BACK-ORO[R
RD'ORT, G ~ CUSTOMER ACCOUNT STATEMENT, and GllllERATE INVOICE.
Procoss Modollng
All event process can be further decomposed Into elementary proces.,es tl1..1t
illustrate In detail how the system must respond to an event. Elementary processes
are dscrete, detailed activities or tasks required to complete the response to an event
In other words, they are the lowest level of detail depicted In a process model. A common synonym ls prlnJltlve process. FJementary processes should be named wfth
a strong action verb followed by an object clause that de.scribes what the work ls
perfonned on (or for). Examples of elementary process names are VAUOATE CUSTOMER
d,aptw N lno
32S
elemeotary process
discrete, detaile:t activity or
task required to complete the
response to an event. Also
calledpritmive pff'X9ss.
IDll'mFICATION, VAllOATE ORDER.ED PRO OUcr NUMBER, CHECK PRODUCT AVAll..ABIUTY, C..UCUL\TE
OROEl
cosr, CHECK
CUSTOMER
CR.EDrr,
SORT BACK OllDEllS, GET CUSTOMER ADDRESS, UPDATE
CUSl"OMERADDR.ESS,ADD NEW CUSTOMER, and DELETE CUSl'Oill:R..
Logtcal process models omit any processes that do nothing more than move or
route data, thus lea"ing the data unchanged. Thus, you should omit any process tl1..1t
corresponds to a secretary or clerk receiving and simply forwarding a variety of
documents to the next processing location. In the end, you should be left only wfth
logical processes that:
Perfortn co111pu.tarto11s (calculate grade point a1..-erage).
Make decfslo11s (determine a>-.Jlablllty of ordered products).
Sort, filter, or otberulise s1,1u111arlze data (Identify o,--erdue lnvolces).
Orga,if..ze data 111.to usefu.l tnfor-»1.aff-011 (gener.i.te a report or aJ.lSWer a
questio11).
Trigger other processes (turn on the furnace or hlStruct a robot).
Use stored data (create, read, update, or delete a record).
Be careful to avoid three common mechanical errors wlth processes (illustrated
In Figure 9-S):
Process 3, 1.2 h ..,s inpurs bur no outputs. '\X'e caU this a black hole because
data enters the process and thet1 disappears. In mosr cases, the modeler
simply forgot the output.
Process 3, 1.3 h ..,s outputs bur no Input.. In this case, the Input flows were
Rkely forgotten.
ht Process 3.1.1 dte Inputs are lnsulllcie11t to produce the output. We call this a
groy bole. 11tere are several possible causes, lnducling (I) a misnamed process,
a) misnamed Inputs and/or outputs, or (3) incomplete facts. Gray holes are the
most common errors-and d1e mosr embarrassing. Once handed ro a programmer, the lnput data flows ro a process (to be lmplemenred as a program) mltSt
be sufficient to produce rhe ourput data flows.
>
Data Flows
Processes respond to loputs and generate outputs. Thus, ar a mlnlmum, all processes
have at least one Input and one ourpur data flo'tl.J, Data flows are the commwlicatlons
bet\,,.een processes and the system's en"ironment. ler•s examine some of the basic
concepts aJ.1d conventions of data flows.
Data in Motion A data flow Is data t11 n1otio11.. The flow of data between a system
and Its environmet1t or between two processes lnslde a ~tern Is co1u1uu.11icaff-011.
Let's study this form of comnmnlcatlon.
A data flow represents an h1put of dara ro a process or the ourpur of data (or h1fonnatlon) from a proces.,. Adara flow is also used to represent the creation, reading,
deletion, or updating of data In a file or database (c,Jled a data store on the DFD).
Think of a data flow as a highway down whldt packets of known composition travel.
The name implies what type of data may travel do"u that hlghway.1llis highway ls
depleted as a solid line with arrow (see margin).
Toe packet concept ls critical. Data that should tr»-.l together sho,dd be shown
as a Sngle dara flow, 110 matter how many pb):rf.cal dOC\truents mlghr be lncluded. The
data Oow data that is input
or output to or ftom a process.
Data flow nane
( Data Flow Symbol )
326
Part 1wo
Systoms Anclysls Methods
Membership
application
E1111loyee
Sank statement
Existing accot11t
3.1.1
Generate an
employee bank
statement
3.1.2
Create a new 1•<11------~
member accot11t
Employ,1e
sta1us
Employee address
I
__.._..
Memler Accounts
New accOlllt status
Accounts
3.1.3
. c ~ccun"'
.c t-'nc..cocctifi"-cc.cacctio.c.nc.. .__ _.1 Receivable
Freeze member 1--'F-'-roc..cz.c.en=a,cccc.
lleparlment
accollll number
RE 9 • S Common Errors on Data Flow Diagrams
)
CF I GU
-----------..._.
composite data flow a
data flow that :onsis1s of other
data flows.
FIGURE 9 - 6
The Data Flow
Pac ket Concept
packet concept is IUustrated In Figure 9,-6, which shows the. correct and lncarrect
ways to show a JogicaJ data flow packet.
T he knou,11 cottiposltf-011 concept is equally lmportant. A data flow ls composed
of either actual data attributes (also called data structu.res- more about t hem later)
or other data flows. A composle d..1.ta Oow is a data flow that consists of other data
flows. They are used to combitle-similar data flows on hlgh-level data flow diagrams
Telephone
Service
Provider
ttemlzed
calls
and
Invoice
Poy
phone
~---Invoice- - ~
bill
327
d,aptwNlno
Procoss Modollng
(a) High-Le vel OFD
Customer
Order
Process
order
Accepted ___. ...
Order
-
( b ) More Detailed DFD
Standing
Order
Customer >-- Order
Rush
Order
Slandard
Order
~G U R E
9 •7
Co mposite and Elementary Data Flows
Accepted
Standing ___. ...
Order
.
-
Process
standing
order
-
Process
rush
order
-
.
Process
standard
order
>-- Standard ___. ...
~
-
-
Accepted
Rush
Order
•··
Accepted
Order
_ _ _ _)
to make those diagrams easier to read. For example, In Figure 9·7(a), a high-level
OFD consolidates all types of orders into a composJte data flow called 0 11.0m. In
Figu re 9-7(b), a more detailed data flow diagram shows specific types of orders:
STANDING O llDEll, RUSH O RDER, and sTANDAAO ORDER. These different orders requ i r e somewba1different processing. (Ille small, black clrcle ls called aju.,iction. It Indicates tl1at
any given ORDER ls an Instance of only one of the order types.)
Altother commo11 use of composJte data flows is to consolidate all reports and
inquiry responses int o one or two composite flows, T here are two reasons for tllis.
First, these outpu ts can be qulte numerous. Second, many modem systems pro'\oide
exten.sJve user-defined reports and inquiries tl1..1t cannot be predicted before the
system's impJementatlon and use.
Some data flow dtagramming methods also recogrtize tJ.o·n daui flows called co1~
trot flozvs. A control flow represents a cood.l:rion or noodata event that trfggers a
process.Th.Jnk of ft as a condition robe mon.irored wh.lle the system works. When the
system realizes that the condition meets some predetennJned stare, the process to
control flow a condition or
nondata event that triggers a
pro~
.
328
Part 1wo
l'lllm$
- - Control
- -'bw- - t>
Control n ow
Sym bol
Systoms Analysis Method s
wbid1 ft ls input is started. The classic Information system example ls tltne. For
ex.ample, a report generation process may be triggered by the temporal event ~m-OP.
MONTH.. ln real-time ~·stems, control flows often represent real-time conditions such
as TE."1PfltATUR.E and All1TUOE. In most methodologies tl1..1r dlstlngulsh between dau and
control flows, the control flow ls depleted as a dashed line with arrow (see margin).
Typically, information systems analysts have dealt mostly with data flows; however, as infonnation systems become more Integrated with real-time ~tem.s (str:h as
manufacturing processes and compurer-inregrated manufacturing), the need ro
distlnguisl1 the concept of control flows becomes necessary.
Logh:ol Data Flows and Conventions
WbUe we recognJze that data flows can be
Implemented a number of ways (e.g., telephone calls, business forms, bar 0xles,
memos, reports, computer screens, and computer.to-computer communlcatloru), we
are interested only in logical data flows.TI1us, we are only interested thar the flow is
needed (not how we wlU lmplanetll that flow). Data flow names should dlscourage
premature commitment to any possible implementation.
Dara flow names should be descriptive notm.s and noun phrases that are slngu.lar,
as opposed to pluraJ (ORDER- not ORDERS). '\X'e do 11ot want to imply that occurrences
of the flow= be Implemented as a pbysfcal batch.
Data flow names also should be wllque. Use adJectl.-es and ad,-.rbs to help 10 descrlbe how processing h.as d1anged a data flow. For example, if an lnput to a process
is named oRDm, the ourput should not be named ORDER.. It might be named VAllD
ORDER.,APPROVED ORDER, ORDER WlfH VAUO PRODUC'fS,ORDm WITH APPROVED CREDIT, or any
other more descriptive name that reflects wh.at the process dJd ro the orfgit1..1l order.
l.oglcaJ data flows to and from data stores require special 11..1mit1g coosfdentlons
(see Figure 9,-8). (Data store 11..1mes are plural, and the numbered bullets matd.l the
note to the figure.)
Only the 11et data flow is show11. Jntultively, you may reaUze tl1.1t you 11.1,·e to
get a record to update It a delete it. But unless data is needed for some
other purpose (e.g., a calculation or decision), the "read• action is not shown.
This keeps the dL1gram uncluttered.
O
A data flow from a data store to a process l.ndlcates that data ls to be .. rtad"
for some specific purpose. TI1e data flow 11..1me should dearly Indicate w hat
data is to be read. 11lls ls shown in Figure 9-8.
'=) A data flow from a process to a data store lndlcates that data ls to be created,
deleted. or updated In/from that data store. ~,In. as shown lo Ftaure 9-8. these
data flows should be dearly named to reflect the specific action performed
(sud1 as NEW CUSTOMER, CUSJ'OMER TO BE DELE'JlD, or UPOA'J'ED ORDER ADDRESS).
Notice that the 11..1mes suggest the classic actions that can be perfonned on 1 fl.le,
namely, CIUATE, READ, UPDATE, and DEIErE (CRUD). In a real DFD, we wotdd not actually
record these action names on the diagram .
No data flow should ne,...- go unnamed. Unnamed data flows are frequently the res,dt of flowchart thlnklng (step l, step 2, etc.). If you can't gl.-e the data flow a reasonable name, It probably does not exist. Consistent with our goal of logfcal mod.Ung, data
flow names sho,dd describe the data flow without describing how d,e flow ls or co,dd
be Implemented. Suppose, for example, that etld users explain their system as foDows:
"WeffU out lbrm 23111 trlplfcate andse11d ft to .. .'The logical name for d,e• form 23•
data flow mlglll be OOURSE REQUESt.11lls logical name ellmlnates physical, lmplemei11at1on
blases--d1e Jdea that '\\"'e must use a paper fort>l and the notion that we must use catbon
copies. Ultimately, dlls wlUfree us to consider other physical altematl,-es such asTouchTone phone responses, onUne registration screens, or even e-Ouslnes., Internet pages.
Finally, all data flows must begin an<Vor end at a process because data flo"·s are
the Inputs and ou tputs of a process. Consequently, all tl1e data flows on the left side
of Figure 9-9 are Ulegal. The corrected dL1grams are shown on the rlglll side.
Procoss Modollng
d,aptwNlno
329
, FIGURE 9 - 8 '
Order
Canceled Order
Process
Order
Cancel
Order
Data Flo,vs to and
from Data Sto res
Order
f) toBe
Deleted
9 New
Order
" delete"
•
'"create'" ....
-
Orders
••
" update"
O
New
Order
Address
'"read"
O
Unfilled
Order
..
Change
Order
Address
Summarize
Unfilled
Orders
Change of Address
Summary of
Unfilled Orders
I
I
•
Data Flow Conservation For many years we have tried to lmprove business
processes by automating them. It hasn't always worted or worked well because the
business processes were desJgned to process data flows in a precomputlog era. ConsJder the average business form. It iS common to see the form dJ'\o1ded Into sections
that ue designed for different au dle11ces.1l1e first redplrot completes bls part of the
fonn, the next recipient completes her part, and so focth. At certain points In thJs proc~Jng sequence, a copy of the form might evett be detached and sent to another recipient w ho lnltiaUzes a new multiple-part form tl1at requires trailScriblng mud1 of
the sime data from the itlitial form. In our own un.ivetsJty, we've seen examples w here
poor form design requlres that the same data be typed a dozen times.
Now, if the flow of cttrrent data ls computerized based 011 the cttrrent business
fonns and proce.s.,es, the resulting computer programs will merely automate these ineftlclencles.Thls Is preclsel)• what has happroed In most businesses! Today, a new emp h.asis on b·ust11ess process redestgn encourages rnanagemet1t, users, and ~·stems
analysts to ide11tify and ellmlnate these lneflldrodesbdll.a! deslgnlng any new information systetll. We can support thls trend In logical data flow dL1grams by practicing
data conservation. Data co.-1servatioo, sometimes called "starvlog the p rocesses,"
requires tl1at a data flow contaitt only the data that ls truly needed by the receiving
p rocess. By ensuring that p rocesses receive only as rnud1 data as they really need, we
simplify tl1e interface between those processes. To practice data conservation, we
must precisely define tl1e data composition of ead1 (noncomposlte) data flow. Data
composition ls expressed ln the fonn of data structures.
data coo.servatioo the
practice of ensuring that a
data flow contair1s onty data
needed by the receiving
process.
330
Systoms Anclysls Methods
Part 1wo
Corrected
data
flows
Illegal
data
flows
r
81
a process Is '
needed to
exchange data
flows between
external
agents
.
81
'
0 $1
81
a process Is
needed to
update (or
use) a data
store
81
r
11
11
o s1
a process Is
needed to
present data
lrom a data
store
o s1
'
I
I
OSI
'
.
81
,
r
11
11
o s1
o s1
a process Is
needed to
move data
from one data
store to
another
I
I---+!',
052
_________
CF I G U R E 9 • 9
'-·
Illegal L>ata flows
data attribt11e the smallest
piece of data that has meaning
to the users ard the business.
data structure a specific
arrangement of data attributes
that define a single ins1a.Jlce
of a data flow.
_ . ,)
Data Structures Ultimately, a data flow contains data items called attrlbu.tes. A da ta
attribute is the smallest piece of data that h.as meanlng to the end users and the bllSi-
ness. (lllls definition also app lies to attributes as they were presented ln Chapter 8.)
Sample attributes for the data flow ORDER mJght in d ude ORDEll NUMB.m, ORDllt DATE,
CUSTOMER NUMBllt, StUPPlNG ADORE$ (which consists of attrlbutes such as STRJ:E'J' ADDRESS,
CITY, an d ZCP CODE) , ORDf.RED PRODUCT NUMBERS, QUANTrrY(les) ORDERED, and so o n. Notice
that some attrlbutes occur once. for ead1 instance of ORDER, while others may occur
se,--e.ral times for a single instance of ORDF»..
T he data attributes that comprise a data flow are organJzed Into data s tn1ct1.1res.
Data flows can be descrlbed In terms of the following types of data structures:
A sequence or group of data attributes that ocntr one after aitother.
T he select/011 of one or more attrlbutes from a set of attributes.
The repetr.tlo11 of one or more atlributes.
T he most common data structure notatio11 ls a Boolean algebraic notation that is
required by many CASE tools. Other CASE tools and methodologies s upport proprietary,
Procoss Modollng
r
F IG U R E 9 - 1 0
A Data Structure for a Oa1a Flow
Data Strudure
OWER=
ORDER NI..MBER
ORDER DATE+
+
(PERSONAL CUSTCMER Nl..MBER,
OORPOIWE AOCOUNT N....IER)
Engli,h lnterpretatiAA inslance of ORDER consists of:
OWER """BER and
OWEROOE and
Either PERSONAL CUSTCMER Nl..MBER
or O::QPORAlE AOCOUNT NI.MER
+
(e!WNG AODQESS = ADORESS) +
1 {PRODUCT N....IER +
PRODUCT DESCRIPTION +
GlUANTITY ORDERED +
PRODUCT PRICE +
PRODUCT PRICE SOURCE +
EXTENDED P~CE) N +
51...M Of EXlEt-DED PRICES +
and SH"'NG ADORESS (which i, equMJiont
SHIPPING ADDRESS = ADDRESS
lo AO)RESS)
and op,ionaly: ~WNC ADORESS (which i,
equi.alent lo ADDRESS)
and one or more in s1an c»s of:
PRODUCT NI..MBER and
PRODUCT DESCRPllON and
QUAf',~TY ORDERED and
PROOVCT PRICC
PREA&.10 AMOUNT
(CREDIT CARO -WI
(QUOTE N""'eER)
EXTENlED PRICE
+ EJ<PIRATION DATE)
and SU< C* EXTENDED PRICESand
PREPAID AMOUNT and
op~and ly: both CREDIT CARO NU"'8ER and
AOORESS =
(ll06T OFFICE BOX NU"'8ER)
STREET ADDRESS
+
OPIRATION DATE
+
and op,ionaly: QUOTE N....IER
Orv+
(STATE MUNIOl!t,JJTYI +
(OOUNTRY) +
POSTAL OOOE
ond
PRODUCT PRICE SOURCE and
AA
instanceof ADDRESS ronsists of:
op~onolly. ll06T OFFICE BOX NU"'8ER and
STREET A)DQESS and
cnv and
Eifher STATE OR MUNClllWTY
and op,ionaly: COUNTl!Y
and P06TAl OODE
but tssentlally eqttl\<-:tlent, 11otatlons. A sample data stn1crure for the data flow oROm. ls
presented In Figure 9-10,1bls algebraic notation uses the following symbols:
=
Means "conslsts of" or"ls composed of"
ltteaiu ..and .. and designates sequence.
f,, ,) Means "only one of the attributes within the br.tckets may be present"deslgnates selection. The attrlbutes ht the brackets are separated by
commas.
i, .. } ~feaits that the attributes in the braces may occur many times for one
Instance of the data flow- desJgiures repttition. The anrlbutes Inside the
braces are separated by commas.
(, , ,) Means the attrlbute(s) in the paret1tl1eses are optional- no value- for
some ittstances of the data flow.
+
In our experience, all data flows can be descrlbed in terms of these fundamental
co1tstructs. Agure 9-11 demo1tstrates each of the fundamental co1tstructs using examp les. Returning to Figure 9-10, 11otlce that the constn1cts are combin ed to descrlbe the
data content of the data flow.
d,aptw Nlno
331
....
' FIGURE 9 • 1 1 Data Structure Constructs
Format by Example
(relevant portion i, boldfoced)
0 - Structure
S.quen.. of Altributes-The sequenai dab
structure indioot-E& one or rrore attrib..itE& hat may
(or mu,t) be indudod in a data flow.
WAGE ANO TAX STATEMENT=
TA>IPAl!R DINTIICAJION NJMIIR
+
W<M'IR NAMI +
TAXMJIR AOOMSS +
WAOIS, TIPS, AND COMPIINSAJION
PIDIIW W< WITl*ill!> + •••
Selection of Altribute....lhe,election data structu ..
albw, )OU lo show ,ituations where different ,eb of
attribute, do,cribe di/went in.ianai, ol the dab Row.
'\.
+
OIIOER =
(PIRSONAL CUSTOMIR NUMIRR,
ClOIIPORATI ACCOUNT NUMHR) +
OCDER O.&JE
+ ,, ,
RopeHon of Attribute....lhe 19petiion dota m,c1J19
i, u,ed lo"" off a data attribul9 or group of data attributo,
that may (or mu,t) repeat tbem,ei,,,, a 'f'Ocified number of
tim .. for a ,ingle i1'61ance of tho data flow.
lhe minl'num number of rE1PQi tion, i, usually mro
or one.
The maximum nunber of repeiliom may be ,pacified
a, •n• meaning "mony" where the actual number ol
il'61ona&Y<Jri"' for each in,tanai ol hedol:J Row.
CLAIM=
Optional Altributes-The optional notation indiooto,
that on attrib..ite, or group of atrib..ites in a sequence or
selecion dala stn..cture may rot be included in all instooces
ol a data ffow.
Not>:
repetiim data strvcftK9, a mininvm of "zsrd'
is the same m malci'll tn9ertin, ,.,_;Ill grrup "option:,/. •
CLAM=
POUCY M.l#l&R +
Reusable Attribute..-For group, of attribut.. that on,
OJJE =
For,..
English Interpretation
(relevant portion i, beldfa..d)
POUCY M..MIIER +
POUC'YHOIDER NAME +
POUC'tHOI.OER AOOSESS +
0 {DIPINDINT NAM! +
DIPINDINr'S RILAIIONSHP) N +
1 {lllPINSI D!SCRtPflON +
SIIIVICI PRCN1DIR +
lllPINSI AMOUNT) N
POUCVHOIDER NiWE +
POUC'YHOIDER ADDRESS +
(SPOUSINAMI+
DlTI o, earH) + •••
c.ont:Jined in manydat:J ffowJ, it is deMrable to creae a
separate data struck.Ire tlat can be reused in other data
MONTH+
O..Y +
stroctores.
YW
An in,tanai o/ W..CE AND W< sttJE1'ENT 001ui,t, o/:
TAllPAYIR IDINIIPICAIION NU. .lll and
TAXMYIR NAMI and
TAllPAYIR ADOR!SS and
WAOfS, TPS, AND 00-NSATION and
PIOIRAL TAX WITHHILO and •••
An instonai o/ CRDER c:on,i.i. o/:
Either PIRSONAL CUSTCIMIR NUMIIR or
OORPORAI! ACOOUNT NU-; ond
Ol<l~R l"'1E and ...
An instonaiol a.w "'"'"" ol:
PQICY N1..MllER 00 d
PO.ICtHOlacR N- ond
PQ.IC1HOIDER ADDRESS and
z:«o or more inltances of1
DIPINDINT N.IMI and
OIPINDl!Nr'S MLATIIC>NSHIP and
one or more instances ofs
IXJIINSI DISCRtPftON and
SIRVICI PROVIDIR and
IXJIINSI ACOOUNT
An in$1'0r'lal of <l.AIM 0011$i$IJ of:
PO.ICY Nl.M&ER and
PQ.IC1HOIDER NAME and
PO.ICtHOlacR .Oa<ESS ond
option ally, SPOUSI NAM! and
OATI 0, IIISH and •••
Thon, the reu,c,ble ,tructur.. can be induded in other data
RaN $1'ructures as folbwJ:
ORDER = ORDER Nl.MIIER , , , + DATE
IN\OICE = INVOICE NUM&ER , , • + 00£
PAYHENT = CUSTOMR NlMER , , , + DAlE
J
Procoss Modollng
-
data flow
data flow A
0
data flow - - - + I
U+ V+W
- data flow H
-
data flow I
data flow J
data flow E
w-.
data flow R ___.
-.o
data flow S
data flow T __..
Process
data flow X_.
- data flow O
-
data flow V__..
data flow
data flow C
0 -
u_.
diverging
converging
~ - - - data flow
A+B+C
-
333
d,aptwNlno
converging
data flow
diverging
data flow
O orE orF
X orYor Z
data flow V ...
data flow z+
dataflowF
F I G U R E 9 • 1 2 Diverging and Converging Data Flows
The Importance of defhling the data structures for every data flow should be
apparent- you are detlning the business data requirements for each Input and outputl
These requlremet1ts must be determlned before any process could be Implemented as
a computer program.1bls Slandard notation provides a simple bur effective meaJ.15 for
communJcating between end users and programmers.
Domains An attribute is a piece of data. In ai1..1lyzillg a ~·stem, ft makes sense tl1..1r
we should define tl1ose values for an attribute tl1ar are Jegltimate, or tl1at make sense.
The v:ilues for e.ich attrlbute ue de.6.ned in tenns: of two properties: d:tt:l type and do.
main. The data type for an attribute defines what d1ss of data can be stored in tl1..1r
attrlbure, whereas the domalo of an attrlbure defines what values an attribute can legltlmately take on.11,e concepts of data type and domain were introduced in Chapter
8. See tl1at discussion and Tables 8-1 and 8-2 for a m«e complete descrJptlon of data
type and domain.
data tfJ>e a class of data
that can be stored in an
attribute.
domain the legitimate vaJ.
ues for an attrib.Ite.
Divergent and Convergent flows It ls sometimes useful to depict dJverglog or
co11,--erging data flows on a data flow diagram. A divergio.g data flow ls one tl1..1t
splits into m,tltlple data flows. Diverging data flows Indicate that all or parts of a sh,
gle data flow are routed to different destinatlons.2 A converging data Oow is the
merger of multfpJe data flows Into a sh1gle data flow. Convergh1g data flows indicate
tl1..1t data flows from different sowces can (must) come together as a single packet for
subsequent proces.,ing.
Diverging and converging data flows are depicted as shown In Figure 9-12. Notice
tl1..1t we do not include a proces., to ..,oute" the flom. The flows simply dJverge from
1Sotnc- a-pen,~ that di~rig data fbwJ .itould be u:11".d Oll1y wheh 1..11 dlltil ifl the flO'fl· ~ routed to 11..11 de.rtinu.
tiotiJ. ~ ptdl'.r the- <'.Li.de OcNarooddi..ni.dob
that 111lowJ Id! orp,tu of W Row to be touted
to diffetctat proco-.
dj\•ergiog data flow a
data flow that splits into multi·
pie data flows.
coovergitlg data Oow the
merger of multi~le data flows
intoasingle datl flow.
334
Part 1wo
Systoms Analysis Methods
or converge to a common flow. The followlng notations, nor supported by all CASE
tools, are used In this book:
O
0
O
The small square }·u nction means «and." 11lis means that each time the process
Is performed, It must lnpul ( or output) all the diverging or converging dam
flows. (.l'ome DFD 11otatio11s simply place a + berwee11 the data flows.)
TI1e small black ju.1JCtlon means "exdusl,. e. or." Th.ls me:ulS that ead1 time the
process is performed, It must input (or output) only one of the diverging or
converging data flows. (Sotne DFD 11otatto·11s sl1nply place an * bettiieen the
data flows.)
In the absence of one diverging or converging data flow, the reader should
a~ume an .. lnclustve or;" This means that each time the process is performed,
It may Input any.!!!: all of tl1e depleted data flows.
With the above rules, the most complex of business process and data flow combit1..1tions can be depleted.
The Process of Logical Process Modeling
Now that you understand the basJc concepts of process models, we can examine
b,uldlng a process model. Whtt1 do you do It? How many process models nuy be
draw11? What technology ex..lsts to support the development of process models?
>
Strategic Systems Planning
Many organizations select application development projects based on strategic information system plans. Strategic plannlng Is a separate project that produces an
information systems strategy plan tl1at defines ait overall vision and archltectute for
information ~·stems. This architecture frequently includes an enterprise process
niodeL (fbe plan usually h ..,s other archltectural components tl1..1t are not Important
to this discussion.)
An enterprise process modtl typically ldentlJles only business areas and functlons.
Events and detailed processes are rarely examined. Business areas and functions are
ldentilled and mapped to other etllerprlse models such as the enterprise data model
(Q1apter 8). Business areas and ltmctlons are subsequently prioritized Into appllcitlon
development projects. Priorltles are usually based on which busines., areas, ftmctlons,
.uu.l supvurtiug ;q,plic..M
4tivu:,; \ViD t~turu lit~ 111~l value lo llut l,ush1c-.s:, as <l whule.
An et1terprlse process modeJ ls stored in a corporate reposJtory. Subsequently, as
application de,-etopment projects are started, subsets of the enterprise process model
are exported to the project teams to serve as a starting point for building more
detailed process models (lndudlng data flow dL1grams). Once the project team
completes systems ai1..1lysls and desJgn, the expanded and refined process models are
returned to the corporate repository.
>
Process Modeling for Business Process Redesign
Bush1ess p rocess redesign (BPR) has been discussed several times In this boot and
chapter. Recall tl1at BPR projects analyze business processes and then redesign tl1ern
to elimlnate Inefficiencies and bureaucracies before any (re)appllcatlon of information technology. To redesign OOsh1ess processes, we must first study the existing
processes. Process models play an Integral role In BPR.
Ead1 BPR methodology recommends its own process model notations and documentatio11. ~fost of the models are a cross between data flow diagrams and flowcharts.111e dL1grnms tend to be Yery physical because the BPR