Use case diagram for dental clinic system

Analysis & Design Modern Info Systems

1. Describe a fully developed use case for Receive new book in the university library system and then:

o Describe (UML) Activity diagram for the Enter new patient information use case

o Develop a first-cut sequence diagram that only includes the actor and problem domain classes.

o Develop a design class diagram based on your solution. Be sure to include your controller class.

o Add the view layer classes and the data access classes to your diagram. You may do this with two separate diagrams to make them easier to work with and read.

o Explain What is the difference between designing with CRC cards and designing with sequence diagrams?

o Explain the syntax of a message on a sequence diagram.

o What is the purpose of the first-cut sequence diagram? What kinds of classes are included?

o What is the purpose of the use case controller?

2. Using RMO that is the case in your text book answer the following:

Assume that RMO will begin asking a random sample of customers who order by telephone about purchases made from competitors. RMO will give customers a 15 percent discount on their current order in exchange for answering a few questions. To store and use this information, RMO will add two new classes and three new associations to the class diagram. The new classes are Competitor and ProductCategory. Competitor has a one-to-many association with ProductCategory, and the existing Customer class also has a one-to-many association with ProductCategory. Competitor has a single attribute called Name. ProductCategory has four attributes: Description, DollarAmountPurchased, MonthPurchased, and YearPurchased. Revise the relational database schema shown in Figure 12-10 to include the new classes and associations. All tables must be in 3NF.

3. Read this narrative and then make a list of system capabilities and describe how the project could be developed for the company:

The new direct sales and accounting system for Especially for You Jewelers will be an important element in the growth and success of the jewelry company. The direct sales portion needs to track every sale and be able to link to the inventory system for cost data to provide a daily profit and loss report. The customer database needs to be able to produce purchase histories to assist management in preparing special mailings and special sales to existing customers. Detailed credit balances and Aged accounts for each customer would help solve the problem with the high balance of accounts receivables. Special notice letters and credit history reports would help management reduce accounts receivable.

CHAPTER B

After reading this chapter, you should be able to:

Explain how the traditional approach and the object-oriented approach differ when modeling the details of a use case

List the components of a traditional system and the symbols representing them on a data flow diagram

Describe how data flow diagrams can show the system at various levels of abstraction

Develop data flow diagrams, data element definitions, data store definitions, and process descriptions

Develop tables to show the distribution of processing and data access across system locations

LEARning ObjECTivEs

The Traditional Approach to Requirements

Traditional and Object-Oriented Views of Activities and Use Cases

Data Flow Diagrams

Documentation of DFD Components

Locations and Communication through Networks

CHAPTER OuTLinE

17204_APPB_ptg01_019-052.indd 19 12/12/14 11:44 AM

OL-20 PART 2 ■ Systems Analysis Activities

■ Overview Chapters 3, 4, and 5 described two key concepts associated with modeling sys- tem requirements in the traditional and the object-oriented approaches to infor- mation systems development: the use cases and the things involved in users’ work. In Chapter 3, you learned to identify use cases and describe them with use case diagrams. In Chapter 4, you learned to describe things in the user’s work domain by using class and entity-relationship diagrams. In Chapter 5, you learned how to describe use cases in further detail with use case descriptions, activity diagrams, sequence diagrams, and state-machine diagrams. By the end of Chapter 5, you had mastered all the object-oriented models used to describe a system’s functional requirements.

This chapter describes an older and more traditional approach to repre- senting requirements. In this approach, entity-relationship diagrams represent things in the user’s work domain. However, the models that represent activities

Opening CAse San Diego PerioDicalS: Following the Data Flow Arturo Romero and Lei Xu were meeting to review the first draft of several data flow diagrams for San Diego Periodicals’ new advertising billing system. Arturo was the analyst assigned to define the new system require- ments. Lei was the manager in charge of advertising accounts; she knows virtually all there is to know about how the current system operates. The two had met sev- eral times before. Their most recent meeting (just last week) reviewed details of the current system events, ad request processing, and process participants. Arturo left that meeting with pages of notes and sample forms and reports from the current system. Arturo had telephoned Lei several times since that meeting to ask additional questions.

Arturo began the review by saying, “The materials and information that you gave me last week took me quite awhile to absorb, but I think I was able to under- stand and document all the system activities or use cases that we discussed. The purpose of this meeting is to ensure that the processing requirements I’ve written down are complete and accurate. Let’s start with a few of the diagrams that I’ve created.”

Arturo laid out three diagrams on the table. Lei looked at them briefly and said, “I’ve never seen dia- grams like this before; they look like blueprints for playing a game of marbles. And I thought the entity-relationship diagrams were strange!”

Arturo replied, “I expect this review will go slowly because this is your first look at this style of documenta- tion. I’ll explain how to interpret the diagrams as we go along. Ask as many questions as you like. The quality of our work depends on your understanding the diagrams, so don’t be shy.”

Arturo continued, “The pictures are called data flow diagrams, or DFDs for short. They divide your system

into processing functions, represented by the rectangles with rounded-off corners. The arrows show data move- ment among processes and between processes and files.” Lei pointed to a square on one of the diagrams and said, “I assume that this is a company purchasing ad space?”

Arturo replied, “Yes, the squares represent people or organizations that supply inputs or expect output data from the system.”

Lei said, “I think I can get the hang of this. I rec- ognize most of the names that you’ve used for the pro- cesses and data. I’m not sure what these other symbols are; they’re named for things we store in our manual files and database, but they don’t seem to correspond exactly to our system.”

“They don’t,” Arturo replied. “They’re entities from the entity-relationship diagram that we developed a couple of weeks ago. But let’s skip over those for the moment. Why don’t we walk through the processing sequence for booking an ad, and we’ll discuss the enti- ties as we get to them?”

Arturo and Lei continued reviewing the DFDs, and the next thing they knew, over an hour had passed. Several pages of Arturo’s notepad had been filled, and 25 corrections and comments were noted in red on the data flow diagrams. Lei said, “My brain feels completely drained. I don’t think that I can do any more of this today.”

Arturo replied, “You’ve given me plenty of things to work on, so let’s call it quits for now. Can we meet for two hours at nine o’clock on Thursday?”

Lei replied, “Yes, I’m free then. So, will you be bring- ing more data flow diagrams or do you have something even weirder up your sleeve?”

