System Analysis: Case Study. System Analysis Overview It is one of the most important phases of the...

System Analysis: System Analysis: Case StudyCase Study

System Analysis OverviewSystem Analysis Overview• It is one of the most important phases of the whole system development. Generally,

the whole process consists of– System analysis (may include survey phase)– System design– System implementation (may include testing, coding, etc).

• During the analysis process, there are two phases:– Constructing Environmental model: It defines the interfaces between the system and the rest

of the environment, i.e., determine what is outside of the system. It consists of three components:

• Statement of purpose• Context diagram• Event list

– Constructing Behavioral model: It defines what the internal behavior of the system must be in order to deal successfully with the environment. The following tools are involved in this model:

• DFD• ERD• DD• PS• model consistency is the major issue when using the tools above together. This will be

discussed in detail later.

Case study: Case study: YOURDON Press Information System YOURDON Press Information System (YPIS) 1(YPIS) 1

• Statement of Purpose for YPIS:– Example statement of purpose: The purpose of the YOURDON

Press Information (YPIS) is to maintain information needed to sell books to customers. This includes order entry, invoicing, generation of shipping documents, inventory control, and production of royalty reports and accounting reports.

• Context Diagram of YPIS


• Event list: There are 40 event lists in this case. The following is some of them.– 1. Customer orders book (this includes special rush orders, too).– 2. Customer sends payment.– 3. Customer asks for book information (price,etc).– 4. Customer asks permission to return a book.– 5. Customer asks about status of a book order.– 6. Customer asks about status of an invoice.– 7. Customer needs (monthly) statement. (Temp)– 8. Customer asks for credit memo.– 9. Customer wants refund check.– 10. Printer offers quotation.– 11. Printer advises exact print quantity and delivery date.– 12. Printer sends invoice for print job.– ………..


• Drawing preliminary DFDs:– For each event list, build a DFD for every one of them. As there

are 40 event lists in this case, there are 40 diagrams.

• Note to the example DFDs:– To be consistent with the textbook, the notations in the following

DFDs should be standardized in several ways:• Double-headed flow is prohibited. It should be replaced with two

single-direction flow, representing input-flow and output-flow respectively.

• Data packets should be named explicitly for each data flow.


• Example of preliminary DFD for event 1,2,3. – Event 1: Customer orders book.


– Event 2: Customer sends payment

– Event 3: Customer asks for book information

Middle-out approach in behavioral Middle-out approach in behavioral model constructionmodel construction

• In contrast with a pure top-down and a pure bottom-up approach, this is a “middle-out” approach. After the initial DFD is developed (for each event, there is a DFD for it), some upward leveling is required, and some further downward partitioning may be necessary.

• Upward leveling of the preliminary DFD:– group related processes together into meaningful aggregates, each of

which will represent in bubble in a higher-level diagram.

– Look for opportunities to hide, or “bury”, stored data that appear at the lower level. Thus, if you see a group of processes in the preliminary DFD that refer to a common store, and no other processes in preliminary DFD refer to that store, then you can create a higher level bubble that hides the store. See figure on next page.

– When the processes identified in the preliminary DFD may not turn out to be primitive processes, downward partitioning into lower-level DFDs may be needed.

Upward leveling the DFDUpward leveling the DFD


• Figure 0: The top-level DFD transformed from all event DFDs. This DFD should be further upward leveled subsequently.

Case study: Case study: YOURDON Press Information System YOURDON Press Information System (YPIS) 7 Figure 1(YPIS) 7 Figure 1

Case study: Case study: YOURDON Press Information System YOURDON Press Information System (YPIS) 8 Figure 1.1(YPIS) 8 Figure 1.1

Case study: Case study: YOURDON Press Information System YOURDON Press Information System (YPIS) 10: The Entity-Relationship Diagram(YPIS) 10: The Entity-Relationship Diagram

PAYMENT

REFUND

RETURN-DETAIL

RETURN

ORDER-ITEM

CREDIT

ARCHIVE

CUSTOMER

PRINTER

WARE-HOUSE

Consists of

Consists of

Make for

Based on

Based on

Make for

place

Consists ofStore in

Write

print

Make for

Consists of

MONEY

ORDER

BOOK

AUTHOR INVENTORY

INVENTORY-ITEM

Store in Consits of


Note that the process specification is only neededfor bottom leave bubbles.

Balancing the models (1)Balancing the models (1)

• Balancing the model focus on model consistency. It is not only logically wrong but also dangerous. We will examine several major aspects of balancing:– Balancing the DFD against the DD (data dictionary)

– Balancing the DFD against the PS (process specifications).

– Balancing the process specifications against the DD.

– Balancing the ERD against the DFD and PS.

– Balancing the ERD against the DD.

Balancing the models (2)Balancing the models (2)• Balancing the DFD against the DD

– Every dataflow and every data store must be defined in the data dictionary.– Conversely, every data element and every data store defined in the data

dictionary must appear someplace on a DFD. – WinA&D support automatic check.

• Balancing the DFD against the PS– Every bubble in the DFD must be associated with a lower-level DFD or a

process specification, but not both. Process specification is needed for bottom-level bubble only.

– Every process specification must have an associated bottom-level bubble in the DFD.

– Inputs and outputs must match. The DFD will show incoming and outgoing flows for each bubble, as well as connections to stores. These should be evident in the process specification, too: thus, we should expect to see a READ statement (or GET, INPUT, etc) corresponding to each incoming dataflow and a WRITE (or PUT, etc) for each outgoing dataflow.


• Balancing the PS against DFD and DD– each data reference in the process specification (typically a noun)

must satisfy one of the following rules:• It matches the name of a dataflow or data store connected to the

bubble described by the PS, or

• It is a local term, explicitly defined the PS, or

• It appears as a component in a DD entry for a dataflow or data store connected to the bubble.

• Balancing the DD against the DFD and PS– DD is consistent with the rest of the model if it obeys the following

rule:• each entry in the data dictionary must be referenced by a PS, or a

DFD, or another DD entry


• Balancing the ERD against the DFD and PS– Every store on the DFD must correspond to an object type, or a

relationship, or a combination of an object type and relationship on the ERD. If there is a store on the DFD that does not appear on the ERD, something is wrong; and if there is an object or relationship on the ERD that does not appear on the DFD, something is wrong.

– Object names on the ERD and data store names on the DFD must match.

– The DD entries must apply to both the DFD model and the ERD model.

System Analysis: Case Study. System Analysis Overview It is one of the most important phases of the...

Documents

Transcript of System Analysis: Case Study. System Analysis Overview It is one of the most important phases of the...