Chapter 8 Structuring System Requirements: Process Modeling

Chapter Overview
Chapter 8 introduces students to several process modeling techniques for representing business processes. Although this chapter focuses primarily on data flow diagramming, brief overviews of functional hierarchy modeling and Oracles process modeler are given. After a brief introduction to process modeling, data flow diagramming techniques are introduced in a section called ata !low iagramming "echanics.# $his section demonstrates the basic ! symbols, definitions, and rules. $he authors use the %ane and &arson symbol set throughout the boo', and these symbols are e(plained in this section. )oosier *urger, the food ordering system first mentioned in Chapter +, is used to illustrate basic data flow diagramming concepts. $his section also includes e(planations of decomposition and balancing. Chapter 8s third ma,or section introduces four different types of ! s- current physical, current logical, new logical, and new physical. )oosier *urgers inventory control system .which is manual/ is used to illustrate the first three types of ! s. Current practice in using ! s indicates that very little time should be spent on the current physical ! . $he fourth ma,or section in this chapter, 0sing ata !low iagramming in the Analysis 1rocess,# introduces guidelines for drawing and using ! s. $his is different from the mechanical rules presented earlier. $opics include completeness, consistency, timing, iterative development, primitive ! s, and analy2ing ! s for system inefficiencies and discrepancies among ! s that are supposed to be modeling the same system. A )oosier *urger e(ample helps illustrate these guidelines. $he Oracles 1rocess "odeler and !unctional )ierarchy iagrams# section introduces students to two other process modeling tools. $hese tools are Oracle esigners process modeler and functional hierarchy modeling, a tool found in several CA&3 products. 4n this section, the authors show how to prepare basic process models and functional hierarchy diagrams. Additionally, the authors compare and contrast Oracles process models to data flow diagramming. 4n the last section of this chapter, the authors overview process modeling for 4nternet5based electronic commerce applications. As they e(plain, process modeling for 4nternet5based electronic commerce applications does not differ from more traditional applications development pro,ects.

Instructional Ob ectives
&pecific student learning ob,ectives are included at the beginning of the chapter. From an instructors point of view, the objectives of this chapter are to 6. &how how to logically model processes with data flow diagrams.

87

Modern Systems Analysis and Design, 3rd edition

nstructors Manual