Arturo smiled and said, “The toughest stuff is behind us, but you should expect a few more surprises.”

17204_APPB_ptg01_019-052.indd 20 12/12/14 11:44 AM

OL-21CHAPTER B ■ The Traditional Approach to Requirements

(use cases) and the interaction among activities and things are very different from object-oriented models. Although object-oriented activity models are more widely used than traditional models, the traditional models are still used in many contexts, including documentation for older systems and to present requirements for new systems to users in an easy-to-read fashion. Thus, learn- ing how to read and develop traditional models is a useful skill for the modern systems analyst.

■ Traditional and Object-Oriented Views of Activities and Use Cases

The traditional and object-oriented approaches to system development differ in how a system’s response to an event is modeled and implemented. The tradi- tional approach views a system as a collection of processes—some performed by people and some performed by computers. Traditional computer processes are much like procedural computer programs; they contain instructions that execute in a sequence. When the process executes, it interacts with stored data, reading data values and then writing other data values back to the data file. The process might also interact with people, such as when an instruction asks a user to input a value or it displays information to a user on the computer screen. The tradi- tional approach to systems, then, involves processes, stored data, inputs, and outputs and it includes processing models that emphasize these system features, as shown on the left side of Figure B-1.

The object-oriented approach views a system as a collection of interacting objects, as summarized on the right side of Figure B-1. The objects are based on things in the problem domain, as discussed in Chapter 4. Objects are capable of behaviors (called methods) that allow them to interact with each other and with peo- ple using the system. One object asks another object to do something by sending it a message. There are no conventional computer processes, data files, or databases per se. Objects carry out the activities and remember the data values. When modeling what the system does in response to an event, the object-oriented approach includes models that show objects, their behavior, and their interactions with other objects.

Because of these differences summarized in Figure B-1, the traditional and object-oriented approaches to requirements employ different models, as sum- marized in Figure B-2. The models on the right side of the figure were described in Chapters 3, 4, and 5. Entity-relationship diagrams (ERDs) were described in Chapter 4. The remainder of this chapter explores the traditional models on the lower left side of Figure B-2.

■ Data Flow Diagrams The traditional approach to information system development describes activi- ties as processes carried out by people or computers. A graphical model that has proven to be quite valuable for modeling processes is the data flow diagram.

FIGURE B-1 Traditional versus object-oriented approaches

Traditional Approach

System is a collection of processes. Processes interact with data entities. Processes accept inputs and produce outputs.

Object-Oriented Approach

System is a collection of interacting objects. Objects interact with people and each other. Objects send and respond to messages.

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 21 12/12/14 11:44 AM

OL-22 PART 2 ■ Systems Analysis Activities

Activity diagrams are also used, but the data flow diagram is the most com- monly used process model.

A data flow diagram (DFD) is a graphical system model that shows all the main requirements for an information system in one diagram: inputs and out- puts, processes, and data storage. Everyone working on a development project can see all aspects of the system working together at once with the DFD. That is one reason for its popularity. The DFD is also easy to read because it is a graphi- cal model and because there are only five symbols to learn (see Figure B-3). End users, management, and all information systems workers can typically read and interpret the DFD with minimal training.

Figure B-4 shows an example of a data flow diagram representing a por- tion of the Ridgeline Mountain Outfitters (RMO) customer support system. Recall from Chapter 2 that the CSS supports catalog, telephone, and Web-based orders and is one of the systems that will be replaced by the new Consolidated Sales and Marketing System. The CSS was first deployed 15 years ago and incre- mentally updated four years later. Traditional and object-oriented analysis mod- els were commonly used at that time. Thus, the CSS is documented by using a combination of ERDS, DFDs, and use case descriptions.

The square on the left side of Figure B-4 is an external agent—Customer, the Source and Destination for some data outside the system. The rectangle with rounded corners is a process named Look up item availability that can also be referred to by its number (1). A process defines rules for transforming inputs to outputs. The lines with arrows are data flows. Figure B-4 shows two data flows between Customer and process 1: a process input named Item inquiry and a process output named Item availability details. The final symbol—the flat, open-ended rectangle—is a data store. Each data store represents a file or part of a database that stores information about a data entity. In this example, data

data flow diagram (DFD) a diagram that represents system requirements as processes, external agents, data flows, and data stores

external agent a person or organization, outside the system boundary, that supplies data inputs or accepts data outputs

process a symbol on a DFD that represents an algorithm or procedure by which data inputs are transformed into data outputs

data flow an arrow on a DFD that represents data movement among processes, data stores, and external agents

data store a place where data is held pending future access by one or more processes

FIGURE B-2 Requirements models for the traditional and object-oriented approaches

Events, use cases, and event table

Things

DFD fragments

Data flow definitions

Process descriptions

Entity- relationship

diagram (ERD)

Class diagram Object-Oriented

Approach Traditional Approach

Other traditional

models

Use case diagrams

Use case descriptions

System sequence diagrams

Activity diagrams

State machine diagrams

Context diagram

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 22 12/12/14 11:44 AM

OL-23CHAPTER B ■ The Traditional Approach to Requirements

flows (lines with arrows) point from the data stores to the process, meaning that the process looks up information in the data stores named Catalog, Product item, and Inventory item.

Process 1 in Figure B-4 corresponds to a use case that responds to the event Customer wants to check item availability. The use case trigger is a data flow

FIGURE B-3 Data flow diagram symbols

FIGURE B-4 A DFD showing the process Look up item availability (a DFD fragment from the RMO case)

Process

Data flow

External agent

Data store

Real-time link

Step-by-step instructions are followed that transform inputs into outputs (a computer or person or both doing the work).

Data flowing from place to place, such as an input or output to a process.

The source or destination of data outside the system.

Data at rest, being stored for later use. Usually corresponds to a data entity on an entity- relationship diagram.

Communication back and forth between an external agent and a process as the process is executing (e.g., credit card verification).

id

Customer Look up item

availability

1 Item

inquiry

Item availability

details

External agent, data flows, and the process come from information about

the event in the event table. Data stores come from the entity-relationship

diagram.

Destination

Source Use caseTrigger

Response

Product item

Inventory item

Catalog

© C

en ga

ge L

ea rn

in g®

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 23 12/12/14 11:44 AM

OL-24 PART 2 ■ Systems Analysis Activities

named Item inquiry, the source is the Customer, the response is a data flow named Item availability details, and the destination for the response is Customer. Each data store represents an entity from the CSS entity-relationship diagram (ERD) shown in Figure B-5. Therefore, the data flow diagram shows the system use case in response to this one event in graphical form and integrates processing triggered by the event with the data entities modeled using the ERD.

■ Data Flow Diagrams and Levels of Abstraction Many different types of data flow diagrams are produced to show system requirements. The example just described is a DFD fragment, showing one pro- cess in response to one event. Other data flow diagrams show the processing at either a higher level (a more general view of the system) or at a lower level (a more detailed view of one process). These differing views of the system (high level versus low level) are called levels of abstraction.

Data flow diagrams can show either higher- or lower-level views of the sys- tem. The high-level processes on one DFD can be decomposed into separate lower-level, detailed DFDs. Processes on the detailed DFDs can also be decom- posed into additional diagrams to provide multiple levels of abstraction.

levels of abstraction any modeling technique that breaks the system into a hierarchical set of increasingly more detailed models

FIGURE B-5 The DFD integrates events, use cases, and the ERD

Order Item

Order

Shipper

Shipment

Order Transaction

Return Item

Customer

Inventory Item

Catalog Catalog Product

Product Item

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 24 12/12/14 11:44 AM

OL-25CHAPTER B ■ The Traditional Approach to Requirements

Figure B-6 shows how DFDs at each level of detail provide additional infor- mation about one process at the next higher level. The topmost DFD shows the most abstract representation of the course registration system as a single pro- cess. The middle DFD shows internal details of a context diagram process. The bottom DFD shows internal details of process 1 in the middle DFD. Each DFD abstraction level is described further in the following sections.

FIGURE B-6 Layers of DFD abstraction for a course registration system

Course registration

system

Enroll student

2

Produce class list

3

Schedule course

1

Course enrollment

Student

Offered course

Enrollment request

Schedule

Class list

Choose days and

times

1.1

Assign faculty

1.2

Offered course

Assign rooms

1.3

Available rooms

Course

Available faculty

Context Diagram

Academic department

Faculty member

Class list Student

Schedule

Enrollment request

Schedule data

Diagram 0

Academic department

Student

Faculty member

Schedule data

Diagram 1

Academic department

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 25 12/12/14 11:44 AM

OL-26 PART 2 ■ Systems Analysis Activities

❚ Context Diagram A context diagram is a DFD that describes the most abstract view of a system. All external agents and all data flows into and out of the system are shown in one diagram, with the entire system represented as one process. The top- most DFD in Figure B-6 is a context diagram for a simple university course registration system that interacts with three external agents: Academic depart- ment, Student, and Faculty member. Academic departments supply information on offered courses, students request enrollment in offered courses, and faculty members receive class lists when the registration period is complete.

A context diagram clearly shows the system boundary. The system scope is defined by what is represented within the single process and what is represented as external agents. External agents that supply or receive data from the system are outside the system scope, and everything else is inside the system scope. The con- text diagram doesn’t usually show data stores because all the system’s data stores are considered to be within the system scope (that is, part of the internal imple- mentation of the process that represents the system). However, data stores may be shown when they are shared by the system being modeled and another system.

The context diagram is usually created in parallel with the initial list of use cases and events. Each trigger for an external event becomes an input data flow, and the source becomes an external agent. Each response becomes an output data flow, and the destination becomes an external agent. Triggers for temporal events aren’t data flows, so there are no input data flows for temporal events.

❚ DFD Fragments A DFD fragment is created for each use case triggered by an event in the event table. Each DFD fragment is a self-contained model showing how the system responds to a single event. The analyst usually creates DFD fragments one at a time, focusing attention on each part of the system. The DFD fragments are drawn after the event table and context diagram are complete.

Figure B-7 shows the three DFD fragments for the simple course regis- tration system. Each DFD fragment represents all processing for a use case

context diagram a DFD that summarizes all processing activity within the system in a single process symbol

DFD fragment a DFD that represents the system response to one event within a single process symbol

FIGURE B-7 Three DFD fragments for the course registration system

Schedule data

Class listFaculty member

Academic department

Student

Enrollment request

Schedule

Offered course

Student

Offered course

Course enrollment

Student

Offered course

Course enrollment

Schedule course

Enroll student

2

Produce class list

3

1

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 26 12/12/14 11:44 AM

OL-27CHAPTER B ■ The Traditional Approach to Requirements

triggered by an event within a single process symbol. The fragments show details of interactions among the process, external agents, and internal data stores. The data stores used on a DFD fragment represent entities on the ERD. Each DFD fragment shows only those data stores that are actually needed to respond to the event.

❚ The Event-Partitioned System Model All the DFD fragments for a system or subsystem can be combined on a single DFD called the event-partitioned system model (diagram 0). Figure B-8 shows how the three course registration system DFD fragments shown in Figure B-7 are combined to create diagram 0.

event-partitioned system model (diagram 0) a DFD that models system requirements by using a single process for each event in a system or subsystem

FIGURE B-8 Combining DFD fragments to create the event-partitioned system model for the course registration system

Enroll student

2

Produce class list

3

Schedule course

1

Course enrollment

Student

Offered course

Enrollment request

Schedule

Class list

Diagram

DFD fragment 1

DFD fragment 2

DFD fragment 3

0

Academic department

Student

Faculty member

Schedule data

Class listFaculty member

Student

Offered course

Course enrollment

Produce class list

3

Combine DFD fragments

to create diagram 0

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 27 12/12/14 11:44 AM

OL-28 PART 2 ■ Systems Analysis Activities

Diagram 0 is used primarily as a presentation tool. It summarizes an entire system or subsystem in greater detail than does a context diagram. However, analysts often avoid developing diagram 0 because:

■ The information content duplicates the set of DFD fragments. ■ The diagram is often complex and unwieldy, particularly for large systems

that respond to many events.

As we will discuss later in this chapter, redundancy and complexity are two DFD characteristics that analysts should avoid whenever possible.

■ RMO Data Flow Diagrams Figure B-9 shows a context diagram for the existing RMO customer support system. Normally, data flows and external agents on the context diagram are