+. $each students data flow diagram symbols and the mechanical rules necessary to create accurate, well5structured process models. 8. &how students how to decompose data flow diagrams into lower5level diagrams. 9. 4llustrate the concept of balanced ! s. :. 3(plain and demonstrate the differences among the four levels of ! s- current physical, current logical, new physical, and new logical. ;. 4llustrate how data flow diagrams are used as tools to support systems analysis. <. 3(plain and stress the importance of the ! guidelines- completeness, consistency, timing considerations, the iterative nature of drawing ! s, and drawing primitive ! s. 8. =. 67. iscuss and illustrate Oracle esigners process modeler. iscuss and illustrate functional hierarchical modeling. iscuss processing modeling for 4nternet5based electronic commerce applications.

Classroom Ideas
6. 0se !igures 85+ and 85; to illustrate the basic ! symbols and the correct and incorrect ways to draw data flow diagrams. 0se !igure 858 to demonstrate the problem with trying to include sources>sin's inside the system being modeled. +. Once you have covered the basics of drawing ! s, have students complete 1roblems and 3(ercises + through 9 and 67 as in5class e(ercises. Once the students have completed these problems, review the problems in class, reinforcing the points that you have made. 8. 0se !igures 859, 85:, 85<, 858, and 85= in class to teach decomposition. ?e(t, as' students to complete 1roblems and 3(ercises 9 and 67@ these e(ercises should be completed in class. 9. 0se !igure 8567 to illustrate unbalanced ! s. :. &upplement the chapter material on ! mechanics, decomposition, and balancing with your own e(amples, which you can wor' with your students in class. A good source of such e(amples is written organi2ational procedure statements. "odified procedure statements also ma'e good homewor' problems. &ee 1roblems and 3(ercises 66and 6+ for e(amples. 4t is best to devote at least one complete class period to wor'ing e(amples. &tudents can prepare these diagrams outside of class or try preparing them for the first time in class. "any issues arise that are best handled from e(amples. !or e(ample, students often encounter difficulties when identifying when to show a direct data flow between processes and when to decouple these with a data store .emphasi2e that data stores allow different processes to wor' at different rates and at different times/

86

!hapter "

Structuring System #e$uirements% &rocess Modeling

deciding what activities to encompass with each process .emphasi2e the principle of cohesion and the goal of each process being of roughly equal si2e and comple(ity/ distinguishing processes from sin's and sources .emphasi2e factors such as audience and the ability to change or control in ma'ing such distinctions/ encountering logical inconsistencies or ambiguities in narrative descriptions .emphasi2e that this is the power of ! s and the typical interaction between requirements structuring and requirements determination necessary to resolve such ambiguities/

;. $he )oosier *urger inventory control system e(ample demonstrates the differences between current physical, current logical, and new logical ! s. Aor'ing through the entire e(ample in class is an effective way to illustrate the differences in these three types of ! s. Aor'ing through another e(ample from your own e(perience, or having students come up with their own e(amples, will supplement the )oosier *urger e(ample. <. 0se a CA&3 tool in class to demonstrate ways to model processes other than ! s. )ave students compare and contrast these alternative methods with ! s. 8. 0sing a CA&3 tool that supports ! s, show in class how the tool provides for decomposition and balancing and how ! s are lin'ed to the CA&3 repository. Bater, when teaching Chapter 67, you can show how the repository lin's ! s and entity5 relationship diagrams. =. 0se a CA&3 tool in class to show how the tool chec's for completeness, consistency, and other elements of analysis as discussed in the chapter. 67. 0sing Oracle esigners process modeler, show students how to prepare a process model. 66. 0sing Oracle esigner or another CA&3 tool, illustrate how functional hierarchy modeling is performed. 6+. )ave students identify an organi2ation that would benefit from an 4nternet5based electronic commerce application. 1lace your students into groups of three or four individuals. $hen, have the students prepare a set of data flow diagrams for the 4nternet5based electronic commerce application. 4f time permits, as' your students to also prepare process models and>or functional hierarchy diagrams.

8+

Modern Systems Analysis and Design, 3rd edition

nstructors Manual

!nswers to "ey #erms

&uggested answers are provided below. $hese answers are presented top5down, left to right. 8. 6. 67. 69. +. 6+. 9. ata flow diagram *alancing Bevel57 diagram &ource>sin' Conte(t diagram 1rimitive ! ! completeness :. 66. 68. ;. =. <. 8. ! consistency Bevel5n diagram 1rocess ata store %ap analysis !unctional decomposition !unctional hierarchy diagram

!nswers to Review $uestions

6. A data flow diagram is a picture of the movement of data between e(ternal entities and the processes and data stores within a system. &ystems analysts use data flow diagrams to help model the processes internal to an information system and how data from the systems environment enter the system, are used by the system, and are returned to the environment. ! s help analysts understand how the organi2ation handles information and what its information needs are or might be. Analysts also use ! s to study alternative information handling procedures during the process of designing new information services. +. $he rules for ! s are listed in $able 85+ and illustrated in !igure 85;. $able 858 lists advanced rules for data flow diagramming. 1rocesses cannot have only outputs, cannot have only inputs, and must have a verb phrase label. ata can only move to a data store from a process, not from another data store or an outside source. &imilarly, data can only be moved to an outside sin' or to another data store by a process. ata to and from e(ternal sources and sin's can only be moved by processes. ata flows move in one direction only. *oth branches of a for'ed or a ,oined data flow must represent the same data. A data flow cannot return to the process from which it originated. 8. ecomposition is the iterative process by which a system description is bro'en down into finer and finer detail, creating a set of diagrams in which one process on a given diagram is e(plained in greater detail on a lower5level diagram. *alancing is the conservation of inputs and outputs to a data flow diagram process when that process is decomposed to a lower level. Cou can determine if a set of ! s are balanced or not by observing whether or not a process which appears in a level5n diagram has the same inputs and outputs when decomposed for a lower5level diagram.

9. $he highest level ! is a conte(t diagram. 4t represents the system as a single process, with all the related entities and the data flows in and out of the system. $he ne(t level diagram, called a level57, decomposes the one process from the conte(t diagram into two to seven high5level processes. 3ach process in a level57 diagram can be decomposed if necessary. 3ach resulting diagram is a level56. &hould processes in a level56 diagram be decomposed, each resulting diagram is a level5+ diagram. 3ach one of these processes would be decomposed on a level58 diagram, and so on.

88

!hapter "

Structuring System #e$uirements% &rocess Modeling

:. Current physical ! s often show the people and technology used within a system, illustrating who does what and the media on which data are stored. Current logical ! s attempt to show the essence of the system without regard to the actual physical implementation. ;. etailed ! s for the current physical system often ta'e a great deal of time to prepare and are often tossed aside as the focus shifts from the current to the new system. *y not drawing current physical ! s, or by drawing only cursory ones, analysts save themselves effort and focus from the beginning on what is really important, the new system. ! s can be used as analysis tools to help determine the completeness of a system model and a models internal consistency, as a way to focus on when system events occur through analy2ing timeliness, and, through iterative use, to develop and chec' models. Analysts can study ! s to find e(cessive information handling, thus identifying areas for possible efficiencies.

<.

8. Cou stop decomposing a ! when the following si( conditions are satisfied- .6/ each process is a single decision or calculation or a single database operation, such as retrieve, update, create, delete, or read@ .+/ each data store represents data about a single entity, such as a customer, employee, product, or order@ .8/ the system user does not care to see any more detail, or when you and other analysts have documented sufficient detail to do subsequent systems development tas's@ .9/ every data flow does not need to be split further to show that different data are handled in different ways@ .:/ you believe that you have shown each business form or transaction, computer screen, and report as a single data flow@ or .;/ you believe there is a separate process for each choice on all lowest5level menu options for the system. =. &ources and sin's are always outside of the system being considered. $hey are of interest to the system being considered only because they represent sources of data coming into the system and destinations for data leaving the system. 4f any data processing occurs inside a source or sin', it should be of no interest to the system being modeled. 4f the processing is of interest, however, or if the identified source>sin' has several inputs and outputs to and from the rest of the system, it may be better considered as an internal process. 67. Conte(t diagrams have only one process that represents the entire system being modeled and show only the data flows into and out of the system. $he conte(t diagram also includes sources and sin's, which represent the systems environmental boundaries. $here are usually no data stores in a conte(t diagram. 66. Although data flow diagrams are similar to Oracles process model diagrams, there are several differences. $able 859 contrasts these two process5modeling techniques. 6+. *oth functional hierarchy diagrams and data flow diagrams show a systems decomposition into finer and finer levels of detail. )owever a !) s decomposition is shown on the same diagram.

89

Modern Systems Analysis and Design, 3rd edition

nstructors Manual

!nswers to Problems and %&ercises

6. &tudents can draw their data flow diagrams in several ways, depending on the level of detail they choose to capture. &tudents should reali2e that there is not one right# data flow diagram for this or most other business processes. Delevant data flows include payment information, receipt, goods sold information, and inventory information. $hree data stores are a goods sold file, an inventory file, and daily sales total file. 1rocesses include update goods sold file, update inventory file, update daily sales total file, and produce management reports. &ources>sin's include customer and store manager. A sample conte(t diagram and level57 data flow diagram are provided below. 4n the level57 data flow diagram, $ransform Customer 1urchase, 0pdate %oods &old !ile, 0pdate 4nventory !ile, and 0pdate &ales $otal !ile, were selected as processes rather than as sources>sin's because they were deemed to be central to the point of sale process. 1oint out why these ! s are balanced.

Retail Store Conte&t 'iagram

7

Deceipt Customer 1ayment

"anagement Deport &tore "anager

1oint of &ale &ystem

8:

!hapter "

Structuring System #e$uirements% &rocess Modeling

Retail Store (evel)* 'iagram

Deceipt Customer

6 $ransform Customer 1urchase

1ayment

%oods &old

4nventory ata

&ales ata

+ 0pdate %oods &old !ile !ormatted %oods &old Amount

8 0pdate 4nventory !ile !ormatted 4nventory Amount

9 0pdate &ales $otal !ile !ormatted &ales $otal Amount

%oods &old !ile

4nventory !ile 4nventory Amounts : 1roduce "anagement Deports "anagement Deport

&ales $otal !ile

%oods &old Amounts

&ales $otals

&tore "anager

8;

Modern Systems Analysis and Design, 3rd edition

nstructors Manual

+. &ample conte(t and level57 data flow diagrams are provided below. As with the previous question, students can draw their data flow diagrams in several ways, depending on the level of detail they choose to capture. &tudents should reali2e that there is not necessarily one right# data flow diagram for this or most other business processes. 4t is important that the diagrams be balanced, have a clear and purposeful boundary, and obey the rules for drawing ! s.

Cap and +own Conte&t 'iagram

Order 4nformation &tudent Deceipt

Cap and %own 4nformation &hipping

Order 3ntry &ystem

Cap and +own (evel)* 'iagram

Order 4nformation &tudent Cap and %own 4nformation &hipping

Deceipt

6 Ealidate Order

Ealid Order 4nformation

+ !inali2e Order

4nventory ata

8 0pdate 4nventory !ile

4nventory &tatus 6 4nventory !ile

!ormatted 4nventory ata

8<

!hapter "

Structuring System #e$uirements% &rocess Modeling

8. 3ncourage your students to review the rules presented in $able 85+, $able 858, and !igure 85 ; and chec' each of their data flow diagrams. Alternatively, if the students use a CA&3 tool to create their data flow diagrams, the CA&3 tool can automatically chec' for errors in the diagrams. $here are no rule violations in the e(ample ! s, but we cannot verify that there are no logical problems until we decompose the diagrams to a primitive level. One obvious missing system capability is how to handle invalid orders@ typically, processes to handle abnormal conditions, li'e invalid orders, are shown on primitive or at least low5level diagrams. 9. Cour students may choose a variety of situations to use for the nth level data flow diagrams for this answer. *asically, students should continue the process of decomposition until they have reached the point where no subprocess can logically be bro'en down further .i.e., each process meets the definition of a primitive process/. &ee the level56 data flow diagram for this e(ercise, which shows a sample decomposition of the process titled !inali2e Order from the level57 data flow diagram provided for 1roblem and 3(ercise +. $he .italici2ed/ labels for processes and sources>sin's without borders represent the origin or destination of flows that pass between this subsystem and other system components. ?ote that the %oods &old !ile is a potential blac' hole, or possibly should be treated as a sin'.
Cap and +own (evel), 'iagram

'alidate (rder

Shipping Cap and %own 4nformation

+.6 6 %enerate Deceipt

Deceipt

+.+ 6 Bog %oods &old ata %oods &old ata

Deceipt

+.8 %enerate 4nformation for &hipping 4nventory ata )pdate nventory File

Ealid Order 4nformation 'alidate (rder

%oods &old !ile

:. &ome errors and peculiarities in these diagrams include- .6/ different names and numbers are used for apparently the same data store on the two diagrams@ .+/ in the level57 diagram, the data store, Class Doster, does not have the data flow, &cheduled Classes, flowing into it, rather this data flow connects processes + and 8, thus these ! s are not balanced@ .8/ 1rocess 6 appears to accomplish nothing since its inflow and outflow are identical@ such processes are uninteresting and probably unnecessary@ it is possible that this process will become interesting when it is decomposed, where validation and error handling processes might appear@ .9/ 1rocess + does not appear to need Course Dequest as input in order to perform its function, as implied by its name, and .:/ some students may also wonder if 1rocess 8 has input sufficient to produce its output. !or e(ample, where are prior class registrations 'ept so that 1rocess 8 can determine when a course is fullF
88

Modern Systems Analysis and Design, 3rd edition

nstructors Manual

;. 1hysical data flow diagrams help you better understand the people and>or computer systems that are used in the overall systems processing. Bogical data flow diagrams help you better understand the essence of the system, the data and the processes that transform them, regardless of actual physical form. !urther, the new logical data flow diagrams can then show any additional functionality necessary in the new system, to indicate which, if any, obsolete components have been eliminated, and any changes in the logical flow of data between system components, including different data stores. $he data flow diagrams for the new physical system can then be constructed with the data flow diagrams for the new logical system as a guide. As discussed in the chapter, e(perts used to recommend that all four levels of data flow diagrams .current physical, new physical, current logical, and new logical/ be constructed because- .6/ analysts 'new little about the business of the user and needed to develop a detailed current physical data flow diagram in order to understand the business, .+/ users were not able to wor' with a new logical data flow diagram right away, and .8/ there is not much wor' in turning current logical data flow diagrams into new logical data flow diagrams. <. !or data flow diagrams to be complete, all the necessary components of a data flow diagram should be included in the diagram and fully described in a pro,ect repository. As described in the chapter, with most CA&3 tools, the CA&3 tools repository is lin'ed to the diagram. Ahenever you define .or redefine/ a process, data flow, source>sin', or data store on a data flow diagram, an entry is automatically created .or updated/ in the repository for that element. !igure 8568 shows a sample report of the contents of a CA&3 repository entry. 4t is this tight lin'age between diagrams and the CA&3 repository that creates much of the value of a CA&3 tool. !urther, you cannot have an entry in the repository that is not on some diagram. $he repository is also helpful for enforcing ! rules@ for e(ample, during decomposition, the repository remembers what were all of the inflows and outflows of an e(ploded process. $he repository also 'eeps trac' of any split or ,oined data flows. 8. $he various views .e.g., process, logic, data/ of an information system each have their own unique characteristics and provide the most relevant information to different information system specialists. $his variety is best understood, e(pressed, and managed by using diagrams and documentation that are specifically tailored for each view of the system. !or e(ample, data flow diagrams are useful for capturing the flow of data through business processes, but they are not useful for describing the forms and relationships among data. As information systems become larger and more comple(, it becomes even more important to use the right tool and technique to develop each component of an information system. One technique that captured all aspects of an information system model on one diagram or in one notation would li'ely be too comple( for systems professionals to handle. =. $hree ma,or errors in !igure 85+< are- .6/ 1rocess 6.7 .1+/ has only inputs, ma'ing it a blac' hole@ .+/ data flow !: should not move directly from source 36 to data store &6 without first going through a process@ .8/ data flow !6 should not move directly from source 36 to sin' 3+ without first going through a process. Other peculiarities .such as 1rocess 6.7 has label 1+ and the data store has only a label, not a number/ are only that, not errors. 67. $here is a general formatting issue with these ! s since there are no numbers on processes and data stores, but the student should be able to find logical errors as well. $hree particular logical errors in !igure 85+8 are- .6/ the data store &6, not &+, should be represented on the level56 diagram@ .+/ data flow !8 should be an outflow on the level56 diagram, and

8=

!hapter "

Structuring System #e$uirements% &rocess Modeling

data flow !; should not be on the level56 diagram@ .8/ process 16.9.+ has no inputs and is thus a miracle process. 66. $he following conte(t and level57 data flow diagrams represent one way to model the hiring process described in this question. Eariations, based on different assumptions, are possible. !or e(ample, it is possible to include the processes performed by the 1ersonnel "anager outside the system as a source>sin'@ in our diagram, we assume the way the 1ersonnel "anager does her wor' might be studied in more detail, and the way this wor' is done is sub,ect to change. Also, some students might show Applicant and )ired 3mployee as separate sources since only )ired 3mployees provide the information on a nondisclosure agreement. Our e(ample assumes that there is always a successful hiring decision .that is, there is no loop between 1rocesses 9 and 8 in the level57 diagram/@ we also assume application and ,ob description data flows are accurate and complete, so there is no reason to e(plode associated processes to show error handling. Ae also assume that all )iring ecision Betters result in an accepted hiring offer. Cou may want to give your students our e(ample answer and as' them to identify additional assumptions we have made, which may be different than what they concluded. Our simplifications mean that it is unli'ely that our level57 diagram needs to be decomposed. Our e(ample solution also shows split data flows@ be sure to emphasi2e that a split flow means that the same data flow at the same time, but to multiple destinations. 4n our e(ample, we also show the 3mployee data store only on the level57 diagram, not on the conte(t diagram. $echnically, you could show it on the conte(t diagram, but we assume that this is a detail that is necessary to be 'nown only to those loo'ing at level57 and lower diagrams. ! -requent mista.e our students have made is to -orget to include the purge process /on level), or lower diagrams0 to get rid o- year)old applications . Delated to this, since applications are retained for a year and the system operates whenever new ,obs are posted .this timing cannot be seen on ! s/, there is a need to have an application data store inside the system .that is, on level56 and lower diagrams/@ some students will miss this essential element of the logical system description. &tudents can choose to further decompose the processes@ if they do, chec' that the decompositions are balanced and provide detail needed to show separate processing steps and unique data flows and stores. &ome students also ma'e mista'es by trying to use information in the 1roblem and 3(ercise that is meaningless for drawing ! s .for e(ample, there are :77 engineers of different types/@ this e(ercise is a good opportunity to emphasi2e with your students that any given system model, li'e a ! , does not model all aspects of an organi2ation, although these facts are relevant .the fact that there are :77 engineers is relevant for physical database design, for e(ample/.

=7

Modern Systems Analysis and Design, 3rd edition

nstructors Manual

1iring System Conte&t 'iagram

4nterview &chedule Applicant ?ondisclosure !orm Gob escription 3ngineering "anager

Application Completed ?ondisclosure !orm

4nterview 3valuation Application

)iring &ystem

)iring ecision Better

1iring System (evel)* 'iagram

Completed ?ondisclosure !orm ?ondisclosure !orm 6 Deceive Application Ealid Application 6 1urge ?otice : Applications 1urge Cear5old Applications Cear5old Applications Applications Delated to Gob escription De,ected Applications

Application Applicant

4nterview &chedule

8 Choose for 4nterview

; Applications for 4nterview )iring ecision + Gob escriptions Delevant Gob escription 9 3valuate and )ire Create 3mployee Decord ?ew 3mployee ata

Application Accepted Gob escription Gob escription + Deceive Gob escription

3ngineering "anager

3mployees

4nterview 3valuation )iring ecision Better

=6

!hapter "

Structuring System #e$uirements% &rocess Modeling

6+. $he following conte(t and level57 data flow diagrams represent one way to model the help des' process described in this question. $his solution includes the processes performed by the consultants and operators as subsystems within the system rather than as sources>sin's@ this adds detail, but allows bottlenec's in these processes to be corrected. ?ote that data store 6 is repeated in the level57 diagram, to avoid e(cessive crossing of data flow lines. &everal processes can be e(ploded further, but the student will need to ma'e many assumptions to do so. $here are a number of ways that the students can improve this system. !or e(ample, with the current system a customer may have to e(plain their problem and>or question over and over to multiple people- an operator and possibly several consultants. $he customer may begin to believe that they are getting the run5around.# One way to avoid this potential problem is to let the initial operator have access to the customer problem database so that when the caller is handed off to a consultant the customers already opened problem file will go along with him. 4n addition, the operator could have sufficient information and the option to direct the call to the proper consultant. Alternatively, clients could call the assigned consultant directly on follow5up calls to an initial call for help. As' your students for characteristics of a ! that imply areas for improvement. 1ossible answers are- processes that simply collect and pass on information rather than transforming data, collecting the same information into several processes, placing untransformed data into data stores thus causing un'nown delays in processing this data, or cycles or loops that have no apparent termination.

1elp 'es. Conte&t 'iagram

Call 4nquiry on ?ature of Call 7

?ature of Call Client Call Deport H or Other ata ?ew 1roblem ata 4nterim 1roblem &tatus !inal Call Desolution

?on5)elp es' Call Other 0nit

)elp es' &ystem

=+

Modern Systems Analysis and Design, 3rd edition

nstructors Manual

1elp 'es. (evel)* 'iagram (evel)* 'iagram

Call 6 Deceive Call 4nquiry on ?ature of Call ?ature of Call Client ?ew 1roblem ata Call Deport H or Other ata !inal Call Desolution = Close Call Deport ?ew 4nformation on 1roblem 8 Desearch 1roblem Call Deport Open Call 4nformation Call Deport !ile 1roblem ata ?ew 1roblem ata < Decord ?ew 4nformation

Call 4nformation + etermine irection of Call )elp es' Call 4nformation

Call Jueue )elp es' Call 4nformation : 8 etermine if !irst Call !irst Call 4nformation 9 1revious Call 4nformation

Closed Call 1roblem Desolution Closed Call 4ndication

etermine 1roblem &tatus

?on5)elp es' Call 4nformation

+ 6
;

Other 0nit

Create Call Deport 1roblem 4nformation

Call Deport 4nformation

Call Jueue

$ransfer Call

Open Call 4nformation

4nterim 1roblem &tatus

68. A suggested answer is provided below.

1ospital Pharmacy Conte&t 'iagram

1rescription octor 0nfilled Order 4nfo )ospital 1harmacy &ystem &tore "anager 7

rug Babel 4nfo

0nfilled Order 4nfo Desponse

1atient ?umber and rug $ype, Amount I Cost

=8

!hapter "

Structuring System #e$uirements% &rocess Modeling

1ospital Pharmacy (evel)* 'iagram

6 octor 1rescription Deview I &end 1rescription to &tation 1harmacy $ech Deview

0nfilled Order 4nfo 0nfilled Order 4nfo Desponse

1rescription

1atient !ile

+ Deview 1rescription Order by &tation Order 4nfo 8 !ill Order rug Babel 4nfo 9 %enerate Babel

1atient 4nfo

Order !ill 4nfo

1atient ?umber and rug $ype, Amount I Cost

*illing ept

rug Babel 4nfo ?urses &tation

=9

Modern Systems Analysis and Design, 3rd edition

nstructors Manual

69. A suggested answer is provided below.

Contracting System Conte&t 'iagram

7 1urchase Order %overnment Agency 4nvalid 1urchase Order 4nfo Contracting &ystem

&hipping *ill %overnment Agency

4nvoice

Contracting System (evel)* 'iagram

1urchase Order %overnment Agency 4nvalid 1urchase Order 4nfo

6 Eerify 1urchase Order

Contract $erms and Conditions

6
Ealidated 1O H

Contract atabase

Ealidated 1O 4nvoice &hipping *ill + Chec' 4nventory

Completed 1O Closeout 4nfo

?ot5in5stoc' Deport 8

Ealidated 1O

1ull I &hip 4tems from 4nventory

Ealidated 1O, 4nitial &hipping *ill I 3(ception Deport

+
&hipping *ill for 3(ception Deport 4tems

Contracts !ile

=:

!hapter "

Structuring System #e$uirements% &rocess Modeling

6:. A suggested answer is provided below.

#raining (ogistics System Conte&t 'iagram

Deserve I &eating 4nfo 7 ?egotiation 4nfo ?egotiation 4nfo 1ossible $ravel Arrangements Approved $ravel Arrgmts $raining Bogistics &ystem Contract Agreement 4nfo Contract Agreement 4nfo &ales "anager

&eminar I Consultant 4nfo *oo'ings ept ?o. Anticipated Degistrants

Consultant

$ravel Confirmation I 4tinerary Availability, Cost, "tg &pace, I Bocation 4nfo Dequirements 1otential "eeting &ite Availability, Cost, "tg &pace, I Bocation 4nfo

!light &chedules !light Deservation 4nfo

$ravel Agency

=;

Modern Systems Analysis and Design, 3rd edition

nstructors Manual

#raining (ogistics System (evel)* 'iagram

Availability, Cost, "tg &pace, I Bocation 4nfo Dequirements 1otential "eeting &ite

Deserve I &eating 4nfo 6 Arrange for "eeting !acilities ?egotiation 4nfo ?egotiation 4nfo Contract Agreement 4nfo Contract Agreement 4nfo "eeting !acility 4nfo + &ales "anager

Availability, Cost, "tg &pace, I Bocation 4nfo

&eminar I Consultant 4nfo *oo'ings ept ?o. Anticipated Degistrants

&eminar "tg !acil Dequirements &eminar Bogistics atabase 6 Consultant $ravel 4nfo !light &chedules !light Deservation 4nfo Dequest for "aterials $ravel Agency

Consultant

"a'e Consultant Apprvd $ravel Arrgmts $ravel Arrangements $ravel Confirmation I 4tinerary 8 etermine I &end &eminar "aterials

1ossible $ravel Arrgmts

9 %ather, *o( I &end "aterials to "eeting !acility

&eminar "aterial Dequirements

&hipment ?otification

=<

!hapter "

Structuring System #e$uirements% &rocess Modeling

6;. $his is an e(cellent question to demonstrate the integration capabilities among different diagramming tools. 4n order to prepare the process model, your students will need access to Oracles process modeler. Cour students diagrams will vary, since there is not any one correct answer. 0se 1roblem and 3(ercise 68s scenario to demonstrate the ease with which data flow diagrams, process models, and a functional hierarchy diagram can be built.

+uidelines -or 2sing the 3ield %&ercises

6. *ecause data flow diagrams are a popular tool, students are li'ely to find analysts who are using them. &tudents are also li'ely to find that data flow diagrams for real information systems are much larger and more comple( than those discussed in this chapter. $his is li'ely to help students see why data flow diagrams are so useful. Aithout them, it would be difficult to ma'e sense of large, comple( business processes and information systems. &tudents will also li'ely discover different notations are in use than depicted in this te(t. &ome systems analysts may prefer ob,ect5oriented modeling rather than ! s or may state that their organi2ation is reducing the use of ! s in favor of entity5relationship diagrams and other notations. 4t would also be interesting to discover what type of drawing or CA&3 tool analysts use for developing and maintaining ! s. +. &tudents are li'ely to have a difficult time constructing data flow diagrams for a real business process and information system. As with previous questions, there are a number of ways that students can draw their data flow diagrams for the system under question. &tudents should reali2e that there is not necessarily one right# data flow diagram for this or most other business processes. 3ven if the students have not had much practice in constructing data flow diagrams, they can still construct diagrams that will be interesting and useful to the people who have developed or who are using and>or maintaining the system under question. Demind students to start with a conte(t diagram and use decomposition to create refined, focused diagrams of different subsystems. 4t is difficult to draw ! s because it can be difficult to get an unambiguous e(planation from one or several people. Also, it may be hard to determine from business documents how a system wor's .or is supposed to wor'/. Deal business situations are typically messy, and unequivocal descriptions are not easy to obtain. $his point is important for your students to learn and reveals the value of reasonably precise notations .models/ such as ! s. 8. "ost CA&3 tools have capabilities for automatically chec'ing for, reporting on, and warning of rule violations in data flow diagrams. "any of the CA&3 tools with graphical user interfaces let the user simply clic' on a button to run various tests of the integrity of the diagrams. &ome CA&3 tools automatically do not allow a user to commit errors while constructing the diagram. !or e(ample, the CA&3 tools display an error message in a pop5 up window when a user ma'es a mista'e, such as attempting to place a data flow directly between two sources>sin's. 9. &tudents are li'ely to find that various types of software pac'ages have elements in them that can be used to construct data flow diagrams. !or e(ample, a drawing pac'age might include data flow diagram symbols. Alternatively, a database management pac'age might include some data dictionary features. )owever, none of these will be as effective and easy for constructing data flow diagrams as will a CA&3 tool with features for this purpose. 4f students do not believe this, have them construct a simple data flow diagram using a drawing pac'age, and then have them move sources or processes around on the screen. Chances are

=8

Modern Systems Analysis and Design, 3rd edition

nstructors Manual

that the drawing pac'age does not automatically move all the connected data flows while these ob,ects are moved around the screen. Aith a CA&3 tool, when an ob,ect is moved, its connecting data flows move with it. &imilarly, with a CA&3 tool you can often move to a different, related data flow diagram by clic'ing on a button or by double clic'ing on a particular process. Also, drawing pac'ages do not 'now ! rules, so no automatic error chec'ing can be done and decomposition is not a function of the pac'age. 4n addition, since a drawing pac'age has no repository, symbols on different diagrams probably cannot be lin'ed .e.g., when details on a higher5level diagram change, these are automatically reflected on nested diagrams/. :. &tudents might find that these people draw their business process using either a data flow diagram, a flow chart, a series of input>output models, or some combination of these techniques. 1eople will draw the diagram using the techniques with which they are familiar. 4f they are not familiar with any techniques for modeling processes, then they will probably draw pictures that represent physical reality .e.g., a piece of paper moving from one person to another person, or a piece of paper moving from one person to a file cabinet/. !or people who are not familiar with data flow diagrams, the students should find that it is relatively easy to show them that data flow diagrams are a better way to model processes. Chances are that this persons original picture already has many of the elements of a standard data flow diagram anyway. Desearch has found that process modeling is a very natural activity for most people, even when they are not formally trained in this technique.

+uidelines -or 2sing the 4roadway %ntertainment Company Cases

%uidelines and answers for using the *roadway 3ntertainment Company cases are available on this te(tboo's companion Aeb site. 1lease visit www.prenhall.com>hoffer to access this information.

==