FIGURE B-9 A context diagram for the RMO customer support system

Customer support system

Credit bureau

Accounting

Credit info

Prospective customer

activity report

Promotion

package details

Catalog activity report

Catalog and

promotion details

Order, return, and inquiry details

Catalog and promotion materials

Transaction

Transaction summary

report

Order, back order, and fulfillment details

Order, adjustment, and

fulfillment reports Management

Bank

MerchandisingMarketing

Shipping

Customer details

Customer ©

C en

ga ge

L ea

rn in

g®

17204_APPB_ptg01_019-052.indd 28 12/12/14 11:44 AM

OL-29CHAPTER B ■ The Traditional Approach to Requirements

taken directly from the event table as discussed previously, but because the RMO customer support system responds to 20 events, this figure combines data flows for some events for simplicity. In a smaller system example with 10 to 15 events, you should include all data flows on the context diagram.

When a system responds to many events, it is commonly divided into subsys- tems, and a context diagram is created for each subsystem. Figure B-10 divides the RMO customer support system into subsystems based on use case similari- ties, including interactions with external agents, interactions with data stores, and similarities in required processing. Figure B-11 shows the context diagram for the order-entry subsystem.

FIGURE B-10 RMO subsystems and use cases for each subsystem

Order-Entry Subsystem

Look up item availability. Create new order. Update order. Produce order summary reports. Produce transaction summary reports.

Order-Fulfillment Subsystem

Look up order status. Record order-fulfillment. Record back order. Create order return. Produce fulfillment summary report.

Customer Maintenance Subsystem

Provide catalog information. Produce prospective customer activity reports. Update customer account. Distribute promotional package. Create customer charge adjustment. Produce customer adjustment reports.

Catalog Maintenance Subsystem

Update catalog. Create special product promotion. Create new catalog. Produce catalog activity reports.

FIGURE B-11 A context diagram for the RMO order-entry subsystem

Order-entry subsystem

Accounting

Credit info

Transaction

Management

Bank Shipping

Customer

Credit bureau

Order confirmation

Order change

Item availability inquiry

Order details

Order change details

Transaction summary report

Order-summary reports Order

Item availability response

Change confirmation

© C

en ga

ge L

ea rn

in g®

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 29 12/12/14 11:44 AM

OL-30 PART 2 ■ Systems Analysis Activities

Figure B-12 shows the DFD fragments for the RMO order-entry subsystem. Note that there are five DFD fragments—one for each order-entry subsystem use case listed in Figure B-10.

Similarly, Figure B-13 shows the RMO order-entry subsystem diagram 0, the result of combining the DFD fragments from Figure B-12. To simplify the diagram and make it more readable, the seven data stores in Figure B-12 are collapsed into a single data store in Figure B-13. Recall that diagram 0 is just used as a presentation aid. The DFD fragments show which processes interact with which individual data stores.

❚ Decomposition to See One Activity’s Detail Some DFD fragments involve a lot of processing that the analyst needs to explore in more detail. As with any modeling step, further decomposition helps the analyst learn more about the requirements while also producing needed documentation. Figure B-14 shows an example of a more detailed diagram for the CSS DFD frag- ment 2: Create new order. It is named diagram 2 because it shows the “insides” of process 2. The subprocesses are numbered 2.1, 2.2, 2.3, and 2.4. But the number- ing system doesn’t necessarily imply the sequence of subprocess execution.

The diagram decomposes process 2 into four subprocesses: Record customer information, Record order, Process order transaction, and Produce confirma- tion. These subprocesses are viewed as the four major steps required to complete the activity. This decomposition is just one way to divide the work. Another analyst might arrive at a different solution.

The first step begins when a customer provides the information making up the New order data flow. The New order data flow contains all the information about

FIGURE B-12 DFD fragments for the RMO order-entry subsystem

Order confirmationCustomer

Item inquiry

Item availability

details Shipping

Order details

New order

Customer

Credit bureau

Credit info

Bank

Transaction

Change confirmation

Shipping

Order change details

Order change request

Customer

Credit bureau

Credit info

Bank

Transaction

Management

Order summary reports

Accounting

Transaction summary reports

Order

Order item

Order transaction

Produce transaction summary reports

5

Produce order

summary reports

4

Order

Order item

Order transaction

Product item

Return item

Shipment

Customer

Inventory item

Order

Order item

Order transaction

Product item

Update order

3

Customer

Inventory item

Order

Order item

Order transaction

Product item

Create new order

2

Catalog

Product item

Inventory item

Look up item

availability

1

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 30 12/12/14 11:44 AM

OL-31CHAPTER B ■ The Traditional Approach to Requirements

the customer and the items the customer wants to order. If the customer is new, process 2.1 stores the customer information in the data store named Customer (creating a new customer record or updating existing customer information as required). Remember that the data store represents the customer data entity on the ERD (see Figure B-5). Process 2.1 then sends the rest of the information about the order—a data flow named Order details—on to process 2.2.

Process 2.2 takes the Order details data flow and creates a new order record by adding data to the Order data store. Then, for each item ordered, the stock on hand and the current price are looked up in the Product item and Inventory item data stores. If adequate stock is on hand, an order item record is created for that item and the stock on hand for the inventory item record is changed. If three items are ordered, one order record is created and three order item records are created.

Process 2.2 adds up the total amount due for the order (price times quantity for each item) and sends the data flow named Transaction details to process 2.3 to record the transaction. Transaction details include the order number, amount, and credit card information. Process 2.3 needs a real-time link to a credit bureau to get a credit authorization for the customer’s credit card. This needs to be a

FIGURE B-13 An event-partitioned model of the order-entry subsystem (diagram 0)

Create new order

2

Produce order

summary reports

4

Update order

3

Produce transaction summary reports

5

Look up item

availability

1

Transaction

Credit info

Credit info

Transaction

Transaction summary reports

Shipping

Management Credit bureauBank

Order summary reports

Order change request

Change confirmation

New order

Order details

Customer Item inquiry

Item availability details

Order change details

Order confirmation

Accounting

Catalog Customer Order

Order item Product item Inventory item Order transaction

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 31 12/12/14 11:44 AM

OL-32 PART 2 ■ Systems Analysis Activities

real-time link rather than a data flow because data needs to flow back and forth rapidly while the process is executing. If the credit card is approved, a record of the transaction is created in the Order transaction data store and a data flow for the transaction goes directly to the bank.

The final process produces the order confirmation for the customer and the order details that go to shipping. Using the order number, process 2.4 looks up data on the Order, the Customer, and each Order item (plus the item description from the Product item) and then produces the required outputs.

■ Physical and Logical DFDs A DFD can be a physical system model, a logical system model, or a blend of the two. In a physical DFD, one or more assumptions about implementation technology will be embedded in the DFD. These assumptions can take many forms and might be very difficult to spot. A logical DFD is drawn as if the sys- tem might be implemented with any technology. In fact, one way that analysts develop logical DFDs is to assume that the system is implemented with perfect internal technology. Specifics of this assumption include process that never make mistakes, data stores that can hold infinite amounts of data without ever losing them, and data flows and processes with infinite capacity and zero exe- cution or transmission time. The analyst simply omits any system feature that wouldn’t exist under the perfect internal technology assumption.

Consider whether diagram 2 in Figure B-14 is a logical model. First, is it clear what type of computer is doing the processing? Could it be a desktop system?

physical DFD A DFD that includes one or more assumptions about implementation technology

logical DFD a DFD developed under the assumption of perfect internal technology

perfect internal technology an assump- tion that includes such technology capabilities as instant processing and data retrieval, infinite storage and network capacity, and a complete absence of errors

FIGURE B-14 A detailed diagram for Create new order (diagram 2) Diagram 2: Create New Order

Customer

Record customer

information

2.1 Shipping

Customer

Order

Order item

Product item

Inventory item

Order transaction

Produce confirmation

2.4

Record order

2.2

Process order

transaction

2.3

Credit bureau Bank

Transaction details

Order ID

Order details

Order confirmation

New order

Transaction

Order details

Credit info

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 32 12/12/14 11:44 AM

OL-33CHAPTER B ■ The Traditional Approach to Requirements

A tablet or phone app? A cloud computing solution? Or could the entire process as just described be carried out by people without any computer at all? Similarly, are the data stores sequential computer files? Are they tables in a relational database? Or are they files of paper in a file cabinet? How does the system get the data flow New order from the customer so it can be processed? By clicking check boxes and list boxes in a Windows application? Or on a Web page? Or by manually filling out a form that is later scanned into the system? Or by talking to the clerk over the phone? Or by talking to a speech recognition program over the phone?

All the alternatives described are possible, and if the model is a logical model, you shouldn’t be able to tell how the system is implemented. At the same time, the processing requirements (what must go on) should be fairly detailed— down to indicating what attribute values are needed. The model could be even more detailed and still be a logical model.

Now consider whether the DFD in Figure B-15 is a physical system model by comparing it with diagram 1 in Figure B-6. A number of elements indicate assumptions about implementation technology, including:

■ Technology-specific processes ■ Actor-specific process names

Figure B-15 A physical DFD for scheduling courses

© C

en ga

ge L

ea rn

in g®

Old schedules Offered course Make

copies for department

chairs

1.1

Chair modifies schedule

1.2

Chair incorporates

faculty preferences

1.3

Chair incorporates

feedback

1.4

Assoc. dean assigns reserved

rooms

1.5

Reserved room

General room

University scheduling

assigns more rooms

1.6

University scheduling

prints schedule

1.8

Faculty member

Assoc. dean incorporates

more feedback

1.7

Student

Previous year schedule

Previous year schedule copy (one for each department chair)

Proposed schedule w/o faculty assignments

Proposed schedule

Chair proposed schedule

Proposed schedule

Student-recommended changes

Proposed schedule w/o faculty assignments

Teaching preferences

Proposed schedule Faculty-

recommended changes

Assoc. dean- proposed schedule

University- proposed schedule

Student- recommended

changes

Faculty- recommended

changes

University-proposed schedule

University- proposed schedule

Final schedule

17204_APPB_ptg01_019-052.indd 33 12/12/14 6:56 PM

OL-34 PART 2 ■ Systems Analysis Activities

■ Technology- or actor-specific process orders ■ Redundant processes, data flows, and files

The most obvious technology assumption is embedded in the name of process 1.1. Making copies is an inherently manual task, which implies that the data store Old schedules and the data flows into and out of process 1.1 are paper. It is possible that the data store and flows are electronic, but if so, the question arises why a process would be needed to make electronic copies.

Many of the process names include actors in the system. References to Chair, Assoc. dean, and University scheduling all indicate that a particular indi- vidual or department performs a process. The sequential flow of data among the processes is a by-product of the person or department that carries out each pro- cess. One can imagine alternate implementations with fewer processes, different process orders, or different assignment of processes to individuals and depart- ments. The DFD clearly models one very specific set of decisions about process ordering and responsibility.

The DFD also includes processes with similar or redundant processing logic. For example, faculty input is accepted early, but faculty members later perform error checking twice (the data flows from processes 1.4 and 1.7). Also, rooms are assigned at two different times from two different data stores (Reserved room for process 1.5 and General room for process 1.6). As before, these features indicate very specific assumptions about the technology and division of respon- sibility. The redundant error checking indicates that it is possible for previous processes to make mistakes. A system implemented with perfect internal tech- nology needs no internal error checking. The partitioning of room assignment between two files and processes may be related to technology (for example, no single process could successfully assign all rooms at once) or it could indicate a historic division of responsibility for room assignment.

Inexperienced analysts often develop DFDs, such as the one in Figure B-15. The path to developing such a model is simple: Model everything the current sys- tem does exactly the way it does it. The problem with this approach is that design assumptions based on outdated technology limitations can become inadvertently embedded in the new system. This problem is most prevalent when analysis and design are performed by different persons or teams. The designer(s) may not realize that some of the “requirements” embedded in the DFDs are simply reflections of the way things were in the past, not the way they necessarily should be in the future.

Physical DFDs are sometimes developed and used during the last stages of analysis or early stages of design. They are useful models for describing alternate implementations of a system prior to developing more detailed design models. But analysts should avoid creating physical DFDs during all analysis activities, except when generating design and implementation alternatives. Even during that activity, analysts should clearly label physical DFDs as such so readers know the model represents one possible implementation of the logical system requirements.

■ Evaluating DFD Quality A high-quality set of DFDs is readable, is internally consistent, and accurately represents system requirements. Accuracy of representation is determined pri- marily by consulting users and other knowledgeable stakeholders. A project team can ensure readability and internal consistency by applying a few simple rules to DFD construction. Analysts can apply these rules while developing the DFDs or during a separate quality check after preparing DFD drafts.

❚ Minimizing Complexity People have a limited ability to manipulate complex information. If too much information is presented at once, people experience a phenomenon called

17204_APPB_ptg01_019-052.indd 34 12/12/14 11:44 AM

OL-35CHAPTER B ■ The Traditional Approach to Requirements

information overload. When information overload occurs, a person has dif- ficulty in understanding. The key to avoiding information overload is to divide information into small and relatively independent subsets. Each subset should contain a comprehensible amount of information that people can examine and understand in isolation.

A layered set of DFDs is an example of dividing a large set of information into small, independent subsets. Each DFD can be examined in isolation. The reader can find additional detail about a specific process by moving down to the next level or find information about how a DFD relates to other DFDs by exam- ining the next-higher-level DFD.

An analyst can avoid information overload within any single DFD by fol- lowing two simple rules of DFD construction:

■ 7 6 2 ■ Interface minimization

The rule of 7 6 2 (also known as Miller’s number) derives from psychol- ogy research, which shows that the number of information “chunks” that a per- son can remember and manipulate at one time varies between five and nine. A larger number of chunks causes information overload. Information chunks can be many things, including names, words in a list, digits, or components of a picture.

Some applications of the rule of 7 6 2 to DFDs include:

■ A single DFD should have no more than 7 6 2 processes. ■ No more than 7 6 2 data flows should enter or leave a process, data store,

or data element on a single DFD.

These rules are general guidelines, not unbreakable laws. DFDs that violate these rules may still be readable, but violations should be considered a warning of potential problems.

Minimization of interfaces is directly related to the rule of 7 6 2. An interface is a connection to some other part of a problem or description. As with information chunks, the number of connections that a person can remem- ber and manipulate is limited, so the number of connections should be kept to a minimum. Processes on a DFD represent chunks of business or processing logic. They are related to other processes, entities, and data stores by data flows. A single process with a large number of interfaces (data flows) may be too com- plex to understand. This complexity may show up directly on a process decom- position as a violation of the rule of 7 6 2. An analyst can usually correct the problem by dividing the process into two or more subprocesses, each of which should have fewer interfaces.

Pairs or groups of processes with a large number of data flows between them are another violation of the interface minimization rule. Such a condition usu- ally indicates a poor partitioning of processing tasks among the processes. The way to fix the problem is to reallocate the embedded tasks so fewer interfaces are required. The best division of work among processes is the simplest—and the simplest division is one that requires the fewest interfaces among processes.

❚ Ensuring Data Flow Consistency An analyst can often detect errors and omissions in a set of DFDs by looking for specific types of inconsistency. Three common and easily identifiable consis- tency errors are:

■ Differences in data flow content between a process and its process decomposition

■ Data outflows without corresponding data inflows ■ Data inflows without corresponding outflows

information overload difficulty in understanding that occurs when a reader receives too much information at one time

rule of 7 6 2 (Miller’s number) the rule of model design that limits the number of model components or connections among components to no more than nine

minimization of interfaces a principle of model design that seeks simplicity by limiting the number of connections among model components

17204_APPB_ptg01_019-052.indd 35 12/12/14 11:44 AM

OL-36 PART 2 ■ Systems Analysis Activities

A process decomposition shows the internal details of a higher-level process in a more detailed form. In most cases, the data content of flows to and from a pro- cess at one DFD level should be equivalent to the content of data flows to and from all processes in a decomposition. This equivalency is called balancing, and the higher-level DFD and the process decomposition DFD are said to be “in balance.”

Note the use of the term data content in the previous paragraph. Data flow names can vary among DFD levels for a number of reasons, including the decomposition of one combined data flow into several smaller flows. Thus, the analyst must be careful to look at the components of data flows, not just data flow names. For this reason, detailed analysis of balancing shouldn’t be under- taken until data flows have been fully defined.

Unbalanced DFDs may be acceptable when the imbalance is due to data flows that were ignored at the higher levels. For example, diagram 0 for a large system usually ignores details of error handling, such as when an item is ordered but is later determined to be out of stock and discontinued by its manufacturer. A process called Fulfill order in diagram 0 wouldn’t have any data flows associ- ated with this condition. In the process decomposition of Fulfill order, the ana- lyst might add a process and data flows to handle discontinued items.

Another type of DFD inconsistency can occur between the data inflows and outflows of a single process or data store. By definition, a process transforms data inflows into data outflows. In a logical DFD, data shouldn’t be needlessly passed into a process. The following consistency rules can be derived from these facts:

■ All data that flows into a process must flow out of the process or be used to generate data that flows out of the process.

■ All data that flows out of a process must have flowed into the process or have been generated from data that flowed into the process.

Figure B-16 shows an example that violates the first rule. Compare Figure B-16 with the first DFD fragment in Figure B-12, and note the differ- ence in the data inflows to the process. Looking up item availability requires only information to identify the item and access to corresponding data stores. In Figure B-16, excess data input (an entire order) flows into the process, and the process accesses more data stores than needed to generate the data outflow Item availability details. A process such as the one shown in Figure B-16 is sometimes called a black hole because some or all of the data that enters never leaves. A more obvious black hole example is any process with at least one data inflow but no data outflows.

Figure B-17 shows an example that violates the second rule. Compare Figure B-17 with the bottom DFD fragment in Figure B-7, and note the difference

balancing equivalence of data content between data flows entering and leaving a process and data flows entering and leaving a process decomposition DFD

black hole a process or data store with a data input that is never used to produce a data output

FIGURE B-16 A process with unnecessary data input—a black hole

Customer Check item

availability

1

Return item

Product item

Order transaction

Order item

Order

Catalog

New order

Item availability

details

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 36 12/12/14 11:44 AM

OL-37CHAPTER B ■ The Traditional Approach to Requirements

in the data inflows to the process. In Figure B-17, insufficient data enters the process to produce the data output. Required data inputs from the Offered course and Course enrollment are missing. A process such as the one shown in Figure B-17 is sometimes called a miracle because data emerges from the pro- cess without any apparent source.

Analysts sometimes can spot black holes and miracles simply by examining the DFD. In other cases, close examination of the data dictionary or process descriptions is required. In Figure B-18, data elements A, B, and C flow into the process but don’t flow out. Data element A is used to determine what for- mula to apply to recompute the value of X, so data element is a necessary input. However, data elements B and C play no role in generating process output and thus should be eliminated as unnecessary inflows.

In Figure B-19, data elements A, B, and Y flow out of the process. Data element A flows into the process. Data element Y is computed by an algorithm

miracle a process or data store with a data element that is created out of nothing

FIGURE B-17 A process with an impossible data output—a miracle

Faculty member

3

Produce class list

3

Student Class list

FIGURE B-18 A process with unnecessary data input

Compute X

Process description

If A>5 Then X=X*1.05 Else X=X*1.10 Endif

XA,B,C,X

FIGURE B-19 A process with an impossible data output

Compute Y A,B,YA

Process description

If A>5 Then Y=100 Else Y=250 Endif

© C

en ga

ge L

ea rn

in g®

© C

en ga

ge L

ea rn

in g®

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 37 12/12/14 11:44 AM

OL-38 PART 2 ■ Systems Analysis Activities

based on data element A. However, data element B doesn’t flow into the process and isn’t computed by internal processing logic. Thus, data element B indicates either an error in the data outflow (B should be eliminated) or an omission in the internal processing logic (the rule that determines B is missing).

Note that both consistency rules apply to data stores as well as processes. Any data element that is read from a data store must have been previously writ- ten to that data store. Similarly, any data element that is written to a data store must eventually be read from the data store. Examining the consistency of data flows to and from a data store is complicated by the fact that a data element may flow into and out of a data store on completely different DFDs.

Evaluating data flow consistency is a straightforward but tedious process. Fortunately, most analysis modeling tools automatically perform data flow con- sistency checking. But those tools place rigorous requirements on the analyst to precisely specify the internal logic of processes. Without precise process descrip- tions, it is impossible for the tool (or a human being) to know what data ele- ments are used as input or generated as output by internal processing logic.

■ Documentation of DFD Components Data flow diagrams graphically summarize interactions among three types of internal system components—processes, data flows, and data stores—but addi- tional details about each component need to be described. First, each lowest- level process needs to be described in detail. In addition, the analyst needs to define each data flow in terms of the data elements it contains. Data stores also need to be defined in terms of the data elements. Finally, the analyst also needs to define each data element.

■ Process Descriptions Each process on a DFD must be defined formally. There are several options for process definition, including one that has already been discussed: process decom- position. As discussed previously, in a process decomposition, a higher-level process is formally defined by a DFD that contains lower-level processes. These lower-level processes may in turn be further decomposed into even lower-level DFDs.

Eventually, a point is reached at which a process doesn’t need to be defined further by a DFD. This point occurs when a process becomes so simple that it can be described adequately by other methods: structured English, deci- sion tables, or decision trees. With each method, the process is described as an algorithm and an analyst chooses the most appropriate presentation format by determining which is most compact, readable, and unambiguous. In most cases, structured English is the preferred method.

Structured English uses brief statements to describe a process very carefully. Structured English looks a bit like programming statements but without references to computer concepts. Rules of structured programming are followed, and inden- tation is used for clarity. For example, a simple set of instructions for processing ballots after a vote is shown in Figure B-20. Some statements are simply instruc- tions. Other statements repeat instructions. Still other statements direct the pro- gram to execute one set of instructions or the other. The procedure always starts at the top and ends at the bottom. Therefore, the rules of structured programming apply. Note, though, that a process described by structured English isn’t necessar- ily a computer program—it might be done by a person—so it is a logical model. It is unambiguous, so anyone following the instructions will arrive at the same result.

An example of a process description for the RMO CSS is shown in Figure B-21. Note how the process description provides more specific details

structured English a method of writing process specifications that combines structured programming techniques with narrative English

17204_APPB_ptg01_019-052.indd 38 12/12/14 11:44 AM

OL-39CHAPTER B ■ The Traditional Approach to Requirements

about what the process does. If one process description method becomes too complex, the analyst should choose another. Excess length (for example, more than 20 lines) or multiple levels of indentation (indicating complex decision logic) indicate that a structured English description may be too complex. An analyst can sometimes address excess indentation by converting the descrip- tion to an equivalent decision table or decision tree. In other cases, a process decomposition may be required.

FIGURE B-20 A structured English example Process Ballots Procedure

Collect all ballots Place all ballots in a stack Set Yes count and No count to zero Repeat for each ballot in the stack If Yes is checked then Add one to Yes count Else Add one to No count Endif Place ballot on counted ballot stack Endrepeat If Yes count is greater than No count then Declare Yes the winner Else Declare No the winner Endif Store the counted ballot stack in a safe place End Process Ballots Procedure

FIGURE B-21 RMO CSS process 2.1 (Record customer information) and its structured English process description

Process 2.1 - Record Customer Information

Ask if customer has an account (or has made a previous order) If customer has an account then Ask for identification information Query database with identifying information Copy query response data to Order details Else Create an empty Customer record in the database Ask customer for Customer attributes Update empty Customer record with Customer attributes Endif Ask customer for order information for first item While more order items Do Update Order details with order information Endwhile

CustomerCustomer Record

customer information

2.1

Order details

New order

© C

en ga

ge L

ea rn

in g®

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 39 12/12/14 11:44 AM

OL-40 PART 2 ■ Systems Analysis Activities

Structured English is well suited to describing processes with many sequen- tial processing steps and relatively simple control logic (such as a single loop or an if-then-else statement). Structured English isn’t well suited for describing processes with the following characteristics:

■ Complex decision logic ■ Few (or no) sequential processing steps

Decision logic is complex when multiple decision variables and a large num- ber of possible combinations of those variables need to be considered. When a process with complex decision logic is described with structured English, the result is typically a long and difficult-to-read description. For example, con- sider the structured English description for calculating shipping costs shown in Figure B-22. Note that the description is relatively long and consists mostly of control structures (if, else, and endif statements).

Decision tables and decision trees can summarize complex decision logic more concisely than structured English. Figures B-23 and B-24 show a decision table and decision tree that represent the same logic as the structured

decision table a tabular representation of processing logic containing decision vari- ables, decision variable values, and actions or formulas

FIGURE B-22 A structured English process description for determining delivery charges

If YTD purchases > $250 then If number of items ordered < 4 then

If delivery date is next day then delivery charge is $25

Endif If delivery date is second day then

delivery charge is $10 Endif If delivery date is seventh day then

delivery charge is $1.50 per item Endif

Else If delivery date is next day then

delivery charge is $6 per item Endif If delivery date is second day then

delivery charge is $2.50 per item Endif If delivery date is seventh day then

delivery charge is zero (free) Endif

Endif Else

If number of items ordered < 4 then If delivery date is next day then

delivery charge is $35 Endif If delivery date is second day then

delivery charge is $15 Endif If delivery date is seventh day then

delivery charge is $10 Endif

Else If delivery date is next day then

delivery charge is $7.50 per item Endif If delivery date is second day then

delivery charge is $3.50 per item Endif If delivery date is seventh day then

delivery charge is $2.50 per item Endif

Endif Endif

decision tree a graphical description of process logic that uses lines organized like branches of a tree

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 40 12/12/14 11:44 AM

OL-41CHAPTER B ■ The Traditional Approach to Requirements

English example in Figure B-22. Both incorporate decision logic into the structure of the table or tree to make the descriptions more readable than their structured English equivalent. The decision table is more compact, but the decision tree is easier to read. Sometimes, an analyst needs to describe a process all three ways before deciding which approach describes a particular process best.

The following steps are used to construct a decision table:

1. Identify each decision variable and its allowable values (or value ranges). 2. Compute the number of decision variable combinations as the product of

the number of values (or value ranges) of each decision variable. 3. Construct a table with one more column than the number of decision vari-

able combinations computed in step 2 (the extra column is for decision variable names and process action or computation descriptions). The table should have a row for each decision variable and a row for each process action or computation.

FIGURE B-23 A decision table for calculating shipping charges

YES NO

7th2nd 7th2nd 7th2nd 7th2nd

Number of Items (N)

Delivery Day

Shipping Charge ($)

Next

N 3 N 4

25 10 N * 1.50

Next Next Next

N * 6.00 N * 2.50 Free 35 15 10 N * 7.50

N 4N 3

N * 3.50 N * 2.50

YTD Purchases > $250

FIGURE B-24 A decision tree for calculating shipping charges

Number of Items Purchased (N)

Delivery Day

Delivery Charge ($)

25

10

N 3 1.50

N 3 6.00

N 3 2.50

Free

35

15

10

N 3 7.50

N 3 3.50

N 3 2.50

Yes

No

Next 2nd

7th

Next 2nd

7th

Next 2nd

7th

Next 2nd

7th

3

4

3

4

YTD Purchases $250

© C

en ga

ge L

ea rn

in g®

© C

en ga

ge L

ea rn

in g®

17204_APPB_ptg01_019-052.indd 41 12/12/14 11:44 AM

OL-42 PART 2 ■ Systems Analysis Activities

4. Assign the decision variable with the fewest values (or value ranges) to the first row of the table. Put the decision variable name in the first column. Divide the remaining columns into sets of columns for each decision variable value (or value range).

5. Choose the next decision variable with the fewest values (or value ranges) for the second row. Put the variable’s name in the first column. Compute the number of column groups as the product of the number of values (or value ranges) of this variable and all the variables above it in the table. Divide the remaining columns into the computed number of groups, and insert values (or value ranges) in a regular pattern.

6. Continue inserting rows as instructed in step 5 until all decision variables have been included in the table.

7. Add a row for each calculation or action. For each calculation cell, insert the appropriate constant value or formula for the combination of decision variable values that appear above the cell in the same column. For each action cell, place a check mark in the cell if that action is performed when the decision variables have the values shown in the column above the cell.

Now let us follow these steps to show how the decision table in Figure B-23 was constructed. There are three decision variables: year to date (YTD) pur- chases, number of items ordered, and delivery day. YTD purchases has two relevant ranges: less than $250 and greater than or equal to $250. Note that decision variable ranges must be mutually exclusive and collectively exhaustive. Number of items ordered also has two relevant ranges: less than or equal to three and greater than or equal to four. Delivery day has three possible values: next day, second day, and seventh day. There are 2 3 2 3 3 5 12 combinations of values, so there are 13 columns in the table to allow for a decision variable name, the formula, and the action names.

YTD purchases and the number of items have two relevant value ranges, so either can occupy the first row. We chose YTD purchases. It has two value ranges, so we created two groups of 12 4 2 5 6 columns and labeled them for each possible value. The next row is for number of items. It has two ranges, so we need four groups of three columns—that is, 12 4 2 value ranges for the num- ber of items 4 2 value ranges for YTD purchases. We insert the value ranges for the number of items into the column groups in a regular pattern, as shown in the sample figure. The delivery day is now inserted into the table. Because it is the last decision variable, we don’t need to group any columns beneath it. We simply insert the values of the delivery date into individual columns in a regular pattern, as we did for the other decision variables.

The final step is to insert the row containing formulas and values for the shipping charges. Each cell contains a value or formula for the combination of decision variable values in the columns above. For example, shipping is free for customers with YTD purchases greater than $250, orders of more than three items, and seventh-day delivery. The shipping charge is $35 for custom- ers with YTD purchases less than $250, an order of three items or fewer, and next-day delivery.

If the decision table is used to represent a process that implements one or more actions—instead of value calculations, as in the previous example—then the table must contain a row for each action. Cells in these rows are check- marked to indicate which actions are performed under which conditions. Figure B-25 shows a simple example of this type of table. Two action rows are included, and the action is performed if a check mark appears in the cell imme- diately below the decision variable values. For example, if the customer is new and the shipment contains an item back-ordered for more than 25 days, then the shipment is expedited and the detailed return instructions are included in

17204_APPB_ptg01_019-052.indd 42 12/12/14 11:44 AM

OL-43CHAPTER B ■ The Traditional Approach to Requirements

the container. If the customer isn’t new and the order contains no items back- ordered for more than 25 days, then neither action is taken.